From ecrit-bounces@ietf.org Sun Feb 1 02:07:11 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663C03A6944; Sun, 1 Feb 2009 02:07:11 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB803A6881 for ; Sun, 1 Feb 2009 02:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRE5zJr9z6vT for ; Sun, 1 Feb 2009 02:07:09 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8778B3A68B5 for ; Sun, 1 Feb 2009 02:07:08 -0800 (PST) Received: (qmail invoked by alias); 01 Feb 2009 10:06:47 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp011) with SMTP; 01 Feb 2009 11:06:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+SPlEMwraS4mUKl2tAdJkbsS0I+48k4WXeaybtLo hqZb2N16C2RgMM From: "Hannes Tschofenig" To: "'James M. Polk'" , "'Rosen, Brian'" , References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> Date: Sun, 1 Feb 2009 12:07:28 +0200 Message-ID: <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmD+QuDhnCYM7IsRtaRO6Qky5zzigAW27GA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, I agree with many of your statements. I also agree with the installed base that does not support this functionality. This almost sounds like the VoIP emergency story to me. I also agree with the location aspect. Also like in VoIP. Ciao Hannes >SWIW > >- email has no guarantee of delivery >- no guarantee of delivery to the right endpoint >- no guarantee of delivery to the an endpoint application that >won't filter said message into the wrong directory/folder >- had a HIGH likelihood of SPAM on the recepient's end >- SPAM could in general become the biggest issue wrt actually >having someone at the PSAP have to "look" at each and every >message because no one can build in the proper automated >filters to cover all possible misspellings of a legitimate >email message >- every email application will have to be revved to >incorporate location into some kind of user identifying >indication this is for sos (maybe this is merely having the >"urn:service:sos" in the To: >header). Many (most) users do not upgrade their mailers too >often (like their home routers)... so this upgrade path will >be an issue, because it likely cannot be universally expected >by the network to be in place. >- MTAs don't have the ability to understand where "I am" to >insert location, given the number of users that either > > -- use a generic application on any computer to >access their email, or > -- have a VPN > >for example, I use the same laptop with an out of date email >application (Eudora -- that's not supported anymore, and even >if it was -- which version do I have?). I'm connecting via a >VPN today from a suburb of Fort Worth through Cisco's >Richardson facility (which is a suburb of Dallas) through >Cisco San Jose (California). Last wee I was in Barcelona, >Spain. I used the same VPN server in Richardson to get to the >Cisco San Jose campus. The only thing that changed was my >origination point, one that cannot be tied to an IP address, >because any VPN that I use going through Richardson - which >gives my laptop one from its own address range. > >To make matters worse, I have access to 16 other VPN >connection points other than Richardson (in case I cannot get >through via Richardson). Some times these are accessed >automatically, sometimes I purposely connect to another Cisco >site than Richardson directly. > >How does Cisco understand where I am connecting from? > >I'm mostly focused on location URIs being inserted by a server >in the network thinking it knows where I am (i.e., what we >(use to?) call a "sighter" function). > > >At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: >>Hi Brian, >> >>we have already everything in place that would allow >emergency email to >>work. >> >>Here are the building blocks: >> >>* LoST >>* mails can obviously carry location as location is just another MIME >>type >>* mechanisms to obtain location >> >>LoST allows different elements to be returned. In the >examples we >>spoke about SIP related URIs (including tel URIs) and XMPP URIs. >>Obviously one can also put a mailto: URI in there. >> >>So, if the end point uses LoST to obtain the mailto: URI then >it could >>send the emergency email there. >> >>One important question is: Would email provider be interested in >>deploying this? I suspect "no". Hence, it is better not to mark the >>mail as an emergency email in the same way as we did the marking with >>the Service URN in SIP. Instead, the theme would be to mark it for >>those you care and if there is someone who does not care then >it still >>gets routed to the right place (rather than dropped on the >floor). The >>fear that a user could do fraud by marking emails as emergency emails >>is not really an issue for email at all. >> >>It might be possible to operate dedicated email providers only >>responsible for handling emergency email routing as many >email clients >>allow multiple accounts to be maintained quite transparently. >> >>The next important question is whether the PSAP operator >really want this. >>We all know that email does not really have a strong notion >of security. >>Even though there is DKIM standardized it isn't widely used. As such, >>there is essentially no cryptographic identity with email the PSAP >>operators get and email operators will not deploy new >security security >>mechanisms for this purpose either since the email operators will not >>like the emergency email concept as it adds new obligations >for them and no (monetary) benefit. >>PSAPs might receive a lot of fake emergency mails and it might make >>them difficult to figure out which onces are real. >> >>The final aspect is on location suitable for dispatch: While our >>protocols would support ways to fetch location by the PSAP operator >>from the access provider using, for example, the location by >reference >>concept we so far know that (despite initial indications of interest) >>operators rather prefer a model where they do not send >anything to the >>end host. Even though the location aspect is independent of >the actual >>application service (voice, IM, email, etc.) most operators would not >>see it that way. Hence, they would only hand out location to the PSAP >>if the regulator forces them (and sometimes not even then). This is >>more an procedural aspect than a technical one. >> >>Did you think about an opt-in variant or not? >> >>Ciao >>Hannes >> >>PS: I see James already writing an RPH extension for email :-) >> >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >Behalf Of Rosen, Brian >> >Sent: 31 January, 2009 01:21 >> >To: ecrit@ietf.org >> >Subject: [Ecrit] Does it make sense to email to urn:service:sos? >> > >> >The subject of emailing an emergency request comes up from time to >> >time. >> >So far, we've dismissed the idea primarily because email is not a >> >real time protocol. >> > >> >In the U.S., we have started working towards supporting SMS for >> >emergency use. The objection raised is "SMS is not a real time >> >protocol". >> > >> >My response to the SMS issue is "although it's certainly >true that it >> >isn't a real time protocol, and messages can be delayed by minutes, >> >hours, or even days, people use it as if it was real time, and deal >> >with the reality that it isn't. >> >Many users have an expectation that they should be able to text to >> >the emergency service". >> > >> >Is that not true, perhaps to somewhat less degree, for email? >> >Users are indeed less likely to treat email as real time, >but in fact >> >they often use it as if it was. >> > >> >Let us consider what it would take to allow email for emergency >> >services: >> >1. We would need a way to convey location in SMTP 2. We >would need a >> >way to mark an emergency email 3. We would need a way to route an >> >emergency email It goes without saying that a PSAP could >send a reply >> >email to the originator. >> > >> >2 and 3 could clearly be virtually identical to what we use >for calls: >> >"dial string" translation to urn:service:sos, LoST routing >to a URI, >> >regular email routing to that URI. 1 would require a new >feature in >> >SMTP. I'm not sure there is any analog to the "recognize the local >> >dial string, translate to the service urn, retarget to the >PSAP URI", >> >but it does seem like a straightforward thing for an email >server to >> >do. >> > >> >Does this make any sense? Is there a good reason NOT to do it? >> > >> >Brian >> > >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> > >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 1 02:12:27 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CBC3A6881; Sun, 1 Feb 2009 02:12:27 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840C73A67E2 for ; Sun, 1 Feb 2009 02:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdAYzZtTkhdh for ; Sun, 1 Feb 2009 02:12:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 32CB83A6881 for ; Sun, 1 Feb 2009 02:12:25 -0800 (PST) Received: (qmail invoked by alias); 01 Feb 2009 10:12:05 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp025) with SMTP; 01 Feb 2009 11:12:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/DLqlRmB/Dfj1fVxlCObig5301b+RhzuYv7+10P9 RxiZG+v+glUL5Y From: "Hannes Tschofenig" To: "'James M. Polk'" , "'ECRIT'" References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> Date: Sun, 1 Feb 2009 12:12:48 +0200 Message-ID: <046501c98455$a2dd0490$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmD+XY0zCF+yM80RReHzrKEERhetAAW3/5g X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hmmm. I hope that the Doodle guys got the timezone implemented right. Have not used it before. I have obviously used my timezone (Europe/Helsinki): Thu 26, 9:00 PM According to http://www.timeanddate.com/ this should translate to 2PM EST. It's also fine to have the meeting at 1pm EST but I wonder what others have read on the page. Ciao Hannes >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: 01 February, 2009 01:13 >To: Hannes Tschofenig; 'ext Hannes Tschofenig'; 'ECRIT' >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update > >At 03:59 PM 1/31/2009, Hannes Tschofenig wrote: >>Hi all, >> >>Based on the received feedback I have picked one of the >preferred dates: >> >> >>> 26th February, 2:00 PM EST <<< > >err... hate to point this one out, but no day at 2pm EST was an option. > >The options were 8am and 1pm (both EST) > >Please clarify this > > >>Ciao >>Hannes >> >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >Behalf Of ext Hannes Tschofenig >> >Sent: 25 January, 2009 10:46 >> >To: 'Hannes Tschofenig'; 'ECRIT' >> >Subject: [Ecrit] ECRIT Virtual Interim Meeting: Update >> >Importance: High >> > >> >Brian quickly spotted a conflict with the NENA TDC. Here is another >> >try: >> >http://www.doodle.com/4z4q2fr9mukxn876 >> > >> >Ciao >> >Hannes >> > >> >>-----Original Message----- >> >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >>Of Hannes Tschofenig >> >>Sent: 24 January, 2009 10:49 >> >>To: ECRIT >> >>Subject: [Ecrit] ECRIT Virtual Interim Meeting >> >> >> >>Hi all, >> >> >> >>to make some progress in ECRIT we would like to make a >proposal for >> >>a virtual interim meeting. The concept of virtual interim meetings >> >>is floating around in the IETF recently and we thought it is a >> >pretty good >> >>idea. Virtual interim meeting means that we are going to have a >> >>phone conference call for about ~2 hours to chat about >working group items. >> >> >> >>So, unless there are strong objections we suggest that ECRIT >> >holds such >> >>a meeting on the 18th February 2009, 10am EST for 2 hours. >> >> >> >>Proposed agenda: Discuss status and open issues of ECRIT >> >working group >> >>items >> >> >> >>We will send an update within the next week on the >technicalities of >> >>the call. >> >> >> >>Document authors, please resubmit your drafts by the 11th February. >> >> >> >>Ciao >> >>Hannes & Marc >> >> >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> > >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 1 04:52:55 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364293A6948; Sun, 1 Feb 2009 04:52:55 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D16528C148 for ; Sun, 1 Feb 2009 04:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njsU6n-ElQC9 for ; Sun, 1 Feb 2009 04:52:52 -0800 (PST) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id B2F513A6359 for ; Sun, 1 Feb 2009 04:52:51 -0800 (PST) Received: from c-69-255-80-200.hsd1.md.comcast.net ([69.255.80.200]:54690 helo=[192.168.1.120]) by portland.eukhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LTboG-0004CO-BC; Sun, 01 Feb 2009 12:52:24 +0000 Message-Id: <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> From: ken carlberg To: "Hannes Tschofenig" In-Reply-To: <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 1 Feb 2009 07:52:24 -0500 References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: "'Rosen, Brian'" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gentleman, This note probably goes a bit beyond what Brian first brought up, but there are other things to keep in mind... The fact that email runs over TCP and its adaptive algorithms helps diminish enthusiasm in augmenting email. But as Brian indirectly points out, its the buffer consumption at intermediate servers (ie, MTAs) where the bottleneck occurs. And keep in mind that large companies will generally have several MTAs needed to simply exit their stub domain. In my old company of 40k+ employees, we would receive email messages from admins every November asking that we don't send the dancing Santa video during December to decrease the chances of the outgoing MTA getting clogged. And while I also agree with a number of points brought up by James, its important to note that this is under the context of SMTP. X.400 has extensions that distinguish the importance of email in order to get past the MTA bottleneck problem. Now, before folks say that X.400 is really a blip in the overall installed based of email systems, I'll agree with you. Its deployment is mostly confined to organizations that must have prioritization of email -- eg, DoD, MoD, NATO. And NATO is of particular importance on this example because while it is a restricted federation from the perspective of the rest of the Internet, it still represents a collection of separate administrative domains, thereby escaping the counter argument that its purely a walled garden. (Note that the collection tier-1 ISPs is also a type of restricted federation in terms of participants). But the point is that X.400 has a market because it does something that is not standardized with SMTP during emergencies, or importantly, event- driven spikes of traffic load. So, if we go back to Brian's original point of "we want to mark emergency mail", I think a couple of questions to ask is in what form and to what degree of versatility do you want this marking? And is the form to be binary (eg, SoS in the URL), or is it to be something more along the lines of rfc-4412 and an additional header in the SMTP message? For your reading entertainment purposes only, you can look at an expired (and somewhat incomplete) draft-rfc on the subject at http://ftp.iasi.roedu.net/Docs/internet-drafts/draft-schmeing-smtp-priorities-05.txt cheers, -ken On Feb 1, 2009, at 5:07 AM, Hannes Tschofenig wrote: > Hi James, > > I agree with many of your statements. > > I also agree with the installed base that does not support this > functionality. This almost sounds like the VoIP emergency story to me. > > I also agree with the location aspect. Also like in VoIP. > > Ciao > Hannes > >> SWIW >> >> - email has no guarantee of delivery >> - no guarantee of delivery to the right endpoint >> - no guarantee of delivery to the an endpoint application that >> won't filter said message into the wrong directory/folder >> - had a HIGH likelihood of SPAM on the recepient's end >> - SPAM could in general become the biggest issue wrt actually >> having someone at the PSAP have to "look" at each and every >> message because no one can build in the proper automated >> filters to cover all possible misspellings of a legitimate >> email message >> - every email application will have to be revved to >> incorporate location into some kind of user identifying >> indication this is for sos (maybe this is merely having the >> "urn:service:sos" in the To: >> header). Many (most) users do not upgrade their mailers too >> often (like their home routers)... so this upgrade path will >> be an issue, because it likely cannot be universally expected >> by the network to be in place. >> - MTAs don't have the ability to understand where "I am" to >> insert location, given the number of users that either >> >> -- use a generic application on any computer to >> access their email, or >> -- have a VPN >> >> for example, I use the same laptop with an out of date email >> application (Eudora -- that's not supported anymore, and even >> if it was -- which version do I have?). I'm connecting via a >> VPN today from a suburb of Fort Worth through Cisco's >> Richardson facility (which is a suburb of Dallas) through >> Cisco San Jose (California). Last wee I was in Barcelona, >> Spain. I used the same VPN server in Richardson to get to the >> Cisco San Jose campus. The only thing that changed was my >> origination point, one that cannot be tied to an IP address, >> because any VPN that I use going through Richardson - which >> gives my laptop one from its own address range. >> >> To make matters worse, I have access to 16 other VPN >> connection points other than Richardson (in case I cannot get >> through via Richardson). Some times these are accessed >> automatically, sometimes I purposely connect to another Cisco >> site than Richardson directly. >> >> How does Cisco understand where I am connecting from? >> >> I'm mostly focused on location URIs being inserted by a server >> in the network thinking it knows where I am (i.e., what we >> (use to?) call a "sighter" function). >> >> >> At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: >>> Hi Brian, >>> >>> we have already everything in place that would allow >> emergency email to >>> work. >>> >>> Here are the building blocks: >>> >>> * LoST >>> * mails can obviously carry location as location is just another >>> MIME >>> type >>> * mechanisms to obtain location >>> >>> LoST allows different elements to be returned. In the >> examples we >>> spoke about SIP related URIs (including tel URIs) and XMPP URIs. >>> Obviously one can also put a mailto: URI in there. >>> >>> So, if the end point uses LoST to obtain the mailto: URI then >> it could >>> send the emergency email there. >>> >>> One important question is: Would email provider be interested in >>> deploying this? I suspect "no". Hence, it is better not to mark the >>> mail as an emergency email in the same way as we did the marking >>> with >>> the Service URN in SIP. Instead, the theme would be to mark it for >>> those you care and if there is someone who does not care then >> it still >>> gets routed to the right place (rather than dropped on the >> floor). The >>> fear that a user could do fraud by marking emails as emergency >>> emails >>> is not really an issue for email at all. >>> >>> It might be possible to operate dedicated email providers only >>> responsible for handling emergency email routing as many >> email clients >>> allow multiple accounts to be maintained quite transparently. >>> >>> The next important question is whether the PSAP operator >> really want this. >>> We all know that email does not really have a strong notion >> of security. >>> Even though there is DKIM standardized it isn't widely used. As >>> such, >>> there is essentially no cryptographic identity with email the PSAP >>> operators get and email operators will not deploy new >> security security >>> mechanisms for this purpose either since the email operators will >>> not >>> like the emergency email concept as it adds new obligations >> for them and no (monetary) benefit. >>> PSAPs might receive a lot of fake emergency mails and it might make >>> them difficult to figure out which onces are real. >>> >>> The final aspect is on location suitable for dispatch: While our >>> protocols would support ways to fetch location by the PSAP operator >>> from the access provider using, for example, the location by >> reference >>> concept we so far know that (despite initial indications of >>> interest) >>> operators rather prefer a model where they do not send >> anything to the >>> end host. Even though the location aspect is independent of >> the actual >>> application service (voice, IM, email, etc.) most operators would >>> not >>> see it that way. Hence, they would only hand out location to the >>> PSAP >>> if the regulator forces them (and sometimes not even then). This is >>> more an procedural aspect than a technical one. >>> >>> Did you think about an opt-in variant or not? >>> >>> Ciao >>> Hannes >>> >>> PS: I see James already writing an RPH extension for email :-) >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Rosen, Brian >>>> Sent: 31 January, 2009 01:21 >>>> To: ecrit@ietf.org >>>> Subject: [Ecrit] Does it make sense to email to urn:service:sos? >>>> >>>> The subject of emailing an emergency request comes up from time to >>>> time. >>>> So far, we've dismissed the idea primarily because email is not a >>>> real time protocol. >>>> >>>> In the U.S., we have started working towards supporting SMS for >>>> emergency use. The objection raised is "SMS is not a real time >>>> protocol". >>>> >>>> My response to the SMS issue is "although it's certainly >> true that it >>>> isn't a real time protocol, and messages can be delayed by minutes, >>>> hours, or even days, people use it as if it was real time, and deal >>>> with the reality that it isn't. >>>> Many users have an expectation that they should be able to text to >>>> the emergency service". >>>> >>>> Is that not true, perhaps to somewhat less degree, for email? >>>> Users are indeed less likely to treat email as real time, >> but in fact >>>> they often use it as if it was. >>>> >>>> Let us consider what it would take to allow email for emergency >>>> services: >>>> 1. We would need a way to convey location in SMTP 2. We >> would need a >>>> way to mark an emergency email 3. We would need a way to route an >>>> emergency email It goes without saying that a PSAP could >> send a reply >>>> email to the originator. >>>> >>>> 2 and 3 could clearly be virtually identical to what we use >> for calls: >>>> "dial string" translation to urn:service:sos, LoST routing >> to a URI, >>>> regular email routing to that URI. 1 would require a new >> feature in >>>> SMTP. I'm not sure there is any analog to the "recognize the local >>>> dial string, translate to the service urn, retarget to the >> PSAP URI", >>>> but it does seem like a straightforward thing for an email >> server to >>>> do. >>>> >>>> Does this make any sense? Is there a good reason NOT to do it? >>>> >>>> Brian >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 1 06:25:56 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6C328C11E; Sun, 1 Feb 2009 06:25:56 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BE728C11E for ; Sun, 1 Feb 2009 06:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfJJ+Eaa6Iwb for ; Sun, 1 Feb 2009 06:25:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AB1F83A6359 for ; Sun, 1 Feb 2009 06:25:51 -0800 (PST) Received: (qmail invoked by alias); 01 Feb 2009 14:25:30 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 01 Feb 2009 15:25:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/cIqhGAUrcKr5cOVPPMCBMlROtIN0dQdQrt4KPiI Q/dUJbE/etai6W From: "Hannes Tschofenig" To: "'ken carlberg'" References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> Date: Sun, 1 Feb 2009 16:26:13 +0200 Message-ID: <046f01c98479$09d086e0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> Thread-Index: AcmEa/Vi/f9sGp47Tsa3lFslwUpQTAACsrgA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: "'Rosen, Brian'" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org To Brian: Are you thinking about an opt-in solution or not? To Ken: "form to be binary (eg, SoS in the URL), or is it to be something more along the lines of rfc-4412" The marking Brian mentioned is from http://www.ietf.org/rfc/rfc5031.txt. I wouldn't call it binary given that it allows to express different types of emergencies. Ciao Hannes >-----Original Message----- >From: ken carlberg [mailto:carlberg@g11.org.uk] >Sent: 01 February, 2009 14:52 >To: Hannes Tschofenig >Cc: 'James M. Polk'; 'Rosen, Brian'; ecrit@ietf.org >Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > >Gentleman, > >This note probably goes a bit beyond what Brian first brought >up, but there are other things to keep in mind... > >The fact that email runs over TCP and its adaptive algorithms >helps diminish enthusiasm in augmenting email. But as Brian >indirectly points out, its the buffer consumption at >intermediate servers (ie, >MTAs) where the bottleneck occurs. And keep in mind that >large companies will generally have several MTAs needed to >simply exit their stub domain. In my old company of 40k+ >employees, we would receive email messages from admins every >November asking that we don't send the dancing Santa video >during December to decrease the chances of the outgoing MTA >getting clogged. > >And while I also agree with a number of points brought up by >James, its important to note that this is under the context of >SMTP. X.400 has extensions that distinguish the importance of >email in order to get past the MTA bottleneck problem. Now, >before folks say that X.400 is really a blip in the overall >installed based of email systems, I'll agree with you. Its >deployment is mostly confined to organizations that must have >prioritization of email -- eg, DoD, MoD, NATO. And NATO is of >particular importance on this example because while it is a >restricted federation from the perspective of the rest of the >Internet, it still represents a collection of separate >administrative domains, thereby escaping the counter argument >that its purely a walled garden. (Note that the collection >tier-1 ISPs is also a type of restricted federation in terms >of participants). But the point is that X.400 has a market >because it does something that is not standardized with SMTP >during emergencies, or importantly, event- driven spikes of >traffic load. > >So, if we go back to Brian's original point of "we want to >mark emergency mail", I think a couple of questions to ask is >in what form and to what degree of versatility do you want >this marking? And is the form to be binary (eg, SoS in the >URL), or is it to be something more along the lines of >rfc-4412 and an additional header in the SMTP message? > >For your reading entertainment purposes only, you can look at >an expired (and somewhat incomplete) draft-rfc on the subject >at >http://ftp.iasi.roedu.net/Docs/internet-drafts/draft-schmeing-s >mtp-priorities-05.txt > >cheers, > >-ken > > >On Feb 1, 2009, at 5:07 AM, Hannes Tschofenig wrote: > >> Hi James, >> >> I agree with many of your statements. >> >> I also agree with the installed base that does not support this >> functionality. This almost sounds like the VoIP emergency >story to me. >> >> I also agree with the location aspect. Also like in VoIP. >> >> Ciao >> Hannes >> >>> SWIW >>> >>> - email has no guarantee of delivery >>> - no guarantee of delivery to the right endpoint >>> - no guarantee of delivery to the an endpoint application >that won't >>> filter said message into the wrong directory/folder >>> - had a HIGH likelihood of SPAM on the recepient's end >>> - SPAM could in general become the biggest issue wrt >actually having >>> someone at the PSAP have to "look" at each and every >message because >>> no one can build in the proper automated filters to cover all >>> possible misspellings of a legitimate email message >>> - every email application will have to be revved to incorporate >>> location into some kind of user identifying indication this is for >>> sos (maybe this is merely having the "urn:service:sos" in the To: >>> header). Many (most) users do not upgrade their mailers too often >>> (like their home routers)... so this upgrade path will be an issue, >>> because it likely cannot be universally expected by the >network to be >>> in place. >>> - MTAs don't have the ability to understand where "I am" to insert >>> location, given the number of users that either >>> >>> -- use a generic application on any computer to access their >>> email, or >>> -- have a VPN >>> >>> for example, I use the same laptop with an out of date email >>> application (Eudora -- that's not supported anymore, and even if it >>> was -- which version do I have?). I'm connecting via a VPN >today from >>> a suburb of Fort Worth through Cisco's Richardson facility >(which is >>> a suburb of Dallas) through Cisco San Jose (California). >Last wee I >>> was in Barcelona, Spain. I used the same VPN server in >Richardson to >>> get to the Cisco San Jose campus. The only thing that >changed was my >>> origination point, one that cannot be tied to an IP >address, because >>> any VPN that I use going through Richardson - which gives my laptop >>> one from its own address range. >>> >>> To make matters worse, I have access to 16 other VPN connection >>> points other than Richardson (in case I cannot get through via >>> Richardson). Some times these are accessed automatically, >sometimes >>> I purposely connect to another Cisco site than Richardson directly. >>> >>> How does Cisco understand where I am connecting from? >>> >>> I'm mostly focused on location URIs being inserted by a >server in the >>> network thinking it knows where I am (i.e., what we (use >to?) call a >>> "sighter" function). >>> >>> >>> At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: >>>> Hi Brian, >>>> >>>> we have already everything in place that would allow >>> emergency email to >>>> work. >>>> >>>> Here are the building blocks: >>>> >>>> * LoST >>>> * mails can obviously carry location as location is just another >>>> MIME type >>>> * mechanisms to obtain location >>>> >>>> LoST allows different elements to be returned. In the >>> examples we >>>> spoke about SIP related URIs (including tel URIs) and XMPP URIs. >>>> Obviously one can also put a mailto: URI in there. >>>> >>>> So, if the end point uses LoST to obtain the mailto: URI then >>> it could >>>> send the emergency email there. >>>> >>>> One important question is: Would email provider be interested in >>>> deploying this? I suspect "no". Hence, it is better not to >mark the >>>> mail as an emergency email in the same way as we did the marking >>>> with the Service URN in SIP. Instead, the theme would be >to mark it >>>> for those you care and if there is someone who does not care then >>> it still >>>> gets routed to the right place (rather than dropped on the >>> floor). The >>>> fear that a user could do fraud by marking emails as emergency >>>> emails is not really an issue for email at all. >>>> >>>> It might be possible to operate dedicated email providers only >>>> responsible for handling emergency email routing as many >>> email clients >>>> allow multiple accounts to be maintained quite transparently. >>>> >>>> The next important question is whether the PSAP operator >>> really want this. >>>> We all know that email does not really have a strong notion >>> of security. >>>> Even though there is DKIM standardized it isn't widely used. As >>>> such, there is essentially no cryptographic identity with >email the >>>> PSAP operators get and email operators will not deploy new >>> security security >>>> mechanisms for this purpose either since the email operators will >>>> not like the emergency email concept as it adds new obligations >>> for them and no (monetary) benefit. >>>> PSAPs might receive a lot of fake emergency mails and it >might make >>>> them difficult to figure out which onces are real. >>>> >>>> The final aspect is on location suitable for dispatch: While our >>>> protocols would support ways to fetch location by the PSAP >operator >>>> from the access provider using, for example, the location by >>> reference >>>> concept we so far know that (despite initial indications of >>>> interest) >>>> operators rather prefer a model where they do not send >>> anything to the >>>> end host. Even though the location aspect is independent of >>> the actual >>>> application service (voice, IM, email, etc.) most operators would >>>> not see it that way. Hence, they would only hand out >location to the >>>> PSAP if the regulator forces them (and sometimes not even then). >>>> This is more an procedural aspect than a technical one. >>>> >>>> Did you think about an opt-in variant or not? >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I see James already writing an RPH extension for email :-) >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf Of Rosen, Brian >>>>> Sent: 31 January, 2009 01:21 >>>>> To: ecrit@ietf.org >>>>> Subject: [Ecrit] Does it make sense to email to urn:service:sos? >>>>> >>>>> The subject of emailing an emergency request comes up >from time to >>>>> time. >>>>> So far, we've dismissed the idea primarily because email is not a >>>>> real time protocol. >>>>> >>>>> In the U.S., we have started working towards supporting SMS for >>>>> emergency use. The objection raised is "SMS is not a real time >>>>> protocol". >>>>> >>>>> My response to the SMS issue is "although it's certainly >>> true that it >>>>> isn't a real time protocol, and messages can be delayed >by minutes, >>>>> hours, or even days, people use it as if it was real >time, and deal >>>>> with the reality that it isn't. >>>>> Many users have an expectation that they should be able >to text to >>>>> the emergency service". >>>>> >>>>> Is that not true, perhaps to somewhat less degree, for email? >>>>> Users are indeed less likely to treat email as real time, >>> but in fact >>>>> they often use it as if it was. >>>>> >>>>> Let us consider what it would take to allow email for emergency >>>>> services: >>>>> 1. We would need a way to convey location in SMTP 2. We >>> would need a >>>>> way to mark an emergency email 3. We would need a way to route an >>>>> emergency email It goes without saying that a PSAP could >>> send a reply >>>>> email to the originator. >>>>> >>>>> 2 and 3 could clearly be virtually identical to what we use >>> for calls: >>>>> "dial string" translation to urn:service:sos, LoST routing >>> to a URI, >>>>> regular email routing to that URI. 1 would require a new >>> feature in >>>>> SMTP. I'm not sure there is any analog to the "recognize >the local >>>>> dial string, translate to the service urn, retarget to the >>> PSAP URI", >>>>> but it does seem like a straightforward thing for an email >>> server to >>>>> do. >>>>> >>>>> Does this make any sense? Is there a good reason NOT to do it? >>>>> >>>>> Brian >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 03:04:56 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8963D3A69C2; Mon, 2 Feb 2009 03:04:56 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57AE3A69C2 for ; Mon, 2 Feb 2009 03:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT3Kvl-UrxMW for ; Mon, 2 Feb 2009 03:03:14 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1626B28C17A for ; Mon, 2 Feb 2009 03:02:33 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n12B2CZb013042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Feb 2009 12:02:12 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n12B2A8R007690; Mon, 2 Feb 2009 12:02:11 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 12:02:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C98525.B16F76B8" Date: Mon, 2 Feb 2009 13:02:52 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FFF227@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments to Phone BCP Thread-Index: AcmFJcsVTmxjy0HdTnSv5Rj8gvNhdQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Feb 2009 11:02:10.0175 (UTC) FILETIME=[B1E6D8F0:01C98525] X-Mailman-Approved-At: Mon, 02 Feb 2009 03:04:55 -0800 Cc: Nils Weidstam , Steinar Hidle Andresen Subject: [Ecrit] Comments to Phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C98525.B16F76B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI,=20 Let me forward the comments from Nils and Steinar.=20 Ciao Ha <> nnes ------_=_NextPart_001_01C98525.B16F76B8 Content-Type: application/octet-stream; name="draft-ietf-ecrit-phonebcp-06 SAb.pdf" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ecrit-phonebcp-06 SAb.pdf Content-Disposition: attachment; filename="draft-ietf-ecrit-phonebcp-06 SAb.pdf" JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNnXuX48SVwP/3pxBte3GLbo0epReLF9rDsJvuadjMTAKE TrJhAifZA+wJkz379fd3S7ckS+2WS5pxQ3MY2XqUbt33q8r/CH4b/COog6Suo9qUaWDyOEqqwgRF VkZxnpbBz98FXwY/BU+evkmC12+C2P735jWPyZ1JEcfNqe5bVkRFnCVVUMUmqvKiWrz+Mdi9CvLm Rj28+jF48lkSJUESvPo+2Lx3tlytV8vz4NV/B89eAdYxwBbTASuyKCuzNGsBCyxgi1HA/sUfJHC1 mIirooiyqorLAUh9XC0GuHp/fbe5O5+Aq30iLvyIWBWRifMynwRYOAlX+3y18OCrJC+iuKjHQQpe /bjY56sPLlbry9VZ9CSM7zZJEqaZOVuFeZz6gzqD09IijrIirgfYG+e0adibymlZgkDHWToAaZzT ClOuLqrVOqw//PBf/TE2QxCyso6qFA3klEYjm+PgTcPYVH5r9Vhq4sgYcwiiIbt9ZLars/DfwtQk H0/ClwC3mKBkqzKqY5MFI7AN1cZpsZUUZVSVWT0G0RBbH3xytVuvtuHTu82T8NNnobDZZ/5omyOY poryvMjHoHxcvGVZHKV5PQlv/57ebS5XYfP3H/4Is3ZgMdGY11GSxm/DaFmeRnmFaKdpHZVpXQR5 FFemiqsgqaLMJMUM+9QNmtVRnhWHhHNIyN/0MdUN8U7hKqMiMZDTH67TCmarxkpUrMnSSlGF8hCj qwdrNtMoVncs6KNqooeINffzEMsyjkro3ziIQ4hwEIFo0TiIbwcRE33zeuHhs5ZFElVJOQ5SkCzE Zx2AlPEkDnHnTCd1jhPFmVFneuGJKjQXRjJVXBWFpZ4erIOYRUmDq29wp8+DyzzYnHEwwQZXUb6t mm/r8+CPwavrzs0+DvgMTYuzHVdFngZlD/DFAcDNQ2yXpkVUZpUZQekMyIgBGDVNPCBr4xNQmoO9 Mthcc0iDDTIrh484FMHGcADBWw6ge3W+UOT38ewxnX1NaMMt6xiPcohBicZ1Ug6mEwwRjVv8oHwf 54B9wDxDiE7xZCZKk9aB6gE20NHKulnDumBWWNei1CIY1pVvwtZcE34G69wieF60YeO02XhGtSjP OM8wNKXORqPa3mxwcHpR7SB4PA7YDHauELQyQ8s4wBoNcUjQ9tn5/QaHitG7TYPLu3OOYF9xanXE QkLx46Dvc4gnTpMYh6DITAv6wzh9kHU9hGoGUrOyiNKsmorUAuyhI5QxbxoUP29Qq5zsML0+X7y9 drA2YNSwddphRAgbtrUo/gUMWxpHscErbJyAw/LUM2wPaQdVC7cNvpUI+k319RbVrAaRg6OFkkbp pVr8c4bpFP0hIi6cItJ3uOFUpvSsDqcAfNHwxEDsogYsQsY+T8ySumPeVxoTqRVEHOVRzD/ofnlI 3T19cNyUIXBRWqMOjgKGJmtZ4j9BKSzRN8zkd/YMc9Lccg+/HtOYoTw6mevN45BGflCtHaf8DMA6 ixzn+KpGQ4FDgO2big8aXH7CAXN71XzbNShVRlZhU/Hqi85T7qw7YXvSDKPy8Ol0lp8x8SRJo9IQ +pSTJv4MUDsVUDeAf9g7kK54BOcD5ykqY6yRgv/rsZMmj/A8e1jte573Hby4QaAykKrHiJNoZHWk lTlU6SrH9HW3ctwFz1XW8+5rzlNLdm/GhwToQck+EktPzuu6aktRp1HRRvc9M9rQYC5Ek/OmhqJG mudBUaFFJPFzuP7Ty9O3mebfzss8+MYkNcFmQf5vDLYBy26eTU9/tzjzhMuajKyqJ8GFlPhWywbG 2Jpi3yRNUVDGI3GkZBxmacbiyiO83mJJ44VjngvVsrwuszIo8iRK0xakHrM3zmy+5yDsJUP6ESVe g9gvVDyBmrgLEhRh4qwj5/xDjme4Z1y1wRGXRfV0j4qukosSQXGvGEvuEb3U3XrJN95iT7Zeo75a NZ8qOTdMHy69KJoTS6qH95s0g4Nq/x0tGAqqXnPvkCAP4NTtta9abMRHsnPtTUf8KG7tD66O9v7z 7S2AY7MfOgG9RxGbNaPpwYGjmOuj1V5cbMBOX7FPZCmb+BsrVldkT4zpWOph0wpLaXaUufkK3hxn BbWZZzUgpRVeGsX4pkx9mMsbkMibqOlU5lASOXaS5BVkdGeVRsqkErVC+T7LKR+XXINz9aBs4FiO UfvOzzsmTkqmLokp2DtMzCIO1bs8i+M0yAnqJeypqW2X9wjDpZQSc01fQ53mpuaB7hMZuLTK6ZEI aG2IUlu7SKldVFUaJOKb1XktI35/tG9hoIltBH9EE0vh26QlxiFGARIqe6ABhqgamjsWUIKqukHY Tko6WkNIoKSCL2+YN3jYJ5UrE9V0W7Qg+cmV8ryKjiqpSWrpHqtp2mZELaUx3hrsNQXWKeiDC6c6 mikub2kShFEpqv5ATy01rlOrKeFCxZuqGseMilTlwq4UMaZA5qARDUoqbwjzIX+9hfnUaMygLJ0O E9GoJlODT2c51ZArjunQECWvqOaJk0p4WqVIuLj5vxoJb1R02kKkHEp+Mc7pU+Nv8ep1PzxtvUU1 7R8Rj6KD4oAb24LCu+bKupJ6yBDOca6853McNmvWvLgS/9OXYsLiHCtl+JSRW0voy+s+vXx6Twdd do18tC9lpdiaRBoBkxTVaT/n8rkIfgheWmvXPSD15OHzQgOez6N8wVOljhDJGPRHTRuDZ5K4GaFk NNrmpjxP7bSdA4a8m8O9uvDhOdSZhVrnoN+859Dg0b5X52DhaedwrN9x32/wDCrbdB/dFxGEP9jB NAx2HymozInl6MVzIPWMCDJJUEmzX+vbvkSzEWP9kwOB11+mxAQzrEae4W7BHkEfyEPyuQ+kQve/ DaxvOOBU0yMgIP8PB1Tz9823gBCJk/rA3zjJ5P7eXOs/d8tJIr7vODDYjxxIdjHYXkwE947pp32+ 8S3L0bpSGTjbzf9hf7Od/7AZYgykGSTpWNmUUS49RE1MNNq6G+ZPwu1NdbFbLndnl+Ey221D22d8 duJG48QQI+RlGeQToB3UiscQOMN7S0jK0V5J71UPpPH+Sm00fhau7jZRFt5tbpaZWYfr1RVde6uz 5Rac3m2WXDh7wj9XV8kuuttUySq84jQ3hNxtlhkNpO+lH4XnC1/vfgbTdhzCpwqLo0w7yiFRcrfZ XWxDc3cevsh2zDFbCcxbDjDL3ebF3Wa9CplkuQqrFa2dXHyxo4+4WoW3u22U0O95+0wQcNtg4dBI jzRvmmWSOPbqtq9Wkbmg8dJN8MCUdmdcjSKzvmVyES0tJ6RdSp2M5sAsyCfMAToss/D5KlruzFn4 0tKQvu7w08+u98LId68dWdlAhx92exKweyDhco0J91tpR0q7taGx0kc7PooqpMHPmDjDlk4A7bSq kKSSyfOUfFAPJC9VKCKDQnhh1h+LSbk10c2FVYQi9yi61r6EH5xd7s5Wq7Xc9sXdZvtx+Mqso1X4 u/c++OLV75+FO7SnjMWlZ4+kGU1dImaF8dGMVqMJjG6ql2tzc7W9DsPCLFeq9xvV3lwJL6SJmzUW WyOacbneVTfc6B7vMMWEH2u+tBMUdebSZaOW4FGEoahEGEgZGoXMR05PLAyJCENRDkAaF4ZQHYPt vqY9otbUpE9Z48CitDQr8mIabP6aduBlTCqKGWhJA3lDwD62mvClbaDYtDphHmSewV6raEcgG8Z6 01hrv1rng6tWz45ANMSVY6xGzd7ahW7+aJthOhN6/+sir4IRIIdoW+7p/RKNt8P3O8cxvNuIEvxk d3FzYb2R7e6T8MKcLTPR9DiIVkPiON5c4VMtxW88qVfVesQmp+Erqb08Ynx7fOJIgBPfvdqaZAWo YfVEHfl9Ra6e/3J3scIwvLcUn3l3JoHA2lytdzLJcGnCm21nF087Y1KSrLpDmU2Y8QQhmMFfGVWj IjV5C5KPym+l4KSs3/EHIWESt91go3ZSrDdOyzmLdYkKhKVZtwulE2EXaB3trHewQgJs3CcBokQS 2/BLcQVgjxDmuCR+3F5/eVpmwLtLCzIFVHft9HzcngnZrznM4Hp1aEXDT/fDePgFbmWCR2V1SnSz BvMn5QtYIarLKgmmQLmcYeVmYDAxssiGzMoU2CZI+KzMCuiKyaz0Qer7BEMT0ko4+ZIzSSZIrI1M oGmRqDBbLq8+/+qrFy9eXO9Wy7vza7O+/Mp++uo3u9vTik1OmU+aDtx0fMRmAoZnED3L6YOIqTw6 kHx0KHkoghDQutxeLz9ZTvBUZ0CIUy97HtSTIJyga2awZafdE9bYtb2+42zZ1zWPEhMlAh41qsD0 4BxfKj+B32agLkky+C1HBHogjaNOJTp8jsG7NS/C91nZHC3Nekea7bCQt0rcLrAZSwkNAhWfnpGO /DHlzzL2CvoPqp1tM6HrbHmRWCnqFlq9Y5iTkp6RosbwTIB5ghTNEOwWjRn9LDWW0Uf1IEWPVWmo CJFZzp4HU+A7rfTQhpyWCbqwD5Kf9NhE9MpuCxCS1W1F5Ghb1QzaJoXkF0wyAHRc8zRbFZwWLmnk LgkZ+ggch8v2KPcy30fyMTMQlpL5zllqOgmwCTScoao7+WS9MVsNucXtvRhm6HxNA2lq2qMDyUDH zvAeKXHLshqWDn7LgWKwVoG1QvxzU/6l7i1F5NfNN65pFRj7MaV7wLMKjMIrcgr0mU5D/cDhNFjv +uhFYPZwimo/UkvwJBn3JgNDTHpa0aVHLqXPwh9ASqPbpWSHqAXcUohcX/Jl9zVBgFS1msIj4bbk l6Tcyl2XNh8jUUL34O5rKTOQi1rvzI1km7ZXOB+PlWfP8JdS8rQ+kYLUSWyGSQBetZsz4SElCdM/ o1AcUp6XXIEUG6wlvVhdUFNYbSNqCnhT/L8Mmzh4STJBXPwdqQhBF37XaYMjF8Bn9Geyh4BXsfV2 VQIfVR43r4YXt6u1PU+x2dwktzZLtr2hBN2RFYIbSbF8vLqHquvTzjOvaW5G1KfMc4JanWF8WrWK fEVZnWjqfdwq/u7p85PKO8tQyJSwbGcKUKd1v3KyETVbXAxAGne//vDNR++H5Wq9FaVDqvf5dXh3 d3ZruzyeSTMHuw1tsx2bzpHQ3i6TJ+QA0UUUOG+vf39STkylj1w233IY9lEy9zjxcK+k48Jv6DNL MKZx8Ndmn8N31TfJDgIZfYZZTs9iKpub2f5D/55FnpHn6d7LF9JFSYdE8037Htv9wo6tXcipxaRZ kgRFQjc+HdEMd+8cg7LhX5QJ87j7OMO2cXZ9DMscKtTB/hl0YEpgee+Ux4m9hwxBDNG2CX5YtG+T AmltqJS2EBkS6Wx2RiOBm0t75jUpXuAWV8udW/zAOeZMJqs9xxkW1pRojnb0vTMKg4yldxWyaJj5 yVDtKUVCO3iLqBaE9sweWO7c4v5d98+8Dv7GOpI0+L/gm4Ynh9sWDdtTRSQy6UihPdbAat3nH/gs TjvOkr2WSVdjwso59iVKuWa/wZ6vu8+L7mz3yV2v2WZExpTn6hS2ZODuDagdvgkc8un1AnLBsPL5 B9kOi0ozL7XfEQz5pCPoN8ZmlY29IiIjz8hdCu2iG0Fm2Ywtn3jGvqd/tjsn6JRG5bYTetH1P3ef WODTUZnKARWkAlR25xpmAKq9Uw0zQFTlNEdm7lF+bM8cYIb7dx1gD5GTgewCQysV7fit5LD5mJXT TpaUj0FUd5Ob4f50unPNKiaZRJxCFRGqko1coQW8VArxZdO6uEydBnWKSPRo4vb+iuu4rPlr0lXs UaRf23Ep1VGXdG3JCzYblQZyPdiddNA9jCd7bb3853d//+kvPwdXP/315+/efPdTZ9ZFOtqx7Tai 3dd7r1Lr0b0qZ1+fXDrb6fiXvXuqdpEfq0Zdy9u7fUU3qYCOvYTVIODzw9R075NozjJVrM0POUor YeFIKlW6JAFteNvTN8DFjtLYG7DboLCI671GPgVtzaGJlVGGDd5ZwPOUcJOOddvCTCuy9CCTim+P 0ppMTzIEkUZlCVgJUWWZSraQnuC9RmWfST2U6bzXot8tOsBKoFjYRGhsWg1xbU+G7HDDtP7YwC3r uYi3Ze0jcMtmBBx2HGi3hiISksvqGmaIUyFN2y+bk/abXZ4qj/fvlDWvjGLXOvG8jqbD6Ct0NFmr g1lmgIW8Si/qALoiVxb7cI0nJiLzbTiEMtsIf7TNLSBSYXYzcbNW4PWg01VsS1d7uXCI0dn2EdNH mj4uaxc7bLs3XoE76ONerKTUAXTUPoF0uBeKfL3VwrHYkCFQdAu5ZeEryJ/MJn9qCHrN44zCCyfS bl8QPDuAnHSzIVjV7ad0QLr3qfdnAERudX7Ko4pnTk6Eeg7HFSkNOKzxzXtwL3pw74mvWAO4Tkmo vKM069Ncb6FcKhRUtnBcYpcwI+M6gN6r3KLY0IPjM3tx4d48GK8PiD6p9/QH1zsBxMIlq3ThXpUT ffC6ZRvhni+aW3SSeguD7hEH/XjUYOyzlGcO0LEUYUGVtw1ER0jTl7V7SkxmJFu5dHr2kvlBIWU+ JaIjkH5VlnTk03stLluScM8eSmaYG5+uNsPCryqOE+uDCVK0BXCIlP3dTeBXJd4Afp35QZL6wD9D 3nAl2Kf5HvzH5E1ZWSHtK+Ih/ewWa19DVHS1PoDGn0Mat5DRb896YkimVuWjpBkUAzpVoozWN0MH xVpFr6uDnlL0ZFtt6hrquA65bH+3yc4WdyrGCpZ+VVJcIHvicujXTpJOTyBTGhxe6KOTOiQ6A/ps Pp/oFu9rOV/DiXqjtsvaKH+4Or75r4bRnzdKTJWfsxmKZLUAUsDB5txAAVS+ilSf7xAU0YV6UuVM Cagn+/pVVam+YaBm+t5L32ScSL84k0EGGVn09CH72kX1yQ2o6Cyj05xDXFgjqkzcl10dRtHVR4W+ UJ8DscL8pxXoPCaJlJcksBQ1fiKtIOpklMyKhNbtsRpXZ/8taEPx6p3Ox21vtRyofKUn9dYGwwu7 wR94l4IkB+Vgh35FXIfpiVpjhsVqOUpa/1zVr6cIBzoD2YSiImmKPJ2gAq0zOsgQTNMyVD9sUVTo SYcKRaIOp4M/48WNwy8BcP+NfWWg366bB5S+fDs9QnOSwInkVilf+GFUuMklQ7ySEzO0cM4PlLAr G+vqvMGC0EoaRxNFYx/Tr0ExOlW5oOV9S2j3oI6jgqXPK7PrgwzzCLQpcLUzSgX+WHgM4jgZJNNZ 1e3u+GNCuMEunpplpLObjbLwxf3hgmf+AD9ICstDJ942rKP8UDbKQZXLQflXXnFspQpIh9GLViss nGZVJlN15DG2KhWFXjNHfWN54H3idliFrpyuB7WOCsSSCRKXAedETt+Xd8/N/BxLZThfpJIP+YJt 2N/u9auEGLhXCn1f+BX1SqU2iWZ3XtCTjkqq2PUAfifOfo5RoxySZfyYVd6bP7WJOJbfVONPtqDp SViLDs2Jf3ttRay/V83RWGQWsNTearZbHAA7Bl3nIL9qZKjPaQM5oW1DzKbSRW91VB7oeKW2SopK gz5iid4mBPSkSyVMZ+s5uNIcO7UtqmWe7spBX0RnpvPcn2BryzTLOECmcn5fCbx8FK6mlMtmMyjk 3vSPJRcUfqWziqGKupNRlcpT++iyAXkBoyv8Hj666PFJhm4GU9F1yZ4DLMlxcGkbsp8AOv5XFupr O06KtjsxXlMCfwmw/dGK/nCxi7JHP+hR9lDFoXNSWVEBYLt3iWA+59C45O9ArbfVzcO/femMGiW6 mpX2h4za/WBFLbnOTw8qDAr8V40O1YPeoqa/T1bVGtfNpBUhiix9zvGD3mOfX7h0hBpRfZMjQf+s Dqfauq+P1YXQ51UH6S1Olh0AwHN6kuT8/hAbjFBg6BFlVCfJfsBvLdNHWCXnp1ZNRQPDBLgQigcp +giY5Fct4wLPeQLEXpjkdx/Yj+3hsrbF5J5oUQwnWDQ16+/p4CgyyJuKB+r6FmiYmFo5P0Ks9uU0 /LU/NtfTvvfFelxKHoHzDevmkpJurpwuAz+wvci134Ww7/i7dOsxXMJGhnXRE8CC71UftlHPfslI MV01+l7Vkj7wVROz/RoUEftkVoWkv39V5BDfgiYr8i7eYP3CaoiOtjJOf3V4ZBOrml/6m4bHX1xJ 5PwuVCblQG/qP4aO4Bc9Wc7Db/T5gzVTR7wD5/eIvmN9HkZKEpsNin1iCh//Y5rVpI06ZjMEJJ2f XKOpzxrOhGTe4xhOdk2vDd1sdmMy6dhjTar9kx15e4Z0mOX4kMgVX+wdZDmO0MnwO7UsuUOv9ID9 xR1FQ0t/YWTrRn+4EAbnZKvvrVECOZXTO4qyl45dsD8B4sla5VAYfYzCLDCOC7EckzAp3YzUD/7U HDRqUodC3XGHbI62Fqc39SM7l88iWPWgwSTxZj4p/dT0QBJ3gvp35hcf+WmCnL1CyoKFQhMwOrle cYjSR+BSf50QIarZ688jDp8M1SHP1xMq+fH2wu3+0td+gzCiB9X/A31skp0KZW5kc3RyZWFtCmVu ZG9iago1IDAgb2JqCjYzNTAKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA1OTQu OTkgODQxLjk4XQo+PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAv Q29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GOC4xIDE5IDAgUgovRjUuMSAx NSAwIFIgL0Y5LjAgMjAgMCBSIC9GMS4xIDkgMCBSIC9GMi4wIDEwIDAgUiAvRjQuMCAxMyAwIFIg L0Y2LjAgMTYgMCBSCi9GMy4xIDEyIDAgUiAvRjcuMCAxNyAwIFIgPj4gPj4KZW5kb2JqCjIxIDAg b2JqCjw8IC9MZW5ndGggMjIgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYWUTUgUYRjH/7ONBLEG0ZcIxdDBJFQmC1IC0/UrU7Zl 1UwJYp19d50cZ6eZ3S1FIoTomHWMLlZEh4hO4aFDpzpEBJl1iaCjRRAFXiK2/zuTu2NUvjAzv3me //t8vcMAVY9SjmNFNGDKzrvJ3ph2enRM2/waVahGFFwpw3M6EokBn6mVz/Vr9S0UaVlqlLHW+zZ8 q3aZEFA0KndkAz4seTzg45Iv5J08NWckGxOpNNkhN7hDyU7yLfLWbIjHQ5wWngFUtVOTMxyXcSI7 yC1FIytjPiDrdtq0ye+lPe0ZU9Sw38g3OQvauPL9QNseYNOLim3MAx7cA3bXVWz1NcDOEWDxUMX2 PenPR9n1ysscavbDKdEYa/pQKn2vAzbfAH5eL5V+3C6Vft5hDtbx1DIKbtHXsjDlJRDUG+xm/OQa /YuDnnxVC7DAOY5sAfqvADc/AvsfAtsfA4lqYKgVkctsN7jy4iLnAnTmnGnXzE7ktWZdP6J18GiF 1mcbTQ1ayrI03+VprvCEWxTpJkxZBc7ZX9t4jwp7eJBP9he5JLzu36zMpVNdnCWa2NantOjqJjeQ 72fMnj5yPa/3GbdnOGDlgJnvGwo4csq24jwXqYnU2OPxk2TGV1QnH5PzkDznFQdlTN9+LnUiQa6l PTmZ65eaXdzbPjMxxDOSrFgzE53x3/zGLSRl3n3U3HUs/5tnbZFnGIUFARM27zY0JNGLGBrhwEUO GXpMKkxapV/QasLD5F+VFhLlXRYVvVjhnhV/z3kUuFvGP4VYHHMN5Qia/k7/oi/rC/pd/fN8baG+ 4plzz5rGq2tfGVdmltXIuEGNMr6sKYhvsNoOei1kaZ3iFfTklfWN4eoy9nxt2aPJHOJqfDXUpQhl asQ448muZfdFssU34edby/av6VH7fPZJTSXXsrp4Zin6fDZcDWv/s6tg0rKr8OSNkC48a6HuVQ+q fWqL2gpNPaa2q21qF9+OqgPlHcOclYkLrNtl9Sn2YGOa3spJV2aL4N/CL4b/pV5hC9c0NPkPTbi5 jGkJ3xHcNnCHlP/DX7MDDd4KZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9iago3OTIKZW5kb2JqCjcg MCBvYmoKWyAvSUNDQmFzZWQgMjEgMCBSIF0KZW5kb2JqCjI0IDAgb2JqCjw8IC9MZW5ndGggMjUg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdVdXXPbNhZ9169gZGojszFNfBAk 22pbK212HceTaeKZzLTazuwm7UNn251u9v/PHkgkINASCEAiTSYPsmQ7c3J5cc7F/QD+jH6I/oyq iFRVWvGCRjzPUlIKHglWpFlOi+i/v0Qfoj+i65efSfTxc5Rt/37+iF+TP0lElu0+0u+YSEXGSBmV GU/LXJSzj79H64co3/1g/fLwe3T9iqQkItHDr9Hy2fwiXsQXl9HDb9H3D4DVBWzmD0ywlBWMMgUs 2gKbWYH9xR0SbDXztJUQKSvLrGhBMm01a9nq+WKz3Fx62Gr/Ic7cHmIpUp7lRe4FLPGy1b5fzRz8 iuQizURlhxQ9/D7b96svXsSLq3ieXifZZklIQhmfx0meUXeoAZ5GRZYykVUt69k9zc96vp7GCBZ0 xmgLkt3TBC/iF2W8SKovv/zK3WIBC4EVVVpSMFBDGru1aYfnZzFff1M8RnmWcs4PIWq729d8Fc+T vyaUk2+87CXBzTxItizSKuMssmBr00a/1iKiSMuCVTZEbWt98e3NehGvkpeb5XXy3feJdLNX7mYL WZi8TPNc5DaUw9qNsSyleeVlt7/RzfIqTnZ//u5usK0OzDzFvEoJzU5xNJbTNC+xtCmt0oJWIsrT rORlVkakTBknIkCf9D/KqjRn4tDibD/IyrSU/ifOiqtIBeF4nO64+l2YisYKUCxntKxNBfKQolu/ bGWTplkdjkWmqTwjRKi5W4RYIP4hRfPwhNgiql+2QQ8Uf7YNEH+Klg+X0VURLf+Jlzxa/gsvIlr+ Gy8sWv6CFx4tAVu++w9e8CO/7t7VH768nMlfr7/3B76HX//f7kfqXzc//Izv7f7Nf0QPr3uLSgkj aVHACBZj7DwZxjj58bgEWtpjsHJJpTym/XwQaJ0Dknzo7h4DLa7Y4fUOedntKXYus7x9fZIXA9fn j7Pj+xzOUl5RMHfRjSlr/Fi6qOsWZ58W9/deFkySakVZURdMcu81k3uvt/HixXrOCb+6PgHc1rOs y55kLK2E9HS7wYwA/nXHH3fEAeECwZYxz3PSQmyP4zsAm04586TWrVNaNt+UspRwqm3ssvl2RDzr 3pUfc1kb4pKmBcu0jUePmHGaYjs1IRvzjGC7sOfHzjbudXlxQlPBaJtB7cvrozskeKPvNpljmyxE pp+tJbAEqQ+sxxRLpTgqfgZvVibP+CX5urlci183pnPYaRsidISVWvy6Me0nHhf8/i69WPO5l2f5 7thJhmAqy/OosKBrb1kcmbmffCkRJBUVmw5gSklKy6xtYjufeJn47HJdZmkpSmViZ162oK69uB+1 ZjIXlud8Ooh5Bv7hUmTqdeduY3c+CIgttfgZfGB31qHEz4B0MAl7DlL324yimiSIm/j9MJT4dWM6 h538xK8bkxK/n4p4UazjdwnfXCaMv0tiVS5JZblklWyWizi5IZtlGt/3uhwoRVYw40VUGPjty8HC gttvGYjPz908zSuKvXaN2J1YjuPumbw50m2VtvHoEXOkDAqB3LGvjY0nbw1+T6JuD18diroNSOOg biGryUeS9O2a0MeBqNsB0+DU7YBJUfePbJ2y5D4u1ikqaJvl/D5ZSTKX71aM3xG8v7u54YuLR6Qu 18bMqckiKJ1Ts2Lznxk9xzBes+JkECtW9EU8DCs2qHapE7uC/+wO6ZRsjglpJKwoypQQeijB1CbF n4ciRSskWVwBJ9bVlYEKGaITkqpjPLuP5xfrzeX1en4lGbFNfO6uFhATyP4HWiBbYgE8quwOpQKp B+QeJgN4G0WgXj0VwIyjPMrRCDkVwOj4SwX19mH3ddWKJ1z2/ypNYjHiI7oMRuRSi1YlAjuiIdlS VewFRyNvfkxTmo7bbdX3/SmaIu207fGY6b7fbQun6glWBYJuSE2cPTtHcdxSaVT1gRqSS2T6iSMR ImsDuxB7fbFKFpzEyXr7wSOFmZ1a27fAp4SlJRo4PdAfzzPsvlOvk35SxbRAgwRBv+5UADPGkIIq poO3QrdHxQMN7M6RAdGQZu3jhNSOht67IwrSkbqwa+cjWUNt+GjbTxa8oB1qqFDbkpEKwxZoAUPT jm1Ooo66378+uatpZm3SydEkKNDy1Y1pqK0ANgA59ugukNRW4O31TRzsTltx62j+kv3XhaxGdNtJ gVpt0+xEKcp6vrnkixc7fXFHG7AcScnTjJUInY97Wns5OmpHP6VnivBB0Nz6zEcFmCFRDYGejoWZ oGmZoQf7LC7Rq/dqMXH33qHE5DiielMyvJggTMQYn9O4yvvXJ7QJuezelJp0gxrKUFpOujGpbLve BjyPMaiIdtkhWLvuv0HV++gTHRUJqv4bE7E9A+ylM+ev4e76bxrALltCR8D9bKpU/81kEKv+G3/E A6mKsbzszvqdO6STyhUGpCctV+QcBXg5zZ1XeUoxc3hkl2I0n0pdOWGf4qIsRS6HmTBL1g1rKGVB kJ1nGRpCHDApZfkFVVsvp/IdY5V9p1zIqbtuSylUflPv+5BcMqhog015iYnaDkjGNA9qOzgh4D55 iv0TRVc4xkbbT9bOFY46sdtAnV3YigJzIKxQJh6/siGJXTDUQxunGD/iCqc3kDLMxu5rPmC/r3ZM jS1dSvEDaZsJaSTaJlcLc9e2nndNStu6YQ2vbd2YlIpsNinakVbJPL54xxffJB/eYdw/ucfWabMs N8tV/MHG5v21KCFvnnHM+OT1/2X8TJNjEoOWZDqINQN52NiDgYJIsa4ANI/dQopByyoAk46u8xIJ 5YaB7IGFjK59OtwDcCkGMmA9KVnr6NqCqd0J8MXco2u9VVVy6brHuVk4tYbkUe4Bqu/gGoldjjDK jsiIrVfXq4v4RfIiBinfPVmQjfp8xQRrIbevhScNshGtpjll2BvXth6/kBQYQiRE2zgY8UDxq+HE dlfwUI9TcjPNsz6UB6mzsUHq0WIflxyIVg9M5SE+aI52aR9o9yg3c0KTvQsupR7dsM5hKhei1urR jUnFr2IXt7q7+v4zdDxoj+AMpBzn0UW5BVg7yx+uIC6Pj2CMFmdkIdq0QGor7RNrB0cHBc6sbEG2 E8bTageOZGC5THfURg5m4r3/Ru2pPZUecKhhxWS64zyI95YVTrQ58zkoev/hAdbjiMOAmFr1jTb2 G8H+gzctSDkmfrloFMS+bt73vftoqsYmqCfdfaiqsQ1TmxN/ZBxto/f3K53m+D6J5/c3fD2/SPgi uVnwbz3OXApwOkrwhCsOLvd4wHuMcvDLvZUb/Xn+zDXqTDhYWCEePzEynHMsKm3j8SOuODoKcJ5b 4xVeiI3HbyXuAIfVxO3hsB7EfVLob0B6Uj7SxI15X5Y1xG1iavPR+9c9B/6KuLtBDRX4a+LuxqQC /0/uLr4f8teH9CHGtrbYyr54tJmjR8v25IwEjeoZ3Q76LuLNJWqhcznre8G1uLijDliYNJNnlaPj 1cRtDxUOysfehwbisyuJyGWTLni5trQXy+2h3P+yRtxTiI1DMJBf0DYeP+IyR51ZnGJjwwf6kxNj tdm9dig5MSCZ1D1wJknJCcfzxBmdx2YRWpmkE+aSXRIRjZw4gBpcThwwKTlBFSKpU+y6eyXlaP9f X93hMge/s+eCuBsHLWJUKDJR21fBPusd+tpYt+fnbppStC0pxONnQmTNSsypTAhxSVJO0drXeEWI jQ0v6I29G4SWlIlaba/cIZ2yGTAhjYS95SUMmSt7nzAB7MXe3aCGZ+9uTMqffmS40kPzdn24Thkn isH7PhotK8GFeRFxA/Wo2Rt+yDCr3CAOYZa25tTLuq/IuwAXYlc2HcQYQcT81gk2dufJgJBD5XEa g46Juo11NBLqxqA0rltyDLy/Cz+8wYu6u0ENT93dmBR1Z3xexNvjgDR/4+SGN8/6vf5LnQXEDaxj JuzmMKAG8egJmzanAU0GsToOaDKI1XlAXoj7lZUMTZy4mDJqILnIyu1tv5iaOwMcMAXRZYj8NoVd jgllLm/fcrjr8v3rrzx0JQCVSugYoJ5UgFV9wDSUialdSNHjwHc3sp09Xrk7WMCekzA8Tdxcicu6 9h+mibHdI9QOn9vv3REHPGgc+4PjEHABpol4zAoom+mqUtt49ArIENOwMtc2Hj9iVL6qYs+PwxD3 6rmozNUCY6w1u+cOJjDdmIYXGMwqEzQTuAnMq4EExgB1kCiDDNWq9rrspbTAWDC1BeblHblY3+Cc ObVv8VCYEL7GbZWMF0h/GCDtXt9WlPZ7Y52eu0BAKgzM4ApPhTiMS0zMNeJ+Ukw4zgjTAhhZb2w8 esQYbsW0AK5mmw5iTJuJCleznYLY8NuzlzSUvnistMH0pRtTEG0GMJKqSDP0qlWlq77cftmvwAg0 zuEQjCpygDWUqRBVoZcPI18OmFRqTG9hCtz0spa7GK8b0AIeKcHl2yJHxtoHp0nQj98Zi/XcIkOb ykuDePSUTWVqW1ZeJoOY0bryMh3ETeUlELHhsr3pSwPOJS6/bV2NbhvGCFj4avLBAdNQpKn1pcA5 +NRZX3yONQowldaXblhDmUrrSzcmpS/P0aO6WWIbo7cwvfq9ypExD5CP5cT8xEB8bnFRObIG8fjF pcmRTQaxypFNB3GTIzsNseG5/WmMx1obTGO6MQ1FnFpjsPXHgWc7KT6YjVK8iQO+Q08Xcpw41hLT iSrIUAE5Mq0wxyG1U2Q/XbB4ocTF3d+38GZ/RNcvP5N6YKO+yyI6dpcFochbIw3CjqNrV1/msjts tb6P6/bentN3JZpH0C7rg9BUusfv3C0aEOZQNEZQzJlPBjBGrFAewimKHj7w2KbmJ71amCHvjGHt 0y3cK0pVbfEwq4+QBHCR3qwcX+01F52DHl0Or1DX+8jTfxk9qCOAZEyMndAh5nL/gbrepxvS1krb K4fOcGUc5o2PsbS63qcbUq22s+WnZ292F/t84m/eJs/Xq5TjSmSPkezawWY+aoL7JisUQS0w22pi 8sbjd72uUYoxpRxz5NMBjAhH9h5MxcAM4QUO6J2OgTEGihH9cA92d1csr9mHyCtY05JynCzb6+v2 By9I++cdu5SAtaQch/RkkoKZdiKcJMWnOawlvH6S0glpeEnphKQk5Wt+dyEvIMX2JMHdcYTIEW35 hr7ZbPruO8Yxobi+kR1H2/b8x1pifuK+LkJ2ARiZo2UG4psK4HJ3XcRU8EoF5HkOpp6IgdVlEZ6A 3d10n5gcEyZaUdytePsxDBIyEn6KchzSkykK4sWsOcnWTHa1Nyk+3WD7D24/b4Ozw47tCPQmpRPS 8IrSCUkpypv1Fa4bIlJU+Oayfedoz5ml+g4iHI5+7KGOVFKmAriRlIng1ZIyEcBaUvwAh/G3t6S4 g7r9OQySt6QchzSwpKj6CcWpJAIJ7kMFlBqTKqC86vvmoWaIxQHUUAlC1WPsgEkZCjcPbfXk7ac3 YY7l6OtIxeBQI1ZFNnCjEhEiKrS0E95CPOJuaEpRnqCltvH4ewlK1Cdk4qHxitEjRn88qoB7fjx6 xGrj4mNjH5kJ2POrXFiDydKfFkSfIZiaYUnZPYmzuGudsa/3V153pwagUjpjgDI3VDVtBhmqtaFy 2XZqnbFgagsypu2Tld7CLOJf73AN0Avc57ZK5AXYibwCL9lsruQn7koUYFGKQhopChb5PGczH/b4 nYH43D1iFHOUhcDd5w3i0XMOy3Oca061jU9FvGffHo4Jb6YxfOw7GEMai+wgGx1e+P8H69klgApl bmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjQyOTUKZW5kb2JqCjIzIDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyNiAwIFIgL0NvbnRlbnRzIDI0IDAgUiAvTWVk aWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMjYgMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjIu MCAxMCAwIFIKL0YxLjEgOSAwIFIgL0Y2LjAgMTYgMCBSIC9GMTAuMCAyNyAwIFIgPj4gPj4KZW5k b2JqCjI5IDAgb2JqCjw8IC9MZW5ndGggMzAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AdVdXW/bSBJ8169gJOqiMPZ4vjicya4usZLNruIYB+8auBdiX4zbAw7IAXv5/8DVSORQ lGVyhhK5ZPIQW0iCcrO7qrunp/ln9BD9GZmIGUOMzHgkU0qYVjJSIiM05Vn0v39F/4z+G918/M6i p+8R3f3+/oR/Zv8mU5TuP6q+E4ooKpiONJVEp0rPnr5Fm8co3f/F4o/Hb9HNZ0ZYxKLHP6LVq/ki XsaLN9Hjf6KfHgGrDdgsHJgSRGSCCwcs2gGbNQL7mz8k2GoWaCuliNCaZkeQ6raaHdnq9TJf5W8C bHX4EGd+D1ErImmapUHAkiBbHfrVzMOvWKoIVaYZUvT4bXboV2+v4uV1PCc3Cc1XjCVcyHmcpJT7 Q+3gaVxRIhQ1R9Zr9rQw64V6mmAIaCr4EaRmT1Myi690vEzMu3c/+FusQyCIzBDNwUAlaexjsxle mMVC/c3xGJeUSClPITp2tx/lOp4nf0+4ZO+D7GXBzQJIVmfEUCmiBmzHtNGvtZjKiM6EaUJ0bK23 H243y3idfMxXN8mnnxLrZp/9zdYlMKUmaarSJpTD2k0ISnhqguz2M89X13Gy//WLv8F2OjALFHND GKfnOJpIOUk1QptzQzJuVJQSqqWmOmKaCMlUB32q/lNhSCrUqeA8fpAPdUtV/8VFcWVEMYnH6Y+r 38CUKVFaMBNlmYWm9ClTHUfm5y8PX+rWCkgSfcQ8NUQqrn1AUUKLJDHqDCmiO1CNeasCNQgpvTC5 vPXrK56sN9dzJBeb+XWyjP+4A6VdxfPFOsnfyGVyu5QfbpJ1vMzi5doffyduYyRD3n5k0+ak40vL rxriWYATeFUKlBGRMu4Q+1QKLYBLt521lxCHtONd21BihK5sfBbiXo0rKcIdJVyQcbe/1TA1loYd XFQiCVWKKodpz0UnXbRT2HfA5NK8zHISytUGTC7st+9KP+unVLVpCqfA4gFqKEOl1p9QgPlgcoba V106X5H3/bKfUSRlhokgdJ5csn/Gl2Y/W88yqhAMheOdxSXFj1KEbz/sxxlyCSPZhBBnKeHoUk0H sRBomikzIRsLIy1vdrJxv2rjFDCE2T/1i8kpYDumoYi9UkCJhixDyuDRF91uh1LAdlBDGapSwHZM TgE/bu579agM1bWSNqcKANVvVxukm2baclgNUnMzj+z6szoW+SrbSH+TdWg2Mo5K6ZnFmuEtgxCF 9hoZx0EA48itGix2XKQHZS+XTuWZTtGBpPII8clU3sVCEOJL51scnRCps8rGo8+3BEWnLEsrG48f sZIo8A78+AzE/gHXoeqrquNawDW77zbgDKQLJpcbtGMaSvKq3IBzYlLP3MAMlRu0gxrKUFVu0I7J 8eG+OsbJ99UGHcTFRs57dXo08tGAt5l6AMa/lLOZxkEqsxVngfgMPnE/SGHjnmpk9P0NtRXnZBBj +ENqyOJUAAuUTjTDId5lENdC7tJJR6UzAdYdTGcKTA313lD0WekMhoYy46kzIYdUXQTZdWHbQQ1l qEpn2jE5nXm9WecrvTuhkvkbHEzFUJs7HL3XfP/iJQJmyKROEacBUB1Lv/BFDfGlo5UZDMlk6CEX gMevNugh40ClMvHoEQumCLeHrFMxsUA3Q4sDL+5k4prbXjrQKpEJCLTBRKYd01Dc6URGYbxRYf6j Qfgcd26fBipmPEANZSgnMh6YnKE+xvebfNWro2tGFOdcRSG4XhAS93EN8cUVBaU8p0Y7xJ3Yw2Hd f1Eg7qmAoSgSDUSwtPH4EdtpWwyUTQcxxrGIyTCJPhkb2/ncND3Pj2uB1psGlib14vZ+p03duIsH pqGovdJAzLtxU05OtjQ+fx9KA9tBDWWoSgPbMTkN/Ee8XmAOsFdPx+g3pzo1kQoAdqQgz76tIb68 CCpIimIO8fglhdqLOQiO0sbjR6xwHpexCdlYcBwTp3pCNhY482TyDD+uRVl/ChjAC9uhFLAd01DE XimgvewoPBXwt6EUsB3UUIaqFLAdk1PArzG5W24WuG8n5+vNfYy7ijjX6tXxGe5nGYUOjQrAOe+5 9wkomOBFhh+A6ZkqH31Qs+KlRZozRAPNUEUViCcgeQbjqGll49EjFrhpxDWuvUzGxridjGt9B34c ZuOax/YneAExZt71i6mc4SifcEMZOhSPV4InGHJET8H7NJTgtYMaylCV4LVjcoL3Ks9Vntflrm9x wYyBkFmGLQ3+D/RIS559WwuLS4sLMxr3ptBwLxGH0cgzsLsPCsQ9tUFTe/hrW82FjUePGCs3ML1N UQFOBrG9kWqy82xc89v+JCYg0gaTmHZMQzFnJTFM4GStOFhrnqje/hCgMEd3NX2uGLs7dOplTMVI dSczHUHyuWJcCUwjpP1mnNl+M06ek/dz+SuL76/394r9Hf4QoefeFyZwxQtLUqIGox3fqz/NztWn /oA7zOgwgxteDKtWpgKYp3bASU/Hwpi/RC/U9ptfdtpRuQSWPNk090wL9+q1bmIjwKYhsnIY+bja 7kWXrnJ5+TEPTJdOVVIEuV1P1rRIrKDL7efuquJ2Fsxe3m7mVKUd005VZna72TmLK9zCtVm1Ym23 LcutX3Oq0g6pqFpmqx9jDAEusRgrZAbwyKssMnhW41INRjm6SujN+WArHmGlHKe/6jUymcKMiRFN eEdFdhx32bjGBGCDgccFGCP9GpsNpoJX2O1fKS5hTQWwxAAPlbiDFQjYP6wOecAzr3SCFwDKbLtB ChW8BkgDC57b1ZSiMsZ9UE/BC7mKffjs3NKbWSOH406fxLI5OFQrKnheQeIXkLwGFUaGh40DkntA spK3E2Ell1f2MCqLk+7qF7Y9jeGmihYoThosNy5yxmCaZChOJgMYc2mUppCTl31zVBYWAn1Fg+Jk MoDRusU1vHALdyPvYD3xf+6D6cnLkP4yPQERucUe9bYcINX6TSigTLdH5ysnHB0mLeBQraAGkxPs g2AcK17bITk5eXWmkXZ104s1XYZ79KmyNNFqJFfTze3CwfMlLmwRLcNW7TRNWRPQUREw5wJDXDjY abDsuABrTjKBc52pABaSI3nFsc5UAEvsoTQ02Ic7E4BXO65cXtVgxEJNCgKIVuapMySf0ws3zt4M yarJUMRddQhRpWuGdTRNLcKiEMjz29t4fr/5kOT5lyTBMngUBAd7W7/K5SK+T/QNPl7f2jE2zeIE O5eXixtnYJw6X/zNCTxj4NIMpF/8NOM/c8YRJJO2NJwMYoPrTYJ3tLF7/H28n6LqkdScuflqhvm9 X0zlqUD5gEcwz1R1SbC/AHNWRdA32wmhvkWw1wLd3oV/O79PXsfZ5rAR3kdss0yjjYiGRYF59KHN UahS7HacEGLc3lccC2onY2OBoxsO/rwU4gMqQPPswtu6K3oKcOHB6KmdCpCThO+R7zCRUNETbr7b xmkDZbrUDfRkTtHTVyyOBzclfCkzO02/m1qfeb0h6WSnt+W0rhzTA6nuoI+fpcoxvckgdmN600GM ftZuTO8cxAfU1JI4dwk5VywFhNxDQLXUBZPLnNoxDU5NEgswmNReu+5BTQ+nqAmDaUia1omKF7/K Zfm6o36mcZnBu9ss3hL4BIgJ+xKFEtNBjPNGTDyjLzsZGwvsPmYMO//PRDwMN5UgfdKBh4GuZXpg Gp6b8CYxo7256ekUN+1eJ3m1W0iziF19N/N9uWSH1Iljak5j8FkW6MdPUDhDl5ienQ5iIQTOerMJ ATZgVCO7mXggUgoItqeAeZxzEqYyhBqIcihScv1l9DjxfkpfUrpbCLlc/xv95ft7bFlchwxZdrAc JJDwTLMoBOXp2crq05r/Xfw+GJRb44DTIR4/XQqO/p2obDx+xGAfal8MUXrF6BHjXXB2NOCSNnZe 3EdP13XEQiz8NFDZWWIaFYviuAgbdbzKTpvCMRaTxR1eDGL7X7cxzt+SfIWGPZW3N8vNtSjfgd1T 0YkhDIoLUZEsYPsEUPJ1gSHD0JtaHUjfDX6X6BoetGszVvR++isXLvZ869KkjzH13eR3CdjHnKdh Vp8WgPtxADf6PRnEbvY7FHHtwTeeHHRw1YonA+L/aaCDzdJSDeEzfLaJF+0xWV6jneE93/bGT/HH bl4P0n7iMOP/p1X1TQplbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjMwODYKZW5kb2JqCjI4IDAg b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzMSAwIFIgL0NvbnRl bnRzIDI5IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMzEgMCBv YmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+ PiAvRm9udCA8PCAvRjEwLjAgMjcgMCBSCi9GMi4wIDEwIDAgUiAvRjEuMSA5IDAgUiA+PiA+Pgpl bmRvYmoKMzMgMCBvYmoKPDwgL0xlbmd0aCAzNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBzV1rd9zGkf0+vwIih2tqREJ4PxxNbFKRY5Pi+tiSpbMr2tlEkjdOZO9JnHP27++t 7tsvAAM2hiK90gcCPY1GVXW9u7rxj+Sb5B9Jn+R9n/ZVWyRVnaV511RJU7ZpVhdt8s/3yevkl+Tx 01/z5O2vSab+//oWj0nPvMky3eTuyiZtsjLvki6r0q5uutXbn5Pzl0mtO/LPy5+Tx1/kaZ7kycsf k+MHB4fro/Xhw+Tl35JnLwHWTYCtlgPWlGnZlkVpAUsUYKtZwP4tHiTQarWQVk2Tll2XtQOQQlqt BrT65Oj6+PrhAlr5k7iKm8SuSausbutFgG0W0crnq1UEX+V1k2ZNPw9S8vLnlc9Xj07WR6frg/Tx Jrs+zvNNUVYH602dFfGg7sFpRZOlZZP1A+rNc9oy6i3ltDKHQGdlMQBpntOaql2fdOujTf/pp7+L p9geglC2fdoV0EBGaWjZnAdvGcWW8pvVY0WVpVVVTUE0ZLcn1XZ9sPn9pqjyzxbRS4BbLVCyXZv2 WVUmM7AN1cbdUitv2rRry34OoiG1Hn1+dn603m6eXh8/3vzh2UbY7It4su0jmFWX1nVTz0F5v3Qr yywt6n4R3f5YXB+frjf635fxBFN2YLXQmPdpXmS3YbSyLtK6g2gXRZ+2Rd8kdZp1VZd1Sd6lZZU3 e9gnN2jZp3XZTAnncCLfhpRyQ3xUuNq0yStMZzxcdyuYVo21rYDWdFOkGkrm/iCJfwhrPushwsks CvEQ2xqs0HdGtWawUDUcSvEpX75NmkY5m/qPnszaOoy/1/pVdYxyGPdgshqs1RcAbwDnBGB5nmZ0 ZZOQzRZ41zFeEJzYrirzfhYmPZ2WWG+S488fJqd1cnyAP01yfH2Mv1VynOFPnxyf4k+B1of4i06P 9Z9Wtz5+uJLGWjc2D5Pvk5cXcT66T3IVPCgEZ1kjL+Cm5N0i9I6P9qZ4DLc6AYIf0JfTugYU1/HM SscztxMggPXr21VEiNUW0K19sUOkTYS1kghr83W53ny2frz5tjq62m5eP33//OvXz/TfTfNGXT95 9Nf3D548+kTan//p+vrdO3dl+jz/05v379hDrjYPV7Ex24gflHzP8oMjfl4gIO2LmGDSYpO9efr0 UfOJRujp9fVPQOf6+OBq8/pN8fWDNw0wfL05P9gclufbzVWVXp6sDw7R42i9Oaw23Rq/ISw9Q2C6 vkLz9r5wzXLYxSoqcL5ab9Oj8w7wAY8/PnmZ9V999cWXF/ESsYcXlYvPUrTQiwRU899vGt6YpEPT lchLVJNWbugQQCT8eb/cwhfFfJ9sN9cPj6oTRc5v+hdffflMXf7w6Vf9l5p//vjgTrm+aOu0r5EW MNjEcP2CTMUec160Xdo3dWNBipnzTy7O14diVmI1xD6AIXfVwJ9cBNgCWkFpLY61syJtCsTaZvqm 9POQGdcQ47vN6ZQF4thMknsLZGQZpRbH2EWZVkU+T6mhcwrhvD4+WcOOfbZE0dH6LImyyzZP2xqO 6hKK7W/6Y/w/axCbBtnVCkw2nV0NsmD7gxTjIFl3vqmKtCys7l3izp/dpzs/gPP/hTs/B9PYnT/X vrnx2Ne4LZ1bTwe+0y77J/rPif6zhjuPrnT52VPG2c+tj0wn50WTdiLmIYdMUN4GLbfw6pfJUdGl SEH85lLkBDvPdkAz9Od958X4gdtNWX0LJyVN19vt5mB9KGpy+2zz/EGxgYNzhJ+QDz9Ey9lR9fnj DZra9RE8HnGLi+fX18V2s708O6uODu/J20XyKy2wThTj46xtOj+VdP75wak49NtNdXmIGzrBd+ub 5bAJeV4lS8BeYET38IDytkKOrussSJp95t3x+3DN8r5K2xbCZWgVA9gCWu3hmuV9m7YdEsAhSPPr DHfvmhV5ndaNpEYpDFMaYOgxLqPUUtesQHK27qp5Ss25Zs/i3f49XLMCS6d9XueLKLb5tjxPy43o zfX2/FQUBuL8tDo5y6FZEPofIkcSD/Yesmq1fN2BvC1MYsQaNBIQWFY6dBkKhPrbdXp4Xh1syvX1 8RX0IBT6waWs1eFaK/O0QvLi4PBio8NcrHlCsafp+UF6mD8WAqi8ASJewflecjg1Ysis7KoYTX+0 /vESi0MyK1Dv1w83a9inq3V7Drum8bs+PjvLz2EHhA7bzXfBEyDZ9UNYQcxw93jz+tEnd4thWaV9 i3h9CYYLxHcfRkMBRw+rakGKYbTXr8Schq7DSB6QBa3LLCswMkQQmdoetQLtCET8BK3W9KgT6Yu6 6vGAu0LOr6zaNC+Ru8RyHKIGhKWI44sKyjnJ5Q1IOMiYP8pTpfonVyhQ6TssMQA3ZMHLVhYaShQG tHjeG6hHUQWmwwwkhuLHG0tKqIX2qnWpsfyJ0CeGs2cZ9fqa6md1cwnMHvBCYUpmogetouFFyv8O 0zd5jXVjWckmRL+94UNNE2IVxZiKRlMQDe0e8sriSEM5iVvdnl+JSz070R5RkehfsEikcuY3LLCJ bGUtShYWTPPzuy2JUUKKJVcD0hRV79fBKbG819YZPAgtC1MQjeb5lTdvS0vnbl79KuHUQAHOEgkg hStNfuQ2hG5aVweK4+kL0aYZ/BGoL5QtFX2VI+Plrl48HRX7nbpqP9Q4QQvDiVFlg1j5bhN1Xaxw XScfkhdK77oHpNJrx/NYy0rwVMMR1F2VJR9WS8bACFWuR6hwXXaRMIjqznsEdgaHHoHLUhzgkaa1 YK5wUHcCD3CIp4N+r8YB8GA0i4NQUZs9TE+W98h7Y6IambuyTiImikjCMnKiAOJvhKS81yDZ+kgO lz0nmaWHY2FxaFFFaplttGw6/XwLH0Oe0hPFu+iJ0nRU7yUOCh47UTdVr/oSGJlCc5GDuDu9iRzm I1dEN/DnyvN1u96c5lUnSZPHelWzOlsjjd7l6804qbJBYCFhgarKRQ7p4k6956JHWADHL0FllsIs xosauaW7a5hHrumCZee67FD7By6JCNMGy4mg9bZCyHL9EJmp7SYIT64fVkeb14q8J+urc8Qw69c2 utFB6vrz8+0h1qAPv12jpFCinzudBMdeqMCACopcfNbxGJAZRGNilKwxgi/70V2cvMqxRFrBVC6A VzH1IMBBfPwS8K8/x5oS0gASACGFerLeHCGpiHwpkgVAZjRZ9zQZqNotsri4QgfHF5sna0neShog rxgdizwLEgNJ33y3Xa83z5lJePFqcyKFmFfrM+E2qgCoiPP8/PCxisGRPyhHbBjhY0jN+Vw8uEIU VyCvWveorqmxbQDhohjiFJPbo0yQ8aBozRviQTUSitfzQtKOZiSkWkos4wUBIUa6iS1vpTgyRMXI ySq9Ma+kVZGJUQNWC0B1n6zXOiUV6I5BauNOGVEmpckl1tfoxGjmB83XVvLvgsSFTG8Oe0uYYki8 INfim2YUrcWsJRUdimSlnnEGolEkcRFPpAFIqsDyhggQXjwSyoiqd7PhKJAYAhQh2H7w4EIGL4yI 8ElV8IBqJ0QQWM2GE15VcLy7UjnNynREBA94Rvy5rlSuP+9a7F+Jc7yVP6fe27bKI1TwtG0Z+bzC oS4UBMUKOMjWKYNDbABUY5HU4aDuVnk8DoQB7yUOCh6LAybllsEDX9CtzEQBxN8ISbzXIgnGcUhG BQ/IuwvcitlqzPGCiVKMUrcqUiWz8W7pRLWlTK5iNgWPxeFGnTlSBzdXXFvvDiYJIf6kWfoY+mDa 0IP1TApYDH1d6ar/qgEZK4SwZYnSTlhssfht1te9NvR3YJ5tqUqFpHOXWb9+rlRF08XVJTxdWqqy hxthK88HcAYFE5ywvSrP94DJVp7fDJMlFirP/4C6kzY5RnZxogCdraxGOUBtCqrTsXB42iVS/yFV 6SxRSXGHinU2fqpH42/hA6xxzzAYattxt19li7/bdZRTcBZJFt+Rf6mSkCrh5gWPhaQWG1QxFfgs qzd1+azAZ60OMu8ezmx8pFFvgR6owyJ9FA56PdnFvIODg3TxlNiDP0SuKzhnA0qsJnjW54/S4KNm m6ATV0KOQiaBfLV4n4c/h6MkppvDArvpZMHJQk43dw7ycXnStLsUEHLaXXKOU3QKr6yxIyuDfwdX A5GNXOdLXBU8gzwlnlI2UN0h+QkujnOXlCcg78UztYYB1qzviiXP16XDAeGZh8NI3CZTeDUWXdVT 2o6ruwU4aEuO9xocBB4Ph5usj2+Fl6bwKlmGExczIjpckOjyQYoMXZxjACNcyv7gCZCgvsJy0uvr cS4BqYYD2TJxhbQVkg+X59sSi+/fmezCD69YVI9uSCYgu3i0UTVcsj6PlMvlwfmPl5KM0Kto7580 o0TD7gzfAPGoJTKzYaDCFpq2zaKWbmV/xQ+ffiMbAmwlyVmuywzUNpI1cdriKIO7LKmQyqqugvu9 BPoFQXCgteJODJDKqq7GphADkuak+Sq0y7ON1OEgVSr5qm9LZDpN+g05ufZ8ey47b1zaSlKl+X0x htpxFFWWuD1UZTeqrugQ6bT1FbKK9Rr8jZJLD/ztHTOFZNDkFI94yLW4SYoTe55UvjCXkqjt2To9 R+I63Zyuq1OsE5yhcAop7FMptVEpUiW7kOE7xchpJ7XRKI+ajJNL5M2r7vD6GCIpG3xcGtRqI+Q6 z47OwWKSZbs+/ky4z3GZwm0rhVMV8JcUnD/Ks836XKkvcOr9YF/2qEjIuqiUvKwsnKhk7Qkqw7aX ijG/W1+cXjzb/K14/spp5BcX/cU3r5hv9IhERYYc8FmF1KSuljvLq8frq2cbIdndIt0XaV6jTmAJ 0vdWtVd2iBR7cxbEvG7zCYhaPEjT6eWRbxJfXMAofgte2pyjxs1xqd58Jutvg6WK/95u3tmU/t3O grGOZYM90Ng1To949qicB8ARzKcL8pQlh3747t2D569UDSL1i6pahDyBJO0aPOUz5B9e6d2Y8ANQ ru5bBqGSUESJJoa7J+zrDma2jdp0KttrFXQiMGrtyEPtd682WHvdAlssq3Cm7xSFIsNm/x7lf+UC FADb5VZUoVD63TAdvNv92sNbKBpZvutKC1+Mt1A9/1rKqw4RZ+ZqR+bmh77v7xTOUpJVLQJBQ8cY OK17CFk4E9u6wIffg5bWSpY43SS32b157eTUjaoRQPkajCbKbNUWkM37Jw/E/j2S4gG5genfVnkr +2OlooC9YAzE6XdnLNF7326eYO1UGOlOedzhjVrXKA1VqC0v3z16/qRApat24dUGGDVJp5DaM0cE 5QBYoYaDdHQuBIB6U/KhCaXUt4iLo+c94Sw7qiJ3zaDkO7+8gvKhaRfl+qD5/sHXj1RVAgXoripO sbsnw1FYKPGNBni9RcnJnVadIoNfNch+GKhixHqBFCMgXbxp2JpcWe6WU3F0JI7SWCmZ0390hSRO Qth11sh0EsrEx2/wWI5cWpa809tgP1ZCqiihyvMCRbM/45gfhCCqNis+mYRn8DzqbJCVUmV4SMuo OyaU7MlYc1UEUguO5ZwUR8vkSYOFTylJxHCjNgyKo+3SEqcB2n5oQc1sVWHPvVQNtFhedg3Y1toW cL/HbVEt3nMVFq8bVDmsBAS+sOokhYzI2QJVdQVkBfdEhvdvk6oC2HK6AVs+oAV9UDO6Ygtq6vS+ Ejuq16Lfncg47NVgq7rgBpKYtpUhgBna0ci+3lBXDUWQbNuo12rUguf+igKMIvnf5I1ix1F2dirl V+YZKgVRkwAuk2twHK4/4Fr2KkmhiNyX2AuHK3jqFQoXeCdnpHjX0oqR0Dr+vS96NaaM0os8YWD3 BhzLgDt5t1xhNavKJPWJ6w9y5lOuXqruIROQAzMC7zA2nlG/yNvlGelloDUjaCxlbI2Tfo++dq3u SsgpRbK2ktfllL3FeMiHmWRsm8L2CzkM4GfXNsEMVhoMM4A7tGDhseHEe/w508s850aaEFtQxkqD HctKjOFQ04ChyMaeqFkMHWs7rD+w/EeAyaRWqMKZCJXsXcdcQIAUCxUpflG7UPxjPUWF5uaAq6zP Wvig2OUi/xEb8taOKxv6qgYaUWnzFSoSpCf/qFJuaAGMJ0f0vPjX+59++fM/k7Nf3v3z/a/vf3Em UJa17dg3vYqxmntVjcMVa9kgitOypHgcXiLf+OCuXuGQSqRaBwe+JXn+aYnFnnAvybS9Mk6wZ6/0 rhxlr25ZxiDkgdRJsh81p85eNeC52ELzob2SgoId9mp+75Kn4nHUBKrefHtVdbrNFwbbZngfnAve ADquAYalb6WCc9wW1eI/JwcC49Ql31whysi6WswTbaiU25QtVo8cNqbFUwmmF8YyygQXfNLqJayK 6NFdiwYBenPYBLtijB37jBr8h0gWUNN1I+0MQLCiJLnRUiAvW3xUTNu4l2lxI+1t6sTEoD5kZcyN MKhviBCUQlmhF2oZnKnrW2zHML/gmn14BVPlfi9wkJMaE6MUUlAbmDrs3hNjClOnrmiC1LUzdSt1 r4yYHYF3GJumTr3HtborYwoFpg8r1W6xMaZQU0GbOqGHMYVy7VrdFcit9ovMlzv5phAJnrTNUXDq mcLKyNAMszjWMJPuWiaYxXlBlqWmnnMyZJjMM4XmyZUT9l3SD0K5TgZDHxu2QRx1JawAo00hhLKX 44usKcTaaokTG1Vdzv6msIK+yLDleWSfxKANTOG///Th1+T1+5/e/fqvP//sjEaUHdz5Hnj1cvCk HCt5SzsY/QrPDuYwhDDiSd58Woz2VO5jB7lpy7l63lVE3aW1g0WOaMfYQSlqW2oH8YyO21gQiDuO sTxuEy6Eq9IFdpBtGNSzObqfx+SIhOpOTuawgRVUGmYKDDdui2rxn8tLBG6wz74lhGODIxLE9BpL mOEYa5hetJjQzbT4GoFtgSU0/ZxtMqN7LRoGiPaozbOFhHTcJ3iOtAFN3VikIMbSQSV+IpWdpjIt Pj6mbdTL03mmz97mUEyNbC40JgkmA9eM/NRvytTBZZez6xnZgbdRZaGNoLqWPhgJrezt/V4q3tft JU4qCs2hbF7V75YrbYZgs3DtzCEcS9xrA2dG4B3GNuZQ3uNa7RXYVF8LdIwMLTbWHCpMlblTVzSH YevK/31nZOipi8AcIq9aYLXRM4eKuUSSprgFTLKEWxRLiIQr5tLJDMMbI/4ByZwkmV5OC7ixPJnf pQXUWCblYrjfPOcwNC1KLBTOvhYwtPGlxrUpQ6qA0oYUmTycbodiZRNTfiRDik1pclpMjCG9ZUyJ vafTr/p4MWX0KzxbamPK4iPZ0o8VU0KAJTulc6C3s6W6MH3SlsbGlFmHozFxspaXA0W9tWqDJHtW i22O95Hk6aSez2tBbbYcvztqimjwHoLAI4eLuvcPzodFCgxvU5abdhRUlN0KGJpm1DR4Vsc0iShq BbQyTdai2ZG9Fr7fs6EWplEvpRbUMT22j/dchUwxaBIoRUM4A1NiCK7UglZ3Zgo8ZEwvTymaXk4p munc24SKeRJXz5ixHh6IM6HyG41fg12v1oSi6AG6k7/geurqLaJUiSIrHN0tY8o1jnIfmNAaR9vp d8uVMV1y7ZtQ3OtY0I6gzaKMbUykXLtWd2V+F5i1CcVQxMaZUMFUm0i5MnCErf7vxoRSS0hKdbT7 3jehJZJ+2H0jmzssS80wC1jDWNCdkw4oR4wwbplkMitElsmiZN/JpwHdE2PTNNQPY2XgHlpZsnjW 02sbhKEizMjDehlZrCCWCEsHa2vL8rEVKsk6+cKVXl1zSVIEoXp1zZmZWwWhfM/IRn/EIDT2FQ4j BJ8uCMXegdsnYz9aEIqd9sZwqsr2hUGoPMMgtKxUbfwtglBT5uUbTtMGtWINp22zYoA0KBbo5CAw epooHkE8mwXJWNM27jXR4uQnkc9KNRmKsQQEjl+gvgdnX+CYPhODQu/gEBkvBDUNngYxTR+c6jFN VmHZkV0L3690ERwTOb7O4iJD2TZNBKvWLJ2sCrMtHlC2zfSCPWe5nWlJbMtiGyiCaGyPKGZ37dvA Gt46rVfhZVWLWg65Mb+ULa2dtLK3+x1f2pJ9FKodm4JxIIy/gIhPd9T4DVlVdfVWh2rq2rOB6l5Z NTsC7zC2sXHydhMmwtqIxYax4xJkIZhoGyZXxsaFrf7vxsbNHQUU2DhsDc+wV9e3cY4ZnN2jRDhG s1M4NanjtlGLs3F2JJER6yiSZWLE1Jk4C7knbrbNCtvuFt8vllPDFWV8M+faBmauwAFosGqemcux I+H2C48obsCijGQq5OuLd7rwaF41snUfL0iMfoVn67wgMRskXJVmQmSEhH2JzxpgHyjq5pD1kPVf KZ6Xms/lH5jER+JQLprUOA4AVp6Uh4ZEvhl+r/qjXYzeLPliJ+BT7H+DA3z8P/iL/YpIdp/mOKDb /H2Pe2yGxFqw/Pov/MHHeGT7Y7k6xpeGwh19EWiZUiCbmRXg5NSM4c5ptz1OKktQiTCPmM6oI2rT H8ABYjgFQiCv8Af7P1E8JeeOy8Y+VOccy4nl2Oop+xaBD3+UrYDoyt9QPChPsAsbZf8nHjDD8MHn exBij/mtkefGwUuIioMZXgUzbAmhl9hBCNnkCkIQ1nPcYSPrViPCRrVVU1FJ4ZzrPuxKCvAPf7NE UmSVo97xivABEPDjsMf8x4gs1yPZLmk97VjP0GQFmlxqgGWDJ+CWzb3ghhA1QxNO+TP0ATuQYPyT 6h3DpiuHCykd8hgpFZJPP78aDD49KkomhAPBcmZbs5tb8voRoHJczUkJJ3w4Uwq3qReujuVIUCFS +Ma/3xPLyz55WfnDyoo3vbMsL2T0A4sIrbSHMBq2g5mr3CfkArYbnCdplC3Uj6G0bCB3ymmSN9RM rYwasnynGJbzTWYm+17Njnk/IokT1fA9ZwkKdlPHU1T+pnSQY1KMiBYFxxCQ9KCMVWB8R07yOEdj F0ozKcdBSUCqASubvv4f2obllu8WPAYhqFHBNKHZxixGPInEtL2S7+6BTnBKPAWNXc8RkjJpv001 2vQHuSvkv5Bdhf3WeNBNC0TFYwYpRYOocGa/A6jQZepLIzx/AbeYvnBH/h1BDqWDE4zkuGI1AxGQ i2twD8oHJwbkSNATrjjOIEU5+ZQASgf/kGsoCGSlc0gVSC9HPYBpKFX8zSkwj5Pgy0XMxx7yIGcS odzRclIc3jRcoUSE2Awl/364i+46ArA6b81q2g1iIWdywBEnMpyFb9EoXi3nlPYf58TQ71s8N76U Rx4uUCHC7PC1DZyiqfGJm5wzDWSolsPJCTU/et6L6KM+ucSGJotOjOwPdrjfjRBUktxHxLiMzhR+ eoFkH/7hb7y7wIzA0T3FH4j7xf048XUhJ1LgVJE5rDwjQY+BkBtvgFps0ErestpMxT/W5Ve6LSRE qBox2mL52UO3GX+ykqUbU689FbwjxrWh3X9ikiRap1J+KrfiXtJl/4B7Fx2wE4j0/cr/hG4Em/r6 IDzURh3rhiPr8clk9R/LpvqugusnG8QSfHthJ0bejMLsS2DGuWOU80gjEP5hl9COwewq1PnjCWyW ooR8aRhsTG42jPIfaEXA5ygiZAqZ4A26QNEqPrHu9wUaXRCIrZ8ytmRD3J/f6TvAca9cA0cF64yL dK4hBmkTov+NRuNtgMYduojYQdkhKY2NZwqRGG2LybgHTwsb0DM5G89Apkk8G4A6NiY3/gnEdEab +sjSW4UZZEUqKT7HxjB053MQY2Ha0FTigI/FXLdLtkenILmMXI1j5vEdlAFNQmXlifYgvAv57crK i5dtY7QlHBrgo7P484nTXfjMZBjrEp9iaKWQMp79MMnhZPEuDBTpitm5DtGJcZN9dGJdMTqWOFKp ruxSc+BYjuNGo0DJc5wkYhNiOsxTKAY2zxutQv50AYJM72TgeWfhAvIyqRxShpO1FhAilDbGn6Gx IW78w8llLpCkIhlD8eRvIU2eawHgKFQOcrwebApHmQxPEnscXYQBv4VDgpU9HIwfZ1niohMV0bvo RBijAL7QZsSeDlhIPCqKkE6crFegoct4QgvKnadEhJYcmyTl3JHNqW8N7/KWtp/QGAY3f39TLxHn siP2j5wV4w6SjUJuIgVDrrfzqA7EJNuOoszBPAaaOka17cOUOJ4HGQDIdECBm8zxBfgDXBayCWeZ rqZVcb45DqnCLqGG5yiTmu3O/CVZCapanFNtyBDhL8FgzaFjeB/HK1GUFs+nb6pUlHDzF4dM1IPd ByggmVyytI6EXdlbnDMY4u2rB2eahUPIDOGSmSENNRD/KH2yMlEDX8E/HJR35D5wymKS7iEiNZbv UZkgZ+b7RL1JRHZIg5IbagxqvEutq6OWG9Tjhn7UuT4d1PnqEfZrxFoq2pxfNqYXhCo1bJIxh5cF XpBlLRtQ0zqEtsbATxJRQkgNNtKQhI2hwgiNG9ccTkFMGCfqFA5mX6Q07KS+MTqdmlo9gbU6hruk NNGIGI5OiOX7ewkjKPxVD/fMHmq2M4pggoBUpIT9qJ0nEpOzF3Yx9ppPkDScxFAzzJIvFG1fbayO jWnkVBEOik04tyFw5o0UphzcgFR76CCawU1fB/N9qBMzSSgkw7EHcW5gGCAQt9BforyQUpwUCkPI r6FIGSKgz71gj4UWFMOVKNRZgL9zBiTsJzqMJMg4F9ojIRl4x5ITgyOpwudpmkJJpUeD5++DGjik Guu6+QJi7F6LxycisTDo6p4KfEQch0T4in5ZuCsHoOMcgkkf4r7KniKQ8tOnMykWW/Q0h5Znv5hj IZOQZUL7E8paGH8Zc6K4axVTMjRQqwOeDb1ps3pLUaYKJJAhQ7NxMJwyZKo+Zhebf0TKa7+hwjJW 1oMhJ1bdPbrTKoWU9o2D9SkpzezJLiQFf1tD/Y+q0mhFDEXo/JpbqlrOLVWturNJ69CasKczIuL2 0lEgUP4okmFUHkoIMO/4HCeNsITvG1JGYYgHbj+RiC5iHEB8Pg8nDRWTpstOpI0tjCDQr7rQapoI ck3AsDNbJ71jTmzoNPCBIUnUWgR/G2p5lRbZ8SKVAOZkhTNhuIM/KihWZnmYo4VGmo3mQTKkaR2W gCmoLu5jEmsUj2BJqUY+IXoadxsdbIjtG2REbbVtgfLbNs9HJ0tk0aErPjmRzvAWVg8sbz0FM+1V apuYUlv3CQoXM8XjFBEzmVJbhVVcUkFhdXNNm5F7UTeGy8hek+6S8XppM+jhK4ZeGX3F5xdwMsWL 0v01VBuyjn/HvEDtYrRdSimKxgvdlUJ2J9rPqAZx6Tg7T+exBqTwKEkM6hFSYVKxg9JKe4fyPFQy /iqxmZuJJ1ZSMSbv/xp/ArrJpFI5hsZ9B2x+ji3EgobFeBfh1FLJ+dbK54VbzV7kBytMOIQqfSx6 7/IO/M9VIO/GqSFJiXAY15BQ/M0P+W1Z8MA08Qlyhpk2GiP+ITVphZgX54OEhl344oHUcTLpKzLY UM8j1yAfC0KwSmbkcHwxhyPiRJVdCA2kjhPGk1/vRqXV+MpXXmPTk3yVQKYsQqvtNCCyn7uS0+Gt AcFKaC/b6/berSEbprDVfdKE3FPYshMrPxizcUvkZo05vMZuFzUSWVOYeYcw74R1nxmQbRSlnMIb zMFNmVKjm0I5Io+T8Q0iD6F+ISNGOs2jlIvQ0TadQg1qJJJVmKGC4GvCRkp0+BsbObYpj0GfpXQe 8US0pyRHGGSd+ebdjjyfdZZCp+ACugY2hji9wx2SpqHq+ll3oXZhKoWmgvTmb9RRVFxWOapk6y/L KbIP58nnUVvZ6xnQZJbzdiol2Sib1djv5ZQSjm7qsDy4D2Q6+i2xmxn7iH/LZMputEYsuGAP2Rxi O9USDVcoUb6Ntpz5X2BCuJJkO1Z/GME2FhPiukPqZnFeeqK3rA02OFw5mcN54Goe7yphnYUsMYfy RbrAdY5jynr5+sKNbOZXO1KKQ7EXoi6m5h6CUReyqxJH0oQwz4vscmruAxkWg9sSOeoFkMEpJRmp DGkYSOKQQ/1l7Dg+sM7CfIamxpFaWdtgLzr5IMY3uxea0s0vaxwI1MfWVRr5Ji2N2BujT4Ibg06H QXVeHcPFXszF++hBnNtQZqITZjAb6MFb6gTFCxFOghwS3YhOmIdsEFqx+PaF9gj+otUvFTW1MAkd Wn09KXb5nhqejhSfd8LgFRex0boZZoVbhdmhL0EHYzD/hGrSmGiWsZlb9LktUyjCxyVKS8mhy5Hs 0xnvAeHnfM73mAakCUzASlQ5D5AS5ROz1XQKfWFOFkWGXRnqcgYu8BJsQmcXdWfN8Bxwj/Ackhef aBhtTLs7JUFYCD45xcg6gTnFaPBI1YyvTKkZQXMTvngy97AGRnOhpNV9xOOG7JLRVMTNASw+N7UZ kSGiRJsZBZKbXcIHwsHMm0JBM2zPeSYrhHJrnuSP7Ppc053hY6Gnlr7/mb4jOBztc/0A1ijuYzJq HKwluYdyyWwQNXI7VQppy9+ImqEJJ4XLR+izGLeRKYlQ2IwUpBQNh/fs0Bo47t8/lOELTX5K3TPc uaiOuT5qzZBDSIVSZzNDYhj9ygfZNXzeUIrco/oMF0RCvh0yuooOJxmd7GZeEb6YAQGDBTKhgZh4 /AVk0PlnUWjf4w76iZxtWXr5nN5CeWBZpFKnzMrZLWGkPggY4EiSUQk3UaSCcHp8MUvuA75yI7Eh qgwQmPXRgUCoS0ItFtYgs8Y75D9OUahnwueoBMOhX4GZUab8dz37+LOYRL7UxoZe2GiHqZXvYUXP 8R6Zhz0gM4YLGVVcTmbWd/JemD6k6FIfkOhUC/xDmaWsUjqnJZicfKDFkrxiuqrWleGgsOuksmAX owFCfU4FTk5iVwoUWWgf5b6PJFG54zOOVW2+N3qTIohXoOxpqMhivBDhg4DgJmpiH+rx0BlQVtF6 X6QbrYp5FW/5YFiqEC42kUVId743RJHajRM9OSZ/C0+mmFTxz4CvNoaL9cD+E1yozwNNuvxjYTM0 5Mw4jhS4w3QYu1j176/+vgOi8JU5P7RzXFI04rV7bckGR5wRDsMXWvFWtAw9d+oDTtOVdiX4wuHU q8f5AMekHgmxHk3v4rnzNWVsqKyFs5Cj9lp8TmI6Xht4XoOAZXIOSRqSlNQzs87a1FBjUR74BJ1r zkyoePkcnQUOxp5cX+QD7PlIyz/544m+o621UZuaJy6NECU+zpkJ2ZK/hcaZ80tYqItGs73PxC7N 2NIEFjgUDlUqkSbQzE+omkxrSHbiqHnBmq0FITh5gpLBV4abHDkNpD/fP8tZ7KqAs045h+HzBNyJ 9+LpuIWOxMmmTRtrBEOdY+y8+UvCETlipR5xxfskx4gDRcvyN8obicNGy+q+sqXccLBTrXpDavJx TqZhHHWrWGQxqUcq7eb1GWxex2ck8XXCYobYg7wkPHfSweg20sMSQoVVxIu//QkUQGqKD5p1UKd5 boVspA9uxLyRTe+TtheYDtJt3wfaMFSDF3uEDvuIA47fxbfYcLrxbsAHTsO9Rg5F3atvm07Zwzm4 /g+RenWFCmVuZHN0cmVhbQplbmRvYmoKMzQgMCBvYmoKMTAwODgKZW5kb2JqCjMyIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzNSAwIFIgL0NvbnRlbnRzIDMz IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMzUgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9u dCA8PCAvRjUuMSAxNSAwIFIKL0YxLjEgOSAwIFIgL0YxMS4wIDM2IDAgUiAvRjIuMCAxMCAwIFIg L0Y3LjAgMTcgMCBSIC9GOC4xIDE5IDAgUiAvRjkuMCAyMCAwIFIKPj4gPj4KZW5kb2JqCjM4IDAg b2JqCjw8IC9MZW5ndGggMzkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1d 65PbNpL/zr+ClqizTM/QxIOvbLTJyLGT9Xg2Fdv7uIo2V6mxU5srO1cbp+r+/f010AAf0lCAHE1t 8oFDCAAbjX53A/5X+l36r7RLRdcVnW5kqquyEG2t01o1RVnJJv31Xfq39Jf0ydOPIr39mJbm/4+3 GEY9RV2Wtql/U3VRl0q0aVvqoq3qNrn9kG7fpJXtyI83H9Inz0UhUpG++SldP1gss1W2fJS++d/0 2RuAdQywJB6wWhWqUVJ5wFIDWDIL2H+FgwRcJZG4qutCtW3ZTEAa4yqZ4OrharfePYrA1XATk7BN bOtCl1VTRQGWR+FqSFdJAF2Jqi7KupsHKX3zIRnS1eOLbHWZLYoneblbC5FLpRdZXpUyHNQTKE3W ZaHqsptgb57S4rAXS2lKgKFLJScgzVNarZvsos1WeffZZ38Ix9gJjKCarmglJJATGpY358GLw1gs vXk5JnVZaK0PQTQlt8/1Jlvkf8ylFl9E4YuASyKEbNsUXalVOgPbVGycF1uiboq2Ud0cRFNsPf7y arvKNvnT3fpJ/tWznMjseTjaTmFM3RZVVVdzUN4v3pQqC1l1UXj7Wu7Wl1lu//smHGFGDySRyrwr hCw/hdBUJYuqBWtL2RWN7Oq0KspWt2WbirZQWtQn6Kd+UtUVlaoPMed0I38YY6qf4neFqylqobGd 4XCdlzG9GGsaAq1uD6Fqypmng0T2IbT5rIUII1NKshCbCqTQtU60ltBQFQxKsinf3KZ1bYxN+7Cb WXmD8bmVr6ZjkMF4ApFVIK1OArwJnAcAE6Io2ZRNx2QWYV2HWEEwYlutRDcLk91Oj6zv0/XXj9LL Ll1/hkeVri/xkOn6wr5x48o2trZxgUedrmEnXVbJZAD/Bgv0UqdrHvfYjts9sk+ehn/krotHCU26 W9uRZvIpNAcn5/EM6RP6RLJ+aL/U4IHFHPwgd1G2Jz/M8B6KDEApvwz+fIkRwBe/OYArO49r5aUy Gmv8qBOHDm5krDCM/MBq/pG+eXE2R0fVglwwNaGRZES3oBF4YJ5GCO5Q3+sU+845hQ2MqU6FCezH 2L4ImGINPA2LRSkNMTQD01QyxvmDQ5ACJSM0I6z0IyBZ3zmxvvOf8t0uv8mabZHlepXv1ldXYlvs 1sutXuQv/+f7d28f5pvrqyu9WuaZ94fQQYjt4jLf7h5hTH69gZ1f6Gtxk6+y3XqjF7t1K57k2ZdX WbHMHyUn7oSR4UcUQq+jyBoSnQwJGSx13maAvBVZjr+vxG4NBGAlZmX57hFwoTJxlb/aLlW+VBnj 6MVZlwLFVlS6qtMmYikR6vYUo1dWBBKIikGyFsC8N/pSX2T5j9er7eZmWxAlbXK1WzcZiOPyGqi2 TZdwEFdnxaeCp9N2pfDAh5DGgug6XHacgNOeYgWMhBJCJCCWtFTbzYuzggVTu2skYSsCrAhMfZLk LwWsfYepec/+ZUR8ZmjYIUQZYkTpupC16iD5Z2C6X8mvu0I2bQudPQ/SRPI/sML7LulvhfeG5GOQ rHxm5CQ0gVEmVyvdbG+gFpZg/ftSAXVXFrUqdQifs1bb5Ntl/vTdy28h9KEEtmK7BLzZAWV3Ztkv VFE3iC7ErCGC+06QU1JUBJKH6JDzN/WTI0S/EbRDsZYcj9xP+DXEPtBAbKWQlYigjT28wsirVFnK tGrqAgGXpkOMu9nDKVmn9B/yGx3SIV0Lh7aAj6qEasittZJfpnUDU6UTEsmTQmpENURZNEJrSTP+ dDR/cQIWvM6pGwnIw1gkxobew4XZm1lX3tvQDqYQPRhnQ8dGuhFdsDb0GKR5hdOFq+XJzoXoG4Q5 2qYG6c2BNNU3+UNj0kN4G+lbkFUOoXaR3Wxh5G6yzcZYZTtyUkNt8xN2GME/pM0QvhvDPm893sBt KAD2AmHK3fr6Zquf5aRKNN4WN3+HZb7Mvlw+M29sV5KBPrUkD7PsaAOevjaJSMueyLqUoqsRWYQO qdpWqip5/XQvV3nZJyuRogFbw3YTlU47xCMRe9IpvUq8IuFEAuN9+pr4OemHUbrq8CyIdWIg5Vpg hZl50NDCITcTR82EYdICYMFrEY/CLMrBYxbeZ2Cn8JAClVUzXBUCzXurOjIL4UZWiJong1WZhr1V Bc0EhPOqEgveZFXH8r6jzXe5zGRWRvVyE9vQwDUzpvpYHthoCPLR7FPDh7yCa0mmxBOynrINTIpW bDeq5zw0gxFfgazzZrdebTN01cYeu7lBWgMcygRe6IuL64VxyeGhw2PKr1ZbDAE3P5B7RH+eZHxd CQq6BnnWi2z5Sq++2FA0gdjSJOfR+OxINAHOzTmjBLJuUXKgRBqzlj0z4G70niIcYQSIVsK+YvSG qL8w+4qF+nkMqp4lSMSWbVCNhnH29yy+89RqdJrwivqTmgEMQWzEXkOMxNoVPc4kgKu9I4ssLKkD +7C2NMT2vSQDfCKlhtPYSpfaicmjfHOfeZQxmKNwNDsh955GmQHJGmQ+Qo4syhYh/j7VMEkDZPgR eQTOrRSUDUjXJilAjQkNdMkRziMczpxwK89+KBGRrI8nInxC465EBGcgziNfJPJhshIqZfSyMz/a catyPXpjEhAnSGrPvUhFFxqFa/9BAqWqkWR3SdBRNdrUNc9j3LmJqRTiqCAKhZQITMy7QZq6KXHO XHRCRMKZa9pmHqBRUOy7/PHi5kpvF8uNs1dWWaEvF9v/RgoAvpPIN8sVIsSwb2CtTTIimxd5TkE1 snv24mAY+wq1Kpt7stkq2N112QTZbF8s9CtyFbNcaJf7oeVRi40Omtje4vDCXN7HoQmjLs5rzCmQ muqQ6YpZZISC/yQRAZtDUzmscRTmPd08JlR9AlAoWEKougJHRgAVx5OxhhCZuk2r2glIY4dqKrm6 XK70l08MT2WrA5xp+fC8oQz45V1Ziwng8xtMtaNjqWESppRd3FCOjJOlhq8yFjz3JR+ocEnJIOP9 RqPQbqGXgHfE5Hn+LbJSlDNd0K/IEqwysc1u8usrZI9bOL9egJhMMb3uyUU3+qzuX6/BEXEtRRuU IfAS+yZDgfnFFsW/tIK7ZOR5ZZ4sUe7dSdBfxAruS+aVCJtWrhRrniWirJBTZJ63QiKAOrPM83bI CKR5mXf79xjlMDTXAqv0G4HMRFN3AGO4e/NQxSFqaLCFWJANKvpKiWDqHEhTGxIm27guBTXBlM6D NLpAZO0LiCNTxIFw20vOTb77vM63C8McSXT9X+hJFmAVx2Kgexm9ITlJEi+fZz9dI2J4VmWmkMTu BILVDrgQayVu72MNA7LpOonI+RgkvJoIiX1MDYN3nz8wdjjhLRxhhlliS5n5XJJGFhGJOouveeAe 1P948O3jF5Fw8XmpQCbGGaAaZ65EGgHXHqYoSraf3ByKFEPzyHsiI1x3SGVgo/BBiaC9+wtBdMBR aESJUw2XtKODYFoif0z16UhvVrA1BM15PL15gtT3+l0bsRa0P1GaaIKNEGnm/eEZmKbCLI7HhvKV uARQzSYzUOFjHeJ5iEYe8Q8n6yEvKOczLF4PRQD1aWgCqj7eJncfQvRqKASiVCR0BvE2f0uus5iY +04ThQuBE4ifGA9luxAC4cTvLfmbcNCYB2KOGtGxjVK1XQxoJ0rMwPItiTpGKgmcwdWUKU8RmCa1 3JWUR9YQmEp2WuDQQv9XYGq5a1rIXTriU0qZfkg6U39i38vAZC4pqw4HODTPQ7ll954g5V1FzUP1 LyTSOwRkaR6GD+8q4RR1QDJXIMrLa0rxN84IlTJ0PWRJYQxlyzHKZMrtW+Ra6Lu0flqHgYfWwLg4 IZV8TPr2OqrCOQx5UEeB9EbS91N0lLGbjoi6XkcFwMSi7ncQvnv1EH11RK+jgiDCAfBk/frTdZRR nJMijR6oXkeFA/W7oGnCSQOInKukLUQh3sUPvirIqSVfAA9nqUDR/qPt5fXKOUxkVCuKUiHAu1iu nqBAcqUv8ldqW9iSePPj/YRttFaFKLs6ZJnDgNtfNn814SnyBn0U58ZomLN5fgI1Ki1pmAiY91TM 71pp0EseZJ87qjcMCU7HpItOsFp60RMBVBxTxfqgvewZgTTv5n11svAJ9PF64RMBVRyiho5EiGvT W8gzIE3NqNeDQM2QR3083/FouEV6AtnRoXfZ4AyZHoE+H7Sk2O8Ny7+3GsElHIk8Y9mkItsGxzTH IM6T4edvyh9gl4XDNfRoAykR592oXFlFAfYNkqIPTeb0JWdOw2E8YX97WYc4PWo4gxJxT3e7n0lF DHXgDa4XKJY4xIZIIalCmwg9b5BfoHSp07pKNQMfou/uSXcolLyXTRg+cagQxStn5BAUL2lNd1jE QBUnE6OVhyp0RbcejUGa59o/IWwAcUJJMUpsGrsMVxldrxaTQII5kdiXG3AWbXNW60viZqdW4M4j t6IQajS21flOJ6NWrW4Qf3UgBVky4aQIoRi7717goNAdQXXHIPP7/il+XYiC9sbVHFBTBR3HH0Ob ISr4eASkkf/7h0E9jnU8bvQkE90zxUGjAnfq3Ex5ab3Jr1BIfVbm6ckCl9vIsgxKtH8NLX77/PVX 35yXi1qE4+lIlGLQQrIZEVpmaFkERuV6bIFyS41DGMZDGTPRlF6jymcmQJlg+ZFwuS+fodxUKFBn ZiJXPnMEpBETfWWK0pD/xJlMX0XT13JsJuxBpRsZzt8IVIBRFdgWtXAFyjqoJs6dlfTh40EJ3D2x k8K9P7IOKuAYC4RVdoWTFVgGTHnUpnhesweJ+K6DQwu7e5p7WrJsiqZTQcEPLAwbvcxETrlRWuN3 z1+/PrM8ERJB4ZqsMYb0P0kro5pY+5AHV9qHFtzPZ0a/R52+wG0sZfrW5kSOnSdLA4L+ZGNJhbPc nTLnvhD0x+VXqCf0B8yCg+wJxmEeHExDTp3C5PYIF7/aafy1cUeOriZVo+BOIWhfUzxC4iTUBxyG nba9R1tVKFyV2ferYBeVKIlEC13Q0UrM5VroVA6Owd5i2KTpeEM/KKlxvaOC0qDPu3kquH+o9BoA hPCOhneFFge2a7lFsA5g4+gnpuJe700AD8WKdECH27QWRdUA4NrNPmixINBUtpOHyjVglO2z19AP wsVVFiX0efcxhzeKKFqA3B44sHts90vp2/Z6JXst2IJ/IjUv0/9PvzcUHXTwUYmySboS2tGefKT3 1L+/T0EvoDbcleDbENrAG1p1SY6FeUNGzoy/Tcbvc284S23GdhQHRyELfQszixJlcvggZuIvixLl +gYu89ct3d6n0A+t7+miNUgHFDKYd7Ad/WVnICYE09n5RYJxw/fZN9fXrYu+Q3PxqhP/VY8VA5N/ Yxj9+/jX0Rvg+qc5YEqZgTvPsVJyo6cmCk/TJTMfhm2G6JC/67sx0aHlJKI7QGKHiK7nRUfSB0TI QGA4qHo+PyRCeIXD5fCqsURbgELAIHlIzK2Qou6w8xK02hAR2ZsFTbXK8E5ekvbCVViUXdmYRKip T8JNdPzaz1tXEEDeUMF1uNSTHybNB0mF+ah64M8/v/+Y/u3dz28//vbjh95bpRIFP3H0dzSuRcWp TboIz3wOW8yfe3CuT/QrSnH+GfoLeeL6M4W708axoMN61UX7BnrV3h09TKYPUuhRyXSvV5FZ8TrV JNWD9SnpYZOohlzGAWRKQZsENPLQe8rUlkoBWFcg1f8FZvRUT3tU1iCSgTJ1bUabsTL1bZ7uNRSd wpHsQQPoraKC7v22oJbhOFxEBZupBbf080tcwQMqR4sDCpXINV041i/HtQy0kOY2I1xYlLi2Xtxo N7sXQCglMzBAM+21QbiwbvS99luG4wAy4QYo7ftZBGIqBxTvBbpYWwA1InZ3DAjTtr1evcQbjDtV qYquIYvNKi76e6BMzW9W3eGGEaO/+A2UzYrRUDm1osABrXu/g5QbMyeQImVrtbRXmijbae23zV9W IcGcROtAaZp3o9r8DPyGuVkJmu/0rf4vp1ANdKwghVuNV5BmpVZhEw5YMY5bk+HvThly5c1BYTFU hr5UsVeGib6bWEAaMcSCqZiA9ojlIJH1fOTG9cqwn6vnyLtEABDVd3LFmD3pJ37Ve8pQS5jopAKd LsQpMgnX805daMrojuoonIfC9V3uUJRTghNdyLcnvP7t3c+//PhrevXL21/ffXz3S687gtSh+xTH qnu1WwGnEAGowfpUdRj8icPqUONY7lAdGpoqYZCRJUKnKISSsBxwRhwaG3exdfv3DBlTYrbUE3eO w8rDlBB8sAw5nIbrSsiMsA9bTA0CtVYBjig/xbljUabr/8MTF5jCErlEZZZ/vsN7m66xI/Trb3jg Oli6VlUla1xcO76W9Piq9iJyBNt8rahu4YiVdJnTzLrs9vrrOLAuukgVgH+JR5Ou6T5YAE5HpfGg k9e4VpZOOsO5da8CrziBTbe9YgQixXQ6mwdq23iNByalI9voQtfDmp7mHPd47p9GA7aYjG++vfPz dH4bc/MHN/G4daaUd++PUwz8WkSZ2lnUTuvvJ0Fhv+ckRnDtD+SII2XEUpFJQt3g4J/eCMw6Mylr WPAweDifyzR8v6QctqzAumdPy3ML26dl2O5Etkwh2ACiTCZJJjuU9BItMmVzI/dcgvownAdwo7mi GCPo3gHwAj+4j+OMK/wImmTO2OINFxaDNGm6MfUz2XKj6Zm6npMv4nV8l0AkCXlcO7fs8D8r40gI URtV+wtLRtLQY9pLQ14bo5EXxfAzbnAng2FmbqUrmoFGh84hqtI17wp35d94HoPxZDqQu/7F4viw oOLdZSnEfeiqbGwV76MXYoZUeFW8HB7Oe8RExZNxz79aimFgHDWw9BvPhj53KIG7OecESeV2E4eY VDOn2/w/EQQdwNTo9oa3ihHGi6NrwIE3bhwjk7uM8eZmY8QxNsxNHRDxPAHj2DwS1zimBp51zJXc yICPIX1sd5iuKIcqZtiYQ8d7ynNy43gV/ntJ9LYN5fiQCWeOVbhtowQOzDCb4JvhwQS75sjNIRoX ztAOHaRXXpvryntiqD9xKGKWcH2YC/nxApNDmPI8P4+Igbf2GfDedzmIW4bNQT4Wm7yL9kdPDAwq bzj3GVMIk+aYlz2FJAN5D/A/aTcjtTKCnAqHEg5t58RawHYyvfIKmQcZYbw1Yzp/iU2ARL225M64 HKOUh/O4MZ0f3CBWgQf5ir9H/7gAyIwpgWUdf5bn5D2DafhJ2I7kHUn2r/ejjjAPY3QMsBNOjDaW 9bxExp5jD0NfieO28TxgluiFnyLr2wo37mDFerT0ZGbpZt+8g/VvlI6DSAplbmRzdHJlYW0KZW5k b2JqCjM5IDAgb2JqCjU0NjIKZW5kb2JqCjM3IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg MyAwIFIgL1Jlc291cmNlcyA0MCAwIFIgL0NvbnRlbnRzIDM4IDAgUiAvTWVkaWFCb3gKWzAgMCA1 OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKNDAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjUuMSAxNSAwIFIKL0Yx LjEgOSAwIFIgL0YxMS4wIDM2IDAgUiAvRjIuMCAxMCAwIFIgL0Y3LjAgMTcgMCBSIC9GOC4xIDE5 IDAgUiAvRjkuMCAyMCAwIFIKPj4gPj4KZW5kb2JqCjQyIDAgb2JqCjw8IC9MZW5ndGggNDMgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1de5PbthH/n5+ClqhGR+t4xIMvN2oq uU7jO189cS5xOlab6djONK3dTuvO9Ov3t8ACfEhHgbLlqdsODxAALhb73gX7r/jb+F9xE4umyRpd yVgXeSbqUselqrK8kFX877fxy/gf8dXjDyJ+/SHOzX8+vMY0GinKPLddbUuVWZkrUcd1rrO6KOvo 9ft4excXdiA/7t7HV1+LTMQivvs5Xj6YzZNFMr+I7/4WP7kDWMcAi6YDVqpMVUoqD1hsAItGAftV OEjAVTQRV2WZqbrOqwFIfVxFA1x9sdgtdxcTcNU9xCjsEOsy03lRFZMASyfhqktXUQBdiaLM8rIZ Bym+ex916erhKllcJrPsKs13SyFSqfQsSYtchoN6AqXJMs9UmTcD7I1T2jTsTaU0JcDQuZIDkMYp rdRVsqqTRdo8evTrcIydwAiqarJaQgI5oWF5cxy8aRibSm9ejkmdZ1rrQxANye1LvU5m6W9SqcVX k/BFwEUThGxdZU2uVTwC21BsnBdboqyyulLNGERDbD387Wa7SNbp493yKv3dk5TI7OtwtJ3CmLrO iqIsxqD8vHhTKs9k0UzC2+/lbnmZpPbfN+EIM3ogmqjMm0zI/GMITRUyK2qwtpRNVsmmjIssr3Wd 17GoM6VFeYJ+ahdVTVao8hBzDg/yuz6m2iU+KVxVVgqN4wyH67yM6cVYVRFoZX0IVUPOPB0ksg+h zcMsxKpoMg0L8R6QrIUYWQsxfTZBZ3cpqmu2RvebrZAMslSFioOAikVEZus067CrgTqWdNTazsYM 8nZ1ITJZ1aoOBQmWdLT8dfosWVTbLEk3C11tb5MFCdjdL9zs88CY6X+CeBWVht1TywHA43ZPkiq9 StLbLQy0dD1fbGeX67S+SjM9211sL29g7c63esaAR8ddg/sOf8xnESorC+3hDnFZrs+KSiWKrBCl 8CBZHhlH5TS2nWxCOseu0nDcRCEPse1Q6KYPvwjH0+DkQrwCDbsROhRsOwLUULx9HNseE2/Qd7Wu 6uoYSD3x9nX6cHa70dvZfJ0+++nV2zdfpHWS7pa1SNK5TtVuWR1kFMPka/BHcnuAaa4volCHeoD7 jny639Ov4eZIcDujPoRr9kgUxnWh8lzGRVVmsIOqBq5ntSd8skaZfwCmQZSiqSEqs6bWSqiKtA1m VUJWmC/Rj7XiAtEH/AwRR2+QtaY1fz4aWDgFD54xpMS7CxmEiCmMsYeO42GYljEYqBABMo0xpgqQ ljF6II07eU8fpV8kpM/We6RzJGw1zdIlAqqEhrKdABxzavnq+XmBEzAFyqaBlJsAnJUZFO+ob+Zz PUsTHwzJKBgCRZtuZ9s5FC8p2OuOnIadNGYanMIjsswE3EO3gSAW6UBk4pQBsuLxd0ZcWbkA8ZSL poSnkUO917VURfzd4z074LI1wBCyURXBpusiLvE+xDd1TE2FmGhNTRm/i78zYqSdRnbbcBXiN0zL iqiEL4CJhV0nK+IC3WbhSSthmjYARBa8ohZT4amwQoN/fmtYqkKsz/ZN3x/N1WY93iKvZ/pO2KWH pbNVD/Ngv8cixAMiDTEmWl8JoeuqOWzhDI2Jj7FwjK90xFtqBfkEoKYJ8qFjEm7hjIPUs3CePv3x o124aNSvhIObi4KEzASwPg5T4PsPr0e8SlhIucolPIsQkNir/Drd7RCrbsX12np063S9SbItvCIY e9tZ+vsv7/I/P/r26TcTlM8JloQs4RoLDVekt4dxV+Tx22fPyYJdJJm+nG3/mNx29YuR5ver7xOA VGATJUsY3ROAnIA3SJOp5o6XJiWkJEILYf7SUOfdj6UTBBzSe1JSbq5EMqxpQSI9V0Aj4V989zoq S2Nf8sOknwqfqlvbyDYNPFuqDnGhooHJPoDzEGACSpCTiHE47k6gMGDM+hN93B2CySPrVbx8ehFf 6nh5hUcRL1f28dA+EjxUvLzEQ9KQiIbsLuyPC9vLQ11v3fuRZ/I6SAnSq8zEaLlb2ia/ubLLIY5y WfIY/2a3+OFXLgAXwOOZORZofMu9pEAvYOcxbj3ebYkfW7j6KGCw8PhTfHcdRlBM+FPyJbJCyCKH dd8/PDQ7lG5jF/7wCJEnes+TjI0SoquC2DoUTtkzNn7aLWe3xnQXGlY8Ge7p7kIvOtrCG/c36xuy 86+gK+CiV/Cg1kmVIJ5GcbZks6bAAuIHcK3WiDTMbtPVjZhvN4g4nDds4NxlYxcXZYgrkAhoQ4qN 7JaLxO3n9jpNH8zwX9QOzJL5ARQ8SV8o1BWkc5WkCcdX0u06tbgjLQqv8qwhEr9XicyTVEGhgZe3 CXa02oaT3wnirEKYpIJhUjJgh6hvGMxDkOllerMmx3G3TCucxTaZX6V6d5Gukt1yfbMwp5SCHF8g szcHqWU0eJXMlb5d47jaINeKkn4wED4T+pH+RsYpqBblpY8803ZfbOeK6Ge7SPWLGVMOcR1C1ERW 2KJhIBDgC734ypLkmiLa2XaR3azWc7AWRjwhlIHbfnv1ubacV0gfBHEX2ZfI8psj2c7Qmnf2iZCk Njtdby9nkB10oLT9BPEFgZOn0+/yFzDwHHjx4um8BwxLoa6ViMvw3RLTv8ReNxs637MymTcBC4SX CmTfQoJwjO63Xz4gAY2CgluDXyPW0UOExF0ex2ZLINsquaI98Qry2W4n0+/NcI0jgpJgMfoDuQ/n PRgn+Iq6oHB4kOAjMmqpDIT0ZvtV8mK7TiDHIcBXG6Gv0jde7+X9DFEqF3quMy3Aa7SSH3jejSLO rCnENGWjE5zOE0S7KiqE0AuEwBn3YVR3Zk4okBqs9CSYJqDpJP8M5QeICQ5AGg9Hu+RqOLK6blpg 9V0rNipgTRyuPRoqZ1TRbDYknB0bsKDwbJCCXyAgjDryg2gfUVDFZXcf3Zz6Xji1DYtKbfIhDXI7 dh8hph5sPLJnwcFraNeLm1lGRi4ZD6RW/G7Oy9QIJRUK1XJTAJ9AracwNUJJha6FBymEqaEJwgn1 FKAalMapBlzdI9Tx0NAEPJ3E1Vx+XJQ6C6oLegb3+Yx+nkYiH0URUBD3AQQnrxcpteUbz2E9z9aC fTxYjka32aAfQu7hMJ9wrgL1hSjMAf3fB/NQ+nxDJkhP61JZX18gpbcJYpecqaaxDx4+v7s+LyOj sh1ZPaRcaCMh4udzGYQamZODLv8QsxMAGojokCiEjwgWEiK6akFCzgz/KezDVlVLFwNEWOsBYjoI XVHAB7EhijzZVngU5wSyRLl8KXPUVfeBjRhKDyxxEzJsnyUsCE2hSyozCICpi0CO2VHIDZiDTKQH amXoYaJqQKuJo4loCRKgbgoF+l4bSxSx+5FDgZkdSkE/DKVgXTtEIJBHq1OAEb38o7AzeHF+FWrt aL7CA5G7A4t6oDA9/MwHBGpILB9P6sicEvMlrLRxAqUzB365WpD2eKJMt0CNp3VaAw3h56KS4xWM nNYh+wWxKBPB8oE4snVWa+NEe2/OxhBIOLZe9LAczjqBfgr9bG2784pT5I9VXkGX8b5DJCpKEcMP 4wSp0B5GnuPCEbIGAfd6nD6Fr5htUV5i8XmZ6PWGNC7FSL9H6wdjjOKAzKnV8KLT9c1moxdzJLSs RcrT7TluZ5m4uUXFBY0871E4B1vDBoOLEHISG03RKGH3+pebxXZ9uzXWtelEWlGYIN1ul2YJEpBz /SJZ/LhOsjnscYQfKOiDhN4GNfuIxSJ6ipAf/peasjWDLor8GXz8QH99pv3j6kgpRFCAYaPF1SVK XdL0FeyPhTtcCmG1rOR3yKbX6mY9x87PuhuJy01SKx3rCbuhgB0FsRDMQcQnQaCStrRMQbf+IKwz dQNX6qzwex7USBbXTdilP8Sg2hy3CW+tr88qKQRKAfMC1qCDMkRS7Amvw1VIRrV1S86OVSyi2ga3 J+tYmzspKFjElcumgAEGIGGyakmi8Lz1inTds4JvEiI79tBwf2L6FBlOyJCVMjdQCaSQk/lcFZQO TSEwnde59RWUfZDGQ1ZPmx8fIAV7ijkUGK9C5S4KnlGeOAWs56eBhNBTiF+D2ri6FEgMjIE0zK5O O7ypVVOwneqqFJA+zHaWnvqHN4wFnL1oCllxVE2Vk4D6ODzBwB6tmRJI5aBoCpIxBE9sXKNM2OcW n9iU8CqhOyXzxNcPm0SIC+AiSupux3CpEuwa2H4L6FNo06G2HBH67nr8sdLTKKD0lEhC0P1EqpWl P3HzjircwwpFSY5jCipMMam286mR40pO2Ar2/XhpXivUchpQctTah89WlXDQ47Y9Qx+FFsyqCpcF HfTcCIee9m9eCuixewNKC/2UgtFAwdeaPVQqLJFON65Hn6WHAR3kTVHC0cmQ9mxqMoqsJWcdC9jR ZM8ZP/F6SJX36+CDnjZdlLj/BpxEHUoOCQWLxG7m/8As8E6OJHnu8DseX55UkHuCreILcvUEoKaJ zKmlhq1d0ANpnA6ffgu74EQtHMgfrRaeANc0VHW1cJBh4LXwCEhDw6D5mNLlEKi8Fp4A1Ol4ohAX oBqVBq0WHgepl7lAjfdud6KtyTnFo3Ap+owLimn73Ncn9aEV9XGoOmqwQA2oJoetGYIqNlia9KGr aTO10ifcIZr2yQiJGzgSkcoxIIeqykQVUQ30vdVFsIs4tkAPtDjWs7tY6JXJ/nibHvd0P/0dIq8N EH3EVa0Q/WT0Zj+8agDlEjsUNJkSylWSkVrerlcmvidQYX9mZYuyEVXoKtbhezmzC+6wi3wuauWc KYOPjFAiyD4sfcj7UyvjZvIrZGQE0gV5/MYW7x4zmUNva0lF97MoumOva0n6lIy/vhVsvEaYR/e8 UH1O97zM3ai2aZfxH2k5Et+JikplqLXHtQl84iNXsKveI00+7HtnU+dktfpxBV1k0aANJBYyXG6W WMv3EBPjbDBt0HW8o50UlU1NiXtyC/y8EjVquGPbAlSCEEpEJtHDYPue1zASkS/EZzywFI96hz6M wx2u2PdpXA0ucDEXPXbxTgdDQEvZQS1UrgfTeNR+TzsPeLJYIQh4KYe6FiaPXgd5i/B2N22fGxWN zvsrInQy/m/8yhD1nnE9vBNoHBRoVuRVzZVAulqoeu13aOOzKEVDBWU8RgmIbfTgk1yoVjItR+vR 6357tMVjkUwjPlE4e7NWha82YHUV+TfTlTszwsDmW6/pszmgU/frO/rKiSCo2j5wIlpuRdty78N8 86trj7V4rN8nvQsreyz4N3ssGdh8i2H17d6vUa8FZvqrudFJhUv3XxyFteSoCwTHl8zfR52+IRF6 /g0jQixlWWqfCMd6iKsHUiUKkiot5zv+aQWE3yGW6uyQd/2O49IEcC4RPMJn2TJBVxhAqTYfqqDe cNWo6fqh5DSQAhDO8sybvDJXT0nDQEi6pl+3kjD2cCjsVuN7dDTSPqwughDEevQtlj/88u5D/PLt L28+/Ocv770dYljSL3zsPWxRtO+hdAy2QbdETJFO7UogqADCRVTJpf50r2h3hPBLhttNuIldPtJ7 X785rGqdP9tRtfbjjZ9U1Ur6+sd7fNGJPutEoapgFUtzTFQIOhYBJoR4zAII+kxTry3RU5RQNBKL eT7gLqPcwFKkXF2X13aUdtG1JuXGilSjJEdBuEGm7vUF9XTnGRmuSsOJbn0cp65BW6ZYzgCFpCMl 0x3/atvuqCPuaVVrxD2eKfH9LLtqp4f0B30Tq2VdzfDs97QCzI/pzmOcAJXt+g5zXt27I/ACzGG7 uxN7TFiGhZwbs9cBcRxN0qokHYymAinmTqOav1ttGpm20XdEsEZpcavAl02tJgRZi4N/ud8VRNw7 6EnoY5h2KOyDmvZaE7d7CoaD/mINZHo7mtK0jS5zK0TcIpPbajlJ72l727/c7wQna0S/G6cR7U6N hjN7dnAQbtre9q8R7YcvU7nPJnS1H1ECEu7AdIcmLO+M0kk0cuR7VHC0w7ApKz63cEfvua4OK5+V 4S1OuurSoWlPW2pQjpK4jPiJtSXxI25auGKkVotB7X1Kbenec0ZtGfyKe7Ql7pM67UyBCCOpcngy ZKhUpLyEkpmkC6FSZ2hX+18cMqbGaIgMHwXF1Za4Qq0hvDRnpCBbQ2aGfVi0w463RgoKJx9T8V0e L/+JJ+7RwlK5FCjKc8+3aNfx8h/21//ggWu1j/BQ0RL3m/uldgHb6tpfvmp/vOJO1xLiEbUoYxsb RNiwsT9ZyKmukS8YA3KqQ6x6NYpooSadOvlxa1sIt1BxImIc9EBYmtBA9YcYyWvybzyPSk8xpP8b XY9G5w0Ww4PKUgEEP/rzsNhkZDrjyscAwmkkB8uPUAgEqqcQ3hHdk0b0wG2QCkWxl0s8WowwDqg+ EzinC+T4jdHEnaaWFL1U5olSTn7gbim1eD4v2sVv5H7jzjUm4PWMwwFsPMb18iA+iy2gal/cP64N Vm2PuX9APJJfjFfQcbVXVU6lfed7HP54ObN02VQ4rsYVjPdY2lO+PzCmUofpFmKi5PYYzOHc2B3z GN4jswCj0a3DTT4xRo6h5cidMXeail7gmGcwVpli+qfBq3kaiwyNMTjXJ/BEV8AEZoUKE9Yy0tii md27Hpqt5PR8QXs7KNFJmdaILg0len0CYHz6GikGuAZOjx4A6+wCPWhXU+X52L48VdsCasjzv1lK ZUrpS1smLUepTFRMfvwjCiZJKP2MZSB+mO5Z7vghRm45udF/FUtts2jkBA+Dgc57hPcxxE35aIQj BxSe68bfjDhADp5KgTZmJd4vsyI/+sKXt8u4WANdELCMw8OMTTX6EJd0SwCmAw91h8CoMbLECwiW LIx2Jyfcsw/BPeg3apkPg9U5b4cn9OXdPuT+pExOyMvtYyc15f9zwp0UbvkXuSuF7h2Up28vtRnQ /l4GhD23h8JD/UkZVXiNU2gNlp/smfDIF2iR7uYjMuiPHGlwJ6OUlQefUB+XrDt4UccmKwBFizOJ 8bnzAq26MWzHL+GTYmr4e4d7zncm+M460h5UbBt8Kj0h/z8z3HScCmVuZHN0cmVhbQplbmRvYmoK NDMgMCBvYmoKNTI1MQplbmRvYmoKNDEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAg UiAvUmVzb3VyY2VzIDQ0IDAgUiAvQ29udGVudHMgNDIgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45 OSA4NDEuOThdID4+CmVuZG9iago0NCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAv Q29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMTIuMSA0NiAwIFIKL0Y1LjEg MTUgMCBSIC9GMS4xIDkgMCBSIC9GMTEuMCAzNiAwIFIgL0YyLjAgMTAgMCBSIC9GNy4wIDE3IDAg UiAvRjEzLjAgNDcgMCBSCi9GOC4xIDE5IDAgUiAvRjkuMCAyMCAwIFIgPj4gPj4KZW5kb2JqCjQ5 IDAgb2JqCjw8IC9MZW5ndGggNTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 Ac1de3PbRpL/H58CJsEzBUsQBjN4OeE6oqPs2govFVvZpNY8X10pdm2u7N3Leavu69+v5w2QBAeQ qF25XASGg0FPT7+7Z/h7/GP8e9zGrG2zVtRFLMo8Y00l4orXWV4Wdfy/H+Kf47/Fly+/sPjuS5zL f1/u8Bj1ZFWeqyZ3x6usyjlr4iYXWVNWTXT3OV7fxqXqqD9uP8eX37GMxSy+/Rgvn8zmySKZn8W3 /x1f3wKsY4BF4wGreMZrXnALWCwBiwYB+7dwkICraCSuqirjTZPXPZC6uIp6uHq62C63ZyNw5S9i FLaITZWJvKzLUYClo3Dl01UUQFesrLK8aodBim8/Rz5dPTtPFhfJLLtM8+2SsbTgYpakZV6EgzqB 0ooqz3iVtz3sDVPaOOyNpTTOwNA5L3ogDVNaJerkvEkWafv8+VfhGJvACLxus6aABDJCQ/HmMHjj MDaW3qwcK0SeCSH2QdQnt6/FKpmlf0gLwV6MwhcBF40Qsk2dtbng8QBsfbFxWmyxqs6amrdDEPWx 9eybq/UiWaUvt8vL9NvrlMjsu3C0TWFM0WRlWZVDUD4u3jjPs6JsR+Htj8V2eZGk6u9P4QiTeiAa qczbjBX5fQiNl0VWNmDtomizumiruMzyRjR5E7Mm44JVE/STG5S3WcmrfczZX8hvu5hyQzwoXHVW MYHlDIfrtIxpxVhdE2hVsw9Vfc6cDhLZh9DmgxYijMyiIAuxhkovS1YYkBppXZbqQ1k9RcYiaSK+ g5F4Fl/weDnDRxEvhb37j/j29emsRpizRQ5d3gU20lB2gOVZru3ZuEtrQyb2BDGGlRQVZ0EwAYEK JiCwVJjD6hIeL9Rdpu4u1V2ODxYv07OIujD13fZMtVb4EPHyqWrVT+g7WFS0Klx10cPI56PlgVdI KNDlpOsHJyUrBQRswPpZXMG+PukCOqYURVYLyMQAVyR9BlSf0D8SMMGgjnhcjwDqtP4RVEcj6qbu gTRsFr66++VJ9UM4qiaoH9BUUzHORsE1DlVjzdUGznZdsXIQpL6c//GX7RZMHUpUPqYQDQjy2vIq Y20B9usQVXcF+2BNx1SI+mF5mxV5PUxUAEkFKJT2Wf6Ybrezy3R1s55vlw1LUiay7XK+FrN0kyB2 cb6e6dvzJOPb5Wy9Oodhu/0tbZL0ZpVsXp9FE9EsleIRlcrLMquaxqE5JOgyQstPUFJOyxdFJliu Hagohx/KEDaiyNHtXVwKpfTVh8R6aVTWcvXi6sUflCclO58qNFRDc1esFnHdhXUPcIw9upI/CpNF GHT8a6WHER4iPa5tpe3yxFq2reDF1CWkTziwy3aU5Bkb8UBMs6haxNa6IHUJTvkIPv4MxrTJk+zg kawc3alRXy7oI1rWZBAB5+f4QJ9n6k4PcKG/NKaUfAY2mLknEwnPyl7RktaLxiAzCmbY4aFOajoV iBkhLAyhMmJRMbERcm7sojrDKW8QZm72ejN9x2+U4TRBxznDaQCox9VxznAaBqmj4169n2446eTA MdfPGU4j4LqfOQD18uUuOpyvcIZTCEgxiyhfcXcvw8lq9AGwmDWcRoD1AJiKf4eG3p/ZcYZTGEjI 7ETLu/RpUq+zZHWdrinJc55s1rCUEtOcwlba/CIW+MzQa5XOkvkbsXixSr//z3cffn0Kk+vqSizm +B5O6QjR4hvQFuEheauqbbK8rkIsqHMAf4PEQnqezLnYpHOR/oyY+WKx3iQ/p3Pum4l015ujNR2T 1es0/QtHCoymma2BsHR7JhbnqdiePda0EVPmCBCFzNsZv+tVerUQNea7uQbsSLFsz9YJ26yw2hIB xZOntyddN9bC80GmIq5GTGAEo0wwfVlLwXB49QakEPf+13fpH7++ze9evfruT8DkbCNv37/6Ebcv P3z/AzkSyvUAlTUnRSlvYBEVjQU/hCSS03oTVvFXdYVMkVH8wym11VWSrYke4X0FWyUT1hvuA2Qj suYd2Lo+7o5REg7RBJPEOl8VQqyiMQEmJO195yva499YW1g6X1eP6Xx1Yd0H3OM7X8dhsgiD83Wj zHbtAegP7Sxoj0x/LBBghb1vzH/dRzsL12oY4zJoZ+B7tOIR7TlsVB/ZNYIfoTvpgXQn7aB0/Qd9 h4QuDafvrL8Ykd+hB9ejTHVs5Ax9xwbz/ddwbOCuQm2U8YjVJbx3rQ+khUue50Vcgu0pwIxRoYao MMVPsmUtl3/gPbwybxtkSLK2EZzxmvIknBwZJMMqjAd/VaAaJ6tb5JsZjV/UDQmkj0cLYnpCYpzF g9gcokchYv7EUp5wUdQcyJAQmcSQXzrUF6SnjmBClApBufYBmB7ZueOZKKk4axiijm/3vk+942u+ BpyVsoGSKdowiLQLhYBqz+DXlv56dpFm4uoqWcCiPFtT/QncAwH7eZEisrrYpG9QNrBJnxTpFQzq F8k8XSUL8jGMy9A3jgY41dS2vXwrC9oUV6J6J2ctwgtoq8qmKXgZvX254ztcOEcJpT7gZiRxGIoL WN4UMV1yuszjT/Fbyb6uO9Fz/2niPjySyeeZel7eFGXgCOr99NKiigwoqHcLez89XdRIFiroiQsV 9FEI9OppZPrpIYIexTzjoKf5q5cWlXyeQLHQH6sH9MVfYI2bMyk5En9gKJpDv1CxL22MN+o8oEzM QKUXN6jKo3QAHLkn8NnI29OebLoRKHKZCZCpdmUPPgwfea6M/T4Jj2fXHXJ15OdmXjASbkGSf0f/ HQZpggkNFuVlA61XaZDUYgzb98nHG0iCNIHHfQlfWoqAOUTEHPJjNkuy+Yo8cn8pcGsWIYGHtbpc zZNzeO/b5eqGZIpdmROna1qeVRWYzcz2X0D1mrJdFO9mBVXnSG4YXgDI8BHpwwlk4ZTvCKhGOPcQ G2ND0KXVvh2Qhr29t9Mjq4HSjGpCkGUr4u76DYM1DlN+RC0k99vAcirLBmGQAUz1Taf3u3aBDIZ0 g4eK2U3siSwGsgnSDXgfMRJwsx9568vSAHOAqqSHDPcIhjtDkL0SJerZWljqsJ9jhJKh71HXJi33 RpBSOm65T2ALK8DLFlq2QsF+ALMiQ00hRaWmjKmkg3enNeslpsisGAcuosVrWH5WJuvlPS2sBXBb c9SkjYH1p+ZmzTYgQ7JYmRCwXBdCnF+n2U2zhgfcdRwfVHFywUGocD/HwMuSP6dvZLj5SqxWa9Qz wGzpg7mfTTrUesxqjgOsZlJ9Nci4xV/MYATA+KvBUea+Crdfo7qFPaPHqeU49j5n4ePY90eMQ6L6 8BUAMtyeZkUJK1rOKcI1jGMOeTHqeUFWNC9pNhhB3eUsGjUGjSDnoeBxc4BVHQ3VJvpW9djtP2VT ZDnnQfmEJ/MUiYSvn+XvXr58Vj199hRGG5lxUuh3ZQCi4CbhQCQ8S1fkBMLATr7JElhw2+UVvv9m TXIuYZfp2/fPHymBUtYsQ1FmEWLLrT4ibQSFhbxRsli97rPeg0oI5EeQTISA0PCFuDk7wuAwRD0a CTEMnPqCMcUguPaB1DcMxtmaE6CytmY5AqrpFhRF6I6ly62teQSkTqjn2+m2puVxsm8Op8ytrTkG rPthCtgazuIbWzMIJB2CejvK1vxpPcvYDWn5NKFM9tViDTPTpKtJoa4z/liyBvFR7EkKctyNw9u1 oBGumGETCZnNjNLu8Jj7dnIwz4cEmylNi3odiKERoJMPj5jKKv1pfnm1RsElg0R/9fw58uKwCwls yo+rqfxZJU3VKmzEYy0EZzAXcxEi9P0QENL850Km+7NMho58h+VwRenqBiQG9yadL1BFMbu4Ycqc v37MqFGJEA1S3EGa3RCfM+J78TJth1KQxvWhVaUWUy9xJUC8ZCIsEtjXIAqp6IGFnaf6NLzfiO1p hxBfr0HWGc40BbphwhVFjV0Fwrp6jEY8sasHr1I02MEZ4OoRXjK2TpANPKHrUbWUrRFAyxjQFM8q +66zvntckMMSqOOGhO1pZshS1C32NI8BVxXl+LRoorraCl15ZNsj7esdGRRAjcdcqtBEBHbTYn8d y+E3NIXQ3hQFJ8I8B5JnTVGS89Fg85O9qeHQhI1AdGreHLEapQZ0D6Dq0rhidsPrUKhF5khlcBLn E6Cwpq7hnHNZaUGBlhrudkHUcJz7drhe6q1BS8daqvAqs7YMk/NdRWtCVbKGJ1mDlBZUyjMnrUW+ ywLGBIWp1/Nr0momIINvlfujQ9mQeJKjUQiHKI6UfCeSdWrOQDbqqXLEtWIORm/h2Gh0Y5NvELon sKhDd4Pq7bBtnVrDEH66mRg4V3YnBrBJrqFMFAL/EoVUadd7Asifi6yP18NSaApFFU3WolAI6JVT DDEcBDNZC8yyuYT5udlx0PaLlp01COY0MFhZoAihQbgbW3R1SJM9AqfV2KNdhNUhGt7aiDez1RzG wVJVTJK83seFJ13ZoqDqKiho7FgLnsGUdTymIkKjboxVyLG2CNAjtiSz1ShLGSHd8QyizxFGKNUI MuNLm73CNYR+Lyc9RfBgNOgI9fyYnK/1XEldHPZcbV2cgDHAK2O2d8viultEEIeAe22rvGRZ3Ms9 ZXEPHUize5K6oO4p2Xv8qjgNkg7beNiLju3ogmWPojQYpSfdz4VwcsPITu8C2sGdyuy7dR23G2ls LqwtsbmWyrwGIFIRLwsR6gl1VR7tu0apnr7rbknSW4R0qZ6+k1WAUa+2jzZqU8lht1LQ38MUH9zD JEv5xuxhcu/p72HaGSp8D1NP3YaEGilkjiqSegTedyv9RhkAx2J6zsYRiOZX0LHSoesmapXQgZut t5/eZwuTjc4MFHDZLUwIKh0HSofPHiCiN7DbxG5hCgRJ7jZ5dY9Eu69CBlBltzAFwiX3C50WVXYL UyBIElXf2h04cpuyCdTAtgwPGkiG9Itdj3tUDCk67L6Oh0DtF11Nx16IiKDIZFHgNI0hkPrZiIHK ofTDLEsWqEOABXopA5QyUkkRjxkFL9PznbjAKAEDHA/aOE7AcI7jE4JixG/gl6bfvf+79og2ODLN VlPKfSc1poNYI+18l87TZk2+6zzjr09rU0MKFBRzEOFz2TGpD2N3xz06Tr8Ou0xuud8nvfv0ex/p HULBTnofhqlPwNN5inB0TMk54T0IUSdv9er+iatjYDnZHQ7W/RAlmXVIm5hjO0QARFrvfvV4m09H QPUAeBqwBuze0zCIpIb7ymo4FW32VJxKKOi6T8roUcbB5R9krA7yuqYUxByZJqRcHnEHKo7elAXJ IbGhTCCE2Cl3Q5oMorlZszXUj584+59XL85lSoUSTjgSU5ZPUFLKTZyvKb+JVBrFGBfiZm5wI3Nv tEv1pOLeClcOnRxamPxDJwnkBf3M8Ss67kcbBHR0VUbROkH9k06rIO+PITI0ZlpqG/TrcGNsijKj CL/AcXUGMKXNjhT9hoME+3Bsea0jAUQgXR1y1z3aUbB9kPZHQ43/+A4nojEcO5bHv6pDNx8qolbw hnZN4JBa7GWg40zlZojwaBiekbsucGQZNnC4Gx0QC86XlAge4YQ91Jcj2c4ELzDaThsGxZEtGceh yLYfWhD0F7SbGigUVLnmWrBTjeP8xgiH9theui2oxX+uoPByWaGOzY2FNJWAMY4WAxXOHaFsjwNd N9zBVkcfGLeooFd9PkUClZDYLodyY92EeugMRU8oiTYjey3q/TGNZHvpNtMSVRrKPX385wwOPnn9 DPYMUJFZCQ9yvTYSBjMb0+bm129xI93Ff0XWq4j/L34naXkn7tnfYkTczRmcL/zn8efIXX9CO07j LFvKaOM7FMDSFUr4BAoH9R2WBtsV1Te47l5Fcge0+R5FXSAv1YPVKIfGwO4NSCnijuCgqzs6jRVk T9ef6OBM1GzmRSTvwVBgIjOCvsPYeEZ9g+t9V+Z72pX9KVI9zGzMG9RM1btpzgYOunat7grolluh aB/NwX1i5JoZ+sEp6nSuFOT+Z79Nc9EQtTh+3KUDn/YNd+/22m0h7utJhX0SIHL8aGjYtRhK9znZ zNGfj24Dd6usLEGTI6cDTgQIlFMEFYE3icjUGbCygMI/PZ0kNDOObo5znGQ9sNwImtlbNy4vM1GY cD5y/NRRf8j4PaQahqOjW/79t09f4p8//Pbrl3/812enNyhnYMcd+xockkRHmlZ4qXxbY08ww5ml pgLjQd/g5oNNgxnOJEMZb/Vc7ASx9ytCYyp4ilAd8f+wipBjh5NRhFTCPFYR4hmpCKnwWRZBoxxB jTFeE1J5PJGgrwlNm88Hts1SPW3v4IzKXIzWw5ZQxLAQWNlpCmjwH6pQTsRANp8c12E3B3af4ig6 qwXLSmTYZGKYV916UkA1EPsp/RepBiuF7Ihei36vJ6vAlAqWnV5QrFpD2j7+cwoXQKHrZhBmIJJ7 EyTyrViyaPYnopcII2l1aHvttAD3k5Ufh8FrFCGuIaWcaqLvlNqC7eMpP16TotLf4Hrf1R0UKkk0 OjLNKD9Be4M6yq/EuYdK+dGVUTp07ZQf9hbluVZbZgSlxGhso9zo2rW6K/M9wUxjNlCmZjZO+dFM lXKjKwNHt9X//q9yF7NVfjglameTdEf5Uf1/S6UDnvLTjLOPWJz5dnjRAeUOIey2YKQ++Xi6z47u Wb+2zXG4JmGPLzWd++yrm9xThxrcQzg3WqPFZxjX1tOXOKse9jvVGRp9CZOUY5cBnTPRca3G6csS J/xgS4jJPXUUpnKunIK5j8I079GRDPeeh9OYwa9wM/JVZon8pNHQquDgn6oyWyStjcqkyoyxKhO1 GEplojaDajuogm+qykSlKwo8ha8xdROGtOrJNFkuQJFqhhOHSGUB5eRLCsRdsaUL5tluW1CL/xwV o+G8L99zFPTjEw0cFQcUtCgj89KqTWFaPBli2jCWVVWmDS1a69nRvRYFg5RHtpeGa7fXbounPw1u fJloMOhkokGyFW2mwZ+NWi4nEE0f81BkGu6hO1tOsQ3SX6jUwbWvO+leaUAcX+PpTqJpozvpWvfx r0AZsrWAlSDHxNLhZydQUOTrziKHFSZ1p7zSOkteO90ZyXupDe0I+g5ja90o3+Na3ZXRnQSncRzN bJzupJkq3UhXRnd2W/3vxzqOQlffearT0ImkVUNzhtMc9R6igQE6sWRh6AT8KhkfE3Pso5tCGN8p TQO0HMkIAz03T/+Z6e64i8SMNUOxpFV/yl0s5aFI091FqtBrKHokSy8ip5bI8XtAf9G854TqL/gV B9Qffn/BV3+SklD1Kz31JqfKT3AhWAq72yFRkUqtjfNofTDpbA+mpCmzjtLCCuFmYat6UZRD6FYf yuhojZeO2qeXVK6Ux8u/47ONl3DVLxjOQjafH3DfxMu/qW//gY8yXj7HB4+W+PWNblFRwKxMbLgz q+FtcDjyCFKOD85LUZMt5MG8flCA08+X1OrEOEzjQt3Rr2egERlsOvaZarowKar3quLlR/XdDQ6O wwNr3OGnOLpd6MA5BH3NE1QFhq5UNoZhkEkYjZQJS12S+dRQ6PnYYrtf/+tl7O1qkfVb0eGFlgYp 1oFobidaFHhAhqZBaSLApNZ5+38GEYZNy5YjBRLh0MR2qfAvRCqgsXf4BHeZ22vcolUToKYcTZWa 5FaKnJAIpJ79Rvn4GxocdKgflBWHIGs9nB6cfs0HZCnv1E/EgMhNV/rhGJC3/kCfA6R7GJUTSNdQ CKxJbl2jPQRiCRfc3GVAy6OS8Y7waERc7Xh09Ax9iRXKAzDEcSBLHZfBc6QF2qsgyCwuqHzRMqdR EFMAUwpCIAgFfjenuu/B/ck1RNi0xjLn0MR6zEk/c3UPhEvIZNHQsEZGzWDFmIiPQOb/mibIXfPu BuwJhtY6TNMwaWZIhC6X04mo0EGySyTPFcVzWqNp3tECRT9nJIAeVL9Jv9cKpIhev1ZCAs8f4J2w tQzknRK/HQhvGN7sUSK1AqLDPP8PV55w2gplbmRzdHJlYW0KZW5kb2JqCjUwIDAgb2JqCjU5NTQK ZW5kb2JqCjQ4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA1 MSAwIFIgL0NvbnRlbnRzIDQ5IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+Pgpl bmRvYmoKNTEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEyLjEgNDYgMCBSCi9GNS4xIDE1IDAgUiAvRjEuMSA5 IDAgUiAvRjExLjAgMzYgMCBSIC9GNy4wIDE3IDAgUiAvRjguMSAxOSAwIFIgL0YxMy4wIDQ3IDAg UgovRjkuMCAyMCAwIFIgPj4gPj4KZW5kb2JqCjUzIDAgb2JqCjw8IC9MZW5ndGggNTQgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1c73PcthH9zr+C5pH1HXyCCBAESSWsfXSl VpIvnmjkNE0u7QfXmWln0iT1/z/TtyT40woPOItKnZnQPPGoh8Vi9+3Dwr/6X/u/+oUvioIXKpO+ SmMucq18nWQ8TmXm//eD/1f/P/7564/Cf//Rj+v/Pr7H1+hJoeO4+ai/SzTXcSJyP48Vz1Ode+9/ 8qt7P20eNJf7n/zzK8GFL/z7H/31s2AVRuFq49//27+8B6xjwDx3YDrhSZbIpAPm18C8WWB/sIcE W3mOttKaJ3keZxNIY1t5E1s9jw7rw8bBVsNJ9OwmMddcxWmWOgFjTrYa+pVn4Vci1TzWxTwk//4n b+hXL7ZhdBYG/JzFh7UQTCYqCFkaS3uoJ3ia1DFPdFxMrDfvaW7Wc/W0RGBBx4mcQJr3NK2ycJuH ESsuLr6wt9gJCyHJCp5LRKA2aDRrcx6em8Vc/a2LY1LFXCn1EKKpu32pyjBgf2RSiZdO9iJwnkOQ zTNexCrxZ7BNw8ay1hI643mWFHOIptZ68WpXRWHJXh/W5+xPl4zc7MrebKcsTJXzNNXpHMqntVuS xFymhZPd/iwP67OQNX/+Ym+wOg94jsm84ELGn+NoSSp5mmNpS1nwTBbaT3mcqzzOfZHzRAl9Qn7q X5oUPE30Q4tzOpGTCNa/4lFxZVwLhem0x7XswuzCWJYRNJ0/ZKrpyjwdEvFDZPNZhgiSKSUxxCzN uEoLaSDFyFAChJI45f17P1U12WwuzWSmHWEsX+5eXjUxtn7YijSesACyBKRDZGqK9QFwQvDY0Fnf cVH2DNuGCWEilU5EMYupmdLOYN/76682/pn010FzCXER/vqyuTtv7g7r5vbNxv/Bv7/pqLj3yDWC EAkXCmGl9YC2RhhOOUaAGqEbwbqwN+oJqUEIzUX6iVN6o4meQIJRYxgs6Yz6ojEjuDnZ9nlzaY0a bDyyf958GjWXzFh+i1v80LzATM5ZOy2b0XfODhu8Cr+ANx+3T5nJM5B++1WjqZ0t/06wo1QJElo8 XTCzdlzDGLaF3ynksq1IM2DTaWaVLdjhoJ1QdfzSssRCFFSKOJwLKrdytIOE0t0msKQJwjFV/XOQ prniCpbiPCxLFoSrOxW9JEJ3+BfbRSqr9mH7qb0tT3E6QRxDwOlGMzxfcLnZ0rXgkiLlaaHlBNJ8 RbMND+vyNgr3TCh+WK8qFbB9CGlkWwXN7Q1j34E0C7L3Yd3YnUzr2SfAPtk4yTmQTiASJbIN1XNy jvEEdpdUPGF7xQK1YuXtbqeiVesQ7KHBvv7w5i2Lwh9vMUa2SjBmjBJ1+z7MKvgY23gOcWLo/m5D lZIrESuboXIVBCFfYcpWCog7f2cAn4UtkfKOK1pDFmwptYkUBBp6nZ85AA6D/aJrUWQSsh+xEwOq YXe/51oUWcpzDeo7hjS/FsvzchVuH/JSrMEPAQ+j1WFdBatzpg4bVi9IctiAXV9csO1TeSpIpy60 jaPeVauEXf39ZwaPPWwQmTEE9uYf33/453OWh1hmGYYjDutc4GajIravyh0WIE9uFl11EvWhzFLk QfuxtMtqGaG4K5l0kdgWl09HFxxAuWW4Ybh0YgsziKZk4friU7bQhPkJXXho3bE6OzRxlTKDoGxJ CQIufVhHJaLtk6QHnSPCSWG16vo8/m51vquQ1IU4Z79cv9wiOUIrpMTYP5NU+yo4+2bRYUjkcS2F 9F2GwQAcwSCvRIWA16XlVbVFUq6jRaRuV8BeB8N6lOWyYSMpBM+yHFtVDrPxVHFDK66htdhkPrfA cQI37uoM7YDKLXK4cuOuzhhDms/H19efho46p2E7LIAcqpZlNXkMfRubh2PI86wGvOAXRLwtMfiS vQtvzm7YDn9V0GBseewJMy4zzYsMIqQT1rXAuo4QUluCXoKxg70jxrJU3IYrpUAgDPBl+GyfeOEh tCFtw2vqpNBmD6DvoykI+VYhZIVd+TAl61tQubfg7P13zIv2A2a0aDTuh0y6SSKtdsubjEm0kwqO tgzcLepUIkaPQCFTXxugNsFNgR8PjHsbmLoV84L6joDfYvWuQiwRTty5KresKlvpYL9wBsFAUtp8 b0dk423tAliaeUrNc/wxRoZKROW2udS6qDxRbHaO1a1Yr2Psv8eq2z/Ia0hpfTFbLbKV5yGMPoM2 2QujWXe3qPiIfgotY2y8j8F6DUrfXJp+Cgj77mr9CdG4U+stMA0NSDpx6pPqTXaE39EFym8tLZPy i9sLunjNBT80AnD7EGnKUInNV89wB4XZfJM0Y9yRVtw/IiAr463YKKMP29eQjI1PRXOpf6W/BkGg D827zWvMI/W7ve775hm0XNBvbN9qXmA+Nc982bwVcvDATbxHb1GSClJWhl3DdkralT/06Ubrh7DY 9igR8gWzdpcJsCHGY5QXNgGWvcDsLAhKoS0DW9SJ7wJqYfKI4ktleTaBdIQ8fvHtM/3W3lRDMc5S z88FNCaRCCdcbqZyrdBzNOBlWqSzkKYl+hV7Eex3lLnLlgQhRUMK261I4mzUozOI1EQ+qoipu6BP 8QtnbAmOVEh0EJgl0q7bOS0aoWXBBdKvWuwUY/7tVu2bZfvP0OUidQJJLXUA5eaKzjRCQOTLk3wC 6ciqLZiM1Kuq7hEabCn1dB37I3kI5ijAhYkPt/sE1WHz1bJqkNQ5R7eC7Ab0+/siGlxzRX0BaZry LJ71RdWxn58XXR+6oBULkn0cExoU3QnZCdvBHSEbQ5p3RaoSURu+Oqd9Hdp6wy4VxHLaoSsXNSDt XQj8z8KAfTt1Uu1YrY1gZSyKDjQFVatCRD7uch2RIqFhsmNMdWyzdhcO1zLjmcgQGR3wcnUr9pT4 aKMPOfAS+IP9skB7J1WKF9Q+Z9GsTlas3XLRORcxnQ1AS1TqAo0WCrklCeDqrmRVzSZUXm+ijW35 2N1GELt5iu3cDrBNqO5yzM0Y3OP3y2QcjfYIkA7WdIB0QoDs8wipENSV/cAJDlPyn5RHhuzasjWl zyMzmBoqe2oeGbJr0jaOtTH2S3QeUnPQxWsOunySRwJGW7ErEJYqjC4byXXR5SvjlPpAQVxGsI8o 2XXOC9gziQW836Nru7w0/RnY7CESNsD8+AV7gtWYFJDDWsw2K5jdlujKyM9HIukA5pGjT58j9aTU TChkK9/NnjBqe2VQWy0KTqAdQxYCqc8BXNt8VBd7fZlXc21kmxHgRw/bCSY9HwC2mnS0t9TF6yUL M+yvVkE9/SOgjx3CQblxGqOAdzpYdoc1VLdgUNmyLDyooqnC1pULPH04vH1SmoOohBVuTtnMB6Mf pGarW7AxUZoYtKUTJIsaUSApKpXDiA5AVV5ig6NZO4Moj2i5ugvhnMTXSLSt9YmFttRinHpMSDIx uG0W0YicN15AUBc1cJdNVQHVSqdWQkoZRtQXuCgwAcPhrMoY1nyx2G5gRTf2yAwncjkEJiBj5zlk HidszpDaw782PUGdHKawB53F7SyOzTVVHJ1E7Al3rGnakfMmnYjtAspNDnPljuh5a0TsI5BG3PH6 6nQR23SUHuO0nYjtguvzTAWq/fE9KGN/grxWc7vT5Z2IbQXJFx6dJ7+++NZFY/3Eqeq9zVlYtB+O 7v3Md4H1CJbyf/V+y1JgnCjM89QWEk7ee+vrr9l3Cc7e1+oWKa1tK0VXALOpyNpSrLoECJkJwu0X o2V11z7C6BQNCcK+RyQMqLXeMIYQ3bA42ExpDcNptSfqPVi03UPi30TQhfKVA/jmHMW+EfQIcD0z 6ImvoKWwchWh7c404VXYswHjiFBQPtUsQEdDv5FV20rvUe/Q+2h40cD6UcjVWVD9DU44Gts3lwzt yDTyT1ytkWTrFiAqVSDPLTp9vfNBrMmU1QEBwo3mSSDdRZgxNLs8PH9oaKVHqaWyLa+o61KIm0WH JBUUUTBvH0fcbYe0LBPsjQyBQsXSqiZwgIRg77x71TbB4B/FAJ3uD9EOGwaONsFgo4B6JtD8N+hu eHwVomuCGYP9/2iCscDUdVygiyhtmkYwu2S5+RaWunfFtKC0XSam22Xcu9L+0PSemP4WOi+J/pT6 zluPf2a+b36/+cK03ca01Bis7S/ZNkc1rUbQ9tks6h44eY36CpWsy1TUbTtPsY1Obd0pjubbbHc4 1Q0nyHld3eACyo3iOQeitm4YQxrXVyYQdfttxcW36Maznb0hF7ZsfckQHgvwThdQp3bjWO4XdIXM HKZpIeo2d641X1fIHIE0rvmu2XNz9nF4VosOaUEwrvdR0ZdT70fSMYw7tHAPD49C/caxLnRvE4PC Dfq7N2BeOPqFzudFeUWXxRPqnJexFUM8HIIhHW/6nEELwyoDKez542gk7F09/L3CI3ScBuMtFTsL Gz7FFehwuVMBnawxxvjmqYZOCyO3GnlNYetjeGZqcU6AJnSL4aA66eeNKfpJczQYHtBuoOKpZqIX ZosF/YtlaOdI7Ic2pGb/A3zuM8gKZW5kc3RyZWFtCmVuZG9iago1NCAwIG9iagozMzU0CmVuZG9i ago1MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNTUgMCBS IC9Db250ZW50cyA1MyAwIFIgL01lZGlhQm94ClswIDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5kb2Jq CjU1IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEg NyAwIFIgPj4gL0ZvbnQgPDwgL0YxMi4xIDQ2IDAgUgovRjUuMSAxNSAwIFIgL0YxLjEgOSAwIFIg L0YxMS4wIDM2IDAgUiAvRjIuMCAxMCAwIFIgL0Y3LjAgMTcgMCBSIC9GMTMuMCA0NyAwIFIKL0Yx NC4wIDU2IDAgUiA+PiA+PgplbmRvYmoKNTkgMCBvYmoKPDwgL0xlbmd0aCA2MCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzV3rc9s2tv/Ov4KRqGuZsWmCBF9pta2VZtvYdTt5 dNNpdNttnXRud5LutOnM/ffv7wAH4EMSBdCR9yYfZEIkdHDeD+Dwj/BZ+EfYhKJpkkZWWSiLNBF1 KcMyr5K0yKrwz7fhq/D38OLxBxHefghT9f/DLR6jO0WZpnqovcrLpExzUYd1KpO6KOvg9n24fhkW +kb+ePk+vPi7SEQowpe/hssHs3m0iOan4ct/hU9eAqxDgAX+gJV5kld5llvAQgVYMArYf7mDBFwF nrgqyySv67QagNTHVTDA1clis9yceuCqS8TAjYh1mci0qAovwGIvXHX5KnDgK1GUSVo24yCFL98H Xb56eBYtzqNZchGnm6UQcZbLWRQXaeYO6gROy8o0ycu0GWBvnNP8sOfLabmAQKd5NgBpnNNKWUVn dbSIm0ePPnHH2ARByKsmqTNoIKM0tGyOg+eHMV9+s3osk2kipdwF0ZDdPpWraBb/Lc6k+MwLXwRc 4KFk6yppUpmHI7AN1cZxsSXKKqmrvBmDaIith59frhfRKn68WV7EXzyJic3+7o62KYIp66QoymIM yvvFW56nSVY0Xnj7Mtssz6NY//vKHWHKDgSexrxJRJbehdHyIkuKGqKdZU1SZU0ZFklayzqtQ1En uRTlBPvUTpo3SZGXu4RzSMgBa7VTfFS4qqQUEuR0h+u4gmnVWFURaGW9C1VDydwCCSqwyNM0C4uq TMCtVQMHYds7xFcZ7HQTpEmTFbLBA+1f8BpJS+RFkYVVkSelLMALDTygXMAHzZK6wXfEDL8ew/2D a5tl5JdWcCSKQmQaEUFRK5+WP7SvlRnH9DVc09PwPA+XM3xk4fJv9uq/w5dXx/NV4URnKTwIB2Dz JGUvOnTXBROUJ/hHlkSqAUwpORaIAygUeHkbjuJz+ZlQMKo7j+Xo13WSgdGrIaCjkIHSjzRtN6f4 FOFys9QkX/AwX17QaLA80aM5PiTu5WfOcIlHIT/EM+f4AM8k+ko9GC7T3i3iNKA76Xl3huoqzG5U FuyPykjysgbKt0+8fdQKVFgGnPASeEEgHkH7UK+LV/K5HrzUH/Cse2sO6Gq45olrdQxesqxMqm1G 7a+VrYOVdEWCfvTpoPQevyAFlxZ1nUkovTxrpICKaf968XgrVD5vY2VECHlFegiuE3QnFKtE6ABB kgGNUUBe02UevgtfKKXYPksh0+6pskSqqaBb8Wymp9JjeaOmz/zmC/NGtFAxpAhc1ZjHVEI0dXeF 8CzSKUvEPLD6eNIukEcmLE/B0FmfgnGwNuuYJ02u/hHRkStpahAhaWqZC5CR7FtWU8ojrIh1qlSG WZFkMpOhSJNKyLwktXvYuu2T7y1WarmhNfMySyrZlC5Zl/ghtFif5/engiZYDImgDg5uDnxooIzJ HUsFHTfjAme0lhXZhh5I44Fm8/T7B+W37qjq0s9RZ9UiqUuRCy+4/FDlGwDXSN9VpShGQRp6jk+b +CSq1gnCuqPiiyStaqBOfOj4+O3X3x4ZLPi1TQVl4APW6vryUi7mscpQyc3pN/HJT2kWC5lslvO1 nMXykj5W8Zefvkxvv/jixVe4dXajLp990vz41ZP4NOiLsavpEqy7YLBS0ZSIydKkJGuWF4Gj6SpL oU1XkSsjkYXvwxKaWZmzArGVMmfu9quEBVT2CwEHPZvTfGZMVpLGssBjPgOLrBB4wrSq+RhmJL19 4auaKuwstWrqyUulZwtMZtepByYs0kLRWSQBOljfoax6V3F1HUsnw5MDlQiqXQzPTw/fnMRfIrLq c+1HNT5weNNSAAfI+SvA/vPGpwKhq7JG+NsDadz4nFytoznFB6646hLR0frAK6wg/jDUHoAd1/o0 OXx4iRzDGEhD63MeycvFujoqrkSm6kijcA1TT8dFlUC8k9cVAvMR6g1Rlc/niNim8BQUg1O9Bg5W 0aCE6APVdERREgdgjZYmhSxQm0RV6wBIujSpY+ClNcOTsaUAOwQa8mq1EPD/PGh4ZGypmgyCmXGI esi6icS6ihYX7KG8eXPiUWljxeVTB0GSMUGqVY4Ceb/SmBXItBSozRzAW69O+fgh7OEkbKnSvKOa h48H77QYVxT3i60cmwSaBn6nJ7a+uposji7KK0d4UcKz9QJrYmjBjtYh5dVG+CJHYIYk+ti+ClZe 8WZTTkaUyounwahKRVZdSqpEVh5Q3U1vAawPtyOpToRgEjUGGB4XkEIR0AaUp830EN96yuOoqpGX Q1YaPOUCFxPwuKiqi0TWOSWsXEAyqHoWf5tHCEETRPmreBbNn8vFZ7EKrttQdh6LaLNczWPacCHd eXBCmilDpqIiT3FkEUOttj/KfhKr6EQuPMR5AtCtOKd5gn1UXJcb3yPiZyEmQAXbhcpYCh71gMqP R313riD0L7KyBo/2QBoPmmBPJxoIR1OKfF2a5Sg8+0DlwVHdIM7R4bYcVUKskehwq/TexUC4WFJr IHyg8uOobmLTJQywBuIASD3P9umzOxuIQxbeGggfuO6GqkO21BoIJ5CMgbiNf8ixnRMmIl7Ia+zs jNerODq7FPIiuolrGIwI26Tw7Rtwn85l/kB/rdXg6kwlQr8TZF3mOVKdW+nN/YmigdxoF2Y8Kmzl BsnFDLtfXTJYm+Xl5UJ+vgas80hcxC9+fBSvfr3eLLHsswhLXv0DC1vABD7BGiKDB2Uk6yieYw/n bHVJd8zm8Vyqe2ykGWPqan0DXA3zukdaOLbGYkeGU82ovlCwKnox3ETFK/gEIDLQcaG0XOBU3J9A LVXIFmWDnLA70Gegw6xLh7Nr8kzq+WYJnmvxDoeF2DIRayLL5nQhz+xqt5PsRyIG1FOaN055VFUG IJ8LHEgrfIOywSpaIAI3PKUk7Pl6ng84bG2Xv7qKWVyJTzXPkrwK/HkeLTT7qmnuiRmRN8oz6bRt XIkTNESldE1Lx0TONqfr82tImSqgnEUJ6ZH16gzCGc3Xs3OgA2vERuCro64qQ2ZVCmScSo9VebgJ E1y8Vt1lEo6ndHI8761SXHoA5Wf6fP1OWynugzTudzZ3CCPdPU9dKfaByw9VXYfKxcezleIxkIYJ 6Kc/xg9nN5dyPZuv4q9/ev32jXuQCLvhS06BsxZCVHk4BuMwSjyBoSbNipMDUK2rmMNbcmK0GbxR tW7tuMwuYrm4gepF6AirQsadnowEFOxRlUwr0QiAsS3FyYFRIfzpesEROvlZc6wPMX10syL4tVkh VdnRq2Rk4L5cr6KbIytOFGZVIIpNEc5ruifFWTTY1YPt9y4FRb8E3AR1buMrH6j81IGvqNn4qg/S uOZ8ejs9vnLVnCYB5wOXH6q8NadJwI2BtKU5X4Cresk3HSeR/OqdJGcSYYgOnSj9Rm6hcpUWEXmK 1h1cbZZn0T3ppoKSdNg97hJctQpnDT9OLijIon0w3xHkUE3kqIr12Xp+VLWK443Y9J412DfqDvoq xgYeBeANgEYsYeBXf6gvVpdRsoZ7mhBdECVigR0TA8f8qKuyxqKgrTQyd4ozmK9WV+4meoIqwx7Y NGtQnjKgOSlYd5AmeA0ttooiqWucn9tRdBl6DV7O8iAEdnG37LbKYgSoodKYrsecUmpmW+UBkHop teYeUmpmW6UPXHdD1cGUmtlW6QSSSal98f3X/pX0rWPbI1UzkWKnnsTORR+wPgKmwj+wb373SXKB M0HYWo8dcuN8rplKnYEJlk9V8nGmizgI8clWQM9yFi769TqCx6trVVoPk38fV/DUr1Gngu5mfRIc PoM+EF2vXGOBrSg4o+KU5XgVmVPMnyKbCo/8VWtMXuEA5SX2hkbfrs+iVxx0qAQkloU9ovDUFQpw 27VQiY/WuCrLQwlaTHlvMUqRS/jz0ilGeQBytMTx2QM3xfpgE1UjkVg0ELpYH5jumzXlcedJ3omT nq8RMSJOwmng+RMihAQbLuIFs591wEaod09OADaz4ciek1e2ilSmuuXGE7PyV7HKp2LBiUSWH+nv myetl6lZT+FC822LscvrxSWOTMOvGOxf/ripVXQzqLHIsPBYrdEDx+lF0foVaZFgkz0fYB2v/nr5 FRMkoPUrPIDyMwHeoaT1K3ogjYeSjak/ke6Xl5HKAiOPsbpYzaMzEyRRZoOqOGJtttmj6nKOe89W 8fN8DXmeIRWihfq47Flir1GVwszxGl1CJBUPKQXu7v9OYAnLpxI5j5RaxDj0TLHmKgZmhVjFNxLH QaADgW8h5HN86OgV9aM3KBhBMzakJG/M1TPoietZog89zCLaZoJkGgy1DpVMfebIVOE2NhLRX479 YC5U6fMTlkfmd89hDlrw97Afak/HMdVfJnEcEr5U6LMSD7GewFYZVE2VlRYil6gKWzq0E7ct0cqd 45opGOmeVLdEvLpzj8UwHry8rsV6lUOZbDbZA9hIndQgBQQWOfIZPGwtIlQLHAVxBNeD9AMP2CV4 FVS2lTjZvhceRK69MBFHyuY53NTz3AtXXdgcE4RZhlCkyXFGdR+u7jeqRr+CJEtxWHEMnh6umqda kfowVRdRjluNMhARPb6gUkYQ1QNsOlPZsGokeM1Q3EnlGJNbpuIwEYia2EHL7vZUu0r2Bq8Zsoco N+GU8kEUcfeGlsePaQ3yTB0P12C52DQPyk2wBDlOSBcCfYP2ommoTZ89Raz6YE5bFNxdH8Xjvq1v jANAzE6nuh1Sf58+TF8/fvywPMF+fl1SI5dn2wldmS0+VHLLSWaVbThuHJRhN5fAeV508VALcqG+ B46nUN/0CkR/LeoY4xYGeZHdO+IwbWIklC92nTLRu01imCNt64itJjFtyxj3nh4TsAelp5vEHAQV 9PZvETPBLtgWMfshYgvaRV6NliFFuGx0AxFurMKtRg40VlHNU/Y0VlGtSszzppkL/wjYmhqZcM8S 1bUlGPZ/WffgMRM5NURRYPHk3BCFl4UeM+48AQr4si8ObsPdQwuS/RQYsu+OzifO6RcXj6+NIZFi RkeBnT7z0LGa7Oop86zAGj23YnMdcEWdgfIwhQPh8aqhHACp51c1P04vm7MnA2SNosq2pvCB626o cq6hOIFkaiifDDccnezYAro+O4tu1kjo0q5e1WiVdvTonaIUsan0ubCnXu4nB5Gj3w0OQ7sY7OHW x14FHZ4TdmZvFUfgCh/T5SSdhKS6QBsh52Ugc8e7cHWtxrbIiJGhm91gX26NLNJnR4U7h7+ERsi1 D9wefD/B4lNfopKOtjEmjXfS7acz9JdR02qrWg7Z7K7mcoybrYZX8FGLRwdXGXnZtbyJvzPHAZ5h A30E7sXuM5ULfPbIDvAmiUV01Noc9VJNK5QbzSpcxO249M4kPLcmlxYkjdjxMgG2LKrUEkRInWRD yXNxgXoMCf5MogilC4YqgDqm2LdcUaFTWOPWCHyBbC9OkKN+pJgA8OrSGW1hsqci2hJmX7sdVRtQ U+cGwhdCIzgvZyt82t2Yx6iC1/DSBRzENHyja/fd/nKdrnJe/eWIjTM02QwlepJyA5yMei0jYULX Hs3lAjyHeehIHjUDfR9S37X2Wjfl6XRL091AqUfasBsoHZUtkBlBR04cNiRAGqST3u8Ye4exAhl4 /LC9r0CgkarmIGjug6XVQWcEx++rCioIz9m7eMxhJOg8V1Kamtq4EQw8F3pi42S4pE6oDBX6mCYN +txjhNdjRjCXxJc5ut3iAADf9Q5juK9CbGnHpMRWswoIsLN3RjQMai6+C/vo9BppLjumMdHObrFl YTAjXbjMWAvpyMht+D9oX5eF/xu+1kw63LyxqyFhLtDgXqLXL/Ne//pdCA5AG6SmDuw9yCxSAIN+ oyl65+krw7u3g+v+t70rLFNdC6QqQUL+W7UlaXClfxWt+UimCUb11y31hs713++oja8gKAL1HaQo wzc8A19hbjxD31j5oufo2qzAzGKxEKjfsOvl37TX/W/7V0QCagUJmRppOwnp6nAGttFQ/ed9d2w/ BwWWP0c5YYurtjkIMzH325l2Sf1/UMLRRkHjpidJdky3aqRVpLR/oEQlrUjxB3WfKyowKcqZpIhq o8CN7iM1LkxYlTYpWtVBUSo3DZqOL+28FbqY5La2itNCdCN/qGIIdA+moz4FL/56+9vvP/8ZXv7+ 5s+3H97+3ubCqPernfrAL7Fn0/5SgV4vRVZTlkv9YG0aIFP7Y9Mk6KP+QrukED3iSP+Haf1IFu3P 6WZlUwzmSFe70KGrnTWYIq0FpEYZS9vyzb3zHBnLgJ6DsaQudrZJmx3bMpij7UVh5KyBkQlO5JZd g1kiharGOuJkxzrmK0MLmDprDWYJDFOr2Z7d00Odp/YMtA8FdFADtSpqLds+h76nDXDY2kpkW4AV bMWxSzEjra0M8OoMfVfXVpoxq9dKnrwzwBC0yq+Favuu7ZH2OYi6XnGrFwI6wkeog56z9ptRbvWc RXi7Gkw1uAszDUbae7YtLMS6uz1yaGGJWY31asAP7d+tZSVrRhaPFFaK3SYwaOYKHWytlazTgO/B aPuX+R7tDqwVzbACmGzcZawoHDxckRWlv261hVN/t1ZUf6ftppmBrzA3W1H0V8PrBpSlNX8Fasx8 nwI6trB2NdbCqpUaC97QnGzN1RsWcrLj+i+Nk9aajumMrjUtkcwo06JEV+WWgbaYBQR1Z5auOzbC GruYrBUjZik0xmyFzbBZK48Gqs7IPunf1hCjDzFaQJkWLQZV77jnsTV4JOA1MN4aUuwKRWUSdcDB e538DCm9tqqBd75l38geDizpN7+9+xC+evvbmw9//fy+tTpORm7v70jYUSyjND833Y46/0THkAoc cSRDKspHxcCQKp0FtgVjUiCDV3wJtHXLUkQmcI9VP6mhD6N8COPDdFVQq5CobAcqVvhAkMNZH+wh p0f1h85GIe7U/gtKZY9RVhFpuPw3PptwCdSfC5RizOdbXNfhEo4NffsXPlAaUp35gyXeb9Avnjis ashQalXjjZokNeJIkXUZWZfmJpT4bad89IcmwNHq6LyybwBQlSW8EACZq/PSjn6nV/W1vhX7EGiN Ed4EgFuo6oQXCtDrJjCbKlthOnoHAe75h/7g6hU/SK8gwC384IpuCcwbCLqD9ucNUAyqeiJc8myY u4djHQ2Mc85OHLtxDpJEeWM7T/RYx6LYsg6vxsBPBbYW44wipLIJUwZxjMd2cVT24xUzUfrfMVJU uU9aPPLk/MSvGuPX+vcZqv4tBkZ+YgaoACr/FP/+FZ4HNE/0BxN1APiN/in+8jmuhAg67NSjlfZM vGjlUsAzUo6gB2JhjkANadXtZwgxNwhgJG0xGa2cF9dn0kTLQf85fpzRwGjsi5rGTbjsikOg3r0B qeJBfp6JQi+ugODwbJZSiqn6TAGiBHQrcxMVnHHFs/U4xo7yBF1omPEUU92VbkrFHujNZ+lGPSjg ++mk/JBu3XIi6NZn44/E6YwppiLjhPHGhKZ6P/Ren99rLTZMmj71mBZaUK3eZfDplSsgOz+oJrWy 7CBhlmH6THGFWcG28WnwccgHFTmyqc2QD6egZIY82Bj5lIoMQD6YfbKbjNQ+FzPGGO99tt9SQorf mSj8wfifwCEBtJalBoPBv9+XbLaMjHYW0C4xA7Vno1WlDBOviafmx1tr6U2uO/hCaGiKUNiUwHrS NijNgVxrzfUMNy+U0c00ZIngNVl0qS0mfSXDtzBKHmNqwvpbzRFf4wM6i70UvkfNFhgNaASjzxlG kfPsferxPEy2gZrsy3IfVl64XY4SLH6AGYxm8ybcPldkRM6QuscWxJRa+e0nXccZoX6hIJ1RPLwu YMIb2OlcVuL9a2W22xbv5bI+svsiw4Q0LMCX/9S2mHmHV2ruYU5goplRJh6Pdn/S8llLX8WSzPV4 YSa5SL/gA5r7d3zAHLAIXw2QeySntMjQHxmnXEKDXo4je0Lc4QSVkQWqTIKUMpYOIckdyE71f5xF 2WULtsm+2WiUMqH6ep+NMEs1k4TJzi4YP2AUgPncqQi+wU8p06g+XuMKVkj9sPXB+upprQnMsPEP s0fPCtCwFDMIB0h8a1+d8NzMbu0v3adI1nh1Cr3raYed3qYNI5wh9XKzVJjIeGMsdMUsXBpPmFG8 04ifA/1VYOwP3phAxqHFG9HynxiEJBoq9CnFvMEEY9L0b+El8p1mGlYMv+jJmZhGl6p7A+OD4ktv +g30v0d4U6LjEJX3d5DPirwN9hm1RiT6fMtoNF/yJSOnVaLKw+JLno9xxbcycjDojYYpKgYmRVX1 RxAx4OOtnaMOyo8J5NPkX9JrckrsaXWHDPbZsBa9trEN1pjTDTey4DAV1COB5XhmYP4wj7gEfyw6 9HJHGDGmKqsxM88Byt8LyXX6DglTbGkwZ5A5cdfL3yHPZZMwtFsbdtoso69yWboZ9/3vFsAGMjNM AeZ4q9uVruEHfukpB76zLxQP9GQ8yLhkSWOC8Xc82CVxuLzCL7Tm6ltMhiX1TSKvYbcw808oLWr1 pvpBa+5aPvEm5RQZYVLi3bYlbSTZocUGwgsRGdJH5Rgd6IMAmLC3BhLB3jwL4+tnPdhP3/SRz1cW 3cqg8eP8HYsM61X+jgeNseg/oWbrZsY6ELZM5k2KCYoUjXRRhJDo+dkjRjDqRQ72EToo0kmQUXWC igDukIFNWOL70sWsf9UzToiyHCAf2GidyhpPFxfoKVejbG4h/3/nmePN8iW90/yw4JFl2h0xoKCN ziioyJjSDPWrwNHtXlXMcU8uZ49K7EFC0XrEKz1+bcZpWfZYpWNtZmxh2/7aA2gl2B5WGcZ2MQ+z Mmf+5g++lXUO5+950DjY0Dn7FMrYmn3P9FBYWqXYWTG25m3tblbZV75slnhdrKZ5XazJ8aDyTfnW q56t/AFXVK9r0eSNggmay3CzwHslsUvpsJBBbRn/e8wUsb/St2QOFQi2XYxFww+Mxi4/td4kh2H9 n2La8CDbKZ5mp5nsm2zc6Y19aF9fBrTYx6m9qnF0LrpYCJcfN8I1rN3/Dcab+XIGTq2DQUWBMa2+ s/rA0I+paiboCw4XFnkCw1wsBsYnYYDMDIO7riy5uLtYayzH9EW3qaiTsYQ/X6RoY1CidEAE8zWW /weIjE19CmVuZHN0cmVhbQplbmRvYmoKNjAgMCBvYmoKNjgyMQplbmRvYmoKNTcgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCA1OCAwIFIgL1Jlc291cmNlcyA2MSAwIFIgL0NvbnRlbnRzIDU5 IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKNjEgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9u dCA8PCAvRjEyLjEgNDYgMCBSCi9GMS4xIDkgMCBSIC9GNy4wIDE3IDAgUiAvRjguMSAxOSAwIFIg L0YxMy4wIDQ3IDAgUiAvRjkuMCAyMCAwIFIgPj4gPj4KZW5kb2JqCjYzIDAgb2JqCjw8IC9MZW5n dGggNjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1da3PbxtX+jl8Bk2BN wRKEveCmhG9CyEpiK6xHtnobs868I9vTtHY7rTvTv9/n7C4WIEiBu0jAqTMTgktczh6cy3Muu/pn eBf+M6xCVlVJJQseyixNWJnLMBdFkma8CP/1IfxD+Pfw8voLCx++hKn678sDLqMzWZ6meqj9JvIk TwUrwzKVSZnlZfDwOazvw0yfaD7uP4eX37GEhSy8/xgun8zm0SKan4X3fw1v7kHWMcICf8JykYhC cGEJCxVhwSBhv3EnCbwKPHmV54koy7TokbTLq6DHq6eL7XJ75sGr7ksM3F5imScyzYrMi7DYi1dd uQoc5IpleZLm1TBJ4f3noCtXz86jxUU0Sy7jdLtkLOZCzqI4S7k7qSMkjedpIvK06nFvWNL8uOcr aYJBoVPBeyQNS1oui+i8jBZxdXX1lTvHRiiCKKqk5LBAjdHQujlMnh/HfOXN2jEu00RKeYiivrh9 LVfRLP6/mEv2jRe/iLjAw8iWRVKlUoQDtPXNxrTcYnmRlIWohijqc+vZt+t6Ea3i6+3yMn5+E5OY fefOtjGKKcsky/JsiMrT8k2INOFZ5cW37/l2eRHF+t8P7gxTfiDwdOZVwnj6SwRNZDzJSqg251VS 8CoPGcACDDlwR5kIyfIR/qm9qaiSTOSHlLP/Il9c7bKqvcevSVjOk1zyPOTuhE2rmdaOFUWR5Cwv D/Gqr5rjSSKACHfuBhGLrEokIOIjJGmIGGiIGD97uvv+xuDW4HHcKuGBoI0idCIqZAHhVj942HVB HSgdtOBZ4SALrKE5pSzKwpUkQOlgWb3545P81aSsKllS5kwwV7pOwKoSsUaRs8yVJMWqF9/FT7Zn 8VxE8SYq6iSK61WcyNn2rL64XUSbeC7j21UUP/0p5fH2TC7iUkp3zo5xUEWeMLYnhMPIcb6aIyRY r+vZxU1cz+PrDz++iutZwm43ESiei642QwPGKI5LwFfAuxaSS5eAT67ntZytNFeZTLZL+h5vl8nH 23pVqy+/S2q8FIzNNvFFJDfRvE5+f6Nel75cX/3+yY/xpl4lAKuLyxt9Or1Sc85Z4BpTdv2Qb7Bb iDJJuVOsqwTpvcQ7slSD6BVEEHI3g9TVs/j7r+/Th+fP3/xwow7vvqre0eGTSSejwhYZekzFw/yN UQaK2DNZNRQd8hJ9J//0ZR3Nt2fuStp96Y7BMS9FUlUFzLJ+6S50eXCqSxHE0CU25ogHUsZh/R6n qO/ioVHrRV1MyinBkAzKGBzF43T13+C0nBKsSvI8HyKozyhWr8YxSdkQ9fqG0RCnoCQD8HicSaBp BwyNZ5LFHQNQSAiWZEXKnSgySMjash+0BR7HMkcNbDEtLxJZZdxFBb8fR5KjCgLuFyVHKq8YIKkv WrDy76rqbhxhjrwqsiRjSEgMEtZXwh9ejqPJkVllCokXcDUevOqCGP+stXtIklaJQGh4SKL6Wni6 kMSFqBOHJG4k6ZDk+QlDEje6ThqSuJGkWXXVhCSjFVBb+GDQ5zCkg5kAXnAhrQnATYyEFOcGwH2p wqIn+f3br6/j82i1oqTUI/HHDtqfFMNaz5BXZZLz1AmRTxp/tHD/RBNXueHcKQqzTvt/JADhWSJR EAtzjzl4QKExMQjAmaQEY0OS9gvDAbl3EDKGMOSr0gqpbB/CPHiFKMS3xsSRr2KMiR5Jw0WcU4Qh HAmrQlatXB1y7n0I5MerbmrPLWKTSYH62iCv+nBx6kiEVwLhGqDirkztvsA+UeP55JIqRr0A8VpZ HSNpJzqyZs3EIiORvyPAFkhisxIp/yGu9aVLI/9xPt6VrhIZ7RJI1oeuu4mRv6BWkwx1wiGi+iJ2 Iuif54jhJLpfhhpWGjB0qmqEE1Gnhf6OJGk8+9XpoL8jXaeE/o4kaVa9iF/J+Lye1ef1nyKV5kZG eHsWJfNVLFGn+DPPVxhGqjzeyHgm50BtjMnX8Rpp828inIV6RRnFAOjzuKiB0CkNPqPUehHFJ0Kf MIZoM3EpAWAii81r/A9lF2r/wlyXKMGglAGyF2qis3YamHw8v53NInYTt3jdFmtM/eDHn95+eP+U mICBeXS+niOffqKZo/ohq8pp6iVerMS8V7eJMLOiiAoj0Wq+XZZw9CLavJyUcIbEEPIcAJAehHtY 4hGYtg3e0BUhRGWSMMNg2ysJM4IoWxfOPYjyA0W+QNvWhXdJ2sVpfcRRfTfeEjsiDlsX9qHLj1W+ ONvWhYdI6uONqop/hMGda+PkCdL8GmyYEGiKyaCFO9I1/Cpfixp2A5XpVfw+5avYWD1tFsn0oWBK dWsy/7Cp81v4ibhjbmfR/LVcfHMqw0glFy6dMjGPOwJ4s9YF7DgMOL0N+siSOTEjXkQfb2FElS+k +VN1GAXVHVaAJwkSVqeaf1omFUudEjLmzXhk30dYtIKhuZdT7Gkoc8lpeFj+EakDa/mzKk2KLD2I wfsWLd5uc0/lNK3sjvYM3fBSUpulD1XT2rNMIB1FjflDJPXt2Yt3cW5UfrvcEMJUHSNzuUDzJTWL AHN8E8VowlBYDDZjtaovZugniZ+g8WW52aBNk6yNxisKgU6KTdA8nQjO7SRd4CRZh4ZUD2EdoT+t sKKOlbo1HxqWngOao8UIFpowKvIUczAZDS9Ae2hmWchzjW2Z6Udaxb8rL8H1EnYhRq8kWpTQ4EKN SNG32+X5mkXoh1HmHmbuVPYsQ5icOWJ845nyt69ApgbkFKSsF7Ko0ZzUAnkMNi8PcqaDHIgjGhQi HQPQ6wXan8HOq8ah2xkjE452p4kl0axmyTI0N5WlkxdT75eczC0FMxG7xOtEgAPF0z65nbZ6l0qr 2tlPOh+OVRSiTMvQZz7TuiMOznIysobDh9Ive6a/b/fRo5+JFC0LGTro0E5dIG8ID9dfJZRUQv1D y2WFxU5ViYbLpCqlYKKgnlWqixVFKcMMvRhSUrMyGts5FQDQtVwwiQPc8+MU65Nas4LJ5BxlEIf1 SX4+cISxa32gB1V+PtA7/LE+cIekYcz84k3MGSUYyASrdEpfhB5fBTeCbSRISFtDHndoHA5l8+0W TYGqE3UVv0YSRGF5BWsV2O8442mtHkfYVIkit9S7OGBly8izwbLP5jWaGZHFMQ4AlnuF4cUe2eDO Mb29fqPWGmodBS5IWQXgirE8K0susuDN9V536kXbUo1VWNBtqFKeYrVhjoU8n4Er0AOLNv3wU/hG qXJ7OnVg96+m2eOSJKOLhL6evmBZg+Md6PnqoSA5MKRkZeZxNcuwpNKQzzKeKvoDN/rp6bi+M4Hm m53BXjdYnwf6HvRcTAEs0PS0c5hgwWZrELFAo2LNEqxhHaJAr0mbKjWnAaVYaC9WAWHKX8bxKxUa a2BLsbLq9UbkuLjUJyFqVMhYZRJLBr8tAT8WFGbCnU/qottp440JrLF1Ub5G5zT5IFMuVCOxmjEm s4jWwPCklwD1NNhiEEotY2TSOXHEnFi8CSfvMadYvQ8iWNvESQ22EFhBUMJeGwJJ3vurlo+ikMdd SA+JuJSIWzlIwbyDEXE/0PPKhfZIUst2jizcsbnQbIiknVqsHxTopvdcOlVtJtSBILXUPFjeXY3P g6qOXkXXl4c9i9n6EJsHdafqV2DTnhPsENSsjtEEuRiU6i6+R5zZohFKOaoEARWeom/XsITaai4k QtEbWBgEsNFKkL52jIs2urBGcP5kaSY1M1ZlJNJIWVo4FWPkDFWnNcjb0DpUrAD6+ln69vr6Wf70 2dM28gmOObg9dTJyMvBaGBY4lAIwwIfcE+U2sB0EVmlmZmXlsM/1MjsjwLQ1Oz5E+WmUdwzSLM3b JWk4Brl7Md70OKYsrenxocuPVV0b7eLHbAlmiKS+J6seDpifnqVR9qQ1NTXW7cnF+V4l+JwqrScy OzlLcuG6DEyVKmbzm/h1jTV6BMrIggL00H4Vi8jAHRieKUxPhrRGXlSh9CAZ8bOx+UTsuSxrVs8v Lco2/cEqH6lms+ydcNq6C21mU7HSp+5CKH91u17LxVy9j8anYS0h+hPUEkXEDr01oyrbRwk+VKB0 4hJJSeTIV+BQEW16CdtTSSICa3gWp9gBmQYE7ZRgxqu7QPq1eU9riXrcSq+4NC/XxPOWMTXS2VYF X06rZWmRZHlehKjJOM9tz1seTjjsOaUmUUjpwUOJQoH28pIWHkmOGgA1jbEsAeAokWOglAYO6J7H E4UjYEOLcjjHs50E/HQuWtPkEj5N63ZsaCAfp6jvde6q8Q7adelTs3beg6zxjCIMemzpU+ufBxm1 E9VV7/44uvhqgqhjZKGTPOE8zaFhSsoPSRTe3w5Zv4xRYNZgWIdeuwT5RulEkWnJfPF8zwI5JwlU AHGMJp4nHFsB+dD0ZN6LcozbsnbclqsMlqKIT5eImYSDaHrzprX2MLAVApBmYk4x67urPW472Ptj CebQIcFM5HGGterY5aZAehTHBR37pHjpmiQLcFVu7oAkM8cWTx5pYvNc9PBrenA3UZrr7f5SR52b 2sIPvk2tDuOoilEfBNLPugRWncCz4ZFYN+4Uv597LM/e8/PHg3R0R6YZ7VYkDU3aEB2JiAEkZQmd QevRQt6qrGurXgohry5XaFC1zVvUDhBR1wWSKp02C8LR88t1DZDJEBOs1iikqG1K+sp3WM530MUx OXctpEDGsL0RetZIxGinI6xddytEaC3BgmS6iAoxHKiJZBxrc9zuQMxXD+VVhUKKIoX0RV89NlAa yOW1YCuF9FdH9ioyVv92RumuF1dX8fkKAcNP8nWEzUmoVQNBAfX80sEdGrVRF8NaykFhud5uf6Zm kblkKgaBfPTfvb9HGUhKCSwbKbDrELRfT9jF8qLat2d5H6dqhBba1yCQ2UtLbtLhw1rY1TjdjIHA umm+QVcN9VpTpRJd9Ej8nVNXCrhL+8ig+grf15w7Kb/hvROUBkXYzMyF39Mym1fYsq3CoquGJBeT Z8wdGAibV8ETQ/SnrdjkQAhwUV5U7jFuwG6ik/ctigYs/DO8xHu9B+4xG+qMFUQpUMLNFFagjS9V adfDBvKCrpcSgIGKsbogjG++vj4rBEAttmihRoUU2RIUqntDuCW2gkVDPh5pzsIAdpyRwDjUKINO AbQKtCOApAX1u+6POY10r+MykTkWMxMJzRMRD6BBkFp9GqIQg+cZR1OTpbwZeUC2AGeVEj+aMdxL Sky6KEF0c56UtOUJw02bu3dGNA0h3cueZejaG9k/Z+c62DHiDVjaXmk4GLRU6VeBUxrSzUB3No+d 01wUNK/qIfwL8hA8/E/4Vgtyfw+8Q6V+wbCVCeoT5OTpOFDHn3CMTRthG/RvgoHpSgrRUIzf1Deq GXSO21F7BMnQxwVn4IQ5Fsro4FvzBOwlhm9EBx090KadkHk6/kTbK6ou5kB9B8aFBmFzZ0Wa+YZ7 4xr9C44PHTW/U53jU6DPIJ2i2TRP0DPVzyZ+NHTQcTvaHoHdATWVUPXt0Z4V6jXrCADqu5CJz90h o0MH5ARnNdL7mAwMyIkVi0ZOrEqT2u3aAifFD1rFbIS7q8DYSojmtjOPZkhnx4iQlDBdxrEheIWu I8gRlJGESW8QqlJp3a21ySizZo/JtEqLCv90uIxF8eZre1+ssRBY5WS8GHa1piYf86EyCLAsuB9t 6Pjbnz99Cf/w4ef3X/79/59b90UqY29MV3e+7j3HOPD2ORK7GyMOy3GdelzZ7ns+1SPaGUF+EzCc Gp6usr3tviBBB/qvGoA2rfsDR6iTiJP7U/GEp/uja5T7QxShbvALvJ9EbFuRo+m4v2asqwZ2zEo9 BcnYwbf1TxJ5ajhkdArvjzmNdK4T2AhDZPDKHf+HtD4eiH3srf8DlkgySS6uUWA70rEEzVjX/zVj reWxd7fmqaEBlm9vDD7LeER71v5I57qGN117YBjYuj/LY2ui7EhnOnZs7yzcyfhNe85oHwinICkb o/yQOu74QPVdeS8litYHQrDRcaj9mjqmc3AnjJqzO79LGDzjA7FICgkgOFfrA7lENkk/m4607wnU aOsD4Ybwm/Je9g7mG+5tfBzW+1CoDj+5ewQp1aNEHd2TziDF2vGBaqbKx6kj4wN3R0EWbRRN/CJ2 +/lAiYaikv7yROsEgwFhaX2gfcWHXnozFgyc1ZyD/I42AaDe6pEdayFwe6/jJkDdysBWO5vOZcZQ 7I3sXmc403GhllufTIWJJqF8KJAuUDz1rTc+FAligQXZvU54Pw+KRVBo0YeZVk1xQevZyBX+ih60 ec6EHtT5EYc8aHGVpq3HpmyTwmIp4COBF9r8NmRAoTyFMYaXL5ADKfqsV/ChAS+H/4YK/twAdn7G PelPltiUE9qY6Vr9oXsRsdheA5e34fL6LLxgabj8Bz6rcAn0coG9eOznB3wvw+Xf9a//xkcWLrEl +oUIluEZYtz7l+2fXnGY1k5qsfmrIsO7jsmSw6xg37+hifVqOpgYNrMmymt8yHCJbC9RjkD+ArM7 OLhd4sfCnpOcBRd5uBR6sPmR4StuZz7QbUHnzPCBR13oU80gWGa5o9rAxnJn+KVngKnY/Sqz3DFa sPPaLXcMXu3lMyxlZAdygZZpK47ItGK5SzleGkUF01KQR1GdsTtknUgaH53VLxHGoXlZduttXyCM P0E0oF3YBpwk7DU+kDsZlEb8pR4SWCN+NYRxT4oX+hQjbx/1vW/x0Yr97inn+I2xYLkrtuZJkAkr r6p3aFKpwJ8K4nmzWMkYpx0bZf/KE7i30VMzZJs5GR1GbEIsNb+ZM/+m5xLYPwp1fC4HZWFY9WSB eI52mhZmNr6q91+YpiwMCmVuZHN0cmVhbQplbmRvYmoKNjQgMCBvYmoKNTEwNAplbmRvYmoKNjIg MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1OCAwIFIgL1Jlc291cmNlcyA2NSAwIFIgL0Nv bnRlbnRzIDYzIDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKNjUg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAg UiA+PiAvRm9udCA8PCAvRjcuMCAxNyAwIFIKL0Y4LjEgMTkgMCBSIC9GMS4xIDkgMCBSIC9GOS4w IDIwIDAgUiA+PiA+PgplbmRvYmoKNjcgMCBvYmoKPDwgL0xlbmd0aCA2OCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVxbc9NIGn33r1AseeM0Tkd9kVoCvIMFARLHRQVStVM7 GvYBMg9bxVbN8v+r9rTuEna7Wxl5gQfjK0dfd5/vfDf96d17f3qpx9KUplJxT0YhZUksvVgoGkZc ef999P7h/ce7ev2deV++e2Hx9/sXfE1/ksVhWL7UPhMxjUPBEi8JJU2iOJl9+eZlD15UfrB6ePjm Xb1llHnMe/jDW57N/WAR+Bfew7+96wfAOgZs5g4sFlQowUUDzCuAzYzA/mYPCbaaOdoqjqlIklAN IPVtNRvY6nyRL/MLB1t1F3Fmt4hJTGUYqcgJGHGyVXdfzSz2FYtiGsapGZL38G3W3VfPVsHiMpjT KxLmS8YIF3IekCjk9lBH7DQeh1TEYTqwnnmnuVnPdacJhgMdCj6AZN5psVTBKgkWJH3+/IW9xUYc BKFSmnAwUE0a5dk0w3OzmOt+a3iMy5BKKfchGm63l3IdzMnfCZfsFyd7aXAzB5JNFE1DKTwDtiFt TGstFiuaKJGaEA2t9ezVJlsEa/I6X16RN9dEb7O39mYbczBlQqMojkwoT2s3IULKo9TJbu94vrwM SPnnvb3BCj8wc3TmKWU8fMpGExGnUYKjzXlKFU9jj0EsgMihOxIqJItH+Kf2R0VKIxHvO5zDhby5 6Zuq/Y2/EljMaSx57HF7YNOezIbHlFI0ZnGyz1bDozkekhaIcOd2ElFFKZWQiAcglRJxVkrEp0EC rO9fZodVK4Qv51q1KpFQHmKXVqo1KRRvVD6USoxTVmL6DcL1wrsU3nKOB+4tXzfPfvcebqdTspDY PIS+6IOdVSh7YAUNK43t9be/SfaPoFZsLhkLZoUJBiwxwYBvSpNhdbUdWflwXT6clw+L8iG8mF2y 5iOvyhfzCzzi1VX5UP3MJZ5hOWj5mavyWdj5yKz+n+rvV29W/3/9KryRRvWu/CaodtJlZfDqEjLX ZlkbEyIUmHRdW/rgEjHB3qM6ZFryDCtnG8l12R8hpk0oICEW4TiFpw5jGjKaWyDXFYs2jAYfl0iV qCOIeoR2f//rnUMcMrBTQUvhzMizOJMhiyDKzHbqoXqanY7RbBLSUIRcWiHy2EznBm4+k6+S5ks/ k3MCfe2TJPA/BhDad2ecBCxY4TWoyMe7D3iHUDlXwVWwI9t1Nr8k78DQxVacHU8q7DXxEVcGd8GU 9hvlVrRJdjiYeAQRQ1HpHA5Y5PDhGB7Y89ss8F2IpGspy5SCiBlCvNS49ENcDpbqIrKkEREjQSUR RRksNaSRdbYZTW2FMDomjRRSQiwxWgmYTnhkdWgu8OeIlUpE1ZFl9Xl9gq2Oy0iJQALa/yeit9ZZ MoFwOOK1ijyQ+yz4rSSsfDmnwfvb0Qaz8ZvQF6FMYuYpM7xeCu1puts6FEBAiMXcH8kNN/zTIB3z UU0oECsonjY42R8JlDv+h0gAsWYVF9hLRlCYa1oPCeQyEjBgrUh1VCAwglWbQMAAqWLVRsTCfBEM BsluK+CbOABeqwgLQMva4PAY+uF5+dAPAKpwIl9OreOhBpUQiWewQLUojQWcZPyIVWmYKUZuOo5R 4tlflekf/SfoeBtn1+h4F1DjNYGTkD8CqeeA77/8mufxaOq2wQUnzFLOsafM69fD9TRTHePJhCNR Ak9iB6kW8y/IP59kqGOoWIgEHE/cUAkUH4kvApIvk7VkWz8gjYQhclG9RekWpTfUkmR+0X0fz/R3 g/luIzOEJyudz6YCHh1Z2ovZyEBY74riYm1qrbEu3MJ72oQfdfSkMfvZqrxwxFcoj2VrsghokCmE Twi4isvid3nO8Wy+K54W39hl6w3ep0J/g8rVhgV+sLvuGOVEl40kq8S5sLns7WYHyAFZBcXSZOtV GzNuFlJlu2B3OylslqQ0VkpX1+1hO2idMcFiXayPOdN1iEqwHqlUuriFEaBat+AAyo3rXHVWk9/p 28lcn7z/PN4tWAbVrVvomcqMy81U3VSYVZDRuAUDpGFYffOWvJZJxgKyC1RGdVGwSudUR9PeZ4zY cJzrQBK5zf7qmk/BjnzMfAFi7DAK8SW5DHyQ6CbQZLM7PSPqmFhKq6abihHXGrWvPdsvBcOvZJFp 005Ou4hyQchuu9DpNP1KTfgEa4OlKtJs9acLPzItjaKzAt0VqDTEDtd6IhoFg6KjR1ZZcvMGcsqS j9jVDY26gHLjhtE02odkpqv7T6ejURdcbqYaTaMmSEMaTZ+TDzigX8/uyN2/fnv8eq6PqFY2mqZa RbsI8gsoXiScyEeRQcVtgsUqQw4dn1pvkzVdZJuCAwqGm1QTNXFplDCIo1DaSLl8ucF1bRZZIejy i4yhexDsdNvzEjNThXMQQtuIbYYWqjRE5OwC9VS8g+bGiIVVVP+z8I4DKLfDNJ53epCO8M6bE/KO Ay43U43nHQOkH3hn0FrjdPIKUWmsY8Kp8pgjmx45YCIPCNwLObIuq4YFmTUk2KMKYw/0CNfLUjSR IP8/AGw+l27r6noEeMgoKq9iAMl8BBK0ToxMX9iEChwCTpfNjZiGe83NTN3tr0n+WD2C68pIjMb3 I1utl2dr/el1ExTo2jQ2IB7uyJoKFKmvC/G8DhYKHbX2dh2x/VqnqjPRbS9Ttwo1LLWiEVMyVUv8 9orKQGy93WzkwtcC4e4xugtfnkXPyLuXD+F9+unz+yKAgO7Y4EcKVREoXaYv3n/x+dP7W3KiNFgk NVMIq3yQpgeJcGbRCqNJF4WFqOwKZFhqkGUG/v/JCSxEaTeCoKnMtq8mMNwnE1MCQ09okmLLmjCd lhIY8hgpQwP4EUgHKKE6/YiykRH2yU6SufQhs8sD1ZXbJUHofGu1ESdqWYlQaZVgOIfDwsFryA/j ChTyxfJU9CUYkCZW0XSTcmFXSFl0+EtnLB5fnmnUO2SpEehgAiTrJzdWGHSYOPnLkfwNsZW8qLoo m0DnVHaG08MckpWdT5e1cADlpglcpVOT/I16kMzS6f4FOeuViT7my0qIJldEodyyhSJoyipN8Qjp wzWpMnOd9OE1yfzKFeOjhZI4UVyu62lKWsXlP8KulUFZRFII2AsJAW20CCbFz1IExGGC4+aA32Eb jVBlLI1phCGIBpKNACBn8e9nH55pKfnIz/Mc/1wEf2yDtQ9RdbdF7qYyunYZM6vRyRGpDxEpzM1E iGccrLmuc1BoypxUWTVyV6bw1E3nvkntsgz5LqTn4RTmkqxkUf7FYSR6PLCyKIGKXVyRm+cIH9Gj tVvfTmpjLiU6/5RXXsRP5B2kQkhkIw0dVnmwB22CxaYtSxbtNe1A3qAvS3ewNG01P/RlYQ2d+7JG nPWmL6sP9ueY0LDA1DXgFiaLvGXVYFUNWvRnKkCc2qqrshWr7rMaN5pRdXbNlm59WoMd1UnoztrZ 9IISmrl1PVGsMBKOsXfdsHVwR2lhXxikaNcc2ybdH58/CKolM3SWpwIdP/sbtcpooxijmS2dRNlh Sx2c6W9KSbICZUNP03rTRpTVkGy86f1bp5GLEQe/GblwgeVgKSyeq3xtZi76kMzy9eZTIV918KSr SQj81kM32aRSSX4BeaK9Z6Nia7G6XZftRUWlGCVkFPaz+YmSQZIjCYtWepu92kyJTHPrCUTaCt01 iVdjstms0+4KGVGFcS7c86My0z6eGSZ/TjEnUtwTA6MZTsDcbNVNCttIjxhpslRX9U22GialLgNd oVT2yrfLy5btP7hvSyhUGBmBDRdxWlvp/sswQneGi602OyRkxlnKctZHF29liDl7F1jjLWVTasBc PZUcibgjkHp5RSZHm6mRRIYxaMYVVWHK7DBVPb1PMxNg6eLfQUHEcIcEhWl6W0i4n9BsCX+j2wIC 17sjDG91ZJ6vZBhfj1PoRwOFghZ6Czg+SLJZv1Y9orQWRpgjM6vHQtH+JerRsKla9egAatpN1apH O0jFpvryvNBEyGE95rlJEtkf0REKU0+JxwnGkvT4W7vE5joSJmeRus+XGUOHO7oskffI/DaniNtw 4M41RfKjVXX4zELqVngtAidN1jW7VsChAYqNYisb1n2JtOpip4srASmSjEiL6bzrasv8DG3pbXFP dzchzQP5qbucUOjEm3zSy+KQMmgY4p7DZdXTytPoUA4lk0QhqxHtY4ehXDh/KOtSfQk/sWDWw8K4 wUVjOhug4xnDRgPqYWE9uF6t5T5AQwV4CrWMZlM9zpWacA1XdGpDVff/Q0WJJowdmoHtTZqdQizj NOK+XCr2TMBOayscRx7FGMg1QRpuq+nFst5TTEbKCdb4XWUjlrXTw80DQAjmXdXTWhOL5VSiL0Cg xmSF6SRiOUWLKk9wgzNLSH2xXBYYUa5BQocx+RE18dKbFjX0RvPUrpWfnT+sqxpmkSBCKQWF9+Va zkuVMal3bUWDSihu2GQ18pAA3aTqDFo3DSG7RQVqn58Ycgxm6KC1Kg2WXyzkChJlJctpi5U2MMF0 xnyH1/EhTMfoqTuMa9Bg4xeGvp3U0GhkxO12cAO3+pps5JlDmDNCA7drjwgsFfWMvlkDE5e77YwA hXsLovcsEp5wAOXGmq6p3whDfSrBJHof0pHU75s6zIHke3UFxYyeRTQltJEBookkwIlnENp68Keb +q34AAngMmdck0Xzbb11O5HIpFu33Sc4l5xzq8iiyGZrxvshm30oTCqy3N1o6WBwMu3VKkZVHMEf OVztqQ4qup4QClkNKEx9TqEDMYGLQ+GAadpzqtdLJRha70M6ck5fOKxdN7lsmTJFCIbb/iiowJ6d +qCG4lTH3vBXFXPos+77wQrTRNqbIelQcEmHSpJtOWWuMyrNnbvwAw1d1KkKfSDLX530DEm0yfNQ 68zqol2d3f8AIjdcUwplbmRzdHJlYW0KZW5kb2JqCjY4IDAgb2JqCjM2MzkKZW5kb2JqCjY2IDAg b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTggMCBSIC9SZXNvdXJjZXMgNjkgMCBSIC9Db250 ZW50cyA2NyAwIFIgL01lZGlhQm94ClswIDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5kb2JqCjY5IDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIg Pj4gL0ZvbnQgPDwgL0YxMi4xIDQ2IDAgUgovRjEuMSA5IDAgUiAvRjEzLjAgNDcgMCBSID4+ID4+ CmVuZG9iago3MSAwIG9iago8PCAvTGVuZ3RoIDcyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAHNXGtv20YW/a5fQVOjtTyxR5wHh8NstamZdVJbFoIaBry7UbEo7LTYBFkgm/8P 7Bm+ycjUDF06bT84kin5zOV9nPvil+Dn4EuQBjxNWaoSEag4YtxoFWiZsCgWSfC/D8Fd8N9g9for D+6/BlH+/9d7fMxeyXUUFW81r6RmOpLcBCZSzMTazO4/B9ltEBcXlj9uPwerN5zxgAe3vwXLo3BO FmR+Etx+DC5uAesQsJk/MC2ZTKSQNbAgBzYbBPYXd0iQ1cxTVlozaUyU9CB1ZTXryep4sVvuTjxk 1b6JM7ebaDRTUZzEXsCol6zaejVz0CseaxbpdBhScPt51tarF6dkcUZCtqLRbsk5FVKFhMaRcIc6 QtOEjpjUUdqT3rCm+UnPV9Mkh0FHUvQgDWuaVgk5NWRB05cv/+ousRGGIJOUGQEPVDmNwjaH4flJ zFffaj8mVMSUUvsQ9dXtB7UmIf0bFYq/8pKXBTfzcLImYWmkZDCAre82ppUW1wkziUyHEPWl9eLH 82xB1vT1brmif7+gVs3euIttjGEqw+JYx0Mon1duUkZMxKmX3N6K3fKM0OK/n9wFlseBmWcwTxkX 0VMUTcaCxQamLUTKEpHqgIMswJGDdxgmFdcj4lPzpTJlsdT7jLN/Iy/Trqia7/gjgWnBtBI6EO7A prXM2o8lScI012afrPqm+frD9Tu6WRM6l4R+2O1+X1Ou2G45z1RIdydqQRdqM8/CM7pbhluaX85U mJAVPoHLWlfP1c1uudiu868S17uduKL0aA6r3/2HnsxcCV9bSXyZaAKelUZCuTBR0IS1olnI+GZL 6E1+mGxODeEZSeCsrEAaUcwVfoOrIQa6Juc4KA5P6Eei+KRHEyZmsBwV+BytvoGS7JZbsrjq2sNQ HjDC10oVM86jBmKhd9+VBFWpSYI4kCixN6b33Qa99iCLPS114bWAIrSMZTAEqm+ffmlJm/rYBA6w BlO4mDORGGkOQSpSuFmRwl2+obsdKHZjHMr8Sth8TReEkSwhW2pW1k7OF+rHVeEyYDtbGFaC3G9L YUvWuAoXMan1SGmYSmQjchfH4OGlx1hLrZogBLGpVPOAtbw4ntSEFUg5CArk5AHKTzV98xiQCaMS k/QgDScK95f/GGvEjvkyQmvEY9DfrqSGYflJqm3ELn7FRCySCHqDkPp+JX1JH+owUdlvFd3nuyUi XRba+H9acYGlARHIDfeUzKXKjfxGZkz2IuW0Bl1bD4fKupWcwErW8D6oO51mIdle0PUGoO2bH8X1 BcUBw42tGawoyYtTuAK0x+AC+CrLgpaMkfWahtOeLJLIWKy+u5+MzG/U4hX86bni6mxVkZmt5Skt fzGbrvSXRCmT4NcufhURQRwd37aAHahJjvCuIOUR1zFsoQTmwkX8zNPXkekY5smtx+hAGvYY9OE9 vSvs7I4STk6hmpZNW23cbjPLzi9yu1urzYIRqnYnPTPsWm9u2QjC06pwZZw6NUyLyKkgXBLwXGef Q0N4lOT17KAC+f01BOSZ8dQW40u57Uvc+mzVKggIVpJtydbdpEZUBrjmLEmV9kLnZ1K+EQ/5EDNR OiywfsQzq8aSPAXmV7ITXDIhJfcSWNtfH3CLI1KPujSgQRaUjpxKAz6cs4cpzzwO5B4KdUQplQl8 MI3XK6d0KALnNKidH4DUSYc+fRrNOevyxmwwS0tQaZJo0njBepqkIK2v9+ANTbcvb9zUncAkRvEr VtDxYYWqen8z2/v79AmJYyttvMnmlofRkk/aGHaHaoXNIO+KtFG/f2fLLqhPNT5udqhj+I0uOrQy bVCIYvi48jgufMbDZEcwGQm2kPdxKkgucWoT8pypKqqQYS9ass7cXd4IsCpCG9FEfcMZTmrXEwuw ZiMa5WiF8OrQBd4tE+Q+fLc0nEwqsYSDNyORDLQHuit3SDACX6KaSLAQqfuQDhBVL0i+gb6JW6hU xXZeYf+IQbcV7FEr+cZX5An3oDdu4pYHpqd544NlvDpuDUPqxK37dPK4hcyHxwY0zQPW0yR1MG4Z WyvRqRukgOdxK72k71CvvOuEoYODKz3VcqnkcGEwSJMcFFhH3Z8msEOqxSVHu1fAs3vcQ1s3Gu0X 8mgdDTMirqyvsvHaA9XTBHVIs7jSTIBDuEEqNavsrd3RoqEEIoSgXeXqa4JyW1Eqb0rtRdMtL2mh pWqHEPIm3TPl9RiQgDK4kKPyZB4RawTtwCgCWtYGMi+A7YsO/bzZg3SMsOAmYAnBEi72IeonpuMR WVM5ZMAY9BPCTunpiIOzNyHU5IYWFz+KyTPBeNHjeY9BvZPgTAbLED9EsMQQmn11Xb/5S3B7NdkA H8hRalKOhKeDeVaC7WCWLCpHCwN3lzNC11D4V1pyRI7DmCDHAhPkGBcCxE22AjwrXrHi1ap4FeEH D5YoztlLePG73Unx7kXxsvzEafFm+YmXnd+1v22Gb8v/IL7N/Vb1FN7JE9vqELcm2BFLsO9W1eqF qUb3e7UX1HB2Wlsh6unI6FFj2E8bO9kpclM9KSpYolJ2lssH1R8QtIIvs8fS+FgyFdvpX0dIGOGd LdPUpvEPR9d0LdWGb+k5WeSdola6iSyKZ9uydWQTe5YlGWsuWNMkQ+b/oDB9Yoj9NCm6L8WkyTPV qWMYNZeR07hIE4JtawzNbns65Im2TXRV680UxQkurOtBqugD1yOojHCGjYHFhqUJZj8ccmvqU1Ac AapuYqON5gzKz758U+q6id2FNJxS3/9MX4Tbc5WF0LLrf7//8HBMa3si31rSjQQLRLlnVc1f2Ben 4IULdWr/mS3oQ2RnsZ6HJMZ2ziXWLiTxl7aXKE+Kcl/lT9B+ha1h2uzXTcjygbS8YogjFY7DckxC f9uQBYbRFEV3NzvN/mmnttAks53bZzowVihQCnU6cY19TRYYhmkcx8F0coRBYNlDRZEO4hLgvij4 nehxjCa3xFbJPkjfiR8rNN9kg2gMPS5ZMjizO+cacV9rejwAubyvo9hxj3G5VC5qdjwAqbyvbXIM wnWmgiUKdpb5vsAP5Bol1T0v3iwZb0luK1Z8Cq6cU2YHVu3Pg0fcEw6vByqBzarH1ai8J7UAnkKD XW5KHaWVUSzmbpsNT6LBLqhqGuyDyi9Mt8vMTjlyRYMPQOrUT9Of6b/KyNuMCJUTORigDkM1x9RR zQyncPACi3dKYvKri3u47VLOQeXjIhhtmtvZp4aY15MkOALnZHEBrltUpJ4nmGJakznNjaw35+cY 2UISsUX+sFtueGsWHWTHVmyb3zTkoqyaFfPcdgiMcZTRqkIbJirA6NH86UnkmQ6PzUWh3Qpslkls CZIqAhkU0+phS/vwu/JGQxbXhNC3R5OeQQjOIoUFRxRJnM/gYdUjXLIQCqutcVxDcklSjq8yMvcp T4wBphTDqI/0AuYhK8Rv30RFoKuVcEw+VLdvHzHrc0XCFtm026kCw3MqRUvSB5afpNqxwiV8CY3N Ms75IKQ+hUUutlueEjut6bvG5Td7JFGmSBOsXvkIzKNWMIIaNiwEap8iM9ynWn2BPWUXw2n4qNrF wL6nM6jxiuVEQqpdjAOQuiQkpQJbFhn2lbDAFG65rZ9hWjTfhZ6Ue2C/DPPKHNyjI8Fh7rGiOa3A JqhdO8tCZMHzR0I4zcqR1vwTdKtwREupUA4oxtMnDWeN0krFZCqcKAm4SFMlzNflbJAutmBq/LhN iQ3Z1dRT3r5TJj9TWfw0ZG77gPV3XU17VPRSpURLXHkc1cNljAiQjfQ5HgUQV220Yd3yS1xGoGoS Fw9Ufj7DN2zX9XuUn1qCGq4vpvejBz/cl2S0ECbwQeUnKN+ojbE+POnEEokBQfWDEDK8429zi9J5 oU6JzZHFKxQp86pkMcT4pflAzwFUXf1pbbmaecMzPcBSjFNnAxPk4RzeNivqrflQ+bShA9OCWDZD rlCidCHmXmPuI6wby++YKQdx6mAatqRpdZYLpMLYohiE1NdZbF6W6yJ1Jj/50o3g+YzQIM5+7jCt 6ARip8F62CCkvuge3nuU43tE2IVzCvTxYvsIgyEV64PyCLTfQDo8HFIHWolGOU8efWRAh3M+DRKo 8OBkeT2vIrHLjzyrHqEZU5BXRQ352QryXcx/jnkVB0x1RRrzKhi0tyX5st6OJ2nYynxZoMd+vC3Q F0X42bIszUMfDo+2VEV4e2VVxC+HYdCms+9Wcy/L4o90R1y6AB4Zn8HfmLW/xr0JM8J0hF0ZiFMe dOX7Jxl8sY88wQbBY7l2d/DFpy+/R1KHLLruy/uAGh8fbK6dQxqae6mWyx0h5XMv9/f0qMxJ0U9v MlI8zm6zCJt0zTatbeJXzMTY4Rdke60gjBmRCVZYBB6spRXWTKsjuTTgPaQ8glIJg8Wl2JgakgvP w17j2x9uo/vLyzc/FSuupByGKNsQ7ScHzoYeZfKYqro80hBPK2IJ4qGLEJEGnOc3vE7YoQH5zS/n n9BBKZ+MsW6mMmwhA5z7bGMfJGMftgPePUc7h9tWRKUwkz40B8ljPrDsc9ZpFUbiyX9CYHu7guSm MB60bYQWSxS6TIoJeB9QbY70f3N1UtsKZW5kc3RyZWFtCmVuZG9iago3MiAwIG9iagozNDM0CmVu ZG9iago3MCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDU4IDAgUiAvUmVzb3VyY2VzIDcz IDAgUiAvQ29udGVudHMgNzEgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThdID4+CmVu ZG9iago3MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMTIuMSA0NiAwIFIKL0YxLjEgOSAwIFIgL0YxMy4wIDQ3 IDAgUiA+PiA+PgplbmRvYmoKNzUgMCBvYmoKPDwgL0xlbmd0aCA3NiAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBxVz7c9u4Ef6dfwUiUY0M2zTxIAkmUS+iz7nEtuom8T2m0SXT cZLe3STXueZm+u/3W4APibZoQI7c5Ac+TECL5e7i2xf/YC/ZH6xkoiyTUheS6SxNhMk1y1WRpJks 2H8+sB/Z7+zo+ItgV19Yav9/ucIwelLkaepudVcqT/JUCcNMqhOT5Sa6+syqS5a5B+vD5Wd29Ewk ggl2+ZFNH4zG8SQe77HL39jJJci6jbAonLBcJapQUrWEMUtYNEjYX/xJAq+iQF7leaKMSYseSeu8 inq8ejhZTpd7AbxafYmR30s0eaLTrMiCCONBvFqVq8hDrkSWJ2leDpPELj9Hq3K1fxBPDuNRcsTT 5VQILpUexTxLpT+pW0iazNNE5WnZ496wpIVxL1TSlIBCp0r2SBqWtFwX8YGJJ7x89OixP8e2UARV lImRsECN0XC6OUxeGMdC5a21Y1Knidb6Jor64vZEz+IR/yuXWnwTxC8iLgowsqZIylQrNkBb32zs llsiLxJTqHKIoj639p/Oq0k848fL6RH/9oSTmD3zZ9s2iqlNkmV5NkTl/fJNqTSRWRnEt+/kcnoY c/fvuT/D7D4QBW7mZSJkehdBU5lMMgPVlrJMClnmTAAswJADd5hEaZFvsT91k6oyyVR+k3L2X+SL l+us6ub4moTlMsm1zJn0J2y3mtnasaIoklzk5iZe9VVze5IIIGI794OIRVYmGhBxA0kOIkYOIvL9 h+vvbxvcGm3GrRo7ELRRMS+imIgIt4bBw9UtaAVKRx14tjioBdbQHKMLU/iSBCgdTa/e/rRc3p1T 7I+NZBUqSQXchCCy8q9B0kanA/BBlFKaliQfpyPg5W2x1xiZyLQQfXkaBoHlW36h+XwSF/FozGHm l9NqNBvz2Vzr5V41OuQ48LGK+cN3qeSzeFLEkxMei/gAA2a8Opi7U3rUPrLc0xO+F/n6Vau2ONTh K7C7FlpqH94LnSyn40qPeKJHWNnhGbwae33+7s2H9w/52Szm3z25TF++ePH4+U7plxYa54KF0B9g ILeQHSlKoPUMGlaz1BnIYdmBgzNW+uxQWflYVMs98DU5E+MjXo0gU7qoFiQWy+kcF/NJBYbH9yUa yiSp9AoFJJN4AVkGdQLyPOOz6nCEtVSQl9H4tLUi0W0Rgi0kWSiZqCzLWOFP7m4Fodu8IRHm5o2y j3PuslH6OOLdRrmZpj6eCDC1N7y32/BEt08OUrQGJ65e8/Ofjh8c7/PjD+cXPH9zwU1MVmfBx5oj ZDA5mo+tJp0/kPy3Vu52EZmSmUiwzUPdN9Pff8ux7kyoipfTBdx0WHqjF1U869RkF+SqXMAhNjKE 3AA16QmAj0h2apKCk+kmPLkWGrqLmliIewvI7dRkkKY1obybmgBSfrkaQLidmnhQVAPcq29/Og8I lvXeXQtyB6iCV5KKDJGDwp+qr8CnAXxr0iRVqdSeFFnUXV7xi/fnzpas2BFstOM4GfNOV783Z4Bz cczPcZ/wz7PTFz+ccv5Anu+nDvE8e/z6Oe182PDuaXvOyzQpS5X7ILflNEni+Xg5NSIGiQKB+xFB tyJetTp44dv4ZwN5BSE1uR0ZCyE2wOxsAdNas5MX8NRUE4YYhmkBJEGbQuO8SOBISdmXHGdKZLJ2 rSHSaYZkDf5Fl1csz61q1gebYMjaZMyFi12mDA/uKhkDxz8rpUGmaY3O6AbChEjSOk3EdroNI0Fk tBKlB00ts96w6Ys9dqjZtMJBsqlwVxN3tY9DxpCucUezF9Fl/cd64JH7Wz3wqbuqH/k7rgo2PcQB cyPnQ7904B45cpPBOtOcIxxy/NLUPQN3+2d2eer3/raQMwGzrdKi6PFqXbAcZml5Reve0g8NAgE5 9FJkqVfE/t5QQAhRd9vevNHyLSStIZOrx3x/tJjriqIMFjHPzuZzPRlzSqgBeB7oScwP4kRh16pm BzNAZ+wKtEEI/Ypw9AHh6kWM7eKgwpDxTn16heiLzjQ2i1oWfHY2FVcIlXiL6J02DJklutkvhrNc 8zMjqgT4ALxcLJAvmQEt7D9dTinUAw95lIizBeDExYfcwYerx8+eE3ZY8HcXF5IfxvCadxr/AW5D phBbjluUD6vvi81pkUj4VTdUIPT9qbsYAh/r1LoD+Waa/k9e8zBF62bg2SYz8P7BOV9UswQp48kR xG8GXZ8lk8rAoUb46bsHrWLtInIDJJFkOXJL9Vp8ZDDAym6h6hIp2syQBdr8vvsy+PC0iseEFbbZ JT0rO1RqgBALFUJXAKd6DqCPZigAPKmlGKKorxmHMQUwi91yCnl/W5wT8AZ3zCkNhFoiPjlAUZ9T opptxyUb/bfvbziXh6hCYTRA82Y5B01rVmR7LvkEFBDBTYqyBDT1oKgOc7SW6/mJ2zq345mvDjYl clmZw2whA+6xQVHS571GqLKl9QYr60/2FiZNFAAtpTFsnexhdxcpnLdl2Uu9D4UGtiBMkgWRpQgi 7PnpTpklRQ7okYbRFACLtvDZ2nBFVhiU9/mJ3b3hoiGi+kbtbgbE20G6haQ1m/b2Eb+Ahi7iokpi 5yHBASooRLaa4jRw83139200Ic1QJCnZEOV91EFEI1c4RabQGRiXVebz5RQ52QPy2Cg+Weed6wUi PEkLibziQz1Q0BrxgWhfJ6soLMtRPuSD6FyOE4DTHFmXFE4QVUrZa7wGWhe9nPox5M2rMcVZ46dz xGIp8WNdVjK0/Uf5qwrVo7t1o9pNAYWuZeGZLG2S53CoFZai5xRT3q1lE0hSiYKhjs6S6bN3hdm1 1TIZLwDZcg5pWyNQBXLDdto3IXexa0HpnyyAqPuya8Mkrdu1F66OpAc9bAioTnRAj2AcYOxQrCJs XgB3qOIAZgVV/SOoHEI/bZ0HFM1ONot3q08lKvEyRMKbF+BjQaichuIrOzXSnW2T8MVulNa+jSbr O4ormKaJex0jhNxajtaVM4LSwAi8aYKwa++jYbirFiIDt7pPfTwjl/1hfn5fBg4FNyjC9co2nc2o ZKUa/2vGKQ+/0AdUEcVtVROt8vzJz3wSJ3qyaO51ayVbb+NgVEvkbLvb2nYcD6P3S1UkWcA670ni NDp90NhROxzDyJ0vlwFFe1uAFWR+tKYq9hCqwkxkcPpMIWxMfU/rJA1HaMvXYBWSorMZdHT8Sk++ mfFXqkoUb2LkthLPmsy2QI9C4k5Ua39ut8YQ4cfcZKZdl5cxBIqyeGK31tBkaJYpdEua271vkc0+ SYjVZCpNCfkClqCYAJ61du1rqxXvSansPxSSlmh2Kw0KbpOSsn6qoJplpAAlLplGQWmaoxFOZBpF 6+ibQdF6pqQRJOcfb62quQvi1QYJz9yripKH1GZsoaGoPpS5yqChjqabgFV/qwpT0FCsh0opWRgF Qd5MUR/qoai2Ly4BHY+3h8CosRD/0D45SNMarDqvfRFpyzIBOpzLWLsmdgPH1uZP9hYvl+peS3QR DZHdf7kojBsDK2AHhvlCtoxAQ+0uOou3ikGceavXgKi/q9gc0NSm0fT4tS30dlqJMoZUlDmKulJs q8ZIlUWvj6+5joddET367qDN8AEwEL2taD35zCRsAk5T9om9toR0j1PNfX80mUcMSTIaJNx4e4H6 E78Z6Pfdj4o8akhBNbj/aNS6oO7BkY9zmCDQHwWNF90CMIO7alZwrSSrzwNaQf27CBXZc6KnXcNt BbhbiGSLjHVB5lbU1SvDe4GTv52qii14LNMM+4I/XWFGJxSpdKxCAF4YpL7wuvpt1tfUNwjSrW5i npHtDtIFULXjHaOFdAMkXdsyvm0hXd5AOudBkC/xbh8NCtazcPfaQN9KUwav+xjWIOBuMV4TBtEa CXnPxnsH8FBrSG0ibvchh4uyuXaBtafu/OKdki/xuYA0ZyHEB2jYnYyRhAiVTfH9sDEKCittQVRb RqADiApTsFBLBLVyXWrrJA37TG9L/g+FXmny4WN/271F1kMgJF7gWxYshLy61IlDsxFUNah2Rc0S QgzTLrqASEyBJhW7gi4l11VA8e/j08PTE/cQOXs71Z5uOxCUj/VrwiL0BrUnq/WDDYZbF7WO21kH tVlYF7MjS8CpyGOVE7MuFoUnKfqOBd9X25lOJQyHV2/RASJkI4rvXdhIfzU7sauMm9ftCttwySkm hkYKCqbZwPqKHYStrCaz8QmaRchU0lJ3/GqpPkJDgP0X2ns7/gq2hUlqRU+VQJjoqnZIZNhO6pGA G+FySthRG3ZTHqoSpzulV6DlPi9lyULovbbVDLgxCDi8QcGyQAVuyt67b+fc5tIwD5fGOiXKKIBw k5FPQh/MsP6Jv1NgS39oTJLBKyGnwM4AP8HN0X6D4rZISYYuYBSaC3iPgMRovsV01+5hUnxEBt4x 6o2a53AHHR8awRnUDCJdQxH67k5OthqR4ev3vO6sjqP8lBASHlM3P6I5JsWaO6oyNDOXKBHsaG/u XAGLgHajEWyo72EujRocRCAAVJrnCLFkBXwVFJy62VfuOBoYzdU+VdN17c71Z9bGIbBFvAFPu5E1 B6OOqvpt4JmG9ubO6nqae9eewkzXx/2CiJdk/2VvnED3e+hvchyVSIsIbruCnNI5pAznn3COjz5k pXHX8PDoDN0TsG34m71C+O1q5ZzuYibcvfZ3mZZuToyTAviRJm5/AVUhNAa/bc+u6KMfKrLnn+jz DGhiw4/aa4l64W4Gd0VzY4z9C53fcAYxtXctdTQnZmlX0/6CXTn9tluzo8Odt3ej9gy/+YsNUVCA YmMEhGKVK1KApaiSwhzNvUgPSAueamR4oxxYyXOSELWae102rt8hDexZhhUr0M3V6eRGKwAaVp6q pb+5062wuQN7Uj+zNq7mzZrWtPdsJNfKfIqCHavT+HoHwr7IzGXIwTOJL3Qhstf72hgZd9F84yIt U5SbIb7kPt7QXhJv3KxgSANP8Ekteqw+2Lo4WENMRl+T+Nuvn76wHz/8+v7Ln//83O2BpG/trGE/ QnFs9ANRt4/9LdM2+XT1uDaU9pXm79bCUP+EODaibsWj/ue2rPyRKSOLqXJUlFHnNRxAnGQIx6dm CxiCTzTBD2GauniawBFDHJAY5g4uGoLAvmM3WneO0SwjUjb9N44lm4LnhwhvtccPuDZs+rv76584 oNHmEQ4qmqIVab3B5vZF9aXIvsposLoSXbawUmpwWe7N4lt67kMpWNaFo1vhgOYhakxC1xDKQIl8 AJlDLPHGm7Z5CCPgqtAz1G6EEdSfhJtzHMCMemCCq6bdCH+sm5fqyZE2JHY+oRHRlL5GQiPxxzty zKcYpBED+locfe/MRcXW5KAX7AHDqNsKK4UjSov6iAPWdObIrhe8/gi1YAH7YEREI0buUTDsLiv0 jLFRliEzOfDTwBqvRf46c/LyfweY+8YKZW5kc3RyZWFtCmVuZG9iago3NiAwIG9iago0MDUxCmVu ZG9iago3NCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDU4IDAgUiAvUmVzb3VyY2VzIDc3 IDAgUiAvQ29udGVudHMgNzUgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThdID4+CmVu ZG9iago3NyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9GNS4xIDE1IDAgUgovRjEuMSA5IDAgUiAvRjExLjAgMzYg MCBSIC9GNy4wIDE3IDAgUiAvRjguMSAxOSAwIFIgL0Y5LjAgMjAgMCBSID4+ID4+CmVuZG9iago3 OSAwIG9iago8PCAvTGVuZ3RoIDgwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAG9XG1z28YR/o5fcSbBhoIlCIc74ADHrEM4TmJRbMaSGqdj1p2MLE/SkdNJnZn+/T57byBgCgRo g/J4MACBw+7e7rMvd4s/2Cv2BysZL8u4lCplMktiXuSS5ULFSZYq9t879pr9zs6ff+Ts9iNL9L+P t3iM7uR5kphL9ZnI4zwRvGBFIuMiy4vg9gOrblhmbrSHmw/s/Dsec8bZzXs2fzSZhrNwesJu/s1e 3ICsfYQFwwnLRSyUSIUnjGnCgk7C/tKfJMgqGCirPI9FUSSqRVJTVkFLVl/NNvPNyQBZbU9i0G8S izyWSaayQYRFg2S1rVdBD73iWR4nedlNErv5EGzr1ePTcHYWTuLzKNnMOY9SISdhlCVpf1IP0LQ0 T2KRJ2VLet2aNkx6QzVNcBh0ItIWSd2alksVnhbhLCqfPPm6v8QOMAShyrhIgUAONIxtdpM3TGJD 9c3jWCqTWEq5i6K2uj2Vi3AS/TVKJX82SF5EXDAAZAsVl4kUrIO2NmyMKy2eq7hQouyiqC2tx98s q1m4iJ5v5ufRty8iUrPv+ovtEMOURZxledZF5XHlJkQSp1k5SG7fp5v5WRiZvx/6C0z7gWCgMy9j niafo2giS+OsgGmnaRmrtMwZR7AAIEfcUcRC8vwA/1QPKso4E/ku42xP5MvbpqjqMb4kYXka5zLN WdqfsHEt0+OYUirOeV7sklXbNA8niQJEuPPOEBFRZppSiKiyLE7KwmFrAheVIaKkoPLmluW5jjbN wcxm5iPGVwZg9Y29IsYDtCyDbpUpyGvRuYMwzuPExrKsqWYDwus+YRCi2EIKXnbSZKbTC+sNm1+d sLOczc9xyNj8K3MIcRBsfoZDyhBTmquZOczM1fAkoHuemIsTHDCM/e3UXHxsDgoHDGMP/nH9Cvve GQbDLfa9O8eE5tEbOA6SzVfmDBf/yW4uRksNgHBxqeBPmxMdNCYaQkXO4oVKQmhmK4gTMpEkKctU HgPSVYko2qRQ26gbl0L/IYMqkXCVBSwmhhEILhTZDQdgSuRgShSxyhB4qASxkUyQKyWx4lKm5Pne 702RthV+aO6mwAvIzPvkbtFjqFNTEg8nlAc4bYnQEG4Sk2OJMgDWHU2Pm7dhhgqpCtUiqTtcffsq ejxZL2U1mS6iKyEjWUw382oyAGsPkJ7WpqTIW6R2S28qwmoWyatJxGW8mU8rCcMfcYrhDWJgWjaI yOjyX2/u3n0VLcPZ5kTOTqN38vLH6HQzXy6ryVk0lRHYiNLLzSaN7p4+ujgJ+nJwgOVInsUFT2H0 QyynLdTdCNKY9efXuvJi0AJpZsLLPClwLc+KIhUZu37+SXHmrK7OICcViqxalcApCa+VJJLhtEAJ CH8sQ9yCaym7Z9caYupnKUnfPRSAD4OR+8aDNDZdkIU0ow8YyVEhCwQGyFf1YKhLFak57T8U5wrM 1AxyVKuGMgegCfBcizt7ZSB7diwOXjxrmsYWb/sKX1o3t93JgIqcShGKY953FOTawfIgUG/ZS58w pgb1h2lqB6XDMH073+8VlHpM76TIlC0DU7Z8e0vJq8Ebi0ZF6AEpXEfAzqiQchpNq9MQZ5M1kD+c hApFFQ+tUSzwyxky4SI8l7iFcGtUtKpzAg7Dgkr08fOLcKaqOAQ/q8l6M5+dOwdGfJ7M5Cn4i5az Ss5aSCwJobUTifAbMUfSGJdBwRE0cDjoAQwO0K8GJPcrqQqBcrhEROlI6hPGTGXbRXzR0ErINEaY iRDTiqkPTQPEBGAYXKiUGaJeFCqbJHWHVrxSYaRQ4V2FkdycQMfI8MYVnVvmUAlHFUPatLo7rkK1 ayknizACfYso1PWv9UUU/QibsOQ/v0MQAxBB2BULbVmwmaVcLKqChxEHX4CO1SIcN5wR0AclM47c w3DXByCOJPC8EFh66ifwQW7sAKP2bmwIUeMakM9NmiR1G9Dbt1oHQ5ufRFoLoWvT8HQJ5yWj1RKQ Pw2jCrlL7bjIyhyea8ODH4tCv+YCHeZ8XJyHLiQiE8wx20dPYXCPABLVsRAiV0joFcLsHuuNENlk gnjB5YZwqZPwakvk71dV/IyfR39fhGF0GcaUm0XXP70gdvSsARv0nDgAMbgyMlygjqfItzlW+0zD seAik8gt+0n/eHAxgKhjwUWDpD1wcd2ECxv77gIMgodmYr4HNMbFC+e1cymQCvWqb2kUqzHjAQv1 dQdroA8b5LgMohAtEpmyAQxahDCoSPO1DnWg7zi1cVSwf1dGKxHUqemetQCfiuQCUJ6LXqmI80a7 lAv501oilyIURZiFwBAY2gTDem4W1dkETooys7bfOlIGliPbFLLotUvmqpoKuZoSQ09xRBgZbuZr xIOxnOhSItW98OORal4p9hSUEqA/gIVjgT72HvGi6BWUR5fj7gbBmnOa6xhlAFEjgz6PU1WIguUN krpBv7yO8nB6JWfPsGRvs5R1SBaENGVB1VZCdvrPoZYLxDDYarOcyW/OIxS5yVShs7p4EC1xl4iu KuzImYWxHBcRS6QyWQFEtLz2iU3OJtU/UIMZs+btgS8rBcJDt8GkO4FsxdZYRwAkaDwI369CyByF bpsBh5Er2Nw9zd0MvF7IxetoOgtDOLTNBqDnIv4lUssYsAn4GHc6nAfGlMSqlwPewcfTLXaRnVST dQWIByIaJSRl85yhWhXOFlMpTWEN90HtrigBJ9Q/ErNIAVLsb+qje6051hNl7chwB5vCTC0wWYtV rGff8ISlQZgmrYVoa1uOylpKW5Cw5oDFzv6sof6BzXimRgNFu3yUthzZcUKNLOdxxtNePndzUoUc VVtrZ86+nJe9gBUVNVNuQpru2avnQk/M3WaTGAVcIfigso5WYSWfHavsm2EHRtmLfR26w06M7Rg0 1+DvV90eiMEqlLlmO0KVbXnSoyTQURW1xlksUKV51gtybPodri9G9QEwHeyhVjAiS1ufEsEAt3RI /dXjM6I6nmS9tlYNCqFaSUKv1SIXQmUdRB15uciFUHtIaqwXld9GP0qkV5RyaESRgJb+GqYlN2zt j6fYl5llknWR2V78QwlpBueIjdOo9jmfE5oC4FRU8DvLMK5gyeRzqf6kAUIzBGxzj6zlVg52JBOn 7Lfkvdwswh3yonafQHu7Q0TcbuYvKB4yqGfkQOGqDg51pGT8rgslWo7bSg7iolT0SAJIsBFA9eu5 QMVi9kyvUdpAolFSfPuTCfKhqojtt9Ae/LhaxwujxATjBQWftjA8MqsCG2axwRIbBXuzChVFeVQv uvS3tgOWA7yvkdgBgXDMwHl3WoUSBXYBIfqmQMAHby56RfRHi0MInFZ8Sum9z+2jK7kCetB6sw7d 1xTjQ1uboYc2SpqgkSfF9vxI7OOX2OPbJ87tDuud4x2n6sSxtbNIsF19CMEDkPqzdAfRaZpjn3SP 5YJBjvcAonztQg4g6ki1iyZJ3UZWfh2luhJBSods0AMamZSDM7ehjFZQ6jUuHwraTQ5kTM53TEw9 5FjGhag9y7J+3s1lgY45W8CeSLDmMRDG9cX7/zi2Xgjor24m7EuuCyTgXLbxULtfhEsnmzngb2tS Gq7q+uLlS+utgIaL1XLJK4rcx93vh260LFeDuDwWgAiUlMvM7vPqLigdD0AGEHUsAGmQtAdAvkOi byNBgyHYyFXp6otZJK+jImgw0mXS2Yrr8PIs1Hmws0QTVyGoVNVaL07UCj6qytbBScrjvEh65f+O aFOFWqwqBMUUqNQ0uzvqeIQQ0l+t4XM5w7KSXC2weG3DnHHZVRz1RWxhkQPY3WbMo+TenfYHONZ6 MpCycLeZpVsHa59Eew5nEnvtdM3TB406HQlnLnQC3fvw/QDK0bqFEA8Uy/6UDwC+A6oDXpYCpf4i QevEjg2u7erAoKX+FlG6w2nPuqbfGTSEqGHAd/AO1z0kNUoWb7/9ecj62CeS0ltvO7vB0JaWcGw7 Z0PI+jxJgaiPt8HD3zDAlu9EJKnsRxLjAX3D4NWT6PunN8mr8vrlD8YH2NNXP5DjiMP1Sne72qUz RJkoqspoRiu5HmvGiMiox7RMlfDc9MnOBpjsASAi4HrLFL2IzTnfE6t4KVlc290u4apkb9CPx9E3 lrB35vsVX6p1IhWFYFg/cB0KtLCDCq4+79s3AYgK8BzGQYsCShnUNmFaFNy5aXXwPeFdXWMB7CtT qIsIjh2bEhU/bEjFgJ9eu8e1LBb4DkZ9X0YGKNGohh1caPZVwdYFdHCk6C6h4f1N9lqPK8H2czwH fTnaSuoH4dDQMkNLSI4mCFWmsLuacnsFQ0nsDMZeZXSNurvucQ1cK+puctckyQ9nuGJH37qiSdBD +ZsMVe17MHDrDnq/uyStCO6DrWtadlsEuWmoyXZXtllx19xdgZ8+d6WeqFv2K9r+UvY/9sZodRvA djXnYOsbkpRSN/pQO03z/B7n6MLOMAn+Huz9xZSguiYTfCzFnEG61I4D0TXOO8/svXmu+13IMPSz KE/S+0Tg35zjayO6c0jT5s9uqUufdnbaX++pp5oTVfU1mCLO3IjmzL0Pz+tf3XnXmb3XGXVA78LI Xgr+zV5KmjZ/Zmn1541fg8YZjOlX3VpFjVUPt3HBpGvlcp2gH7YVzinh1n3GgPspIYZy9tRWwlrl Pr1nB9JAWrUFu7FqK7dEbV3YgSqWQwz1Kdf3ttmViElSfC+AjL3EVlMGTYWxQ13RWyHQRFhuhx/0 qRvyANw1oydlonSPm/7aDBrP7Wk9Liyco2HSxo/4/A3daQ5mjQQgiPHI2//tt/uP7PXdb+8+/vnL h9oxkUn6gfe9x/rh+j1UjQQb1Peum40L3+7+aKxX1BwxIDRgAv3q6kki6vdRDqFxlhYDFce+SaAr hwNPE4BxCpTFh6LUAUEAPqqCjhj0OUPq5EJN1I4maJKbORipoyPRSB2N7M/REc4TNv8PjiWbQ/Rn HP3p7niH84LNfze//okD2t2p0VwEczTmN7vI93O1rU++h5rcbRt66y5J6ucDbnXzZaYXfJtGMvCF CSZSdRM+Gt8RflHbvb1qzxbmHmqfR4s8vgBFT9jfVmitB+NLXMTBXqQGfYQEuu1f+auo/53hjD4J QD9ST3/9yGZDp8H80tyErXHbP87N1earoSs0nh3WvdNSidroFxG6NuKgFrOxLfcJMqdK6CPmwn/i oqFKXuRalYJa5FZWlouNZZE+YwCmPBd6OizfllP7YAXJY8asGO0c2TvdaPZzBvZgH7T32BdXeKEM 5vb51gRaMmLcg5lvkWrfrAdgboBTUEWz64nU31Owt7ZGp68zGPUYOlWfYfVomOb0mYMHrR7W4a3e isqKgb4tAc13mmYZt7yRyD0bOp060Myd23A61tI4fPCozFEAVpYRC+YdOsegc1YDfjYSt5N9sUUx pTZwzQhrO+F2JzDtoRghvMTa8BCKSX181/z/AY5rgeUKZW5kc3RyZWFtCmVuZG9iago4MCAwIG9i ago0MDc5CmVuZG9iago3OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDU4IDAgUiAvUmVz b3VyY2VzIDgxIDAgUiAvQ29udGVudHMgNzkgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEu OThdID4+CmVuZG9iago4MSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JT cGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GNS4xIDE1IDAgUgovRjEuMSA5IDAgUiAv RjExLjAgMzYgMCBSIC9GNy4wIDE3IDAgUiAvRjguMSAxOSAwIFIgL0Y5LjAgMjAgMCBSID4+ID4+ CmVuZG9iago4MyAwIG9iago8PCAvTGVuZ3RoIDg0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAHNXGtz28YV/Y5fsSLBmoIkGPvAyxabiI4d2xLt2lLidsw405HtJh07ndSZ6d/v ubuLpyhwFxLlyOMBAYLA3bv3ce5j93f2iv3OSsbLMi5VLphKk5gXmWKZzOMkFTn77wf2hv3G7j/6 wtnlF5bof18u8TO6k2dJYi41ZzKLs0TyghWJios0K4LLz2x5wVJzoz1cfGb3n/CYM84uPrL53mQa zsLpPrv4N3t8AbK2ERb4E5bJWOZSyJowpgkLBgn7iztJ4FXgyassi2VRJHmPpC6vgh6v7s3W8/W+ B6/akxi4TWKRxSpJ89SLsMiLV225ChzkiqdZnGTlMEns4nPQlquDw3B2FE7i+1GynnMeCakmYZQm wp3UEZImsiSWWVL2uDcsaX7c85U0yaHQiRQ9koYlLVN5eFiEs6h88OChO8dGKILMy7gQsECV0TC6 OUyeH8d85a22Y0IlsVJqE0V9cTtWi3AS/TUSin/jxS8iLvAwskUel4mSbIC2vtnYLbd4lsdFLssh ivrcOvj2ZDkLF9Gj9fx+9N3jiMTsiTvbxiimKuI0zdIhKu+Wb1ImsUhLL759L9bzozAyf0/dGab9 QODpzMuYi+QmgiZTEacFVFuIMs5FmTEOsABDDtxRxFLxbIR/ah4qyziV2Sbl7E/ks3ddVjXPuE3C MhFnSmRMuBO2W82s7Vie53HGs2ITr/qqOZ4kAohw524QMU/LWAEiXkOSgYiBgYjRej6Jwtqfx9qf T9Xr9Xy2WkRTGUbibL0W/1pEH473nnenegjijjEjiSROZqxL/1f17xXqzhVQNU/FJpb2NSI6uOfO p7aWIhRwgWwKTh0GTrIhovqi54e4217dRfRgjAqVF/k2kjqi9+5htDdZTpcQuWgv+2nv5cFZ9OjD 2cvoZKby5SrUovl2vb/eB1b6/vgieVWeXz7tymAwJIM93rqEWXAaccIBSyreuoRZHmo9Qi0aSyNE XKaVDH5NtUA8KwQFo3kCECdrS5MADKeIXfEXXFwyqDJFIPag4620jk3PDZRLGG7cVWyKyUxLUWA2 O3QGGwjjPE5s1MzctXfEdCJeLpTkpQNNNbPesjnfZ0eKzY9wEGye4pAyxKvmeGAOufnyaD+ge6ov 7b0z8+V9c2uMAx5nL05wlrF5gkPJ5vZsPad7gupd1VX7ykN8CQoyuqd+jr3YJcdSNd0PfmIXz93m eozmIi+S54Wo+Wo1d8Nc13yl8e8wNVJrbobAn8KwDSmbr+Y8Bmj6Sr5jmKKu63jiYXOvE6bg+mxb phAICgiTC02MB5RsS8PFNEpOZ7NwMo0EsknxdBnDie2rWXS2J6LTBdwYhRiT6UK7s8t3Dy6fRstJ zE9Xy8lRJAHFVpw+qfU+7sRV9TgiT6jIFa6i/cBVWK8bskuCMctTRHN55uL5ZiGc9051KOUx5gAp 04oso0TD3s8P7PgmfVIYmoRz3iNpOKsyXR6G0TT8dmqm/tmDV0+js5/ffnh/LyoI6Zyc8GW4eh5F L+VyER2GhyoCFp/Ql7GaLCAEs3CF+xYkCvi/WgE5qUk0VXclFtAJOC7hIhYE1ox0a+kPJ6sTtYTY 7xa7cUkUigKAw51UDzsywtk3HkAhkiiQKHRIjnuQBD33lt4Ku2UiRbiV10F+ocFaqg/WK4kKrQGA YO6OpAEHABfIk9szd6c+gn/I5GciQcq3S2xgqGT2YDL58o4AHOJ9lRGAc6CpzcAXBippWAUOIkYk DmqUxtkck06nBJ1EUF8NzVWCcPgJsnju3NYuwC8txRFgcFnI3sgqNm8WDU3rSL/kEu02KgSIjtLY JhDVByw3icB1nmVLpqWOwLNBmjqQxc8n9QNw6OaXywHAUgfgLhRZwHL+4O9nHhWb6zDFAFVQlYSn SF97UHULfGK/B03hVNfA6qJqgRBVJgKlWIeZ0/FgMH/1LHr53qYm4I4XJ2G8XO/DW0evpTv2GWGq ealingig0OuJ7ccPKJSs59NpeHgyJSQJeLBYHk0oxUK4oZ/oe72cSg1OTyjFsrdTgKm4iFEnzqrR uAAJD2EY4V0a05Igu5dUtmUYW957vgynZLVdbd4IwtI8FgqM6pA1jC89ONVTZBcjjMorqq9IpAyR 1LfCi+WJO5d6RLlY4ZzHuVQo8vgQNZ5PBI+2peBzhAaqpLhxYOrAp45nAJ8WT4H898TZQWISnU8e niMyrLB+HIcn0/W84BQocLR0QJ+nyzwEJLNCGGxr7LjCXg32BssJguJAgS6KaiwuCuuBXUfoRa2w aYFUKNW4XOC0Tzp+BFE1GPAhyk8MvTF+lY7vkjRsQc6fjYYDju0vNRzwIcuPU23c5GLYajwwRFLf sL0qoz1kaAgULMLFgsJw5H5IQZcLeUjpHxQt5ku+eKwLaKampisbgA/ox5pp7ADXq06n9JTnO/W7 SM+jGog4rxrin0mPEannNagfdrxeoP5GeuxBlJ90jtfjDklb9Li8Oz32IMuPU+P1eICkK3r8ijBv 5UO3Nkf2fKiLeSmLGB60zFnqQdZ4TrlAFOBcFO+QJdtCUgeieIPeHq+cCBOI77MUdmqYVx3CbsYr kDUYVXOBRGKRpG4k2bD6ZrDX4rKBoJoDBckU4YETnyxRt8CngaiaoytHZqVyJQnNycEczq9Qp5OV BrrHB8nbR4/G6aIj+hACiTv0SQ2xrR9NH2T3Du5REH0Ifz6Bi19OIoTKi+ViSm6eEACy85MQpR4k 6dvgFxN4y60JDfhFASLJcqdMfBFOX4fICYQcof+VDPwgiSNcKE9KBK7IcqeWRCd87jXrvi604ZpM UdP7kxVh0wGi+t7qZiq8LXKtE4hbSOpY3/NXf1+v0QLgmgoZ4RXQwcxL7a6GWdWh62as2uYVEHvC qXPJnFhlDXD58Pok4tWcnQkS8jDiCtGDLvT9AEODrOPRKSrL+gLKyjuOG+yKkxSFIsyB04oTKlNS vxYWByD9+GOkE4w/H7y/pyubIRXBdXWbKoTvHnz3Xcv4N7Z2OVkeLv+Bcim6D03d9K6KnCn4jT42 5RIiNSGfjQTd9WCEaQWSlGWRcVaR6GJadWy62CldVDNKuSi96Go7yu1LpXxNPqE2kATUZmdzU8mo 7+lfL93Z1DNjLoEA1aaTLOuzqRvJ9S2+SRB8E4YnlMpH+0ge7rZhSYBhWJ0CHNfh3HBc7mdsfSdT YIVNlmF5WZekLuP6k0ntEhFlZKYooHo5J7+CqQDMUSjOeBHXZG13EXEKrOdClQUQrDOFXX71Bc1P H9uxuUtgV0MwoO8YXaPXrfnpuHCvbE9PIXUMtSW0q7O2TkTdSRRVQzBHknQUdX55Ywi2De/UEMyR Lt0N52cV+iKlSRoIOGsI5kiSZlX5xCttC/2xSMuiMSqiXpfFvRskpooU6dLUqTVP55Wdjd8IRJJK 5JFULllFlQsi8bM0vs6isTRYN3fN4sK+r7hCEdYlpjJJYEHzLEZ1MYfVUleXbMel1H9oNSixwLss UB6MS2rtljmt0zFtQlj8rSR+jnwb50iScC4Y6uBFKTNBVuvjVh8wZmaqFi+FrjMJOFvNTLvFCz6A DG67QwmeqdXipeoz96ajEcTWLV4OxN55i5cDTW0GPjEs+x4HtHRhDWG7w6tq/KIuex7MvzXfUl8/ +r6oHx8HaqDHL/UtpucfF+2dVacYWnaoGcz2j71Esz/uQaWdDvaH3VvQpEI9+vYH9oW0DgBPqYii h/8U7LA9n0OLcsJxFUurEGuLTOqGuLo9zg6sYkXTUqdXPNgR9m76m2GN5eK1XKiFfCe1dKS0iwLJ R5/Rb+is22ybOlr36FzvIWHsEBbMJ+B8AibHWVoUQqbs/NGVLvCjpl0Kq+tlTnODteNM0LpG+pjT x4x9YufaXjW3U3dV/9dkbfCTGOuBsX45qE9gI/2ewEQC+2tJScoscH8/TyRW1xry8VmT4ko/jR6/ QRCpBwACqjO/EdB7AzsEfAY9GIPlwIh+jW0ZvMb5SYTkeb0oa/NGHNXyT5/miBvBbBei7hhmu5Fk YPY7NOaHWKxh1yvSgg7bWEex+WGIWH1VdeyYxYyo9H88RZLoRRth3H5ZQOS0oKwE0LDDqQyrbnys 4r6q5cgucWuTtCUB0zEubtuc1MsDFcWg9dro4TTCM6AP11B9DE051u8KmJPtNKFp1X8lIHTDF63W KwG7JFVTZvS2D1dJCo/dOdVWWcc6GdaqYXExTL4PWUbUaY14a1UL5W8pa0XLoD4cZ9AendJ9s1CL N9F0FoaPdUBGt61CfRcteZmo6W4T21mK+mmWcqaw4DxHM7CLxqD6F85OEAmalDyPVnrd8gLNPJMj 2+hzbLiw01hQcKzaoL2kfIj3CMZHqJbAhhNYEAULZPlZhRtDFqgrKet5h59ajvQioifnKBHoIsJO uVqLhCzRWFg4lTq02JIQoBF8tTxaYnnTbs0ql+hSLlPFLJGGzcPmwoOitqlw3ImgNvQSja8FYlzd jtmlqJ9rLD3sfI8kl6ZgtE4bOz9MEkJfmHkLgjwWfF+hSOcaB5tIajO/lSK9cZvOnpGVf6kiieWV qKi1TCoUZdCiUhsxWhNJNvXfTrVGotCCPTFyoH09/S52tGfoG7Pa8Wm3va1Do98IxESZOvVO6ATg RkP/Ur3ozknbGWjjpU3WRgux0zW8aRFzhUBNegzTw0SMcA6NiVDov6j3FBrGgq88bMQYmmobsZWm O8eCskNS15RuwoIXM3VY24kqOw2cgh3T0IY8x6rxZpUxyeN6rY51BZ5OdGdyOIPf2qlUIguZIlPM qrG52Im7kko0heVIxrpAlsu7ksqtNN29VHZIGpbK9Tr6CbDoOqHcNUhCiQQRZ8pkh+Rhe+MhbAAA vnFeYwLRHpfJStiGufjOQ9h6oMSlH6GBSQM0Geg2Vtj6Nb1t+asGJw2T1CkTQ9iO0Uga1tLWWLvK CGpXDHnU+5hp54zKRivTcNtYgxIyqA0BpttxuJi7QveW0g4P+2TQ9d97hb2wfliEYXRmGkyjhz/u 1lLXMEmg3ahEz5cL6drJkDfBtlno7prp6TjB/nHrOdJi5F1qSGrB30phe0oK8xv0ZwDUCcfDEEyj tQ0b0C2iUyx0o1Vvu97kohl3QQ37yin+U2bO4GTNdJmBm/nDNT17pmfnMQbbE9PXS2ybi9VAVkif 79YBI5edZ7JgwmN4V2zicO3hLVJmHNsTJOy92db6tuoQgjYkQGNShjw8Wrix4SV2ufSoI+A3phIQ pyhFUCZf1wWQ3DfVhHp72KqgS2XcTQXdFHqNTc+QNsKeNBzP6l7A47CzcyyxGba5A6cwnQq4R6HZ BDE7Ws+bK1jhS1mcy/pagDvNtat3Xb3S/I4pODrJE6UJMG8MFFo2IcfomqpJEihDlygKNFRXVy5B IAgvVIFn2bs+4RqGmxcZnmWvKeyBmOaU56me3rpiaaBn1XfZa9UVPKl3paG9/buKD0RD9ayKgw1V NAktwvVpeySbvm/GaW//hX0MBPsfe2sEt78h1MbKFseSWEHthShM1Z8/4TPSYGlZBPo7yZENEdT1 p9BJYM8gw5etz83V5lP1Pdq42KfAXBdoZsCD6zeQGgBM63fTp0vadxcyTp8/0Q6pXL9Un0N7aItY 84TAnuHZ+I35Bp83faq+J72jZ9JTqtFUbzAjNe8mflR00OfmavPpkv2i64dUPeyVJ9FEUZUn0TrR mnYRg32f21esktyBcFSaEmiFv6l+YwyG9OCqNl+90tZvpZnQGbC5EpjuEZLqBFYR2oQmU1oVDeGD ppIEIvLCeiHeQ4jaVvNqN9kEyyJK/OlUFvbHqE6b5yoF85BUXhH711Nm1x50ZanBiC9+/fSFvfnw 6/svf/zzc4OzSLPqB+u8cHO6/T0KLWjYcJK2k9SvQ5bDVmhay/du9xXNiBjPYmwOidU8+YMEO/G0 oCPmFEYygQ4R66nkylGEIwDBkKZHS1AxIjuBviUU9FDOQ6aK2oVMThVNRcQ2czCJAOxUariA3Zmw dOqIJ2z+HxyxhSM4f4QFCvXxA84LNv/NfPsHDti78QEOMpgj+1n3Pujq/tZB9aXJ5PkHk6AKHXsw UsPDsi1JNLmUBcWwfjYEUytSbppcMAraFAm7VeomEPS1nOIUV+0GmfZA7S34BUAMDZF2q8KAqREG F9HpTf0w6Iuni/qWay7S9pi45TUO8Pt4caBfTBtj4jkrc7APKHAGMtovBo1rc5W2ycS02Fc+xhmo wg/vgPFWmmAJ4Imq1tuONLXYTrVusP0MBGKA1EiDIXUZpTuG8CXtB4ovu0yAOhLD7HCpNwm3WAZV P6RWJ0yfnRM7tZbT9lXPvTkzQs+wUS0qadDc6znTT7hhJLX2/x+ylw5YCmVuZHN0cmVhbQplbmRv YmoKODQgMCBvYmoKNDc2NAplbmRvYmoKODIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1 OCAwIFIgL1Jlc291cmNlcyA4NSAwIFIgL0NvbnRlbnRzIDgzIDAgUiAvTWVkaWFCb3gKWzAgMCA1 OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKODUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEyLjEgNDYgMCBSCi9G NS4xIDE1IDAgUiAvRjEuMSA5IDAgUiAvRjExLjAgMzYgMCBSIC9GNy4wIDE3IDAgUiAvRjguMSAx OSAwIFIgL0YxMy4wIDQ3IDAgUgovRjkuMCAyMCAwIFIgPj4gPj4KZW5kb2JqCjg3IDAgb2JqCjw8 IC9MZW5ndGggODggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdVd23LbRhJ9 51fAILimYGmEueCWGCsTiS8SxbjsaNcPZrIPspLaVGWrvP7/qj09uCPUcAYyrNrkwbFEKQc9fT3T 3fjsvfM+e7nH85zlKhWeiiPGs0R5iUxZFIvU+++d98H7j3f+wxfu3X7xIv3vl1v8GH2SJ1FUfan7 m0xYEkmeeVmkWBYn2eL2T6+88eLqg/UfN39656844x73bn7z1k/8ZbAKlifezR/eyxvAOgZs4Q4s kUymUsgWmKeBLYzA/mYPCbJaOMoqSZjMsigdQRrKajGS1dPVfr0/cZBV/xAXdoeYJUxFcRo7AQud ZNXXq4WFXvE4YVGSmyF5N38u+nr17DRYnQU+Ow+j/ZrzUEjlB2EcCXuoEzRNJBGTSZSPpGfWNDfp uWqa5DDoSIoRJLOmJSoNTrNgFebfffe9vcQmGIJMc5YJeKDGaVS2aYbnJjFXfWv9mFARU0odQjRW t+eqCPzw76FQ/MJJXgRu4eBks5TlkZKeAdvYbcwrLZ6kLEtlbkI0ltazF5tyFRThD/v1efjjy5DU 7JW92KYYpspYHCexCeW3lZuUERNx7iS312K/PgvC6p839gLTcWDhGMxzxkX0EEWTsWBxBtMWImep yBOPI1mAI0fekTGpeDIhPnW/VOYslskh4xwf5OXPQ1F1v+NrAksES5RIPGEPbF7LbP1YmqYs4Ul2 SFZj05wOiRJEhHNjiogsUwhKEdM4Zwop4j2QqhRxUaWIP18Nj29K2rq4P22NU8a5gCEex4RI6vEF pa3ewyF5nxdd7qzToDavRsKaKcltIDWZ9GK934eR8pf7NVuGMtivdwjfP9xdvw2zINzA2wb+Mnwv Sybbr57ZP8QUl4vAEGUyHsnVnAtxlVG6dh6u1BaPkvHgZbg/UasweLFfn254EO7X4R/P7+60ni6s Koa+l7EsZZKYSUQL7qWIG6kSyqaUef1kVnmmnKk0lx2mynbM8py3ikkVU7niOOJaTIfMeeyNn16V wXJ/Yi+r/vlZVjF5zLhMEHFcgLnJyjWrzDPGYxTORkhjb1yUm2ly0nquiyujP+ZRzhJkIU6gpsvJ JkTAFyOORggRBp2CnAYh4my13b6Bp1j7O3J3KXxIuascRxGkAepmHp6W/naJpBPuhHP1vvTPwqUM QtAP+M5+vSyVH6r9if4i0zXjUoUnC1teoq+lzl5GZiwSVnzJhuAu6UnD8vQ02JVAHoQab09TEO6m REkDucOR3nDwQ6k9VAc9mRBeOHw0TzOoboXIxvUgtrCLEMdKB19sAlbuT0oW7oK0ZEEdHDccHwp2 +iNBSyJoAV/Nqw4yT5nMBTTfXsYO6doEGXfpGkeVfjhbG7v3H6dnazZkUJet3Q+p8qI6WdMc48OS tWM5bZesGREN/NVHKOCqydKoDt7/m/xW6TO+3UH59usihKXPe7qCI83kmfTS+4GPT9dXq1NyptdP BADL/Tot1Qp2MSd9i8qRZaD/HGA6ABr5bSsdbKuYiLMUoeowzz3gI7+fbha6rDpWWLVFjBESlBBm UddVDzMLxPIvt4ayqjOLY4h0CaOrKpQw19vNRq2WsIFxDdMax/tyKbV7/v0sUFzBNVPs/j1UGx3D UTachcjF54zcErmJFCr10urhbMqDecOhjDmTkqzkfnGPjflbZOISZUueCSQO9rgcJDXBeiWqljwH LWVA9K3zcEnXLik3Smmc806Xkr7KO2a+TQWc5BHEdZhoayHVrEhrjPbxYHSANhUCwkGcRBCWFbTa 2c0rLVyjxqkCh2QFqZYWU34anCOTZwFql63Pg6LQfq3OR3cK1YqvlvgWuJwCfg3VDWWu+EEWbJa6 WqFA3Ip95gQVVRlIu+4hbbyeQyR+SIKapIJlstFSMyfyyiEUT8HUhOLjmKamqK53gG0sHkIyX7I9 QS0Msq1Wxp4OVko6UDxSyUaX5469AhElBs/ePIuNFjpY/4QTF4goMVEWDSQbZk4HX3s/OQVWLphC puIEy4WYm4QJVXsmUydMDqeHcOJqHIKYuTyLR5DMxvEQYs6mxJBEzKU9LbepMdzk1CcwbcKuJGIu Q2fIUMuHcmozgjrstqHJXtP/khFoeRlpTKlQyeacH4M2qMhmlpZKcFFPwXIQmczS6nnRNw6Bsy8x S4K8veBIiNfjuTikX+N6IXixDPyCeFKdiqD6L8JyWXT5B74O6rUEg6YvbsBT6guoctZaTMQxi8EE es2j2ASEimjpIQ9QVIJwyc4Hirr4yiwqVWlxFCF41WK3weqgqBM8sowRvHgMsx5ogjmFIoJ9GwxE ZSScp+BKY0Qv9C254Bqf31cHhTotTzM3UA7nNyF8dZZMukUtnAfYqLElr4L9CdouUUaEuFvN1FLO zOHhNo6lnFKkAUqzlrm5QNe435LbiZRMKORJFoK7/M6heOj7ZVwJ2cR9skGFZkf04d4PqmInphYP rnG/Kx7MkAYEt0Xx8Klh7qhtoS0e2hgza8yQEXqVOXoTGjHb+GEHdZzi71BcA1KLyEYb7wvDszrm zuEIAZu2yhy2uGDtMgPyOVv/wlfv/eoyDgxuXWe+DMtZwQuBlk6JtrbEHvzEhmtLi0c/FFIC3PoZ EFUG37T6eGsHTRz5IJtEXwgkVBHa5c2IBvZe5Xl1VgXW4K80vmbt8Z1Zj7fTTQ7aOU/r9kBzmPnQ v0b40L9GeDkrWMxQsETiBjtxAOsgvwnJBN3yAxKo1QGkYdUyTia0F9IKkHx829xhEnX0R+96prnO qZs0iNasL3TwyVl9PcIpE5Lqg/qZHt/Xd2qKSxGVNKmHWU3Fk6c3s+pjpnCDlKSwewdU8ya36HZH yRSDLhpAMuvjp4/hKah03Sqdqd353KltTK3l6BUcYjQf5rxm3Ka2cSbRxY0iyia1vbyyV69RWHFK bU2gHim1PQJpEOr+X1Lb5pke393JOrVtENloow4qRdUMUISfFPqY7bVzQvrduuQYfF2MEZsKpNmK X9tDmhCME/gVsDPeEJHZ9z2/iX7N89wJV1sQWnKHHOOdIoFTdgGGG066uuylBPYYJxwnx4AlGkjH wjMfpx9+2BbBbl5gaE1OQWmNhGcGNm+QxeUHSzOw5y7nSU359oLqhwtLLRM0LBSp2AmVm6Baxbct 1dAwB65cGiGNazUaZECv8YcmAQ43+zX6kU8DNB63kxiY1qC2v7oztSfXr9/I2zm6hGNwL7EJD0yt MECyUf4OT9JDd2SGfIrdoiyPUqhiBc4mUjjEhb4aWp45FwqAwNgbEI2P/O75ExQ3Y3/nNxowqwBp +gyzdpkJ77iAmzfvw0gsAiqGmRwkOP1MbQiOLj3GvWGKMcQD2THOdJD1XebTpUSY8K+5XbIhfuNj mDTv+y2H0I4iaoipxTpEB2fbIvxUUIcSXTSE1//6ePfp6aDFuTaQJ8kvT94+uwpDSqtThT58Mo/Z BrskoooUGcyjErON93NQxgkej67VgQiZyv0HPzbYsgjr1LgeVGjkPKtr6SIHLgKiqLEbc+oyIAZ1 Bnj14+Ul+oV2AXsZFkH/EvHrBztKbai1I64RP/5xiwjtlJlCPHEQ4nXAdGvz5e3MXIZQaPsUUScw myrIwT4mVEGds0YvSUZD4we89dhALt9N99ZuXIYB1GNxGWZIg6hGTpeMsm7yI0bW3oXU2ZTL9gou 0BwZcZSOBpDjw8RETK/HxAmf650w2kjQ45TAOh3wzVt0YGQUMybodjZBGmegozYWYxvEKCm2mTbh OceNOW6pXTBNF5NNTsdzIiWwWeAIpIH6V20sFTNxh9RFB6s6strr2ZSgHwmWixx1zkDPzKF0Xj8r wepg+NDNNE+3fFlSQbscUO5lULx0QDtBgF0uAtjwKjXDbRZgAf8WhNfIS9+XWAnFy4sAmwYwd4du pkLVJVt97ovjm8j+Yjh1lm+aoiX2J8Xar7iG/fgJCcfUKSCBkHKQZJO1z2okem1MFrshc1C7hyQj KotZjtZOq2Tk9hslIyZQj5SMHIE08MZUPMILR0212N0Phx9KvwhoKnBehUNuLmWceUPUZqfiFtZc ExJsYMINKOinISTzJUB2/jnwdxtV+suDtOOsQkQti/EshZWSAxMxC3Feq6VVWzEWW44gmYWou5wR JXo3Fr4DzIfENIXWVxGjJUhXOmbJ1VOyBRiUtxK8AFZZgJk/LcIduquKJRo916dhwLHJwF8Ws/ZZ EPOYKUygNvAfP7YR9QhILSIbb12tSKoLoj47cYTsnhBNaPIkQ+u6Ez69L7WaA0TuWO8toQa6JR0/ Uc+zmnebeKFtBUSzjUT/UffWs9LBfevkym1lHY9iLKDFULY9NDfn7XpfhH5ntHSSRdwrq3Hhdvf8 E7oj7U9wlIPacBdoe0WfOGoPe1QOKjUCZFW6YeVwnGWIcSYxDVKFVvMnS8qqzMUNfJqjEdIe2HSF 0sXDkUsCjtFHLA0+cnSVpPR+5cX6QUyARUEDdgLrFJuzs3H5DiKaEEQ5dbElmFK7/8zG/FJvGALu 85/fgGIVUe7ipaabn40/aAlWhZE19EkeHCAZ+6nLX69mNb12DuI4qG8+B3EE0sBR0ZS0XkCNSzDR KVoRvkanzrvvby/ftMt/qPWEOgCK8gzd8jyU6j1xs7PmbBIdDSpGk0XzTDYG7KCOEwxYcsx9oeup QWSTYYjr/V6EhVRbjr0x1DqGRZHEa9vr6ASkXSqEiJphm6lNvl4vEgtvejstqSc6xNCkf7bVTavY 1tmMZ816+kJQkzy2lav6AR7/9GkaApCgkA4yDV7QflMyH1wqQ4wgEhgtyJj19PU4NPjmIVBzTekQ +kZ5lI0jJ8tJpOiO85DpjB35p07tmoVLWPClWdFZxdcZD6ZNOIRpYzzbYlZMWOMAJpkKCAdM0Dqa g4YFS/AtcOCzQuRgVzAe6AaR1kMiumiPWLlKhBnqS5sVqsCLB/COC6ijgzQ1Ru0jKRRCqPV/79cX iKDvJcLjBpTGhd5BMqtzlJh7FDF6Bxr4j+8cJYwGkJD+O0h0Ffy2DQpaqDbraXf2jNosRoeDjT13 MQ/01b2pkvZH1RUN7mrqNGnWsxdJDkFj1TKtl6OHefyzp6034ARRaDnIt0TDJgwIC2JhSX5Q5Zel n6oL/ZVVgAM4b/RinhuvTi/AZGd2kgTVrxey6sXfTJ2ebn39GLR5gsYIa0WeBzDPsNovwz2osgfc iHCe1xdxbGADItAQFaJDYX1c024CRcvS9dDlrsQsVFbycol72aYxVfvVq1ldgkR6meVUitvjdpDk lAypeUOVxN0EIv0hSY4TpOmIbLivtviW4L5U2q3YzTT3grso6hytelHRIVpt1fnorXFyZ9Jb+/hD eOu0/dsv3s3VfO/RgvjQv5Z7Q7CLGuUALDoE6zd8OawZnVCE4dUWKqFXJVhgggArTBDgq0pkmOA5 494a71IhcdLyK/orJlK1XCP662L9ovouWqPoQ+zEs5fyBCXlHKMrOeYJh0/kjaVMy4z6T3RKYL21 xuyta7A19ObB8PYr0pen1ZO8rf7YnCzoueofHH4EvvZMtT9Q/1LsyKHf0kip+eXP6MvoAa5+a/17 mm+i9KH/Sf3V+jPPqy+C7z4k/acVrvpHMItNH6qhN78dB2V/GBPUS6T0yhrUo8PDOKjy7WFoPbLd Gz8BVPtiF9wMY0sYOiQsLgrDa8hsRlDYiCsSGUvPBZRbQex6eY5VMyLNZDaCZK7R393qTFSs1Itz 9Cev8PYA7OJeKQaGgd4ZMNoJX/zUBQgkJF99776grvAIb7JoxPr4qWgXsyRGJbmd+rkMF08wiXYt PDZGHcE0lS921b52b84Qkln7moZcKBzUD4RCsAK3hR1r9KIHHtLLCfwiRB6sl69ztO/SKytQE62Q 4uN9h0s03hHxSf9Uv0P3NHKlLqrXYWhWdM7V2N1jE7uIzc82Cqvv83jPtqrHRf8CmVx1u109lP7k 4F0daHVp+pchnJ3m02etDiXuKxOBRVuU4No+IVbN9Y9AqtO52enmHVISay9El1hWs0jVq0/HVUNf 6ld6IodeNXKCMpIW/VWa1WnVT7148vVHN4g+wpAxnHeF30aNOlfsvfsfSlm+egplbmRzdHJlYW0K ZW5kb2JqCjg4IDAgb2JqCjQ1NTkKZW5kb2JqCjg2IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl bnQgNTggMCBSIC9SZXNvdXJjZXMgODkgMCBSIC9Db250ZW50cyA4NyAwIFIgL01lZGlhQm94Clsw IDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5kb2JqCjg5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxMi4xIDQ2IDAg UgovRjcuMCAxNyAwIFIgL0YxLjEgOSAwIFIgL0YxMy4wIDQ3IDAgUiA+PiA+PgplbmRvYmoKOTIg MCBvYmoKPDwgL0xlbmd0aCA5MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB zV19c9vG0f8fnwIiwYaCJQj3AuDgR2wqOG4TS4zHthK3Yz7pdBRnmo7dTurO9Ov3t3eHV1LgHRIw cacBeASOe3v7vnurn8JX4U9hGbKyTEpZ8FBmacJULsNcFEma8SL89/vwbfjP8OrZJxY+fApT/b9P D3iNnmR5mpqh9pPIkzwVTIUqlYnKchU8fAyr+zAzD9rL/cfw6o8sYSEL738I12eLZbSKlufh/T/C 5/cA6xhggT9guUhEIbhoAAs1YMEoYL9zBwm4CjxxleeJUCotBiD1cRUMcPXZarfenXvgqruJgdsm qjyRaVZkXoDFXrjq0lXgQFcsy5M0L8dBCu8/Bl26enIRrS6jRXIVp7s1YzEXchHFWcrdQZ1AaTxP E5Gn5QB745Tmhz1fShMMDJ0KPgBpnNJyWUQXKlrF5dOn/+eOsQmMIIoyURwSqBYahjfHwfPDmC+9 NXKMyzSRUh6CaEhu13ITLeLfx1yyz73wRcAFHkJWFUmZShGOwDYUG/Nii+VFogpRjkE0xNaTP9xU q2gTP9utr+IvnsdEZn90R9sUxpQqybI8G4PytHgTIk14Vnrh7U98t76MYvPvS3eEaT0QeCrzMmE8 /TmEJjKeZAqszXmZFLzMQwZjAYIcdodKhGT5BP3UTirKJBP5IeYcbuRXX/RR1c7xSwKW8ySXPA+5 O2DzcmYjx4qiSHKWq0O4GrLmdJDIQIQ6dzMRi6xMJEzER0AyJmJQm4ibaLWMd+v4H5FkMtmtl5Vc xCLarbdQUbv1Bv9X0Fgv4vj7+uv+jo9ZulOkCdEvFGvYX8a4mp/XoOScgaXyfADSuB5VV+5o6vIq HAIXw41DxKmSs1GYhgToh6aubnchQC4E9Odw4/pYAkQ9+ltFu3P4KIskip+9v3sZqyi+3URbXEGK uItvVvIPFdTZxe1m6cE/EwivZWnos0Jya5uME95CLuNqoXlIyS0AfeG+6xNgZKmA98fKsPCA0QNt E4xMOIBKCgIJFJmpGm39bbdaQyapdU3/5Y6mCcyRlwkvOZHiCEyGOWDAW5DCySC5MAfUhMyPoWnI HWeLhN1uo3gpor58fmtoLtq6wzyB2niaJwXLhmgc5wg/GePrcfEU5o5IIYpHdnZoo6irn8ChRbR6 C2W22MZvScTMi7lSJMCeGID5q2KuzBMoMigMD8ztzuXKHVFdTnUMiYi0SDIpMy+o/Eisq8ZcNKuA JZ1lpRwFaahZV/J2WS0u38Y3uzUiSRfRMnLH2wTWFIonKd/D2ziBrWbWTqJk2EwxxNw4UKfSTixL BD9oE/9qyulxkH4t3TQKUc9wQ3jhRuul1mlYSvIj+N1ux+P312cw5MAR8BruXs5rFHEpkiLH3kJX HdnjJjTuR3W+IqS1iVIKRGT8EVeMoqq/hE2kncMj7mFrEx2F6fQ20ThIPcLb7bZborNrSNyocVRf V0uhybEhv5lpjitEJBArLHqg/yZEXa4yRKXT35SsG4PpVxJ2R0DqEd11dMN2azipZIlfRz/cRhvf VJFfiJBlGSK/ML3HoBzaufPaRSxTiDjA9B4DaWgXkR745rWoEhG/pmAS4W9bIWsUb5YrqIdv44Zz yUSvgOL31zn4+waO/80KT4LJzwPXBGbXAnXMrDaOWV7IhCNN65JZJbtYryVqUmHdVdWyJziecp0A MYOZxTKhQh+IPRTeBHO0UXg5Yo+c1aHjg+JwksKbAlMdBDgO01SF5+u9trTWQ9PBWEljqhhFR4yD kBiyrcasWsjVBbHR3RmPrfMRX0SJgINbbS42L/R+B05Z/wkkyOF+lAoh5hq3LkwzLwmiyIJzqpDI YQ4iD2JtroMk2OC2rDl1nuKIrEgY48hDHYfpVCTYcmoPTeMkeLY7d/dmB+Tk4nLDNs0EbVkfT32g hqpFy18KD1/FqyiRl4vqL4gTE590NUm10ENWZ5Nf8twEgWZVKhRDQL5KNAty4Y+tBPwUUN6dV4hS wcZ1R/oE+SiAdVQI+DGMEUazwtVSKPIJXEprx44zsk1YPY+rpUkkwERbXREOyf/UFBGtkMMCJSOV wJbVDYvixnXdxK+RhKBcQ1Fto+3zDmkhVLiZ1wBp18s5wq3chVSIyhvodcp6Ccm/jPEfwwImxDmn 3cSUgphFEjt3B9vDQJ1A0GQXlTmcbQvRIad7aDLPHuBEmh9WpYLVbNDkApQHmiYIW4rqixRRuhGI hrK2CW/C5lh9jsTwJlpabgKLtZSobfwbj5DxhG0WKAZI4XuPwT/cZsPXtSfiLr6AXl8br2VnBnIs C6cqio2Qt4yynlrywM7bRN/uSSHD4i2yEW8zUk6H2OL4JYSC0YfYpSuSBQXmk6eSXilDhks6Faai tKDN+/YISJEyb1LCAP4y0tUJBWzdWypCIAHee6MyOvMGNU/RYmmVO8lH+jerkm92OivTpMhSJ8/R bBB2eGE3j1TU2V1sfORGfre7LLFgWs773U4rt1mXxLGSXMF981kS5e23Mt5Iuz0L2ZEI2B7LbvM4 w+0mqDRJRe6iPfdpxexKY4AZ1kHAJ4k20Kc6rt1uUqJ51RoL7VINv866Pe1iyWJG4anbaslE1tUV m9ubG6atoi2YDAUWbNnCH39zF0XxXZToCqA3L7766ltsKAmVlhi/seb0prpcgCMRwHl+Kh5D9KlQ ykm8SLXcrasFykh25yt5oa3As7vnMWI2zbq/NRip602wrll3jmciwVkAGWYe64BoMAIeFKjN2IOx slnhbikOBSc8c2IveGNRVQD7Dbg6cGGJCXKa7G9khig2WBf9mPDqFrU0tFv92D5K0WCUExuSHDzR cnFUI0MVpQuD2dW5WxUTjB7FkrRAYC3MLGDGjhx3imrJ6xDcmGDoNAEX1CPhwAUqTg8cSRkaYq88 Ai4TbNsm4DIG02nzDS0HjaAJIPXyDSR1J9T4dDHmWIDBGA6lyEKFYxgb7uK8DgoDomSOat8xkIYe Cmp8usUXKyNJFle9uqmvm3xhI6NQ7EpSRfOwkUb5u5enEjIpkoh54aTFoaguUGCI0BBEoVZkDDUm WmAuUXCy2FRwyGaVjaxEEXbOOKJy7mB7iKAJUrERQRJ2awYB6SIVHzxE0BSY6pjvcZhOHvPtg9QP rw55/KW7PuuKHcfyZapGQGFEEY6BNORx8Kkx1O/++u7995/FxKmGKcimBa+3xVerDQmAQzXtG4oW G/vEGrO1dTIr9zRqQOJQVlFyJ0P2DMHM3e5HLM7UPBxaD8yqu1ukV8mjpOcqMt8pM9Ra7R101fau TmCeaMHY67RQTt6xjTP9W8vkdgHW10KA5KrxhduQCVVzziz7uMIx1xIJCumxmFPJPkjBkimncvXv TiX7jsJ0etnXA2lc9j1BNZE+/RJ7HGnVUtCzyoNiZlT9SkfE2z0cB25m4wvny2VWilGQhoJ5t9vQ EQifouquznA1VQXVXOGo+W8IW5IleWbP+D+2gUNsnW0RqJxVuzKEyBHmL0cxNQSrWl7Ff7q+T1+9 Kr/7kkxM0igaVvqmPhFGTzw8fPHwpQ6nKLkUzxsn/kT6BCeHBVoguLjmlTlAoYMHyOwtljCgjQpB sBhR6FoczhObhFBOeFGAYD1APpXWwNF1FHJZpz1A7DTNUDSIf+H9Q4izbtQ8wF60c5o1RRO/vzbH sPWTThUmE8zoPMOxVoUqfNkH9ABkyLNMOMMzASbkF1NFJSbHYWqw9S5cQ2Bf5uH6CS5ZuC5w4c0F qTL6hD4A9N2T84AuF+bTnblAVPx/eP/CrYPHFLFKxCkYlFAP0/XmG4Qb76BZ1dojxdcFydE7aI7i SWRPM364lHUov+Inn00Wqi4F1BLNFHCwHNzsAdR0Ze1yqAyHwHE2V8GLGgepF1t68+bPd75mzbBZ TTB6EhllbikKFKF+PMD6eZgCtj49BI/3z9HJIRyYcQMpZAH1z3n1XfxZRDWpG+QNdG2qDlfX2aH4 kkkFTwsZFfJbcE4aNSUU1DZB7FQuMJYs26CTyfHNqiUbzhGI1iikyV205CpCwhgnCmPKslaUNYH2 f/U0vqgWqLHfkFuNw7cUJltWFyZFLVfVZaXdTPKeZ10S9X3hhchCnyWxONHorxaUaSDQaWMSeYG6 HyxpXr0vQG0iR/WXD8R7eh9iORNpinhbkaOQICxwgE8We2orKYX+h9ZRJQzjUkFxozYTR3JFQQ0D uESpJp0GEAU1UVAqZBkVJsCZpYNuOBPFaM4fjjaHGshxbSAcOXPSUiNqq3NUB7hQY+wjnfbQocEa lU6UyMpFht2xQLkEDf2kk2/NCDaEFwoV3X2Qxv3AV29s+yXIoORznaYmOt8XO0T5iHlVEeXkSEXO VxZMtAZ1VC/DZbspSQiB2RE3VPFAvkdbW68jdLMKGVFKKtbhXqAfbkrgwLfP3uhGb4ZHIStSVubg UNReZEpxiLo3z/Z6wV22zeDQAksUhFvUFqchwqgqpHuwNu7z8EP4RjNz+wLZ8sP3ierpnSQLdCC2 /oQ5UuY5B73DNQxlGnAJYeUOA2ccnYPMGnBfdNawp88PrQHv5ImeoQAEzSfnNRAe7e/qNeCeOhk1 azjWM68rFh0DGa1YzCUKxOvTEuPsjrKoNcK8xOLWGFlFl6jG2zKqUSGeMTksFE+hEvSWWkBBi9tS aCoKpfrQ17p0xZ4dgN2CV6jJBk1q3kaSHSHieVmtbmUIGayDqi5SggwsUwOwkTBBEHZAfI78+WW3 zQoIZqwbTXerHE8HMVTJQ19CWXgAW1sXDnn3CfqLSRzvY6jfrEFy0V971sVod0pf/dUStMgS9Gg6 eN51mGDy0vODrXM5VNDq+RGghk6kn57vngsmwwNgjZoerZ4fB6nnr736ovFC+u7HTbTaVJsluCDe 7d5daws3MpFr44G0Xh7iW784a/CC+iTgPKCwi3HhYw/8TmANuAkJGtHBVejhd7xKZkLwegJo1OgC TXvAtR6geWALDOLNtbD/i1xAtvVAGldDTUS4dWuhZu5RZve1h4yZgsBGbXCJmJDbsRAkDpcoaITm QObwYDx7c1tZz117vWiXe7vSPiPK0IxK1ApHO766Qyz0DqnLvgPM6izsiTQnQ9Ml5lZw3KxDuwmN BbCMF0iDbzawICoKYOxZF9pgmHU5XOYJSxVsbo/ltIgH1LZq0D3sN4XuGNxmQU6NhfI3pG55SV2l 0FnaVN6hHQFZ+uZi1C2OSjzW3uqwn1Ir2nd4jSHwnIbfmxaqv5TPwoVC48usYGStU3Na7X14+AsQ 8vodOC7G3refrM/R9Hs9FhjJoCxwYJRpl4+lqPX8iFDLYAyTomEz4uP4UfJq6TmMIMCJojmMcFiw kkI0zQiCVVSlvDfkMNB9CZ40FXiHH4J2bgrUl0BcCxFlRBWaf7Zw1yMPSDoBbgU5KexY8AFjWF+B 00j1GEbQswenzkJRz94ZsTDQXM1TZizYG9l/Juy+B2OBHFQCoZ7KIg9T1UDVCG5Br0e6y6nH9p7C TPWS62cewr8jtMXD/4bvNC0fdauJlXB6s4BTLEuQKN2DwHD/AffoTZnhxKT+LOA9E+kpNPUmGaY/ FSlW3d7THWbCaDtWf18gk01z0nuFgE7DxO0vFDjgZH6b7iiMl4qA0/0H6oKKugH8qP4MhqI7O4P9 hLnxjvkG9wfuQKJmlKCjOWmWejXtL9DK6bfNmg0c5r4Zhcfffv93HXyg0MPj0Q3YyC0VINGXcjDV x2YsEI8TCx7yIRZMZXl2nzT2R4j/Huf/dq6WIx/jfyC/85Ah/eFAh7Htersv1WjpMkw7ZqK1tAKN O4G2uGjCLimgA24GRYEaBI7Dl0OFR0Kd1U5Kim6dCASXWmsgA1x/bOdF/2nQhdUvATrXk36xF50V bst4vv7xw6fw7fsfv//0n799bDUypWSaientzse937EeRPs7VCyHZVA2Wv+capLQZ3P9RLuiEKXR yPgiolA8TfP298iX0mSYIthGqC9QzxcyQTUXELcwT1kGtvf/WwooBUI+D349sF4S1+s/8YAwPuHN XIxWR0EddhEpKmSXnyFLzNJwjY6al2W4BuovEa5oru/xWYXrf5pv/4MLEsxPcRHBGh0v+5nl46uq zYNGyxJs49lAiV4REBDj6zLbi74mpi8x1vVXA7HEpQjXr3GBqqYj8ZdYXYILUuq7tfl2gQsWab9E wpwWKZBMx5sVPslwvTGD9hFlXkCPPprGDlIuHu/ZwR/wCa/fmicrTIZZ+o+ghyQ98gIXwGRnAWHS LNQxgd6wow1MeCOofwLf/Uz8O8VBLFUhfy3Tg0S1j3y7MosKKlloMWlx38ed3aZmIwLCSHfRDV4t QuwO2Pfsk/ZiB6kMgrGgRqEdHSC2JgE7LTNYr0dRqEKE0cCqwaq/rGeyv2ofslts56ufPQB10JCf nQDPTNxOnz9SUAsJmFGyDR0fEBLN34EBM9XLsHtnL5Y1+pttt9Cu6cV5MHFNB/66DaqMDv91GwkF iHwp4jYjq2qoVIs+TRZNW6j/AagbYOkKZW5kc3RyZWFtCmVuZG9iago5MyAwIG9iago0ODcwCmVu ZG9iago5MCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDkxIDAgUiAvUmVzb3VyY2VzIDk0 IDAgUiAvQ29udGVudHMgOTIgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThdID4+CmVu ZG9iago5NCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9GNS4xIDE1IDAgUgovRjEuMSA5IDAgUiAvRjExLjAgMzYg MCBSIC9GNy4wIDE3IDAgUiAvRjIuMCAxMCAwIFIgL0YxNC4wIDU2IDAgUiAvRjguMSAxOSAwIFIK L0Y5LjAgMjAgMCBSID4+ID4+CmVuZG9iago5NiAwIG9iago8PCAvTGVuZ3RoIDk3IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNXO9z00gS/a6/YtaWL8okmWh+SmIRrE3CLhjD kTXc1aHb/ZDjqvaquCuW/7/q3kiyZAlHnlGwA3wwTmzzpqen+/XrHn8mb8lnkhGeZSxTiSBKx4yn RhEjExZrkZA/P5K/kf+Sy2dfOLn9QuLy75dbvM2+kps4rn7UPpOGmVjylKSxYqk2aXD7iSzWRFcv rB/Wn8jlc8444WT9bxL9MJmGs3B6Stb/IddrwNoHLPAHZiSTiRSyAUZKYMEgsL+4Q4KtAk9bGcNk msZJD1LXVkHPViezIipOPWy1vYmB2yamhqlYJ9oLGPWy1bZfBQ5+xbVhscmGIZH1p2Dbr87Ow9lF OGGXNC4izqmQahJSHQt3qCM8TZiYSRNnPesNe5qf9Xw9TXIc6FiKHqRhTzMqCc/TcEazR49+dLfY iIMgk4ylAhFoEzSqszkMz89ivv7WxDGhYqaU2oWo726PVR5O6BMqFH/qZS8LLvAIsmnCslhJMoCt HzYOay1uEpYmMhtC1LfW2U/zxSzM6bMiuqRX19S62XN3s405mCplWhs9hPK4dpMyZkJnXnb7WRTR RUirP7+4G6zMA4FnMs8YF/F9HE1qwXSKoy1ExhKRGcJBFhDIwTtSJhU3I/JT+6EyY1qaXYezv5Ev eiGs/YxvCcwIZpQwRLgDO+zJbOJYkiTMcJPuslX/aNKpDCmzKfOlp3/VZNGRZxjrAVKkZAhcfyOP ZS+dMQX+6mSvcVaqKTXozyClBisXwlLqBJuZtJBipHQNBm5J+PqWGFOy8+qhMppuGPaTJ1VGKl/p RLFHHEujccLTTPWB7kDGOYtr8k9GG8+FN2b4j9Idxutgqvy/sdYHEq1PyUVGogs8CBKlp+SfZP3y YLUJhzm4VP0dDvogUTQ1IKPMy26+jJFzlG+KS4e9bCDBbucwmCbRWfWQVOarH2bVM8Rh+5IJHgyJ HlXPzk4D+0MQc/tQm/2yelZEPuYfQT856CdXRvisNcJqXKvV7aOEM+/itm3YFsifmXCKQmcnozGR uEQ1GIcUSDoIC1xiEFNV2QdVZe9XQG+T9EZsCO4WG8AtUpWkiRMiwgOrNfx69fdXHvVfb+9cUCHR xlyDDLvYqUb1DexEPgetDFNW1I1EkyJVyFggMDvsXBmWg+jtj/RkOVtMLioyoJazPKSqOKVFNKFh U1iXLOGarsJkwUDm8csVnc/UTwvL7D++ekPz5XyuZlP6+Gx99pieBiMPTWN4F+0p4QL6VSZctKcp 9JRJXkRsulCTegGW/jwOi9NwNgtX9ZkK9qtSd/nKAGSuOcuExs54QPZwlhFVEtcKcmCMaFhDqmLP sHyRXr6mMiyiFeSCnx+v47e/vfjtFw/yOAInqmyYTuCYeeD0I4++SbOJ2iaTLOGJU2HiB2k7RLok koY8mgQcI2sySZc8DjONJ3Nf8jhiOxvy2AW6C9k48jgCU0Me92PaJkE4n5baDJGgEC+RlgQF9pWW 4VwoEsV4aFlncYqnLZmq39LjRnhNTU0PFKASwQQIEtmYoI6pg9TUgxuN2JX2lGlkWrnR5oYDlA83 GoFJQf+SlsEbD0wecXwEq8XJT1UKzbcLaVhU/fU5fSPRi7HV/4SmIRK6/SdS/035Y5sZ8zDPkSvd ueYIe4rYqkU86YEf3mOaLy4mUC0saZkX0VTSRU65yqfXFS+x4Jc5MpQV0CZTulIgKRM1PRIrMQr9 HidOMgtZuEjCknnpP85eUvoDiFcjythlySUWuZxvrazeFjpdgJzRdwu8Y3E+56Bq6K6t3tOw0luv tz7nWVH8cazFS4gD0AFdKBncbhUyXkRgX+X+1QZYTErsC9stTLDP5eLpYsLUud3ykopa29TmW9Hi dKbOy/es1HkR4f2WwFo7ildFIUpTHJSRoovGMg090Hgs34MQjDhZbfQUmsXQa1zoXUXvK0K/mql5 aUPFV7XNS9aPDQnB84tTNSt//W4S3rzv7Q428gRvn9vt2mxF+zFlvXDQ/WgXD3lD6lS5uKOa8Euq GFvOqD1UTRSBpyHITMPz+bQskxSVMIQ9lX+WL9r2ORtNe45aRtjys+HvR1p1LNFn08Zl1asQpwzn CkewPUZre55qnn+NlLBgZYy1MXQW8kURpTysQxJTy4MuSqQ4WirVBOMGzouCx8LY+VzB+cLVtjfa DSqLQITdg+JuXFCjRoDw5xQRq9CWXgIixbGqj93NAikOP9msh9rteU1v1LJaJ351ol6VToqlPX15 0HWJRDORckF81nWkUKcTlLQa2BxGPjwgjSNllZavoV2VrY9qPGarHAv6Wj7U6Y7w++TZMcuxLtDv oxzbj2m7HPsryqikEZUxOWNLrbo4q8XoWqG+QDkGuX9TeOmq/qp161qNZtX76x/Wz2oxu/7QslIL IqixtnzbFHf1a/D/u/cSSkXJr2fLMwj3nGvSNdJwe8ijYOuJXC4aRBvyZIpuDAbMds+EdWZ3qE/F 1gPlpWZrD1B+Fdu2VmP1S9hqUGBv5Ow9kDoK+9Wj++vZwSCsRs/2gXU/S8FaX24HhP9G0HaCVGvs b5/Tj2X1V9jqb5dWvVpACAaFoWo5vVBtTQGyAKa3tNMq+RKUBwXxQXOpxLBbgoNCNstzIWweiWtE 2QAnUEbyjGiOaVGxOcM7C3LV9Hb/d1CRIBUsw3hK4oAJQtGodrOvAtwohl0zDYsu1XDiP1CgloWE u81GEBCOcbYYJUDPZsMAPVyrF4ld0kPrWjFnidm4VhdSPaIyyrV6mFyyQ+taezGNdS3f7NC61jCk TnaoXOtN1eNCP8vLtxqEjuM8HB2ZWKDroQcQHnecp/EtKKFMCQi0d1OPo/vWfkxH9609kDq+9UbO wpAibG3Gqw/rXLZTKhVuKQzs5EM5F5pXSInfl3PtxXR85xqG1HGuNeTfXFIMiG4a8A7XQnqB3iX5 cImYlSHnqGFw3dpknKc7zvtxKQEJA7J7IHXsNT5FN5MVA3y7DaNodPH4Tk+3kBBG6+EfD/bX2zkX TE2KVnsxlZ5eTv+MHzZsIA3M2TQpej+kzeWnIPqwnKZqibGZezkVSM1gEcclRmLiLCFO0OoNrNiD xpY+RTE0Dp8rd8B2cp3yQXzHDe+NbKFECqn5Tqfvhgb0Sa2S/NWMlG1MhfnU1peLXJbic1HwXKGd GrZax2Ga+MLe5xMpcme9Epd60qOCH1FP2qsr9grLBtEuXtbf7qsr9FDoq7Ac1aIvbl+6e+QIhBIX GDEz1xrt4dXj1iNxiQJ9j51joX2rtc51mAzajIWqAVD9GwYezrUjNTgLaXsgdTLo1YujCWk+sO5n KWchzQlSLaTdPrJDIltDoCt0/jjNp3ZcNKevfv/w8V8n1Hx4Y5ttc9tFRJd0Zc9ulVDWanaD5v6K Tpb2fmFO0TE+rJ62uZSsYkSdJHZq++bzEKCrpSFkT/PDhptMMyNFrMkG43cUbmQKYUakO+ubBws3 Q6AeKNzsgdQNN9nRwo0PrCOFGydIm3Dzogw3W9q95VcrKuox8zrelOL9QRmBsD1bYTjpot+pgTc3 r2w7wY6MYC4Gd2pubFOhNwiy1V1QkyMFQllOAzsNgtSzB3aCAD2TZqKqnKB63dgbxPWbf5cErkQx kSWKeKD1qKJGcMKmDpYaNfrgxdNvoSa6CBhNGTwAqQqHR9d7hhF1ouF9WiD+MnXdAhnA91VWaxx9 73eT9Piqyx62bgWPNyg1d1VDD9UBwVjzHkzHd6xhSB3POlHUYDztBAxuOUs9wsP2PrqKGNCohVAZ GbLZQ7kWN7gq/5251l5Mx3etYUgd1+pVM+9QBHEKpWyVv3cPFyOyEEfMT5WWRHbADvMQP8/37Xs3 yoTIcKc/2e1mX3n+PUZ8XMJqo0wMgXqgUmEPpI6fXb2tC+e0ImE14S3H5JshXQyH4iu07JC7pZiW cW7PHzcz7/XQLgh0fmNLb6tUHqf2FvjWGuPEOJvpm94104r2LyZWRZ1MoTlMFweFztMMd58Mvv7E GTpMb+f9XC+5jjj8kAgYvpIFXxlTgtrFFL46Z+6AtpOe71V1dP4hk2O05O4We1MVbUej/wPgoFLU CmVuZHN0cmVhbQplbmRvYmoKOTcgMCBvYmoKMzA1MQplbmRvYmoKOTUgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCA5MSAwIFIgL1Jlc291cmNlcyA5OCAwIFIgL0NvbnRlbnRzIDk2IDAgUiAv TWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKOTggMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAv RjUuMSAxNSAwIFIKL0YxMS4wIDM2IDAgUiAvRjEuMSA5IDAgUiAvRjcuMCAxNyAwIFIgL0YxNC4w IDU2IDAgUiA+PiA+PgplbmRvYmoKMTAwIDAgb2JqCjw8IC9MZW5ndGggMTAxIDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFXGtz2zYW/c5fAUvURkZsmiDAlxO2kWynsRU1U8dJ djdsMjuKO20nyU6bzuzf33MBkJRohQLV0rU/iG8eXNz3veBv7Af2G8uZyPMgV2nEVBwGIksUS2Qa hHGUst9v2Rv2mZ2cfRFs9YWF+v/LCrfRlSIJQ3Oo2ZNJkIRSZCwLVZDFSeatPrH5DYvNhfbn5hM7 eSoCwQS7+YlND0Zjf+KPD9nNr+ziBrB2AfP6A0tkIFMZyRoY08C8TmD/cIcEWnk9aZUkgcyyMG1B 2qSV16LVg0k5LQ970Gp9Ej23ScySQIVxGvcCxnvRap2vPAe+EnEShEneDYndfPLW+erhkT859kfB CQ/LqRA8kmrk8ziM3KHuwWlREgYyCfMW9bo5rR/1+nKaFBDoUEYtSN2clqjUP8r8Cc9PTx+5U2wP QZBpHmQRNFClNIxsdsPrR7G+/FbrsUiFgVJqG6I2uz1WhT/i3/BIiW970YvAeT2UbJYGeagk68DW VhvDUkskaZClMu9C1KbWwyez+cQv+Fk5PeHnF5zY7Kk72fYRTJUFcZzEXSjvl25ShkEU573o9l1U To99bv6euRNM2wGvpzHPAxGFf4bRZBwFcQbRjqI8SKM8YQLOAhQ5/I4skEoke9in5qEyD2KZbBPO 9kRetnirecZfCSyJgkRFCYvcgQ0rmbUeS9M0SESSbaNVWzTHcxhOfi3ngeTFuJxOxgX2oNvG0ueB NqXzgsNnO5qPyunYX15xflAe8nLanJ34gT9P/SUvDyfqSN9ZlNMjny/VUTmdj3DxaMkPPVeXb51N +vqiKTytPIyUiy96PR9LoKORGjLM/MlcLS84dPuYj5U+E6oRyBKMv+dqwstSPeaLAkO19/m126Fp dcHnY15ItRBLnvn3NWT4SzLJE5chl9OiWBwBP0YHgPUsZhjit5jaF6BFsTg+9gtM9QZVONjg3aBz GCUiyFNoibTHgDj4cjH2iyt37biPOcnTQEKhVci2SVZbC92XsMssCCMnWd8fEQWDcN07w0FElFFE 4WAq4iAOQS0TDoZwR2NEjxRA3qxYkujI0vwYmsV1dPjNU+NN6SudwsN1XeEY8iQxrFOWqzbQLciE CEIbuDJ3BlvHBP3lEvPkeFG2hXgbmIzurqn1lk1vDtlxzqYj/CRsmuEnZtNj/ERs+vCQ/churgaL skUkgyiETGxO9wbi9vxOBiViYwBDAX9DuQnFwwd7g9JCsUMsFOId+H6SpT1A9UtGrAc8TpIaBZlK s3QXJJO48Uzi5nzFH46WMzUfwUM4u33+gqwkTD6ZdusAcBiWOUxKMZ74sP8FVyP++EXEv3t8E/7w 7t3ps6tB7YeUsB+5aCjtYhB76MQ97EbNkUkmkUWrOHJHfqAPR+4BqubIPqD6cWTfpAUiB8ORm5C6 swLn73iiJvAwBX9+EHFVHpaH/uSf4MjiGj6t5rr85eoZH/nHagzGHM/VyPIufB/txsENQog18X3i VXIELQsPy6hV4jRJo0CloZOzWguV8dwI/bA+j4DxE1ksWIXS2PMdvNtLl/Zlk0acYhVIEW5N1dzx w/qI0x6muxGnDlDtsKufOO2t4JNuSJsK/uWagi8Ws5majOejY56qeeBbjW+O8l+vzi8vEQxxUU6v 1zWo95cXGSLkC5MkARfaobgo9VfaKh0t+AfCN0e4CtE+gaRPfARuY9gtBDf3JOJKBrFbbFbpJISW 0GtjCQIjupwjsHzNkdlWBNpMBqI4vvSLYDLPcAzXWwt7+Yyi8zGFajg9R/kgE4htFS4JxGJ5XwFp IiUS+DJymarr+dJH8AknggYYFIg+kYmgAZbl2eNam3i7ykQtwdUxxg7PTICjoiyLUQNzx9tDcPcw zSJGnBlKWUNy0bn/jqtshDWBw9qFCAWGJEOavCKbC8Z1JbG7Erm/XRAKsR1SCFsqkX+fXegA9XfZ hW5Im3bhnD+fCyggygzNZsjjF/Cj+KsftV0oy2A8T+fjE/7AH/vYxqkjfyzVsnhtjEby9gWlmrS7 hZP+sHo3lUEu04QldoQuOqjO4dXqZoiqdOO8oFwussxGp93+lM4qFtDq0fOyjGzKFfnIb/0JVKUC pZG/LfixD6U/Kg+1O6znAJS+lnB5yRbgdzbzR2TMbdpSp/uOJ2oBvQvzMOyUVN5unEt4u8rJ212C mSjl7HOprgnibKICcJ720TVRtJLzeueIHPPJKFugWiNy1gd0DyW3h22o+QfVeji/VZ2ym394H+d3 D1C189sHVA8bCrPe1xjUseQmpB2x5KPtzu/BiIoiqAacgfkQKZIMvTo4s6rNesk8U/DWtA+2yh89 MzmRe5KpRAVOiX9Ct3p6/g45mCFbb7IQZVepWEy4nKywO5yWi+eSVm1kRqHPZWu42LbAvSSmBalX PjDugrRhgfvJSztYhCv8ZYXArGnc0j04dVNXIy+7AelcuDc9f7pFWvabSMecvUCRFekzyb5OtbZ/ B0mlNKQYFhfKjSqL++DafzZdOJ4MF6otUQeh2hxPLgQqvE+g5CitC0dN67LV5ekPFE9SSdB/MoNv V2XQyM+obB0CswFCs0ZuJRVrYicV19RiC3+SUtKi0s8aMGX3DEMMWYhGU2UQU+9D3AN5D5bYw0aL DCxBfU0VJJeArWEKyoguji7uJhzeXT5dPbvgz63Xf351eV+OZIQaWB459Zs+f//29sMDXes+XIjy cC7E8IlTgicFiy1OF3pX8uTQEbuHT9TIU5igVVdETqa5j+/YsoQuqqrxHTtAtZVVD1FpQepVGYu7 IW2Y50enW6whJU6R2lKbidP3VyhIcLSZGG/x6aOV8ccGi2OkQDtMhrapakAu8XAPXtxDHdW8qLIs SPKKF3fEMW0rjlbNWGo7l2KEOUtzGGLTxb7e+IZTEfqJc3g/eRQrdAatbaGdwdTd0Q+Pbi70WTKA k2iSR8caEkkhWtdogD8NYeLqdgkFF0KgIcHOTFe7BIQBnFc3AEy/eda3XWKP+arbJSqgVp1tFPoN sv3aJfbAVLdL7MZUUwvtEk9Mg4Rtl0Bj/bFiUx8/su6aKA/NNfGh5949sUXTaK+7Y/GEiFI03ucC nLcx/VuoWo9geqd9YrsUbBD07CVxfBhnWaSwJaNcCTTpNFsvz+7APG5iBbS2y5RYU8WKod1DMNpE j2eIts6P7KUWjeZyCi3adxO/4JYAzbhhEnrVjsizqN8TsHwFEYCBgs3Qc39/gjqmRZ8ACiQcjbhr Q/B2D4HuM0MABLPTYwhEwvrNdhwEisZhqeDoR/fpHm90LcCH4daGmHbc9GcC4F5mn3jiK5j+Jqvf jWjT6F/yg+THgxcPEVP8tEC7JFKT1EuArhgTe9w+TlC1W9qk65sr9CiO3yD/uqSCHnboWnsr+map t3RKjbKLMfXMUvPl/SSQlBJBlEunAIuGgIDwBmD9J2jwmQn/gr9ZTEbf20FfFaq4go898c1wcXFZ FpR01lm0JQqwS+rVuKDBYw0Af/X2y2tQoZihMYNKszVx7mnw6MmP09ypUDnW2XQKIsvpcklVEH5N ZUr0Pqnj0fxfmDFdxsTIVqcr/ipRY5pXZNhfI2mtM/FjfcegQ4tgGZF/y5jqMTQ+UjSvqOevHr3k r+JFccLfY5WezXJa12vgSF9F8HxU4lQdQDkJawjBeFT9NtV9JDAKtF5b4UPRI8MoiM90jxoG9shO SRkE/gypDKqMrw1y2yMHnalGNYd5IN2K5aYItFTQHpiyOr1BTKmHf+QH4LTRvDi6GhR7hApWJLCa ER6MK/Z7CiokBADetPFRu3P+Q4e3WCclSRQ7IN2znQt1DjXagWjTzuX8YIRVDaTorJqGnas47kJv GbY8K8tfoMJNowm0oM4oZmp5wl/R5j9naBaaj15XWn5QBpUJln/JFPGcYQcbW3UuANbNTjSwdqj5 9UXTG46223rbWuwlSiUqRqVatyp0R79IJIzGVGNHg0dDcUN860NAE1rlZ5UejQRBLAwPleQnPrVz 4SJa86IfYYqoxprra3Elaq4X9+R3YMEKInJVRb3dM4OhGB6z2Tyj/JvhDWqhaMEjOvMhxz0g90hT 7cFEIkX4JmVaQ3JhouxkUMYWtLAXvlQvTD3ItEfWU2RoK8Y6j2riXIxCiorRAgWPFEvgKtdCTeYo /FKfcSNQS19gydtkXaK0CdY+4cC6zX52QcboUUATrItyG3jyUTkUKksFqzC5MOSwk4/sskhknLQg dbsEqA+hhZx6neAP0zLHDS06rPyoGAnMLG/h7TYMw5IQUxqoXELzWU5zEaAe5rOVNnNJHjTmU2Pb 2mLQdqruINqeNavQvEWRW2DpVMg+6K+heH9FBo0oF8lMelhiHSJ/FNEnEJCQ6pMBwz1Yno0UHNJQ lEyi1S55jifqIyYXVn9ZYFfiO0ajHFbrIf+INQgigZx88u4e+8h0Ew2+ptJcF2N1caiQa8fKBXgw SOI1R+B2YbE1W+FR1UX20O4Dq7Xn0Axh2QESY9V9nsI6R4X0YwMIvJDSivAGdnVkxRSkSdJ6G1Ud +4hjGHKaJXiUvZOSH3GKCkT18OZAhYAeVV1UHbtzxLtzhK3fZ0lACKpHVaSrMNXkxaMq5NXErI+m Onb3qjtHvBX7GaWLiP2PvTXc3O4B2ZaoxaqKFEyGT5p8YvU2Eq1gFbjUeWbOSYEVp1GIQwoVFbsH xl6tbTdHm62VZ7YF8rj0THqKyJV+cPMGhJc4Rzhoa0XfcADj0/ZHWm0v9Etp34NIQYyqJ9g9PBv3 mDPY3rZVnSdhpGdmEcTIjqZ5A1HBvJu2KhybR9fP/6zT4XW2HTnlu9l21JwaLsCHikJ8OAmkXjtm RGgLs4A1DAPXzILb9mKWrUzWiFHFZE7Sf1fU1wV5D+n3VEWWdRo0x0w1jkYeUqe3wgesojxTDMwE YQZHSawNwkrkvO0xkloX1RrmMA9TXQUwzVD1bvNc1L0U8lHW5uELSXSl+TEpc2g4PI8+avXyj9tf Pv/ndzb7/OH32y+3nxtHgUSufvauV1lHrnkVcpNoJkHogfXQVPnL6oXSB0O9ohkUg09Hq5JB2NM4 bt5HZQrNiSE4l6ifKXxtSMgIq4GhcCM0NwPzHlENWlTwLJSKQPgYGzowZohyiG7mxxA+rwiPkt4Z ynUiZNP/4hcroT/RLqp51e8t9jM2xYzQ2T/wgwXSp/iR3hQrujdLfLtHVfkItZklbF7nsniFIAT6 q3tcZnqRuTKLbTGu9wYxFSexshuFPwJu9+DQUMVyjh/ULwtzzh4sp9hN2RRhPF2zNHv2RntpgIPN Q+1jZjgISlFRFG+yB5W5fYSH4Zx9hT2oK6V4vz1qb9x8kz2IS2pK65U8e1K6Et7t36Or+Eehslp/ jG6DfWoyG7kFme2oLX3tyCx97FCWGDwIujD02ZyJFu2pdgyK2MfYSy19nhMpvSkEl+iLz5JZitaE 0ZVUZ8L0qQKiHzBAPQDSakjzdclqvtP3R1+BXxcNx6bOOJRIkZIWccaFKbP03JyIFjNShR8Ma2fw GntCeNWdZrc9TeikWONxO02bTH2kn1PLVvXOO9Pdd0r/hK5EW6xKqyTiNl1Zzygohy9C0BDP7DBe mF179AP2wOZXa6LqyJH7wNc5tRjmwxk/zV79AaH/AzfLGqsKZW5kc3RyZWFtCmVuZG9iagoxMDEg MCBvYmoKNDIyOQplbmRvYmoKOTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA5MSAwIFIg L1Jlc291cmNlcyAxMDIgMCBSIC9Db250ZW50cyAxMDAgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45 OSA4NDEuOThdID4+CmVuZG9iagoxMDIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjUuMSAxNSAwIFIKL0YxLjEg OSAwIFIgL0YxMS4wIDM2IDAgUiAvRjcuMCAxNyAwIFIgL0Y4LjEgMTkgMCBSIC9GOS4wIDIwIDAg UiA+PiA+PgplbmRvYmoKMTA0IDAgb2JqCjw8IC9MZW5ndGggMTA1IDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAHNXXuT27Z2/5+fgpaoWkvvcgkSfNlRHMndJF156/qReCZRb9pu nGlSO53Ed6Zfv78DHIAEpaVA2tobZyYUQRI8OO8XuH+EL8M/wiYUTZM0sspCWaSJqEsZlnmVpEVW hX++C9+Gv4eXzz6K8PZjmKr/Pt7iMbpTlGmqh9qzvEzKNBd1WKcyqYuyDm4/hJs3YaFv5MObD+Hl 1yIRoQjf/BIuH8zm0SKan4Vvfguv3gCsY4AF4wEr8ySv8iy3gIUKsGAQsH/yBwm4CkbiqiyTvK7T qgeSi6ugh6uHi91ydzYCV10iBn5ErMtEpkVVjAIsHoWrLl8FHnwlijJJy2YYpPDNh6DLV4/Oo8VF NEsu43S3FCLOcjmL4iLN/EGdwGlZmSZ5mTY97A1z2jjsjeW0XECg0zzrgTTMaaWsovM6WsTN48dP /DE2QRDyqknqDBrIKA0tm8PgjcPYWH6zeiyTaSKlPARRn92+kKtoFn8ZZ1I8HYUvAi4YoWTrKmlS mYcDsPXVxmmxJcoqqau8GYKoj61HX603i2gVP9stL+N/voqJzb72R9sUwZR1UhRlMQTl/eItz9Mk K5pRePsm2y0volj/+9YfYcoOBCONeZOILP0URsuLLClqiHaWNUmVNWUo4CxAkcPvqJNcinKCfWon zZukyMtDwtknZPPYRVU7x+cErMySUmZlmPkDdlrJtHqsqqqkFGV9CFd90awvXVyN8hGVNR/0EWWZ CFlXIhwD0zhXrKvuyWkFUMMggdHLvCiPgaTd1kC7rYtodwa/dZacFFu1SKpaFKMgi+JXu+UqXm3X a7GJbq7i3XJ2E8/zKL4BwAx1FC+iX7ZKByeL6CaazTfwklZX6r7s+W6Xxc9/+vHdzw/j7SqKzwJf 57wr0GOjhgo+cZNm0idq6AJtlxrXlwr+nx88j3dnchHPo9U8Xm8Xaxjn1XUcv8g3K6BDRIv5yt45 z3fL+T5+cOdMzvU897R+uLl52ZQ+6wdNsZBkvsVq4si6uolydRXBhcTJfCNncb652cwugIwkn21+ 2Uag8mZ3Riu+xByLKK4jXD/tGqHv4SLkYTVijcR6YN9z8hHqCKtcC3kZ3YzQmRP8hFZnyiIpiyLT OnPYgdfMRszVFTHFcCRoq7WcQYqe7Xa/xptZIrY3keK3RM5mUTLHkjZKAueXsdSEibUIruGAn5Yu JmKv8gLW3k/2vvniTXr79b+8/vbaX/dNoESdwmHLZWhAO2S8+oZ+BG/0NJVPHNryhiihl1Mvexo/ euiPph5QynYdt141XEmI1gigTmtQ4fbVsqqrYyA5BvXJy3i3Y76HZkui9Zy01m6ptbjWbGyT+Dpd PI9uYLliIeW6xvBTffc3D04rNlmViDyDE8M491HZI3A+QVoomhByGOV9aXl4vYnmu7Np7OmZTsqR V6zqprao8hHjEajqSYyXGBd5gmQD/L0REnN+vl1tpjt7XnDVMoEbCm9vBFzTUeXjGufINuSVgBIe BsmRZC2S07iKfcajLrsQiB/ro0rPgevTUAV0fbwNPJLfVVommbzLNmiIQhFQ7ttqrW+hyuCks3oj 110utE/6djFf+6NyguIQjUhKlADCAbj7imM6Jn3kQDQyqVJkCwYg6ket8Qgk9VSGj5HNUgRiSFsM Q+Rw29OJafpu1DTAblmK7EeTwwT5s9t0sqnaj3ZEgrbeo1L3thaUCeQ/4BP5AYTaT9Dy/1vN/+OY vUtHT2uU1UUi62yQkPfL7FldJ7KpjqHNKW2s5gjbprOXjwzm4KoqR9FgmJoOWJ/GXsdUfg6Gr6BW hwFyRNCq17exhDeJIIxDspMqVBslINGJBKXJUA5HkAh1F5ABFKzm8Su5FTfxah0lCNMpRO94twjp 54tNvZ1HKlR8a5d4Un83owIqHCazon+8u5tR/ZTqbAYknzB9JbeLJHrbTXKp1IcKxs83i4VcgEGY OYLjleiuAuqqbZ8SeQlnrxZN5oPKd4o5dsQcyOvlij2ir8Af2kXQuYK5VGwS6yhoJuNzidQOJbdm 8ct4TbFRhMcpwRDhJDeR0/xyfV8JvrKSSYYeA581c4iH3Mh3r/INwBWbk0qtSFElbWAZDJA+DHW+ 4TzizRaVeZVsMwkcSj1+T7lX1Osh2noNlITV1NIyPpMLZLeEuIxRPLyJi18fXZ9UjiUtEmkeu0gf ShiBOE1rRqstiwKdKMZvHtaWo3IqE3xiiZK0yqkgAegN1DjzN7aKb3MqLkjDZfInt7HWHcqwrEx8 gbQiZSzPybTszrZojtDZFeJZ5IZVhpJyL/3cSsvOePBms+L85T2lKEskZKXwUpgqmFpt6xVqHGRR E9KCqJtuZvGDDKu+uUFSVuf3b7ZQkpIwsYhqKecwALudllnSnJvZRlVGVFrp6sQrReeVECXM7JiV MgVVqYPjx5MqylZgc4nAseIC7LDAIn2/iNawO5Ts3i3X64X8agPVN4+g+6IqWlzGLx/HN8j0r+JX m3mu6EFUlOcgARRoBTV5Wt2Y1RD6inQjr+uvpBuRfSlyP1Tfn24cAdR96UYHpCO68W+ubnz27vmL uPzxRbwW8D0i4kAlU1o1bs61MlQMa4w66QvoSaiMB1y26WqXk1ryVgrTAu1TuZdaZDVIJVCt4XgB 2iF+h/Q7O5coIG9Q+oROZBncLc/lFopUeTeb8yj+DqoUZgR6dU3TxS9Pu9qiQkaohGyOWO3j+Hwz o0DpftRhgWgvQ2eWj98IzG0kSpur7e5sd7ZJNmSkVBER+KaIj9QdfibwF2GpVLhPViqRqIFG8+h7 3KJr+jPFpKfVjJQLkAINXmaJfyHNWFToGZA1Z1uHjdC9acYxQN2TZnRBOqIZX+sghdrzULGmnhFq AmkNOLWOgCsh+LbJYne2gKmm+GYFXUGtJtUGShRaAsoBWgXZbM30SoX0lQXaLIs8TbNQgYnsXAOO 2+9AT5omQy9wgwb0JiskekXaXwFafDLRoGRfhkUpwbC1DFHUhsdIXWdFnuEcneO/nKK/3GrjAmkJ ams70PfeTyvOoUaVswmB1yiGzMdoIVhtLmb4CUfJeEK3T17H6Ga5ffJE6bLAq01+QnJC4a+EmuVl +Mi56W44qZLNEIaloqkMYD74vfaHqIcqn/xohj6WusZWhwGK79Uo+hB5sP2z18TiaVHX6M1Aa3nW SIG3tr9eP9vLNl20GXr0oecVYQtxBeQA3e+h+p0G+J2G78PXShzaByilf8fzECKaQfAMdCZlEb4P xsxBz5R6BsAj0cfsBwOxosgLaddA/Xpj15CDjQpauVqDOuM1+ONBvZfXAHiCzhqObVzpsVmnpgJ6 HtlRU6B9GTznI5H35e/kKInl1t8BJYl3+KD2rWRJynt8wj7nD247Gp0aQR91RtuOCpQI0GRm1G+K bQ/gcvoXvLkNEVgThHxQEKLniSH8cqW79tMQd3rp1wlppbJAF3TdyB6gwQHIUN+egLwJMKH6m9b7 yDsEk8XWj6hcn4UXMlzOcCjD5TkORbhEoxMddkt98QKHLFxGZ8FFHi5LPbjQg3B76EH0Gqsn0INC R9S0aFZ+sNaD/A49a7B8pEejs/DfwzfXfrQ6KHnkMdxdzheoy5UNCmA9pjpAK+BFNwUDLwz6/rr8 gZ1ARFUMTtEn7AI7SMQlKDGiq3esUFqXSCIuSmmHoYdPFD+Pku1igz5IpBZXaIrkrDp7mr0+V0pR IgCtqIEVe29uZLI9RyBF7ZSzmJoU//b49dffcv/zqTvCqFEmR4eAWa6Ppt7z/Q87BHsMMeQHU6u7 oB1f6FxFpZuAgqHFEU33aOVXnnBV05THPeGDYjPcS9+SnZqZ4HT74OHhNYpWi1m08ufIPZwo3T4o 0RU0HYIMCbRo0DRHDseMeyT6rJYL9bAUJY+6BxLEWC1HH/qBw0Uk14tN5Y+rLhk9+yREmidlnRej ABuHq+4uDR+PWyALUTZo+XLJ5+Kq73ILOQ1NqpqroBpkKSHypMHmxVEwTUcTMcWxNgk4+lAP2L57 BE1Oo8Qqmt7ZqDj1SG+cwDarnJwML6C4OW5Me3mXxd1K/J3tSgJp/hzumC9MqmFpz7c+rLEdcLoh XBu4dYI5zxCuQFKkwT/s2Ucc9IGycfQzC/wiKNJ2lMCTPEWup+DzGsG1fySnXk1NvTSlgaoGPH6g kE0oS+GspsSnB2g1nlPQakp0pdBqAjxHqzHn2FxIq/GO6dSr1WrgMBmo2tVMCuuGncvWSiJfJIgJ DzhH0GWOkO7x3qAp6qpXHxFtQUKkiR6BYZBYRD8DSOEfd0ooOsd1XCczYlu7D7sT11G05njk2lja SGX55YuxcV1Xdj2tpY3reoAegGxaXNeFCerNx1zauG4IJm0uLbYQv6DJhmK2LQ4Iz/5VH/jsSOgW HAndwk7oRgHh3aFS8Elx3bCDqpqLyRU2eGEH1aGVFj2LlzGh0gTHtBU9cAc2xx5SBn0nUG9lNCEP hUHUzoBke6L6HHVm/sFuV+521/4u0ATgqX08bci0jwDeH6IJnG/RmTcZvLOD6Oz7iZ+myI75ZFaR 5RW+J4EdnkzhUYrs5X0qsh6gjnAwK05KUE0gp1VkQzDtKzLWWZyZeq6TRrTXifJMnJ65wlkdLhFK kc7jPFONdBVuKfSdPJjirLG3mGmQgyJFhqzVSbM7oqH0MBjZxcBfIruDdHiCJPBBIdvTWT/IxdP4 YiG3a7SW0ddlVtSXupijAI6j2u6HzA0VEbG9m/spVaF70S8Yjnd9BlJ9VMspqL5tFuOTs0B9M3ql +yHUvl9OPiH1pPf3muNJIW9VHTrGCjQf+ED+E1CKXEv8YoWkED4HMNtcXMUvkDXDhcXNJrqir7Is kvjnzWw1ixZX8RfyAh2sNLiCnRHiKn4+38a/SXGDDq4ZzrDBHFXe50m+BU3RQfhvVAJenbhZzuxc zhHH1ZVXZeQH1UpWy/lcnl/FBRZEeScCnTosnmKlaDTGL3Ti4v+EI8V9GTouFnGBhgyw5uLVJnl6 6n6LPCnQ0hOOWNqeATscmBoD/yPKHgJaKw1/1h94OxyktuFq6BGkEvNlOTI02IdK8VhGX3VCtc23 xkdWEc/gedQpUahTFT9Vc8QZx3P2Q0nHcqBFlScoCgm0FGDvAr59gun2xjApvnSG1AReau7DD2RP JdoPCmQMscUA5Ro7UmLTFT6lFdzuj3mNdJ6TBZJ/KUp6BAO/URYiqRv1RoZKfZavocYIXo4ZuA1R fMUn5KB6zdD7APXUJKvq0g5JKRIsgz7vxzN3RvT7Q5qJ70JvhVofUgHtmMGCndxiykJgRzpQmTHM xHCakRZyO3Ib/jfy0Vn4f+GPmin7hZl+TZp4LUfPPngNOYPu7/cYx9cmCmQn1LWcYlkhEdhLVL/5 DPS+bX8H7Wj7i69nAptMaE7Mgh1uyJ9jYvuGTOQpzgCH+nUb4Ktc+GISjb6n7wDpl6pzSAY+hGRm 4DPMjbYVuqJkhp5RvzW0gZ1BrUTNrX7hGXpPb7QdI3RSVX64dQCpzZbKaJnJcnwh6EN3zHBDZ4y5 oWU1S8N9Oh/ghn3aH+APkpKe9PpJamAlyXJyR+KoLUit8X1nPe2YrofQKtIMLTwkVRVhBJSHDBET Zahoo5xilKjRRaRKhYk60yatVJZOpfARGvGpnZcaRoq2bRqZWrqTDyrlA2WA+Wh/8Ou/v/v19//8 M1z//vOf7z6++72Nm0g+7NzHXsVeQfuqAt/cK7DzEC9Wb6xtHfzBqV7RLipEyouKzujneCz2vsb4 j7RbaC4jAdB2i3KK/jlEbbfwjLJb6KGyyU2M8DyGXyCVd/exER8Z7odo4NNU+CISgDJjYF0e69gu O2b5H/YLrRAoCLNpUVIGisNRt2NKFtWYuWtopH0ukKgvFiikdS2XgJJvkFax9hQdo6jX4K4WcjPS 6gVMxXeRTBrjZcasdpJm9s6IBqFVYRaqvXv2BtqH2gV3dALjrlVxFr1WxdmRdimYigmzd1er4uw9 ow0eOUdkaAIYE2qgMkanBBW65qjEmTJV0GPW4IGx0QVmruA33YOZ+BfMUuc6ZlZz0iz4xknP4KGM g6fJ4NEvbYhgp/C7a/DoXJs4MwOfYW42eHDOUnNP9xd8K30vwcQGMYOlU6uxBlFhwRhb5FO0QXRH rTGm6z2D2PFs2166rkGUUEQpPojUMYitDO0zS4d772QDQGFYA1PdxSz2npahWo3QjrXS387VEWNX +tWc/tLfmlGCd/85xoyDBTvWN6P4DlmmexDYjFLdDXn95tPMqJToaagRJEEuNm+C1raRMfy8ZtS8 6oRm1PsVd5hRZKu6vTxKlSK2UG5/hm91w9ZmSUZ5GgHbW6NJuo995UMYJ+ZwMyK+hIvvOoX4iiqF RSaJif5SelYfdMqnMQ4MCgrPkCODeC//V2fQPtApcmbm+A7nSMHBs6H82t9xQO4NX+u8yIMlugbd vJrHsnoJRgVaOlyMoy4ZeNPDC9MshfS87fSCp0SwIvDmHCCd5TirdBWFu+OwOCRuaY18J1VYcG2u 04w8+AqDiFWXaFeg5yl5iSe4ye5GD/Kt1BWHa5R7RIVGDQa65Q4PUrpy71X8PD+h+uhwK54cjd0J TFMU1JOJpIDLNoHDNha72u8F21AnIPDJ+LgnWA2DowJap/brbg6kvZwmV8xaWlMuGchlXKOhiVbB i2HKX+hbQIeAbuWLXXpyC+UePV3u4ieoKle0HKBOwyX6OYg93Cd40HAAsxfzlRldAyywEL6nQwee julg7nFn5wn2SEYyzIMMR7vI+2A9S84UX1owjcqsqBx9Zf8YQct4BwnIC2Wc8C1Mzg3QBjagegMJ crtS0g7fEY0sqfeQQbcwMRSiA0M+g2+XUgdJ8xVeAYahygYODGkCoMAFHlqFb3H1h3k9ZiN6tftO pipiP/sCU1Wb/YyO8O2riYOkcLUnFqHkjG9lzLAWNStkQXWpzrd2BTRYuiLt3nKQsD2OYGXM7GLe z/N0mcCSjcndg5hFUNmWwNCb4WeI+ZZrsAQY7Eof8Kb7lL0MLgN9+Ft5acdkz2CDAecDsybTz+LP 9p9DS+HjtR2uP6CIQkM3nqxHFEa/Ql+fxAYoxj+TiHU5c4NLeAYR9Q/CO8PtMqXLaEyheyYNGgVr lMj9SPMTuAcOGqPPuCu8DNfouYKGWqlSjC4VGeF3WQfCG8/NGgk4vQ8VhKwGcn0p8iaMHfb5h9TQ stfQ6aEcp/hRaH/FPg1sbnTodsyPYl50CcXMy/JleVHVvVs1QUTgO5lOTDVXLl3Gdnl/z1cdrXrg z4/deWDMfgovzu4MPqZ6WJB5MarAD2tuji7C+EzhLTAut4uigyrooN22sqMs9UG5MBro4Ctc1aPM vzUHXoRSxsG8gp+wnKGAYtzwYYqW+hQqwnkrEHWOMiAzaCuYBcuM92Py8JGCDPvfsOVsBMgu4/Xx r5x4F/+GJ7fQq1gj2yM+uO4fMypjg9mHxZ21tCa8dThdFjNqnufhi8xxzKqGc/h0Bajg6fJL3OnY BJgFTGGkCYqT1YFEM1ht/wKGo8/3YzoGv+clMMouwFxwsfkeRi4T7hLLb91vF+NMxhYno5XhlNWj d6iCRcK+JN/1UxZmZDKpm3Xx7JlFPy96HfEXAfwBQ3RmeIf1tIt8xixzK3Mb38J8yVzKlGQSMmH4 OVYafMaPM81bnu+G7jzKr3cV8j0zOX1UsDLfCTpm89xogznYyDNf5LX1TZdavhtyXuv44nscoAD4 uR9wRuk+Fyld9LeZCyYDP+lik6nh3mLEky9yEMCvasWM/BgmI/OEe23PSaEHgAa1xvaNo6V1ilDo DKvER01q+rtJXkaPQTSEMyLCzM3oNFfb9QxlZwgD/wHSIXfgikOXcjbJ5KYyzZuYZfqco3SnuYd5 jkn2X/RG67wwVV1a7ZFcTXeQ5OgZ7Fgi80Zma56csdGiajSRp6hkJnIJ/7TxtUgukzJS+MDgM22Y 4MzqnM3jO3nZfdXYlVjDPnxPd1IbGTPZXGZgKGYgItwSfhOfueqTPRe+ZpwMQyEedtfGXIi13SuF qH8G+5K8xJABZqSY1Rh0miPjhTF4jfU4mx08YseuWvHc6iaxUapCr1ko8dcp71qRm1xTYvgJXkAX soGvmBvnDF+3bOxncxznzBss1BnxFW1b58qwM7MSorkLXR5AUcmMiu0HyK+hMnWuAJ7JM7J0U+pc oVPnwleH/0C1Fp0Qqnw3clEDTc62yiV5WR6ZDSyrZ8ANWzOzs655BVU7vXrl5sUD41jz3CwwRvGz OTFwsBy54PAjEDmVeRpQGv7oPbbFwzAy8p2ybYc/zMm2hGhUX2t/yPC6ioQXw7e0elDfqUwcVPVd WvEzLhA+iSzpAwejlshUNOQzdGMy8lU+8MJdX9HNojIafoGwIcziKIBR5Joj88auWbLlqK4XZJOa RkUfhIbfYR8MPh3jqE3T5vI7tz8alkK+T+IrQ3erIVO+IjXEDMLWm8WD8XQIJZbdeNW8zhlEB1ac KcKz8S0vNfJ/04Y+cw58C6OJqUwfgIEnycDwGwy2+ZQvGv7gF/NFfv+MXmWdkP/BGWbF4RNI4Rms FuiezhXzDxCjl0agEMga0P8HRsU+DAplbmRzdHJlYW0KZW5kb2JqCjEwNSAwIG9iago2NDQ1CmVu ZG9iagoxMDMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA5MSAwIFIgL1Jlc291cmNlcyAx MDYgMCBSIC9Db250ZW50cyAxMDQgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThdID4+ CmVuZG9iagoxMDYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug PDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjUuMSAxNSAwIFIKL0YxLjEgOSAwIFIgL0YxMS4w IDM2IDAgUiAvRjIuMCAxMCAwIFIgL0Y3LjAgMTcgMCBSIC9GOC4xIDE5IDAgUiAvRjkuMCAyMCAw IFIKPj4gPj4KZW5kb2JqCjEwOCAwIG9iago8PCAvTGVuZ3RoIDEwOSAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBzV1rd9w2kv3evwJutdYtWqKJB19eazJuRzNr2do8LNvnjDub 9cryTjJ+JJL3zN/fWyD4glogQKo745yTFtkk+7JQKNwqFAq/sx/Y76xkvCzjUuWCqTSJeZEplsk8 TlKRs6tL9oZ9Zg+fXnN2cc0S/d/1BW6jK3mWJNWp9khmcZZIXrAiUXGRZsXs4hNbnbO0utB8nH9i D//CY844O//Alvfme4v9xd4BO/+VnZwD1hCwWTiwTMYyl0I2wJgGNnMC+zd/SJDVLFBWWRbLokhy C1JfVjNLVvf318v1QYCsuo0482vEIotVkuZpELAoSFZdvZp56BVPszjJSjckdv5p1tWrB4eL/aPF PH4YJesl55GQar6I0kT4Qx2haSJLYpklpSU9t6aFSS9U0yRHh06ksCC5NS1T+eKwWOxH5aNH/+4v sREdQeZlXAhYoNpoVH3TDS9MYqH61tgxoZJYKbUJka1uj9XxYh79KRKKfxMkLwI3CzCyRR6XiZLM gc02G9uVFs/yuMhl6UJkS+vBn5+s9hfH0dP18mH07UlEavYXf7GN6ZiqiNM0S10odys3KZNYpGWQ 3P4q1sujRVT9+w9/gelxYBY4mJcxF8kURZOpiNMCXVuIMs5FmTEOsgBDDt5RxFLxbMT41D5UlnEq s02d027I8llfVO0z7hJYJuJMiYwJf2Db7ZmNHcvzPM54VmySld01x0Migojh3EkRwTKFIIqYp2mc lEVtWxMMUSkYJZHK8wuWZZptVh9Va6YNY/zTy8rC6iu9KOMINctSaGxRKhvoBmScx4khs6yvZwH8 2ocHlfihYoPwepiq9myk9ZYtfzxgRxlbzquPGB+qOVov+4cHOEzZ8rD6mB/M6E4Qzp/Y+akfPe/K uus3zG73G7jKYoz+mVPWeC/4Dfq9ZuQ37I8WdceVmbXOi+ahjWPTdh1QgFJuNjMVpNqVmS1vdB3c m8okESzNsxiWPi9Brm96VvhKgOOWcKxKkaoyEcBl/qLuxAUcqxzdN+dZnBdJwRRIgIKdwVdxUco0 Jal/2Ibr1HZYXsYZOYjGdSq0GNPqo/JTRN1FoXTQmSPJlqfVB+meaE7iqKNPUIyAftJpvFv90JzH ZVHyHPKqMNd+6AbMckzfHcE/YIFVJjl0IEyOP0By6K5QLRInnBeSo6xOUlfGyYfVyQSdlbPlSXXy fvWxRofuyDrA5/d0FyvdLEk3u/rBjGJUH2Y87uoHGSVgNzAfVK9gjsxbmiNeXXlUXzKj+8hujXsv X5uUqzjLEu58L2MA8F6zKphB4u7HMTxMwNOX1PGTtCiEwl9SlIrzAibA/MVePr0RdDlqDRd8TZlT r8wQzsgQ6sAYqhgOVYFDDBk4nH1kL7V1aG8je7fxKUSUcaOgG0X1HJxIS/1gEfYk3KboOSk9B/BS GsLoEHhmFOgZxlOCM5b41321ksvm1YIeJWJVPap5uxIWVJ8b8YIEo/OCDdL6LY2shgJat42YN8TT CqsdnpI0LgrlFWm7MTzdHvwbYeAaSBk81FxA+TxibH+9Z/eXO8WkBJCkME4hmLYb91PglSophAXJ He64f7pa7N20LbfLqqtSnoZcByQlBYB77ecGFiar0DhMVsYSLoLdfH1IFd+tSRiDe6ye7K9yf70a ISsEzROZw4z968iKJzBpKfiFC5ItK7m392ScoDCK+ngsGMcQ48jyIFTjlYrI4ZAHygWPRc7dbdcw ezOucxWvl3srBebaH979uqDmHFpeTueYI16i8tRtG+w23LK04KarQaWqJnSMrM4WfJUv9h+Ghqe6 c00esioRmk3zMM0KGAG7VsFQxkHNKtF8aQ5q4rCgtmal6+X+fHF8Ej09PYn+tqLJsELt7anDk+h7 nPlOqsNjNa++Xi/nZ1F6Gr3Yw03fgOgbXdRM6o59KJVggirrmLjah9J+cm2CrfmpAPmOYBgFJhXz Ar5uBmcq4SC5Hgzjzc/ffSeiB/P1suCLs+h93ZGj+0ZNo1c/P3h///UbLc5ZcDip6044CJtIYXXK HD3JYP/jxSlSSZDCxHkWOgM5op0xGYTgsIIZDGjnMDMYOocm8jSWCFv3EdW9oJpGtoPO26dsoihi LoUtKDesMEGFUjYBB4+rnDslZQ9hu6BsUiQInaWZE5jdhNuVFRISEPYkE9vT837z2bLaOmWTiFgA lFupbFTjBeVD2aRC7EEgFjMgqB4N2Q1lkwgTYUIDNCSgDbcsLSARsnBruk1DatLWcIrBWPINgjTM 2VQCv0nkcDH/ZYTVcgr4vyrPN04n2sJ69miCmHQA+/rCMR2CkBlmHDD1lPlgYlxPh0SvflT730Sr KR6Kh/OEOWuZYtbOC5pxCAJY4Q2lGpYWBkBAImYVIK0n++oI+QfHr0+mgBvWeJ5LGnUG5dXLXHob 7ymk3ozTMc9oj0CGXp5RV3RIzR4OdTLQ6XZxiSJGLglFrm/vjzdwjYPkGcNoA5uIjPNbZwJ7TRiF BDZvKP2wXim0nkhTuJpOTL0Bcdqog47oNFqYkURckwZCD0TGZk0KazaO18wZU8mQaII5c5gHD1zG YG1XUpidhIIjscYHkZHUJIbsKSmeYG5GIpfAB9dOJAUXn2KaMFIebWckxVfHo62BHmwG9JxjvqhE AD8E0x3oE/v91lQFztO4RGqbJyIkXc+WZ6tjsJ2JQToSl7vzUeJuTjlaPg24G7aQYnxJJVwJf5Xq xOAiHYL7/jT6W7CSheR4IokUGQxwDG8HaY+Bvcjhm/umfVfzo2hPLqqwFybSfYPXI6I2lMcLRuHs GDbo8eRLD5EDuWay4IRoyND2Bu42PugvrO747Um/WrcDqy2wZkJUocy+629L6958faD2D6uJiOjF Yh8dOHr1/t4LE7z0y88a0bS8wCQzpznLHto/MqmdI8RecAr/9yC5BUjBy602K2IUMXKzYV0CUI1e 0OHJXwUi+cjbgjVxgNptQEcgEFDkJXqmG1KPv06Ip3oyICGQwZuKQUn1YN3B4O6IBQiRIg2JbJiP pHbIFuF9xDKhkLgPsJ3QRYGxHWFet01oYjk74osCqyMEqLWfnAyoO9ApB2EUOSVh06yuT9PpzOYO YxxnQD17oExg1rHgxgvZTpRKIv2sQGqeHyTTfo8uJkpJJ9HfyvhpLqPkNEEW0IBNgDBqg1/jUHpy HFkiJIAERCdKm+NslxG2tAsZ1QX+baJd9lC4i3Ac+XCFnm13ALshK1qbt91wHMdSlgJpqCwLwTVO rTzpTBuOS+DKYQrUpw13F48LADXNysMDcga+2oCcG1KPzNxFRG4IWBuRCwA2TVZDwcs2JOcDaYcs q43J+QDbyYDYBuV8IBlZPTlbjU1fbZiDO/7MsfwA84ugDgGw7kCrHDyLw51QAkt1PSHpyBxXo61n E7505CFxWvCY0OSwEZNPHlKAmMZEFzCBlwsJr6vXcu7oAjjM+mDFFwFJhmOgYflEVmJJZwi0MAoT monEscADkMCqetJyBz588gp/Po2+O0be1fpgMV8dnURvfn3wVjy+99PBzDdo2I2DdXutQx2JIypN +APUMUDAI9q84YhYN4Asw3r1v1sdxb375/79dgQqniBXiNyQEFQB/RZtF6yJFFfKEdzvQ3Jr4vu3 0eWxXsOecCSxrrYrNFoMhVXnIQBhVUyq90mUqPnx6myBqCGlfh/r4P9WASMvHdlzqL3TR+zWvYDu MKKVBTIYAAlLWHvdwd3KjxexOjxczM+M5N6cRLtIHJW08JNS+/tY3eLbbieh/LCyyGidWNeauMU3 IdLp65tThnqKijohsMIkFZo52tpdYFOoL+Xj102aF/eUFUcmYcqR0opSFrcCs33z7cqKo6RPikkj FyI7jDGNgvvMt1EmVlFgpWYIrPGC0tPPA04wl5gbT7CCbABSzwm+CwruCOlzZLPyohxsvQrTTiLC VIABGWF+UjIB4ZqB+w+It/FDl6zIoqPSgS8ynQo5TaV0rMDl1WEpQJKUbnPQmWXQXt2zH8JG6a7x 9HLrYJoSrN2s1dzHq6sTRjvx4ACQIzisAB0rOaaMapSVhXcPzy8WT/Z0JTJ/PRsBTYLLclpRFAIt NB1yDC7k22KxcJjIAlpxBCFs4q8oWAJmuGmUtgfDCcmQPuNOs8r7dkT2YDjNRAxFOJs13k5AvTFn J4FXKjlJK7z9YU2TkzalDuverO/2AGRGncPD58cr1D2ZGpNwoKKKqCllsvqjugMxOYIktLS7RF6C AeRj2w8XCLgG5LqMME1U+AUjM8ZBbzswXkw+ZoBCmyXAOADZZgDRnSfFehl/ExBG7LIYXw8CUx4q LeAEeosqzIZ36YKXqJABgJXKoMW3ArJF9fMCzvxD+PMn0TXWJb9Zr+fRgz/vLRAhUfNoT+k0wxdY UkGH9xfH8f7qSWfBPJYob6MMCrhYR7A+PSNAsCM6hcTCJgjWpYP24Cj21Z6KFQ8AZlQwJKO09a6R JJMlqMmo10674xCvXtwXryNKOoyeaoOCPFLTYarl0tvLOMQy0hx10Fjag+umimESDA53ogBSXmBl Sh+SW4I7yDikpfA0NvQE5Ua19YxDqkonUWvVBco2MOMHB59AAOrrIX5O9ZoccgKkHimbEIdr5j/c CfICy50ygdzMEFjTJDVEylCdM85o9aEXJBOeQL3IqYzM4XJTQVWuowA+jVczxbshii5YqJHGdQ2w AFh30HgOqihQthT5viBlBpLPkLgDsohKqoh5uXufPTCOl5QPBRIo1sJLokDuxuutDmj44jh196SL UiC6S5WXXdB2Ky2qVZ3KtNWrTfTBtughFb27rFrbTt2GzgQnKlSQomyiU0w2pmlZkCMYoUKoHrVM bHP6RzKZlgsiRwyB6I0ZdLZ+rdeoqsZDQ166WcPqjnMMiTLhYDQB6MKoX6i71Ia8KHtGbhbYDU2b EPXSC/EHpjaaJcBpAKjxNtWHZDUphwOQeiRrJ5GvehFwCLBpshqiWU3KoRckQ7OOV+PL9VEDDoEq wNtzgcLJIaDuQE4OkkVLz4qcPEG3mtezZXq65Wj/+fORIZ2GuLtT8DkWKqAquLekNKzxVqppPAf3 41hUBUigDUZSPtxPb1uCYhNI+KJyc2/eFqgtt5rTulG91PXymP78lSuEyTh/GD1Wz3EBSqkhjQcl KraaG4a527wkhzvgfQJEPGIwl1hvAUitiH1msNZrbEO0F726XK9fR5eP7x1vF2M7uiMjNuH1Dgtu wvHq18eXl69RPUaH8bC2tIrj3Zuv9hBHpjheVMepttrmAqNamaHSPSqZavA+OrxdeQrMjQMS2jxE ni/uCazK3UnWE3kyZYEk1RCAYUY7NFYmSqRdlKgu04fkjkpNiLb4OlaUZJontqTcsMIkFUwtsXmI LhDkkpRNLafRAA/PCoXpUDbbLScb1Hg50eAGUG5nD7NNqBzm1ihA6lFLogHjPPWGBbjDd6hSGacK ZXgGWq+HapqghiicBAlPad8CL0iGVz77r9YvHi0wn6hLOzihKyoqx7hhGsLWrB2tV+RCwfGkqLUD m+0WB4w9VojDR1w0xwpITkS2tMxyRXjq41rS05ZiGy8sFqDMlABpPfr2dBwo9EcveaHiB3ZghJVw gLIFNr4JvQxXvScqtvVBuszGfBnbbk1brah9BXetrrp6mA+mnSQgNpEDP0Tam7qLwMGQNW3WKvrh 2kH6YRM38EOkJTWNLxh9cnieTdjAYPIh7QGj4AhHrYkaOKRkm/LxBWNDJuIpdTspYdMDkAXIatQg A8OUoKy6A5FtM2M1zxfIBpnHISvwDLggcaEHZrRQ3wHObsjxBt1rjEHuDBApFyJbXLQpLAVYqpgK KvjrsAvCLW25Kaw1qiVaZVygbJcZK7eUO4OpwhS7pNXv4dNpAyQ7otMinAZERV4j2sQN7bauIxXj aIUn12lYq0KNswwVAH2QbYqdbDtrBstVRYbCLn2c7tBPQJui/4ZGAmi5KiDBuASILnitWNfqebYp ypnFkpoyBNiWDTFGLYk4jguRbVkmBE18OTUtXMMGlUGwxgvKh1NTmTWsyoLpciiVTarvhAQ50oYF kp5oCz8/UDth1ZT0hOKCnnIyeTPjaRDr7WLujpxQVLVIMH8S0oTTtGqI66MiFjaix+pRL0imATtE aNwQpCNNmnc4418UURXDtmGHgSYBu4A96Gkv2tsHxaYT1oEmayPucZsW3V4YC24/thn37oPVrNyG hVDj2tJz6JGw85hQc3dLm+iEDdOhYeiW4YBvF6XfTuE7LYylHMBuyGqHhbGCcI1TK8+BuslSUdiz GXUZNqb12PxhWqhp2G41WSohoKbZeYBymtI21uSWU8+W3kWwaQhYG2wKADZNVkNjYhtt8oFkjPy2 mVYbbgoAdQdy8slSGVDzSqcM00IqRaGez8+mZqq4mRbNIVD8xEdWuynBjgQ/FP+Fn+MDyejU94s5 JaVgn8TERFEen0ZP10v5EFEUfGJ/vyPKVEn8TeyICAVmILE1D1JS+tDdDjZfUfpHHQ5YnG0Voc4d LlEXOwRhGLcIDQGgfCTydLHiqA8JczQ6srx58zyEw+aLuCq7Y7JStiq3lgDR9meojuuT2VMHn+q2 7abJRNGrKgfEwN5OEI88vFIViPgY2F5RvOD4ypiuAjpSlsgYr5H5CDTMSIcqIrwV5BRZgNxqOCG8 4ukMCOz5m6PEahCsMDmFOgNU2jsnI9frCn1B2Txy2pg/zCN1Ge0cZahCQI0Xk1cUispoU7TaLaYe jayHfH9b1g1tesYKJLxgFA51a7rdgNuVFSKtiNhhyA+Q1bOXE6SkhxbnJLjEPuCo6oR5HB9Mhoa0 aTJtUkrY6EmdMWQCrB2YMIzC0m/MmLEd4N165gHARq0fMRuDexrUpmQ1klO8BRbehnWwU5uuAY+z 9cypG6AalUfS0+4ccyemnvWaZiOGfM3WL/dAZPrjXbjlQ5tYtW65B66dlGBuvXIPRDt3yv0x3YE+ efnkXojqTJnjqe740MIRFHtQNBT6oxpvnfQwOGCdOGpfARGoVYXIx4VYr5+fLVAK5JzWjHyHDcae Hy8ilA6uqoDcEy9ooUP0IpaLw0W9qsB4S1tdPyCRw5mhsGXIuwRId4QfhAldQoRZpdvb2x6+AxBZ 9NBnNGoZRYJMFqod4TMc2VwMpCmVCa3LysnRYwjoYEfBGs5bhLg4+wnq914PlLOnLxn2LEloglTh L8QEII+i89fLpzcSzI6Ql4Q6oEmSsJIVKMgEnNjYWs4ybI+Hs4LhWCCwgNUZdKzYR/ZSl5lpb6QY w8bnoK4t7sOULe6bfWK0jL8+NI9pZjPxevCzUVgIbyBSJCKJzl8INacokYuqCZzl0D7MiOFx9ik8 MkWtGqwfkvVVOIFMMAWZwa1BTXZK823P0NJmpWb08Oaq6pzXmc59mSxQvpSLGUEwz8rASBStnK4x ZRL9psTu1w3w5swFCDKQF6At9Tk8SqGIpcipjnx9J0xInOYwI/XDOycqBIweZS7KsYWNfkN6VHPO yKF5uBFoi6A+0QFVn6pRzuwTjcAv2N/ZBybYP9nbSjN/RzvWGrZJUcgSYv8fbCgFtEbh+scf8T3H 28Fbbq6RWMGMI9qOAP5qdWQUFu3ZO3YemWuxrE9CffR9VKJQ/1j9qzOOPAh8B4z6rwuGIIes/v6I zoIyOkBRHaPr0F/mCdURPRv34Ju2U9F9tNdf/QbNU5o31L/RHJnfbI7p21nvqJUNNQF1UbctQJ9q lQIRLqy4Rp9qTxndgVQ653x1B21Qq0qjGcMnbvZy9nHWdJ9a5ZoOdnuXhrg7V1ldGrprnQFEc6Z7 XyWT3vs3pz5oC0hvlAjQjAyrKAXVH6B19Sn2y2EFlZxJ8tIezMhi83rqDCmqWOgIu66DtJSxWh02 z82Rx6oTM/XgMctTfaX50OtwYGvwvPMPbPny6+Uvn99dsSef319dXl9+bscS6oHNs4d+yhCT9qdQ aAuFMjC5kVR5Bgh7mF+8t62faF+KUcVQFOeEYB+l1qYd2oAltCUv1R+GmBjVRkaF3YLlyKYqioTb 0tcvX0u/a5RaE6UwmYq80xxLj7G4px62MS7SvdVHxSSwdLKSw1u2fHrAjnjCll/wWbLlJzqU7ecl jgu2RJPQt1/xkbIlVo4cydmSHWAEPz9ti3x5vFZNAJrBk8C5J6gU5vNgMtwvVjUwvOfKwcKLPaiQ U5XDo5wtURPyKGNLWR2BQR3hLbG9wJFiyzk+8JJ7+MDbIa2WrsTiZToy35mT5hJzO6Zq6NH71X31 L9FGNvTU7rUz66cMGuy4S1diERr9vnmc+SnzG+YpBvcCoIAN302X/HBQ1ShUhoqXORW/rXhgT6Fu yr1+fag8Cce8ovkwJ3/Ed+BDllCOqjsivCPaBtt0k/zN+9fCNYdGRigrpZ9jDvvt+J/4Elp6J7Ia 1tIUXpIQJbhAX1pEDApwA/xj5xiyb/ZGUffG5bOv7Jdr9CqUytIXn5zDVlNZRI+ONd5eYLcYmJxm i+EO4JkNuGrtFjCs9m+/XX357eqXd18v2dcv7P+uL9mzz18vrz5fwla072FmtzzeY6OBcNu9FPRe phIE3byJGQh6srahQ9m6Fck8kE2QMFwqbMVYh2ZDJPzt1bsPX6/Zu2vI5cPl1eXni0v2CcKGxD+y L1etssxClGWEkGtbQC4CbIERcedVbmi3LXGox8UvpCZ/v/zEvuD/V/jz3Wd6N+3zB6v8xrcYGEuq ITLD4sQUm6cbi+Z6i2rEbFV+/s8vV/9gv3xm0Pv/BVu5jmF1WkXfaodNacOwIgNt6OGfORW9UpEQ 7Zig6FhgINuCUT1cVhADI/R9GGiQCjMmGBtuzP7G0W+FGzBcHlcjs7nEGgPqgcKMBRufU1+jB5Md jhDYoknvzOWQ0obx1BCY/kC68b36zMHcsIK0tNC6w6m50jAO8zBz5KIzs3pYNreYFmmFHUxLJihb Ksl53UhLbipbn0c1mqSFMvT+WoDmAeZaw8dqTdqotUaxzR3/DeXNZsuaHvUl18fTkD1NRE2z/A/d r6lfxY40OzU/YfUBc7/5siZbBscrPAe8ynypG3tnXaAeROB8UkDZxSeraQlYCaOORmPrNzXwc7wM SOZGda4lbYi8JSojjb5a3NKBjNWB3GY1H31dSdE8pcARCLy5vf7hroibL5vf1e1nWqrf/Lhkl92o v0f0gM3WWsyWKDNGL9xXtHlPCkYmxtN5AiuEG/pKbL6rO5G5f6NMzaVapLNlrQX99tr8nMcVqnN8 QFOQ/0cf/6hEvG3SlKIwLRJ4wEyNkG9npnBdTWwC798w0/8Hr4+iMQplbmRzdHJlYW0KZW5kb2Jq CjEwOSAwIG9iago2OTc1CmVuZG9iagoxMDcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA5 MSAwIFIgL1Jlc291cmNlcyAxMTAgMCBSIC9Db250ZW50cyAxMDggMCBSIC9NZWRpYUJveApbMCAw IDU5NC45OSA4NDEuOThdID4+CmVuZG9iagoxMTAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEyLjEgNDYgMCBS Ci9GNS4xIDE1IDAgUiAvRjEuMSA5IDAgUiAvRjExLjAgMzYgMCBSIC9GNy4wIDE3IDAgUiAvRjgu MSAxOSAwIFIgL0YxMy4wIDQ3IDAgUgovRjIuMCAxMCAwIFIgL0Y5LjAgMjAgMCBSID4+ID4+CmVu ZG9iagoxMTIgMCBvYmoKPDwgL0xlbmd0aCAxMTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4Ac1cW1PbSBp9968QtrQ2DTTqi1otEm/GIk4GsIeQMMPsrJY8QOYhVdmqbP5/1Z6W LdlSnKZbQSHJA5cC6uj0953v2vocXAWfgyxgWUYzmfJAJjFlWslAiZTGCU+D/30IboL/BsenX1hw 9yWIy/9f7vBr5ieZiuPVtzZfCUVVLJgOdCypTpQe3H0K8usgWf3g+sP1p+D4FaMsYMH138FkbzgK o3C0H1x/DObXgPUQsIE/MCWoSAUXNbCgBDawAvuHOyRwNfDkSikqtI7TFqQmV4MWV+OomBT7Hlxt H+LA7RC1ojJO0sQLGPHiatuuBg52xRJFY5XZIQXXnwbbdnVwGEZH4ZAek7iYMEa4kMOQJDF3h9rB 0riKqVBx1mLPbml+7PlammBw6FjwFiS7pSmZhoc6jEh2cvLMnbEOjiDSjGoOBapEY+Wbdnh+jPna W61jXMZUSrkLUdvcnstpOCT/JFyyF158GXADD5HVKc1iKQILtrZs9MsWUynVqchsiNpsHfwyy6Nw Sk6LyTF5OSfGzF6509bFMaWmSaISG8ofy5sQMeVJ5sXba15MjkKy+verO2FlHBh4BvOMMh5/j6GJ hNNEw7U5z2jKMxUwJAsQcuQdmgrJVIf4tPmjIqOJULucs32QWdakavM3HhOY4lRJrgLuDqxfz9TI wlKdJEGaplQxpXdx1XbNvWE+yovJKJdDwiM5klQy8vtij/9xMydL3wSki6fGgmoJY2mitofQfpM1 HiuK3NhOZNvo8nBU7DftzjXfdkzVOMso0vU2U/bQ6ceUb+jkHE6QcDtTbZOb5t1oKsuSMoG0liVG feIU1t80qCZNbUyz74AUxABlhyQkxFXZTw6QVpXSYFUpdT+5ungbfLt446j7mGQPnlxVvA1M8TbN Z9PvIgrIvtzZUJkQwhBCHji7BqpHICr4PNjUtWWJUte8PEkQd5wRocgdTE6ekd/fysg/M/yq/LZx lTEqoQleXHWPQLVR2bjKhIHkbFQlWfmQzCJ5hPxw+secXIc6uigm0XFZipx7WZtvqSTRt+AstRLY lvnuBLqUvnUpkiYZlWipuITw7pDMmT6kXUKjy8NTETwAqaFdr+/vx/zXMm/dOzg4mJMb8+HZSXZ+ Vkw0WYzWGUcxGS7JabhEBkKKglLYAInlcBRJdjPfH7j2iLbzSsfmFdcaLp7K+rFcmlceTHfJhDKj QTBHy9m3zXEcUuMod36O4luECo5qKjM5mgc0D7Ja5+fnKRLNRZZwJ08p7dJLU3wzIlMVoGCHBHrg +r4I9pAHq4SmaPEiUNghNTz49GDsW3C2u8cDa06ExkbCdII0zQNVd5uqw5clompUmGh1Q+pcIAWs zIku94oC+lYUarH3p/mim3k51gAMfQ2VCMiWBWJbJLqbl4snsoRRpTQyJAukdr59dnL7ktznwxfk Hj0hNB7H+ZSiCYm4X1eh7kR2Eltkmiptm9+Tlp0ZMk30Rq1Ets92HT3dudrWWkejExyZZqz9jK67 q7oYHaY7gJQ+qGnNGcFwOZP5cLQxthuPuNnByDBZoVxjuNJ0DbuR+RHnm/NuMkyU7lmyO25+ZWSv n1/H2dnZK6R0CXpCy2EYzcniHLr3JTwmKHWWU1Lsy4hcTMMm/oFrE8Q1b0NvRsTGb9f4XfI2lBh4 gCkZSbI3XOYU2Wfo7jEdDp6nmmqWQRMbLD/lwXMdA5LeELcrYWof/PPw7wt07g9DOM19mIZsiq4g hmrk7G5uKG2etXXA3IHFTUOTcdSVfD2ZsbNozHRuJg0RFeTs1auX/bo4S1JAQ1s/9cDoQRvkurOL q0zSWMc7i8j2SRPj4ldnZ8/g4uNIHk5xvuekrM/+wsci0sXk4kiUmc7FSMAgSjcybePS8cfvMWrt t2DLKI/RGqqeysXxPYjuYJ8cHRj0itMa0sql7PZ5ihrXTHWMJxkPMpzPyZsLTKt7laTamZQWNJFO RoHK8szDfTqkFsy02hOGPRR3VB48bSNCgHHKLKqtFoW6CafrNA5eeU/27gzeU46GMUs/wqkiQi6o uGD/ivLhMJyT9/gG9hMOoU45Y3JOPuIbb6QYTkdy2HfDAx0lkcJY18/1c/gPIIkakov/FAUo4yG2 iKagbEXxrJj06jsCG0U6Rjeu4s4FaPSi1NC5h7l20KCNWyeSqrQakNo16L3RdRYeI06CzFLkDzz8 vANMEyZTYfzcA6YHcx3CJEMvKxXY3WlCas6J2mES3iwlM9nvDWakv5EF1NzEwF1j1ErgIQtzY54D p323lmTVfQvrIh5WfrKY1U/y9K4tFIZwGh3DJrl2syyDIGJO1q8tSqwlCLPy5oOtX1usqzKFzwSm TTs2KdumWMWcq3bMWTn0+/Nm6LnZYao9J2yCZgwl+vqZnt4ouU4MIrP06sxy3Y0qdyJ+I/fSVI/5 8IjA/z2MooNmbqSdo4OboZp0WGNdhBG6aHVymb27KrWnt11bppADJ1jtUR4gPXjrIuyI1oCESqEB yS7sXbRnLdU+63wcI8eEZZBqD2x+dPlOLDbaE2NtSFRm1qSr3b+txOfu2+LTa0ZWbiEKAR4boO3x ZTsTR8N+SP5d7Bf7YfQnPp++RRP6VC5DtsY9eHg1vUuojs2MARnvGvbTi6JgDIiwx1ZBclGZt/lI 1LnPOJzSKJ+VK2S9HnotiEmmaMarGtZ+6FsCPi6X2sqiO3t317MuYpgkmdCBD1Y/R/ftC0F2DCTZ gtR09HaW8aN0UWBuakZvTbrs2Pzo6qyLCZq5qaqsrQnpW7p4W+piMaHomJUV6670azPqKpOLfrMx TOlic/OnehoX5fEYHHbIbzhKwVhxVkNyUZ7FLKR5sZ/TXpWGoxulZdpC1jz6tqf0a40md9USC+3V +e0qEdrWeJCaxr2S2PAFY6udm01VevujWhPYY8Ids9ipfd9FbzrYHgIe1h/R3PPB5nfCvvJc52GJ xBUZ7JDsOuGvjK5s299lpm1vGoszHTKGEQ3aOt/oQ9Z+gwTn0a8EckyKkxQj7OoZXFSm7oy+v8hH IXqj6JGe9xudeYZrNQy3HSqcLtLT7/FjhoSbPhgkNSHZNads3Y3PyceLiKG9XAeZ+pD7uF65ScNw 84FhH92hWbGrP7a6ZkAOfhmFQ9NE6xU09jzNTj/inztovwP3zS/MOr/GPr8NUVvQy1HbHqYFOPgR Vj/KURKaEZWoQwjmBDuB9WW+RisNq0+PPI3HAjmWCIy/r1h1cXcPVjsI+0ZFIUUx+hIOxrkqZu+e mfWGlmr+FeZDM8sxHV8zzWlI1KrRhjEpps3iuOfxDWa5uEGlgmT1XE/PNC54GUTwKHembxaXH5SH AWxX2M7LSmg7CtyC8oDlkeduI3KdKCLXyBITbL5NVNvRySI/nLGQXGLbxvTzcKeZyGLfg7oOvrMR dtMhr53HXl9/mJrtPeSWGGoD7OFWUfMBBXdD1B9/Gci0mBUqiDXgn8ArsPKVYdpVQ3LJLC5FJLFc QVQ4MtdGUDEul+Y+RHn8wykDuzKakt9VUVxOzcW8cvWmz22L2hQk0hJcpnJ6t8MVJLTfvK1eF6hg ubDr4TTwbt+0ncVY9UpY0ERkT9vW20kYdV2dNxzk4fjsd6u33k7yQefHl2/aUwdoqc39JXQkdkTo r+SwLHNuz0xbZYFpfz1bv7kUYd2ItCSZz0PT6O23w4LLT7hprILqwX4CMcJGMSDBOBtc2wX9NBwJ uawySnBuOlgz7KuYiyYte31sQZfI0lGR/0wcbuzVjJVUZa92DlcZ5e3tibHX7bHDegFoWi/QXkfh Moxy+sLs2613Mf5z3q+h4kEygfmYXD/RT2Co2EnKBDYVK0guuv4G7VWpyy2gm+eXWMYoinXAnMnI XVY7JEoixeWBBG/l8IE72mRGvYLbhG5zmTbh600/u8GWhSVEclKNv/p5MxMuauGNEDrD+6fcsfll 597xG++mYBpleBOSPYBf5oceC+TbNYNjFYPJES6x4+x8UPUbuBnejgNI0gqpHbgROWasaj2brYTF 5Zhg9rZafYVAoqy+YOVl31ZosaZCXXwWeRrXuAXXZNTuFtuM/h8w3Dj6CmVuZHN0cmVhbQplbmRv YmoKMTEzIDAgb2JqCjMwNTUKZW5kb2JqCjExMSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDkxIDAgUiAvUmVzb3VyY2VzIDExNCAwIFIgL0NvbnRlbnRzIDExMiAwIFIgL01lZGlhQm94Clsw IDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5kb2JqCjExNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4xIDkgMCBS Cj4+ID4+CmVuZG9iagoxMTYgMCBvYmoKPDwgL0xlbmd0aCAxMTcgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4Ac1cW3PTSBp9969QZHnjdJJ236SWSLyAEmcmdrKBSSDFjCfUlGEf qGKrZvn/VXtaN0vaoHQLhJl5mIEC6uh0f+c736X523vt/e0lHk8SmigtPBUyyuNIeZHUlIVCe//9 6N17//FmZ1+4t/nisezfLxv8NvMrecRY/lPbH8mIRkzy2IuZonEYxaPNZy+988L8Fxb/ufvszS44 5R737v7tTff8cTAJxgfe3SdvcQdYTwEbuQOLJJVaClkB8zJgo05g/7CHBK5GjlxFEZVxzHQLUpOr UYur/cl6uj5w4Kp+iCO7Q4wjqlioQydgxImr+r0aWdwrHkaURUk3JO/u86h+rw6Pgslx4NMZYesp 50RI5QckZMIeao+bJiJGZcSSFnvdN82NPdebJjkCmknRgtR90yKlg6M4mJDk2bMTe8Z6BILUCY0F FKgUjTw2u+G5MeZ63yodE4pRpdRjiNrX7VTNA5/8kwjFnzvxZcCNHEQ21jRhSnod2NqyMSxbPNI0 1jLpQtRm6/DFy3QSzMnZejoj5wtirtmFPW19AlPFNAyjsAvlj+VNSkZFmDjx9otYT48Dkv/zqz1h WR4YOSbzhHLBvuWiyVDQMEZoC5FQLZLI4zALEHL4jphKxaMe+Wn7h8qEhjJ6LDjbB5m8blK1/TO+ J7BI0EiJyBP2wIaNzErHtNY04lH8GFft0OwPyRhEpHM7i6jDhCpYxK9Ayi3iKLeI5JfTO/b64eHy V0KuqFzxd5PU94MFeb8k66l/Ta6WJsnP/WCyIPenN4KIiVofpDwg6wM1Iev16jpV2S89GNnazPrV tPW/DDdAaO2VH2fjfx347iF7Ek4ckEQFKee724/8mV4HijDlrw9gzX0Kof4tHcthkcYoGXQchp6G UmsliqzbjfQs9dMj2DsDdjxR/H5Brm72ye3DguDKEHNnFlXoj56qLHocuRAR1XFSgd79iQsB+uI4 qiDZnPirFZ+ZHPx6WbE1RB0mYBVQN0onbA7XDgfo7I7LmlUjHYdxee2esJ+ZIJ0kDxAkY/gW5NUS N49KP33Hg9TPf5xJ09myiX/0nWtunijKw1B5JX6bG/gh9Qux3J/56+lRSsl7NXeoK3sokYhDKhMY 1xKozb1scvdUv8L17AW8tExk3ILUffaZLKbHK5Ti41T5JtWMFVWc/PEy+3GWcQaNoq1ScpROj6fQ tgNiSk2uU5z1OLDHlumhm2vkAuWJQrqxh+bWZ3Gt5TjCOgkjKPTXEbUtUAwvEVw78rRtldm1NCQc scbVs4flFgx1omycGUTEIIKQdCJqGLMPihZR0I6KPXgHNUFqNjGBrJxlYwgmlLFINZtlQTDS8gCJ WcYcQQk3kX+NjSo68NtD/7ZmnHGq2aPGtx21ufE92RjjmzUY0JE5rpJN3QcvciMsluTL7F2qwTuc cNb4CiaDel4j64zFIDr/rN0TbVQdiHiJ6LEKo020mARbr5sp+FgG5CqYz43E2ytBj3tRqXmUQKmS sqDt9r17fjpOi9CrEtCbqz3x9n7rd58Mqx5oeSxozKT0XNA6ENjDwXHDIBNJC1J3Fs/1aHOJuFmv jlfzsXG/lSSBuackqQd3qAxpyGE3fh7uKlGKNM5Vlpevm7tClR5u/1+V7tdrGKIArVAakEMd+GOC jhV9nnWt2nE1qC5J1OIM45Xyw3avS6YUZwwdyBKSjQHuCnSHsOpxW7e6hL4W54mwgZuH1cPtjwwr bsIqTjC5dADqwF0PSdqGlZJwnyV3NmF1cWvCqtXlQi6/QT4aB5x8PN3Lm1o3AQ9eZjOtaGUmNXMo /5DNLZEIOHsmvKj4pt1HlEDtm8gEgtqguTt1ZlcULC/IfkCrGdfA0q8YoywWiH0HpD/qjgoY/8Ty jtpboax4dCuKZIzukNAwFx2Q2sVa1oq5ONkgan4P/GPTAr5a2sPsoYwc6FSITlETZve1Q7Ma/SB/ 9Xwe8PV0Qc5MwwiNg+cS/ReMqhfkBj/zezDHNgRf+dfDBrNkmL+g+iy/YPexLDEaklpHFSSbdGNI zLps+0tyleaHn/X/Bz3/bWbkqH1iVZRy3ecPGzTjaj29Jnd5XZyr+PtlcrshWcO95twH6VRzRUMR whEVqHd/5oJHBhLi3YHIXL9PNgtyF8ST1Xo6yTrXD8PGvFmigMdAkeEA9QcJeJhENBHlNbQyGSfG ZITBBBOz+aCxwkFXiHGE1wTZHStuHUHXri/H7Dk0dXYTUjdvHwKMG41C36UBRyMVXZjTUnw+LM0e wzw1i2xwah/9NOt9FbwO094SiaSh2TMqP+IniOYERx2xsIJko+CnwVytJigW965RLIK4FDtHb2By 3/7LIXp6JPFKxEMsvAnOrMaNnwIEDIYlVzN/vJ6+KKeNtwP3XLAhlXDNPReoDuz1KHCw/wlIEWKo wV53DOXKbS83dQdpubwoGHZCEt6mqhvXCWqBV7ARPyqXZH0gBb1ukteticOeZ1WwYiMD279lNHTz lvWBNpfPXiOXvA84n2MCf7Qgn4qlDPSiX2Hlcl6uZFQGKOsD3QQvxsPWq+hoSWz9euUn/QQKqRUg YRZVQrJRSExWNLJ0Y5JiSDeTFCy0om1Zsz5DGEesaVGeYKGgRL17IrfXVWECinVIGyKL63p5gesq AuTquSoG9fWu5aBZm2tElzFDBWwbJh3MUI80aIScm+Z5CcmGyXw+Sj4d/iFO9/4k2yngH/FfAW2u EXzvfQfTRcWKi6gA23DoIJ49OJQMDsKsfblwWFSBxWh0c3l5sRgW5dbwYD2Ro9B+5G1GeyxW75DV VObJ4UgfR4GtLyUSkGgPz4GwupfANp/NiH4rMoJThl3VRwhrN6Nyjdmcm25UXWPyLgVDRgx8P/Xt PVCP68hj7BVrjJnCr+NuH/SxydKHPnpRGNwcwYnPs/bEoDgFnsBEOkRescc57IkLmB8ggrZ8HVH7 xDE+xKgYpYvZhAiuizpmPDMlIdZtjjM2HWD3OPBtZJseWnVTu/1k6pPaiHvQg8bIE5vkOOcGvCe8 pT2iHqHN8a4DXVyUqh2Q2ifdOYoztc0Gcd8YfN0uq68YwphJKaiOsElSfsVPkArLbUqFaRE3C/4W D+1y0Tw/f3zw1dhQzJeSH9m+G7aUwJwpjEPulV+1e6LxmAKQlK4g2RD9Zv89xiubomVu/v/2bbm2 WN3UJ5P7tyiUMltZZh3d4lpkZSJLNfot6/X1NbYK5sHAzcowpgletnouMB20vY8twntCQML73AZz 3eL51WW8QQ9ZKG329ttQu9NQbT1wAwVYkPrDw5p+mlv53UsJjb65RGIqud19WFeeU+HJMrblrQIl 18+LS6Ofh/w3dGLyFcF73AMf9VjdlTTTPqnltIEVFDuPMFblZ+2eadNA16GJdQem26t22VrrBswX zZhGfH3v61rZPMye8ZRRWL2uR3vofOtChtB2juoXuVHhbxDIYdlo+7CiuY0iiYZbIux3bTcXt+eI omzXdkFCTHju97FnyTGqx5OzY7PMhr3/I9M9yue3dQ896PaNNgskeAKvik/6CSIIDVZAgitqsNyt 9zXB2b6cKCdmpJoGFYE0zOxsG0hCot6LlQ2XtflUbVA/SEDhSVmM9XVPFfB2H1Acb8piiZ5RE1K3 CzElUUMQn3q+U71YsBz2cIW/qiKM4IEbRHWjMhFu1Dp/7zawNppxFN7pJy2E3SHiRprr9HurjQzj WuxO57erm7TCYZyb9254VHD0Ms5MhtFHtDnkrDYMr3pcWUvJbC2ewbhn+7+DOwwmMH3GX16SfZdN UDtQ/S1VD569wcSj02VR9dQh/Q+M4gtJCmVuZHN0cmVhbQplbmRvYmoKMTE3IDAgb2JqCjI4NTcK ZW5kb2JqCjExNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDkxIDAgUiAvUmVzb3VyY2Vz IDExOCAwIFIgL0NvbnRlbnRzIDExNiAwIFIgL01lZGlhQm94ClswIDAgNTk0Ljk5IDg0MS45OF0g Pj4KZW5kb2JqCjExOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4xIDkgMCBSCj4+ID4+CmVuZG9iagoxMjAg MCBvYmoKPDwgL0xlbmd0aCAxMjEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 Ac1dW1PbSBp9968QsrwYBRr1TVKzeDMo41wwLCEhoXbiJTVFMg9bNVs1m/9ftad1sayOaXfLiGTm gYonIYfz9Xe/zF/BdfBXoAKqFFEiY4GQCaF5KoKUZySRLAv+9zW4Df4bHL/4RoP7b0FS/vvtHn9M /06aJkn1UfsrnpI04TQP8kSQXKb56P7PoLgJZPUb6y83fwbHLymhAQ1u/gime+E4mkTjg+DmP8H8 BrC2ARv5A0s54RlnfAUsKIGNrMD+5g4JXI08uUpTwvM8yQxIXa5GBlf7k+V0eeDB1boQR25CzFMi EplJL2CxF1fr72rk8K6oTEmSKjuk4ObP0fq7enYYTY6ikBzHyXJKacy4CKNYJswdao+XxtKE8DRR Bnv2l+bHnu9L4xQKnXBmQLK/tFRk0WEeTWJ1cvJ3d8Z6KALPFMkZLFBjNCrdtMPzY8z3va3sGBMJ EUJsQmQ+t1Mxi8L4HzET9LkXXxrcyMPI5hlRieCBBZtpNoZli6YZyTOubIhMtp79clZMoln8Yjk9 jn+dx/qZvXSnrY9iipxImUobyqfljfOEMKm8eHvFltOjKK7+ee1OWOkHRp7OXBHKkl0eGpeMyByq zZgiGVNpQBEswJAj7sgJFzTt4Z/ab8oVkTzdpJymINV9l6r2ezwmsJSRVLA0YO7AhtXMHFFYlksZ ZFlGUprmm7gyVfMims0KEfZE5hhkUAqPzoQdmSnF04hqc8EmYiyIoPGHFxen7OPtPD69SeL7l7/e zeOL6Gy88lu/nq+kPtoWVK4/RNdolyrCE5Gv2HWJdj1o7WHkVo4rk4oIBOCVwLdEH6/A393J9ZvX cXxB+IL+a1KEYTSPP5/P49vlMv4aFssDMTmMT6OZWExIFKfL6WEUf/h6mn6M9X86GLkG7z14Zgp6 lXAeND/Uj+eZKQFIDKL34LkNSJfT8DL+NOYIr36LKF290iFSH67g9/JceEEdNvVpzRJ8cibYxvjK VP5voXgXQr8nWUGiWa30dyeDcocsl+SJhJg7QO3qdP1mPiwoxeFLtTp4gPIwO9BQ3wyDKglIWh06 kOwh/FtowWI5nRyXKUZrqrcqQQ+ATCD+kEggfQD6cdY7x8gQBsp8sxKYvjmOS1v95volbPUVF4cz Ec7jF+dxaVHense/FbqakovxWBzCeJ9GWTGLLuOkgNbEXwRZTsfw7YOaa04pKhuwN/XP9eOtNaco /+Qc0u9QbVfjGzg8sFW6N4QcEbI7OL5BNbu1i4gs8sZ527VoLyxdcyXXeB9fl9O4wd4KfMjiGkN9 AXqlgswdtgeRRsTgUi9iAAJEEPjDiEzV+pT/HpFx/IHt7d+4S7kG55O/s1SRhHqx5eeOfS0Rai8E 4RWstztbXz41cfcdjNE8vonySS9j3ifIhbehSWqDawYPwz63NupOKMkSpyyrMuRKqdc9sTkmWjli Z5WgOJM9jO07tj7DLV8WyACukAGk0bux9jLLJX7xXX5QOp7P5/HVDPn88iAKi6P5sO4FrQWUcWjz Azm5l9sv4uLqn/gRPMju8zIF5J8iMnPnuoeJ7mFzeCbRABEr0jbVAcxXMKzR4RkKQLl2Gg9zZZro sfA2zG33qvQb9u4VOh9Md2TskKrm1ahqXvUnadVPG1n6abkiTEmYOitJTTttpNtpdYbk8dANB6uB gSwrVatIBbaFKLW5CAfxdbi6QvMqnKGEU4agzhHJOjxHo0d1VU+pLLDBM997U1ZqUkvYZm30FkeL 2dg3RelhOxiqh7lEXNDFbA9S/aTsm9at/FqKCCHnm6Vs0ugHyTdW4bmuu2Q8sEEy7UaZMyl1/fp7 96W7NfP4LTybu2npIVyaCZIIyNaDyE2eNb7dL2YErTlU6I6Ghcx03SiTJtP299jDm/Vgk3NWjyp0 6LRD87PU3qrCJWEJNdmy5247+DOXLIgLThJlh2Sqih9L69rr4ja4SBG5Z3Y9MN3GIzi07b6/dWgw w5QqtilCMsnqOLT4g44xP5YVymgyi7/OtIqixjuoYUHRDbmbtiwd3HZV8DAccL6+qsBQZAEkDBJ1 INlVYf84REsBNarPAt42EahqFEcLBAw6Vljr+Ox/TsqOzxqpiJ8eeYypfQySojSXCpccQ/eg7uBk Bi7+MnS+skQGyIBKaE4NnqeLYigajTJXEL4PvjVpbh9K832PbRSDh8l5q9p5GYKjuq8D3ipWhe5X U2mfgimmrI54MD2vvoT4woIpMpB/Bzfngw2qSYmWttIWsgN2VKEM6i8VWFj3eoQucCewh7uVyNSU ZMwF0zqBr0AZDaZob2ken1UEwvboX2EIS9PJ8UUEU3Iw0h8eVx8m+II/B0XSH+5XX5YH1afvOp/W 37T+PeU3HTV/ov57j/AH8Dc132Y6sAAxFonxOQwBOAhwRRZm+gaVYKsCaLtLntUzEz/SS6wgScSZ PGsg2b3Eqz13mtbTRjT0XQImwdDFAp7AhskMAoaNmAQaayLJ2TZInUR7/zxHAS+MZr3ZKisA22oA epQnQ5fi52Er58gLmPRj6ygSZ5Mi24Gr7fUSSpFAM0q3cdUR424vC17t272ltkSpRE6PSawt4usU l+guFbjS3eqy0qidGC+Hf1fT5JRBgHrkzBET5sdH00egyTLSThlSFoyLrSC5xIKziPiU9Xv4ZIrc DiO6pvTsFl1WVgHzUqh3fInOCgQ1rnM7PTCyBJOqepGgK007xtnzQje00XpYayiUk0hNPWQN8+OH /pyhnilpi9lF3J2mCAamLi8LnbZg6nw903p8sKs8BTOWJBfCad3ii4cK9xA6BqNklqCZ2GBySVDq sQTkeUW2nOqJfRHOisuozv/0tM9K6kNM8ukONuakIHUPIi99dzF6sMkQJgkhxQqYC5t+BtE3ndLD rQI1WAOSPXDbKR5xLPozbNQkFHsrjRA3lXDMarUfV+v1LpeAsmz167UjGyQzoKzikdV7dxmH8sYF LU3Ud8+qK0MT17ARki43pxn2ZrZQ9YQREkfTLc1laxU2PSiw9JQREk9yotANdKOpLA8MHSHpeS+F WZtGcC4eEwGS+wPvYTc5ymRcV3EbUD/ebnIGH8NNS95VOdM6nVzHH96JyfO4COOziTjCFNrs45ov 3GobelDXBhUo5VHMt7tQ93ZBvcc4e2DT+QHaoxCrB7Y2dNhKV49qN2USRkLXDDqQ7HL1g+Rr3dvS Cip3MBYbx6tN675DacWlWNCWVjww9XfOZUl3S/2iLa3YIXU8zv55EY19qnVGGcoFWLkZzLGJLT2A 7cbVtmIBRhYRH2PVxQlSQMtJlIhMip6ryusbOJYaBqJ1vYiO+MqFqRrWIzBlKWFgHoaqVKSukMoS xvIAuYS7Q9zwpkoBWmBRxDIUC3desA4j7Xxex+Vq6zyWm+b/2gGKMj/HkGAzMLj28zx+6qu9qeSY jGok7xJ1eJjdHs6JY+gIkEyK7eWO2xtIvuK5mjRfY21LK6wHxNa3Y0+Dgb0N5xnMGKTdWirX6HVT e1G2tsu7DeHAhxsYRvezXKcF7og9xGxoklNOh7opEME6P4zIdK4vFnRcHEaXRV8td06BsVHMUzzB h7GZ8kVtxbuSUdPmNfWO4coMhVQfaP0ttZMgMVyZsRzO42GyTEHu5vxdUPEEK9MJtfJkourPk0s4 whP0pEsna+WpEyY9husfWSdQUVXBaCw2uuzS66DajadtMRJHp4CjLu+EqI5FSsdfmX93w28YLZfw myOAwwqt1YziVT0lWxjdS2mOiNLhVdVsnbzfgST91Muh5ge7T1zvSmAd1RFSGbnV+fnuuGxRbrPF j849kfpowga3vZJezZVPb+e7B7WdK6xkizTPEX+5YarI2p0mS6cONU1A0iFuDcklJHyqqgo8H8n1 3YsGnGtVxZ2yHvEgxc2vrAxZO1K0h6xPMAuvx6WzBDMhPmz5hX2+bY+2qIIlOY6kc5MSmrFVueR1 fa3usK37NgpDBM+zeZwgj2IR1nTL5V09e16mTtji/Q3zjuWHt1UnbBwNukqlF/8kgo0Aawflz+Si MR4093iRDJKXApsbDSQXPXn2yzhCvxB7zUO2s/UWcSIwBucDbRaPhR4CxlhwdVVlL0RvuB5rHRRu m+uhZZBi8cCFyWYHJv5wscfq0x5DckpxICiVGGeVHiA9XiA8m6+iU4nTHiYgezl3uZzNoskYe/Z7 l1E4LsbH8btizFG0v5pgeQifp9FYl1KasxXaJJRzwiOng4cP+2fLJUZ9X0kX7Gpif7xq8wzjt0LH xx6yXp2hexpdEehCokzm1PPAxTJ1PigsLDnrlTAR+MAaVjtWbhCzR+gtNEzZ9aN0g/d3J/f6wBBO C02igvDqvNCX5XQGl3jROMHkPL4YT1ApIc+xfnwLKxRfRTQ6w+3G42F9Ia6q5Bmavc0P9uMVBpuf GhJfQXKx4Pu4+IE7FafRHwsc2DuEOZpV4cWgL3XlbAQSTQw/b0hQzNjI2PGoty71Kxl4gyLHKjTH WpQ7VD+V8m3XUXQxcH1BWQCZBZ/yaiLsz3sP+7PuRFzLiSiyZ/pI289CVWt9sF2Co8SW48L1fnZ1 ZuHkjfK9ldgePnap2uWJ7kvj6I1wBmbuolZaenquT2JOZlyfrC0P+Kzrsb601oZjj99VwfY7Tj+n +hg0+P0JLCAqMgk6PA/TalqVtW6FwCWkX8blzTq6KNfI1rgbsLcicDOW4/i1i7XWYWLcNFLg6QgP BRVHhT5wNihafbELa44wOh5o/eygd+Ct0M2lWB3rQrKHFuXWHdQbO9xIop/qAo2+SJgJ1Ce6ULfU TdwF2iNtaU0jY4Q59vZq6/i+vCaG05pUTKqbL98NX3dGnPVdyLpkMWxMhowhTzFbg6y7/Jl+Aouk N85T/Ug7NNslfwFrHh4ujtDp1TFtRBYYjDjG/bZJpAs+nfgM480DnCpt4zMM60lso7gw2Y0hu77n 8e2nLgUodONEjXCTdzetvZ9B8g7MUAlQWCeyQjJDs9oBeen6CphjXEbRuVQsp1ZgJlerO/g6vniu 2/iVCi+nZ1gEOWqunpy8fzms5+Ho90DOpqDtGuQnaF/Pw1EGh6BhZzzeXm9/08O44//HoE/G2V+i KfB1zv4PaC/oQQplbmRzdHJlYW0KZW5kb2JqCjEyMSAwIG9iagozODMwCmVuZG9iagoxMTkgMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA5MSAwIFIgL1Jlc291cmNlcyAxMjIgMCBSIC9Db250 ZW50cyAxMjAgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThdID4+CmVuZG9iagoxMjIg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAg UiA+PiAvRm9udCA8PCAvRjEyLjEgNDYgMCBSCi9GMS4xIDkgMCBSIC9GMTMuMCA0NyAwIFIgPj4g Pj4KZW5kb2JqCjEyNSAwIG9iago8PCAvTGVuZ3RoIDEyNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngBzVzvc5tIEv2uvwIDOstja8z8YICsuUQkyiaWVN71OsndRZutLcdbdanK Ve2l7v+/NzAgQWw8g4Oztx+IEEaPnu7Xr7uH+9P72fvTyzyWZTSTCfdkHFGWKukpkdAo5on33xvv nfcf7/T5F+Zdf/Gi8r8v1/gzfSVTUVSd2n0SiqpIsNRLI0nTWKWT689eceXF1YXmcPXZO33JKPOY d/WHNzvwg3AaBkfe1SdveQVY9wGbuANTgopEcNEA80pgk15gf7OHBFtNHG2lFBVpGiUdSG1bTTq2 OpxuZ9sjB1vtL+LEbhFTRWUUJ7ETMOJkq32/mlj4FYsVjVTWD8m7+jzZ96vjk3A6D316SqLtjDHC hfRDEkfcHuoAT+MqokJFWcd6/Z7mZj1XTxMMAR0J3oHU72lKJuFJGk5J9uTJD/YWGxAIIsloysFA NWlUsdkPz81irv7W8BiXEZVS3oao625nMg998nfCJXvqZC8NbuJAsmlCs0gKrwdblzbGtRZTCU0T kfUh6lrr+NmimIY5eb6dnZIXS6Ld7KW92YYEpkxpHKu4D+Xj2k2IiPI4c7Lbj3w7m4ek+t8re4OV eWDimMwzynj0EEcTMadxitDmPKMJz5THIBZA5NAdKRWSqQH5aXdTkdFYqNuCs7uQ2Ye2qXb3+JbA FKdKcuVxe2DjRmbDY0mSUMVUeputuqE5HJIWiEjndhIxiTMqIRHvgFRJxEklEX88u4o+PHnx4hVZ I5XLy/B0SX46X5L/Cblakt/Ol+3V7VO1A5iDxSnVwrgPcdfhyPEUasNfEg6Y25m/AUpykcPnt0eh X8yXDlYeAJkniqZCOEF+dwFx6ecLOQ3IR9Aycv86pKtpEZySN6MaWKSCRjJVHbj9muni4/rtuEZM UcMkaRx7CVJHIrmRAf2w1mGeF9InZ2G+OlkE+p+XRQA/DcYFyzJEuEiZI9hpEk5HXVvOsbZp0oHV L+7cCi9Xcce5oixCkdpe1jakLimui01I1sF2FoTvlgR0RDQfgYUQMqvtbHpa6uTzUU0poLOYcvRH B68bot3rgj+BlonTOkTatvyKG0s6f/3y+hUhCexH/lX8/hQsuT2vmPLTOfk0qiEZ2gFJFIPRW6j7 A/s0DVm+JO+uwJIn4aWcPiXbIzlFoCMljQqXKwixNAI9OsB1iyHXkhLlGmWZdsUWpP51vyhOQnIR PnNvX7iUR4IxKuKku7j90NyixJVxBEP7KQYH9hirSzgov6fkgJObvPDnJBBgH5NZRvW1Xc5jqMpv V2fdeD7wi6AAM+pcx6cykFQy8mZ9wN++G1mYpZymkZY59mDHXWmm7RfxrA9Rd6XLZAI2RDJZoUGl +y3no64xRx5RCs3Qv4zZdnVKxMDMd9UErfbe8IV0KlMUtGks70LUqlIehgiovlxPLHrrCh3GtEGk VNmWN4eyXRzr1voErfX33mx15M2VNxM4xM3Br05uj6qzaXWY48C9GaS+vhSqUH8q/34yQ0drLpqT 5ruD6kpkGv0TeHp9MN9dVp/ML72trjw8muhbmx/aznBWejNzTYRPWfOpxhbiLH4YKUNfam6OdDuX k9kpDrhdfR9zqbmdeSjzF+hg6ktV6zYNxokGbn7CWKq+tzGR+dIgN3dLcDeYyPxg+UuT2gzHt2LD 7//qXZ2PNuYQaFdyjq5Kj49U7F36SDl+AW7bwct+swYTIZvOfRPZSkIqpmhC3z4R+i6hzWM0RZKm gZSWkRRXh2rwApVTtSAQSj9hSeGKermx6tojdp9Kd2XwRe0vOGrXwreH1eGiOizg/jipHR2XYAyh 72Mu0W4HBzeftIPjSu2EuKR0cH00N9eRJiYz7WJ7Z02Imj99Ut2h/hPj+Ob2y+pLA2QOWDsg+sfs fbTjEWX7554GEEtjdO2i2FP95tceAfObIaF+kIFuagNq56ZQjxht3uGlbbo/hjkHYyp9rZfwJQQY WsTCUxaYKsKfuan+fR1b4qmWbrIb6JazuWbYi25uKhMU83aIQC+T2WvUdWQTJgUNCaql7WyxYAU1 anH92/ubj4ckXy3KrlOIiZ29SYe0xQQ6eZFifQ/QVbfVCBGIGdNKvNge4SHIKoc8p3LFNmSKAjCX /naWslMSPluEtGn1TO4fZn8VQcYxbKbsCmoJnQxlM2UPJElDIE9ZSPDvBdvOsCJ4kvLJqlJWhGxR dqvKeqNatPOjyUN9vOdRdHcoRhfYc3kUB501xEdAS4DEG0gVF/Q3B9YSpe3v6JXmm4LqQignYjtL QjjHfAVTV6fmuqjztReNatSGzOIMTRmVWu3CCESRn48afGCPLOER82pYNoZ1WOuHtK9i9DO4nkHf ok66hEAewPs2kqnh/T5Q3SLyYcR/39CmIf57ILXyY0YOS9rPwSaIAEI1UQYhOQk36BaQvGpn5OAg TEfCZxQX+RhtbmerTSGXJEHHVZZf/gN5I0DbyAxSqsDSHZFHiiLFqMqktGFZkOkCHFswDE1GDaZE UhVjqurFBp1VMIH4wxxN7JQVuditAE5jQS51ixv92GkRYuKDORVObjYY0mOljOmpPDlZ+WX6RjbX HarFtMCfYFXRqnqk5cA+tcyK0vww0G3aXOsO7S7lRjOcXJJbdMdemgcPjprzVApFJcCD1k/iwIJD Ml6iBR/m1hUgGw60y3ejRsAuy+miV0FDWGzp22Xg8fNdJrVVsY8ydgDosNIPynccpVVU2+ye3vij 5bseUN8r3/VDauW7n8mxv1nIwg/ymmCmIZVzv/hnSHTKYyQPplB/ICSQqy52KtLZCxP0//o2Lwwo FvROAJZgMIdsUS65ZRpjLD8n5ABANXWi2ikruMVU6rys6zh2iT0C+WORPkpgaA8r2n/qy0utOULC ZF1oaoPrM1VNs9T/9m9/sLqmqxcOV56Mmw8EBJ/I0BmLHR7SgScGZISGW2UmKBfM6OL+GshJFw8A 1ehiF1Buuth1DNro4jakfj69JrudyWXxjV2QN+sLXZ6fQH09DTdVDQ5JtjZhd3OmSFE57Fn4xwoa blSFIrikSYyBZf1YNpzhYOkBiy94QpMEM/Aakk22vzk7KKlWR/6B+vXg4vh8j2vvef1hCMgMmxp1 tLiAdIjkh2R8mcQ0SupI7vdQp0ju5CSnCrcP1HfK+PdAamX8D+SjzjCsk93raG6y/2Zct+OR3p6m hNfGfg9b20fCg9wOb25kzNLtnCDtN69tnA6tXxXxBFbqgdR1ugdIX5uxwy6lOWByINpObOrWsnWr 5x4ztQLhl6bVU/t+02hGVqNojh8V89W0zmyaj4XumEJs+QH2zm2PpvKEXIqCilKVlV9WknncRFdv X5OYTrLM7n21SsS/yd/q1rmv0/YmxBtsJ4Uf7gU6Wv/fXMszoBRSxJ4LXIf8MiTlNRbkKY1EvWHo Hu5xCasBoHZh5QDKLayGK8UWpP48/GJPKbYLSNPAavleiz0n37qMlFy/wJF60uC3kYQmrj9KqNty z2eWZS2UvcXugIUX2Nob4W3WBqWNSnyFOvewLM/Xpjx/vt3+W8f1uFibyMHreYLXW2f7I2efSjd4 gYoGmDmayqCe19Uz6VEYSL9IG+FdCGlAW7nB49hR4E1mpuzs6KRwBzhiw0AuoB6JgdqQ+hnoB93T sl++fb1h+bYxyhIecWwHcYFlumyVYNhI4ssAk9a6ZbPrrN1KmnhNc9NR7BjgkwW6Wo8jNvDaN14q teplada8fvnLi1fjVhAp5sSxkJ5BZjMBcCDHfa9w3TYmMJvg6V3bL9u7xlxURQeTk1jvx9QSxm4h vV/SNPtxeraENu0nG0Rmh9DLr7vUyHSNXK+Gq3v6u25Zl51f/WYTRHx6utP01d6GkTuk8E9kSM88 5l8p52AJGL/VPb/btgH9busdmLrl7cPc07qU7EfUCpjXT5pS0mhc9f7C7KXR//cN6SoI8JrBjuLL Dmq5MWv3FsLI3qjfH8Pb7uapXL3x//VtY3QKZW5kc3RyZWFtCmVuZG9iagoxMjYgMCBvYmoKMjk3 NwplbmRvYmoKMTIzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTI0IDAgUiAvUmVzb3Vy Y2VzIDEyNyAwIFIgL0NvbnRlbnRzIDEyNSAwIFIgL01lZGlhQm94ClswIDAgNTk0Ljk5IDg0MS45 OF0gPj4KZW5kb2JqCjEyNyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JT cGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMTIuMSA0NiAwIFIKL0Y1LjEgMTUgMCBS IC9GMS4xIDkgMCBSID4+ID4+CmVuZG9iagoxMjkgMCBvYmoKPDwgL0xlbmd0aCAxMzAgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1ba3PTSBb97l8hrNbE6Tht9UPdUhgtY0EA E7wUEGB3UcGHhK3arWJ2Z/n/VXtaD9vyJnK3Z6UJfKAcktTp2/eee+6jfwveBr8FWcCzjGXKiEAl MeOpVoGWhsWJMMF/vgWfgl+DxdMfPLj5EcTV3x83+DH7nVzHcf2l7SepmY4lT4M0VixNdDq5+R4U 10FSf2Pzz/X3YPGcMx7w4PrvwezRNCQRCU+D638Gl9eAdQjYxB+YlkwaKeQGWFABm/QC+8kdEmw1 8bSV1kymaWz2IHVtNdmz1UlUzspTD1vtXuLE7RJTzVScmMQLGPWy1a5fTRz8iieaxTrrhxRcf5/s +tXZnETnZMoWNC5nnFMh1ZTQJBbuUI/wNKFjJnWc7Vmv39P8rOfraZIjoGMp9iD1e5pWhsxTEtHs 4uKxu8WOCARpMpYKMFBLGnVs9sPzs5ivv214TKiYKaXuQrTvbj+rnEzpn6hQ/ImXvSy4iQfJpoZl sZJBD7Z92hjWWlwblhqZ9SHat9bZL8siIjl9Ws4W9NkltW723N1sxwSmSlmS6KQP5bh2kzJmIsm8 7PZClLNzQus/L90NVuWBiWcyzxgX8e9xNJkIlqQIbSEyZkSmAw6xACKH7kiZVFwfkZ+2v1RmLJH6 ruDcv8jsfddU29/x/wSmBdNK6EC4Axs2Mjc8Zoxhmuv0Llvth+bxkKxARDp3k4gmyZiCRLwHUi0R J7VEpGcn3fs7RrdO7tetChkI0SgDJ1ABn1jd6icPd1PQjpSebMVzpYM2whqRkyqTGldIkNKT2WpF yxJSh2ykT04iUzAQbb4krChPC7KmxZS++Pk6/nLxdvWSPv32+g1NCY0IU+fT4q9k/cqaeuKkxHej 17VEEIZxMEJraZcKwcMjj0gM2yBRKEp4ImqPPKDYfDzyCFBbj/QA5eeRvjJy65EdSP06bZXRs+l6 qYppmF/SqtSbk3VRzkJCT0jtmuVsuqava0elIlKmWJMI0qDxzGVEluUsguOGikr7zZzQ04lrtXiM j7ZlrEGGTlKhXJyUK4ZTFWqKUAJkiMGwjjVShBI6mhU4LVURPSeKlqcqmr8a9BBCxMhGmgc+hxgr 0rhgSohGVz+USPMANVakdSAdiLS39IyD+BFodejoz28oU1NDopB+qL0PAXTunkiPoC3BNYqTVAem g7z/hhEPTVgAXwX0IwIkUnOKwKlDharylG4jzH590ODZ5oSYMxM79bHWBH2seTFtWGBOmCWrIp/T /Gq55Mi8w2ZWbjTjmcoC4455pHjXqWSJulPq7Sv13yP1XFpJm8Tag2lfEftF+77SO6SIN3m1H1FH EK9uIPSmC3hWEZazFAlxGxz3++HTsvyH1XpXufXFQTMo+r/SivvmTC4JdCxf1AkTMfrcDh1gL2c8 gi63zugBys8bj1Z5ugPpQO750oq5S1QXlgbv0nh/AcuXM4ZqJKdTEr5T0ZOcvv76+dvtSUWRComq nNE5WPMKHVs6J6FU65GIXieKaSO1i6ciTX1CezSKIFQ/UY9u/BEukgkWC5NgLNMAdPFbpMctH1RJ tGt22nIEyV9R+jfIU+TZWSNRK226l3CLfKxrUJKhPSRcrmFZlwrrS2BH0WuLW77ObXlrjywenVwP WsnyRDIhjQm0B2aP4D3CWeycRCToQLWQXJzl9nPVDrhZrZ6/hCVRi1XdgdVbfGxrsDrHwO+RPbad hIFziB1ESbQK28O4+MRYSUQkzGTZw2oVaA9QHn6IAvr4JNKBdCCJvG+TCKYCECpWNduUQKbrQWsW rlUtCB6O/exERQgugy6kfvvlizwkc2TNcpZf2XbJJgWA479NGerAcobsvKi53Wbh0FYodHVxQefD ykFkMXTGEcqNPziF8js0TsaKZ56wOG0rlP5y9fmXf9m6GulmjekyaRUMmLGcGViY12Rp0yhdFzl6 VyGTw1KlkLCvTGHf5hxO9h00qjYVdJKhJSDcTDua3vYBNRJVdiH1h/rq2YYqbQiHu1xZ9VpbFiim 53tKrsro+Blj3TWk3LJFJbuZQpM13xWOw1JC22NNkOYFj516rOiwIpzSghdgsQ/hYlngK5wv6L9X T+Y4D2NXWJDBxsc7iVn8VOF8m66sLNawhu0sIS4jdRW2tql+hdXBbzqyeaTTmwRlh3EqO9qO0qBx qzOmhYLqwgZQhcxFQqLH1fYWUEY0Myfa6nOaLupOXrcIGZgSAT8RWK9qz/GQKDExTLoNrr0YcW/U 4dUOS+7H9Ae1w/oRddthj7dTpjYfg90gh5ahnRrV6focqsg6YhFR9W66pYZXg5aJ2HpgIhM8aM7z kPwQewroGtcR3p9xxvPD+zH9UX7Yi6jrh8+bZgqo75cCU/eGAre+RjEfTAnyL8dAww41UN2001Hb tdjjzqiuwMnUKvqRWjCJSBnmhk4pqVYfzYTT4sdx0Fyyc12KntEmA9RSfsiOs4gFMxKren7wG73D odRtyzEPI8iCvBYJBSZpEBQRRmo7F/gB2qLmkbHuA+ubmUidZlA75t8sdOTds328tNO2O33Neu2i 9jjbIGTgTlwpNBf+YxnVQ/uRZFGMApgrJ1FYSbz/uUBoWws+LOakijP7oVJ6w8oOntrF9xRs73GC kYpclWZY7G+3WfuL3KHXW7AxKiWKQh9MAxdiMRauUmxJdyH1p8XsYlOINYOMqg1gB3KQHdWwAwqk aqrauuMdSqxtX2bQUBJGsliarYVddAdy04Kih8GvEDSR/RCR8hR0hz4HCiSMHCuCHxT4pnGA7Tes iLrAbhJOnYzAe6QwyL3b0q9zDvqhuo61wrfYChGnzbEWQWq+YAp8ny/V1BaLjSk+1pQ40qntMnVs nAYgu762JFE9uEEBhvWpzbVRZf+nXkyCS6q0agLi1M3hhqVDYbjtrcILPY41Fh1i+qp00sjffjr0 kr9HDG42g2DlAWpgPmwXULuQDvDhasOHVaOp7eEjyLhNw3+mJ19jsROaamlX5vJq5DRogIkU7YwM LfX2OC7EcvPs2fudmdjbx9mXl5f06xkG1i8ebdowk0MP1vbq8p3133tf0qkYc1CBLQUfuB4OcYSP bolZpiyTolnn6Q+ck1cFCcvTja2GeNyHzoVQOlAdWP1+6mGpvctzaargCRiegaW4vB5I+9Us1kKh sY27pXaBuT7tw557lineC2x/I2tYW2EylHH7aMLHVjIMl8cZClvqLjfIY3RGeOYF6ng7ubyb4Fio 5BKPrA7YqdOP2Eigo41VPeg48KSDY/9BSjwYPQCt8zpzYGspvK5NsGB8AFLHWmvCIRyjRcP4t7cn Hk9Fm2j0echnN7SNTiCOemhi3GgUQjKTxn7R+PQM6fAoa1Vvyx25S2i834vxhPsBWQvqNuGmn073 eR7Well1nN0eu++yvCN5iSzBIrDwi0cP0b0HyYW9ttrB+rxptUM3ScNSnXj0Et13gAKwHzcur76U C6hxX305QqpefWU7b2za6UcYLWxly+ltLPD4q16lwU5IM4prW7RT25vAQkiEktFW/Nids29t7E8S 3oxEB5XlW8fAy9A4SZ3qfaxeRBha2+f87fgbW6Wk3v2rlu0XtnrfZD/b+LNt9xEWn0WC7WI86VUe x9kNvf8CuXoWAQplbmRzdHJlYW0KZW5kb2JqCjEzMCAwIG9iagoyNzE3CmVuZG9iagoxMjggMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMjQgMCBSIC9SZXNvdXJjZXMgMTMxIDAgUiAvQ29u dGVudHMgMTI5IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMTMx IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIgPj4gL0ZvbnQgPDwgL0YxLjEgOSAwIFIKPj4gPj4KZW5kb2JqCjEzMyAwIG9iago8PCAvTGVu Z3RoIDEzNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVzbcttGEn3nV8DA cEWNqBHmggEmMdYhZDm2aZZLihLtrrnOg2U/bFW2Kuv/r9ozuBOh4RkkYGJXWRQNqXp6+nL6dDd/ DW6DXwMTcGOYUakIVBIznmkVaJmyOBFp8L+PwUPw3+Dq+jMPPnwO4vLv5w/4Mfsk13FcvdV9JzXT seRZkMWKZYnOFh9+CYr7IKkerL/c/xJcveCMBzy4/xSsnoQRWZLoPLj/T3BzD7G+JtjCXzAtmUyl kK1gQSnYYlSwv7mLBF0tPHWlNZNZFqcDkQ51tRjo6my5X+3PPXTVv8SF2yVmmqk4SRMvwaiXrvp2 tXCwK55oFmszLlJw/8uib1cXa7K8JCG7ovF+xTkVUoWEJrFwF3WCpQkdM6ljM9DeuKX5ac/X0iSH Q8dSDEQatzStUrLOyJKab7751l1jExxBpoZlAhGoCRqVb46L56cxX3tr45hQMVNKHZNoaG5PVU5C +ncqFH/mpS8r3MIjyGYpM7GSwYhsw7Axr7a4TlmWSjMm0VBbF99tiiXJ6fV+dUWf31BrZi/c1TbF MVXGkkQnY1KeVm9Sxkwkxktv34v96pLQ6s9Ld4WVeWDhmcwN4yL+PYYmE8GSDK4thGGpMDrgAAsI 5MAdGZOK6wn5qful0rBE6mPOObxI8/xQVd3v+CMF04JpJXQg3AWb1zPbOJamKdNcZ8d0NXTN6SJZ gIh07gYR08QwBYj4BZEqiLioICK9ODu8vym4dfFl3KqQgeCNMnASKuALi1v94GE/BfWg9KIDzyUO aoE1PCdTaZa6igQovViZ2993eRBs9PK0QuoRmWiFcsH3/5LIiz9fPJ7RIqeRJPQxFjfliyX5tCV5 RK8/vnlL8w1hxf78iu5XNAVg2xKq9uf0gTQw7qnaRkV4+UD352pZ/vz5wrVk6IcZ31omReJIlVAu Z31ATtuoMCdvizV5oJv9CoB9TVDg4Fjhjm5zUp8833J7GsoV26+iQoXVsZbVIV9T+gSH71RRnnlX 5PiNEZP0RCeXGcN1uxy8O8ZdAaydEQo0FN3YUyvc+ZI2d31XRLJUwYiqchLNfEJb4nITpO4HjJSH a02AJ12oFilTJhFVXByvGzrnOGtM44Gut3ApXABT6w2H6e1uaKt0mCfsrrybyt46k9pslxtA2Pz1 zLYlGbiFJEjrY7oY16k0HxsmgQxcNO+VkSaYQ5eRPITyy0i+ZWSXkQ5EGq/TzAeK+L+sop7aEITD MuzlV3lE1jTfbjZqWb6zX202vGiC4WapLm3ozOmdLBDwQkJ2w1g5s6HWVJY2GdMidoqCba6iOAfn Od0p1DiIgIiDnKs7fGGM5EiDij6i8rHltQ2Ru+a7W3jlNmQ2H+DniH0WKeRq3pOC+DMafJ/PSavo gfzEeIFAfyIP1WXtC47Sgb07tCco3Obes59j0TMjtak0ba/gHwAVj49nYlZdC6VZyrkImpO4hD8P t54QaQRCTYqipZHoGB4fllPXF2cVgvutR5dYDt6bFjsC0z6VYaC+AcFb14LjSXOzzXiRS8ST/V48 QZoMLbhaWzAGKxlUGosplcYIQw7W3GqbB7qW+M83AA5yPFVgLBuRXLzrlQGIA1i9lEONjfYUptin QIlkZOYlnofLTGAshZAMGQER88DsvpIJX1WRfmBgo+qqyxYfdlDgNtGCQYTxkM1PXf1S1oW9F2h1 xKpn88dCzJCFMK8mGdgEjUkhALiH5j9+mfMqTIqEJRyE6tgdDhV2+8oWjZEtsqdxJY7tobZQ0bhW nZgaLo/r6+lF/O76+kKfXZzhWoEB4QsoE3+TPnLapI58C9SHvFwG6XlrEpEljPMkaA7kEpI9dDwh 5nU6BvcA2/xrlSTaQyg/R5lckhyKNG6L5j29mNVDUiQskYDj9pEq3G1UEUY5ffPzu4/gylQW7VdF 2AOrxXpNdgV8h3BLkqENjPKhfqxlkjiqhuhOLZ/NTKA0jX47LJBmyqk6KpFWcbkta0AQXkUFvGxF qEIEr2NEYUkV1TVGRRNWFSMUQPF7wp1a0wxV1bNZYbtEhMBJgUE8juth+lNCRIay1E5pNCK5oDYQ qmAV3Y1/ilytZYDgEQ2ZMu6RoAUKtaM/ZjBdArL49hswVLCWXW4zwA7ft2/8VNOkpD7E4uvjIhO4 X9tajdMMKaE6hEtGmPe6hQKsMxLTOe5qjZZXZVEDyr2k30G2L69ABlo+PlRgZCuqel57UDEqXmO8 BJ8MYUDtuwDSLr1yjQ5ierSFOMRXS7AxRWrZ1NImocCK2EY3owEtfYbqMLjNGp3syIlBLAjQ4SuP 42Ku8956q+EE7JlMGw2PF+ZzV5Itp+ojlIdbT6gkW071UKTxcGl+KJtDtpW2I2nBiMX8bXIFr9En u8rGUaZUlEfIl5sNIsINLeqeWxEyvgVPk8GUAcZrMsy212Y12M46wOdpLYWLwXYdJqT7T9siL6y4 9EdWQAWVT14StSNRwX5qyKnyiVIDj0/eUPQ6GKaabAwsXdgqsDp0lVQe1Zu3857bIDkakwaYiXA+ 96kcNdWYA83qdvy4o7aKhB7BcZP9eRHC7IBWv396H394/vyHlzfly9tvzXv78smsahUolxVmKYOk PoOLOXn49QQUJATqNjub0ojkgs7OXhck2p/PCs8s2xsjWXgJ5qGrCTEQIBHlN5cDkcZjIFx9syxS d131UaAj0yEyDmLUdHZ1jLcaUuN+uvKm0jLFUoxmjupqiFzAdk/TUzkpUQKq0akQYSRKEcW9hJqu J5cpI4yaIcBm5msiHUwZtWHtZZUfvp+mNUfrkph/4hkaL4chYtzsEV7fG3M7r2AGUz5cjOtuaPYv X0+TyRWx2y2FBIzomLKGdu+ROfvRoZ4Pch5kSxLMB2VN5jy8P4h0YGJeEPeIUOWAlssgm5NQpx1k cxSpGmR7PoS4GCcq6YCyhftE3797ek3XZXv8krgA2g4+zopFOmgLklQk2gWK/HF4dtaj2ZiacZSZ ifvRfguwOxRegsc6asxD43SXAdoOCcrpNpzgLHaVFk67Sl/y4bEWcQo4myWAaB5Se6TTCXCWp5id j2PVivRXgbN2e40rCehR68pFMA9d4fp8exIiBpxNABoPJDpMC8PseRI0K4FmjQbe8BDMT1XeaFZi SxBzUaMiDbP67GgWTGsax+MXOBRqup6c0Gw5NZSMX90QapwYzWImEEseKOI8rOskaFYBzSbYPPER bG40i4k7LM+OyzQ0sVOhWY4hWCz3Hqt1hyZ2OjTrItSJ0aybSBWa/Za+VRQTZsW6+Gc1CgvObH9O GPq9dsnh30Lb1Qg7F7FT/XlRjPuzZwRPgdLNyKzwTsYY9jfYK0zqk7lAVw+jnAA7JLbF0PRCKD5Q 9jg5afcOaIo+edk6Dm13OSUzy9n0PBPoUGvsuznMp+K2l7s7/AP63m7AwyBWoPJtc9zuS1hrCLtz wEJotA1Dwm8wEjCrIQgFABMbYKr6NC6G0Mxtt22IqqvfTDNgHQFvYOJ7g32EEzUXlMGibOK2vpLB HxVuopw6qvRse894B/tJ+1U9MDrvGBIH7sf2QRL4CH4iw1bY0U6NcOoOeGWFCVGhbeP5COUH0Hwx f9vGOxRpHPSbF/QNgn9UxYBqzQEz6rndj2vHgCrawnpPb3sMgSLaYoCO9mJIM/bTjyWzhom2uFYa LQXMALmEicPohhjdxbWDKIh0t8N+OIusMprdsTIL2qadbeah2WRftqrACzbvee2+aoq6wOe8dtej vpnX7gTpFKdArE7sSlsjnUsK8ggeEwrhzkDsggnPjn6KwrAS9goeA3LFZfSjCx4jQg2ht1/w6FfB LtVdFzzGRTogkjEidY82fdX/b5akyoRlt43Id1imtZkWfrRUWKO6gQ/tzzHxI9tJwbI3jgZ62QVf 7uwsIZCoCoFBMI91qhyNQSsM17kRc/ajIjDp0JslntenOJq4mA1GQq6l/Cv5FIbW4+MfTPLnudSX ZfqzPGpUokOHenXEoQa+U3pI10g4GPHqId21RZLW2zBwZ3egy+3beXNTU4AozrE5wJ0Gasr0WUuJ D0laEg6IXsUM+19rlRXc5qz5iG5thyQyGfhIXURX5TVYEevpp3aYB0C94P0HLCjopWAbDuuN01PF txjrXsbtc9DsiZoo3W5GlIPR9qMAeudFrRXi7JGFRxVpgHkuQMEcd1YNKNoJLvId4j4WwKt5TzzB bEV5CXx5GlOUBsV75vaxCc09VSPw1fRWfbn1OHyrmAJkSOuC8xZkduaWx0IEPkfpY6r/AyBki5wK ZW5kc3RyZWFtCmVuZG9iagoxMzQgMCBvYmoKMzIwNQplbmRvYmoKMTMyIDAgb2JqCjw8IC9UeXBl IC9QYWdlIC9QYXJlbnQgMTI0IDAgUiAvUmVzb3VyY2VzIDEzNSAwIFIgL0NvbnRlbnRzIDEzMyAw IFIgL01lZGlhQm94ClswIDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5kb2JqCjEzNSAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250 IDw8IC9GMS4xIDkgMCBSCj4+ID4+CmVuZG9iagoxMzcgMCBvYmoKPDwgL0xlbmd0aCAxMzggMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1cf2/byBH9X5+CFqnaXstr7g8ul0nY VPQ5yUUWAicGCvTUHArHB7RACqT5/kDfkBQpMja9S4fCXYBzbMnB4+zOzHtvZ/UtuAm+BVkgsoxn OpWBTmIurNGBUSmPE5kG/7sP/h78N7i4/C6Cu+9BXP75fodfo3cKE8fVj9rvlOEmVsIGNtbcJsbO 7r4GxW2QVG+sv9x+DS7eCC4CEdz+EZwczcNoEYWnwe1/gqtbwHoK2MwfmFFcpUqqBlhQApsNAvuL OyTEauYZK2O4sjZOe5C6sZr1YnW82J5sTz1itb+IM7dFtIbrOEkTL2DMK1b7+2rmsK9EYnhssmFI we3X2f6+OltGi/Nozi9YvD0Rgkml5xFLYukOdcROkybmysRZL3rDO80ver47TQkkdKxkD9LwTjM6 jZY2WrDsxYuX7hEbkQgqzbiVqEC7olHl5jA8v4j57remjkkdc631Q4j62+2VzqM5+yuTWrz2iheB m3kUWZvyLNYqGMDWLxvTRkuYlNtUZUOI+tE6+9uqWEQ5u9yeXLBfrhhtszfuYRuTmNryJDHJEMrD xk2pmMsk84rbW7k9OY9Y9d8794CVfWDm2cwzLmT8nI2mEskTi9SWMuOpzEwgQBZQyME7LFdamBH9 qf1HVcYTZR5Kzv5CZr0S1v4bPxOYkdxoaQLpDmzazGzqWJqm3AhjH4pVPzXHQyKCiHbuRhHTJOMa FPERSBVFnFUUkZ0de271B3jr7HHeqtGBkI0qcAIViBnxVj96uN+C9qj0rCXPJQ9qiDUyx+rUpq6Q QKVnJzcZOwpZkbNXZ/Fvl5dn5vjsmIVqexIyoTm+FO5hHFFiBVpTklnRwzzMffScbSIogGUxJ4D4 dq5DFm5PXkcAPT8HBaEnmLPs8wu2zFmombZ4uZiz05mrZNgvM75aJkXjSLXULlpmoddhMT/fRRsP A+Qbll/kYQTs17//dv/lmNkIj5wX5/MIL625qpcoVBELL1YFFkowNMeVnucRreZ6vkEUfn1Bz/+e HeqxleWxdFJwv+uPURotrvCwOVvSA9FfblgecT3fdJbsxwBdbrf/poiEWkRQNyFiUmxPOxHkfI1X QOQPtOAy5TpLpMuCY63mhD5fT5pZqeRaSpEFaY2tqprDmWVzpMk8LEj9XLBiuVqA028Y/rdgH8ui sENfJxSFfpdn7yeNtYTrkIgEBdcj1h6NaUTxantlnHEFguASYq/GNAJU25g8QPk1Jl812TamDqRh uXZzw75UDQglETopRM6EHyMIpusjySIRLfEzqIH76w+UTSgbaXSB7bjOqZq+PZp0MyqQ0sxmOkjr J3JJfI8gj1h3hXYdx1o2kFw24/H7Igq3p5MWIqU0OG6KFt9Z/eFC5BGrMf4B/EpjqDZ2IA1vyLxY ucepxx5cHCuFzBXQJkOY+sTbL0x9Qvkk8UbiigTG1BOQOsS7Zo16PjpYpSJ4ShNY2LOJ/lNFa+dk m8xyI2MnmVKVLfRcHr17Py5irh4tHD1tjQiG4PVFsEf/HLPjm4hZeGbm0Yh1PFqv/tkD5bKzmv5p PEBNm4dN/3wCUicPb+7YPxROSaAUIpBrm2uxDkkflaIOPVWTSqKXGq6sOySavqM3RPPNShfov0sy 3jgJK9hJ07bXZmMYmEDaOAmpmh64J9GIJpvGHK64zgJTA3NpsmUUw2JZLQVJNUESbRHxqCB2TVqb Ai2vt1uJ76D+6NvyNzZFvsLr0Ef4Da6XKwHhu7naW8YDLQSsFzy5C81ZrzakydgyKvdKkUPF7lga 6YliE22mlQrCZtykKc4l3VF7VLoR+6ZRCganA+RuPnDI+UPtfYaD5cI32kL3OKbD8o22zg0i6pa5 z+xS20KQP5IWnM4HakWw22vsYxGSvbC3IckROo9CpOAqqvyDtizW27e0IA6UWzD1lcqckiskV+N1 WR+WurS+dmW6eny2WS9I/4RqUuwio0JoDE7+3bGTSKsKGMPaYKlKpbbDX9bFkgLNnI70f2jtDrMG ONVMIEe8UB+qMAjBsyytjyaGxZEXBRpRrdrK4AHKjwKNthBMB9KwYrv5xD6gkX45ut7ZqHVNoGrQ Zvwi2p6CKIGCw+Mq0GpXZC3DW8C78rXN+aJYlalWFpJJ86rtE7EAI9ZOXur2ZIXnWi3g2qHtbk8L AW8cRaBMpmY+ZvaTB3cEkimLafjHA+qBkimBOhQS4wsOIzsHSyYfUAdKpi6kJ5LpF3YLyVCW6bwy 5Mp8aPJoUuKNg0ieSSuDLuThOjltFEWKiq2V6EEajqK9cA9Tr8O5cDrM2HFtrRnEdFhSJ6zmSYym 2125bpgAqcPq2pJ81dA3sn2xAfHlmuVcwf+9KnlQHi3oeAKnX1qkxH3qCM+eHgvsRXjvkPXpecUE BywJpmpcJBHJufaR2KX7HhjRvTOQHJNgW9YAXbQGUeZ8vVrpRUhd7/o+uY5fHSVn7O2r2/gm+/T5 HVFmeowV4ly2ShzfwRMoX3/5+dM7HDJSedB4z+JA5kBiBLSUcVmAwxQpGmqKDRWpCplL5P1q1L6D 61IP4FdYKcDTBxD1y8EzSpSLvwZXTZkU3vswpE45GB+kJqUHRjnISrY0teSCqJ7k2E/nqhhBMJYH pBtdTiPssmmfQFb1qrJ5PhZwgfALKR1jt0IUp66HIZhJgnFqzPe4ZA9GCVqKTEXg/tURod4NYWDi oPYKaxG6pFPjaT0eqROIZswC+TzIrjVMMzHekHdoTBzFYVLtT0U/PUD55dtoLdeNU5cR9N2wm5fs qGNPf6SBEbSiSXspzuPQTFEZOsEbRoqD6guWwuVdg6A0bm7josN3wnhO5ZFuWhV6xYqwsq7wTJUB fKBCIDEoYqyT0vwR9o4WVEUthQQt+QOo2iKaFL/IFGglBscSD/we+3oE8RIZNgvGVhtITvl/ZP55 9OGMmO29PN5u8ddF9Mc6ykMwqmsajGoMyXYUbNLItmUMVkuaaCeGKwo4JjjLQFeYa7bU5bkTNj+j CxT1EzCa+LrAUNpuymvqDqE57jEEicdjHKhBaNq82e6SwLCIPZg/4QPKI5GgsUY3iC6k4bJ786Zs EERPyPADtcJgYXcfVipg2oaRYQpHSh10oQ8vMU2wbk9RAShhmkax6wdrTHRWygueOex9HHFg5G7q ASc8h6XRj91zuPBEj10xorw2dUlbDDo/OF3RJw3e4037hoDjXEWScok5lMdB9fWVR5T24dQzyE/N 7OAuGe6TWWzAR6PUN1vOIzKPU/e8GAELJ7I2y7TwgPW8OEH4fb8bEH2Z5JmgmxcOcSpvnc5OVhvI nGdFqQQVfHt0gl/EluNaG27WPr14NaifEKWB27kCvVNazO5VgFyKgNDuIRpRBQRuASWpSAZC1K8C 40PkYrEIKXBhCRphcM06I0w4raFTmsj3MlZ9Q8WxMGFyD7fXkqFK0I+UB/3p1QCXSLUF3Ghc7XrI HevXSi/y04PkYkY1J504a3sc0gG9qGYEwgFQXQHuXpTEB8rrfrsd4D0lyziBMC0ExsEwMAGuXoSt 7sTlOtxHLQl7Y5fSe+j+RcVADiM7dEKDzImTM1UNU4UaZsCCbo2A/JVKFNqJ3ILlWoSY2p3yzg8+ 04BLRf3WAzaC34SYjpmhlkDp6LgZ5xd4UR6Vl9cmG4SQaQJ2h2EDH9C3pX05aXGXOLsQdFa0w+Wk oMthkn1iPOXHQihY+3Gc0YdfVNvUBaJfB/KVSwq1KybJ0UE0rJYOwYyRFZiyN9AQHsD8QuV7HtK2 IK04PsLkQRXRb0LP4seOzRof7YFPAaCMHADWb9fTxgoTrjLBLYlBSP1YPY8ju7AI2lRCJ6kXrPGR ogOkpzQX7rAameHqzdDi9VWXD0/+gdmUx1rD+kZD3yj4o06YDnI/GcUdIxz4OAVHSOX95IYrN3Od cEqEwPXRTd3kywOphvmUHb9qobd57b+XXhBsSZxineQad4aJ/UzKCto6oyQ8VOvkoVqgw5Q3KFdN xbanC70ELVjiTjNxmyU9D8ME6HyDn+NNmHeluXAa4Y9WuLmJ55rYU8VWtwrcXXs8l4eqGCEI21CD UuEqef3JK8OOm5euGAGq1RUeoPyKlC9LaJVFB9IwTbj7de8Sprb/ivjuyiUuLlU36nEHH9Yl7oaU I5LYg5ALJRFfRqHSGzoMmzbVhOEZtYP6sVw8ikPtyFjBqHzwo4D6rXwf0f8BFREb9wplbmRzdHJl YW0KZW5kb2JqCjEzOCAwIG9iagozMTUyCmVuZG9iagoxMzYgMCBvYmoKPDwgL1R5cGUgL1BhZ2Ug L1BhcmVudCAxMjQgMCBSIC9SZXNvdXJjZXMgMTM5IDAgUiAvQ29udGVudHMgMTM3IDAgUiAvTWVk aWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMTM5IDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0Yx LjEgOSAwIFIKPj4gPj4KZW5kb2JqCjE0MSAwIG9iago8PCAvTGVuZ3RoIDE0MiAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVzvc9NIEv3uv0KRRxdn4kw0PzQaAbrFYhMgjisF m13uDi/UVmCviiquiuP/r7o3ki3JuiDPKMgsfIAYkXrT0/26+3UrX4JXwZcgC3iWsUylIlBJzLjR KtAyZXEi0uC/H4M3wX+C82dfeXD3NYjL31/v8N/sk1zHcfVR85XUTMeSm8DEiplEm8nd56C4DZLq wc0ft5+D80vOeMCD2z+D2VE4JRGZngS3n4KLW8DaB2ziD0xLJlMpZA0sKIFNeoH9zR0SbDXxtJXW TBoTpx1Iu7aadGx1HK1n6xMPW7UvceJ2iUYzFSdp4gWMetmq7VcTB7/iiWaxzvohBbefJ22/Op2T 6IyE7JzG6xnnVEgVEprEwh3qAE8TOmZSx1nHev2e5mc9X0+THAEdS9GB1O9pWqVkbkhEs0ePHrtb bEAgyDRjRoCBtqRRxWY/PD+L+fpbzWNCxUwpdR+irrs9UTkJ6d+pUPwnL3tZcBMPkjUpy2Ilgx5s XdoY11pcp8ykMutD1LXW6dNFEZGcPlvPzunPF9S62aW72YYEpjIsSXTSh/KwdpMyZiLJvOz2XKxn Z4RWv164G6zMAxPPZJ4xLuKHOJpMBEsMQluIjKUi0wFHsQAiR91hmFRcD8hPzTeVGUukvi84uxeZ dXyr+R7fE5gWTCuhA+EObNzIrHksTVOmuTb32aobmq9lwSSdSkK5YuvZtFAhfb2e5XRFUKjNi5Cs Lmi+xDP2w0/i+oLO17NwaZPsOSVlNYcnVEQNHiAriv+/njFG8pyGZPpaRT/Rk4lrsdd2EN8qNEWN lcVCuVShU7VQXJ2d0yJkfLkC7MLCpuLo+LYVZpPvXjNzJZkwJg180HqUpgOokivUpjEiawupcps9 NcyHt/TNnEylWr2hhJM5POGK0iNrxdWqsG50UXpVrpYRI1StTzpOdiCnQC0pdaZdnKII1ycqgneX QfDs4/UNNeReDxnTn3kmGJeGB6kH9JE9JEsYT0RWQ3LxEOsgi0ilBaKrFVJ72tAB/ivgv2nCG4O5 oPMw2IAiVygkQI28t73D+5i4m7XMeRNJ7gYbkOpFZtDRIz37oDtU6pKGxcIpc9HTY08zteWNshHt lTdwhwZFmwzSXkyVujGp1A0/t2o3KrXggpzTSCxlt1zLL6ivjEpt8nBAFPCJ1VvusgcYqdaAJt+C hCIoQ7MJX3KCBAloMqM3qDbeLFEsPBDapPf+eCyZTpUbtIPcH4+hmJlMORqrvD+bkh5opuDrXY9T cdTmMUfIud1gCeo7uHnw5Zs+xQUHB6Subl76VKSW0yI8e0MX6xlUM1QmEDO2KTwnUzpVnfpjKpHo q1IXvYnt5q2p6eYbXY1aniguWSYhum1s7lKdeBDwgCTa9A4ctHd/69BNWA8hYBcdsCHgb2PqtjMP 80yg6qWUhoB7Ee2khLtX9DRcLVQRTnN6/f7txw/HNEX3VKzgf4SyIi1Y03vl9LWEK6IfO6cRYaRI if1iDueM1Nz+tYjoh1ig1h7VQxt/iDMm0UC7uOjv22PZJnJzVFTQCxKVhXXVZTEV/rEMWdVoFtOq 9/ygUGzb0CP0zyWJzm24zsc9oEpxLkgSqccBi7CYF/+0rTK6HNvpujPzQ2JSo2DTIt5URf2Nme3k S2vmJEpJdDUqQkyTVBzrYBfgX0LL1QZart7abBdSlzQeQmRB7FFJ+oA6EJPtgbRLZXf0aNPHg4Lo SkHSDdUURDVdRmFDYlZMsX5YRn3Z+reklYnT1G+AECQwWdAKwvT2SC6U5WHlAREsDDTCxJgakktr isb5+ZPb+O7ly8sXlYZCNvmjKmh2Inoy1kxXa7SwSjupaZBMFuWFNxLirpZSWB8pk1neJDKKTLA+ Kc6WqNfKbAC1YKqY4pb8tw4zptIiE2hxPE4Cn7OO6zASmo8QCcbyG/O7Ocy4LC+1YSYTwguUR2oc ILDU5YlOOGYO2GO4Z/Xgh9WrfaC6ucfDn+7hROeCdQ+kXZp/R28UXUQkhaiLSDxbz4own9J8oSDj osuq1NwdHurdLRnAnBxzT5Vo+NzOBffXPkg5x++RmKrS52KrS+e0mC8qidqCLx8pe72GrsYtNbd7 MhrzZczHXPJSlxs31TREkzI5vHr58vELXA2HAL88q2roVbE+wfWwJZ/auQYu0Iqv9sSgZ3yxiIqq 44jICheLL3h+oCZCY/YpZeZ08iKneXEW4jAF5lGYKozqZ3AzzO+gX20huhDuobiNc5ZlqdPI8yEl rFcvrntA/Shu64e0y22/0Ot/PDt6dlrVUvptOeOxWqStOrA/FJ0vIBaBSa6PBP1EMCXcTkUlQdMH VcmOOtWqIPm4GpHUHMsoBgy4OZ4LbXh45gBSrrNukklo41vP7CdlL88cAKpWiXxA+WVd3xWsWiba hbTbhHark7uf6Y071bVrAcdNvxT7JybhWeCD6sN1FSiQcbZBYst0wqatdu9Xs0R1QBAz+NxqP5dX L3+7okfi+jSu0tXl419eUDA7CP1AKScxEvss0inllPsKi+l6ZjiaViRVEoW2J0lJO/mMsAwgFKR3 ngQ+YA8V4lqxTGON0GF19nAh7gHqUCG+A2lPiD9uScHlcCJfLhYqmkJKxIpEROcqInROGEYTYZHP cyQi+KF1Sa5e26wEBVg1mzn2E8jBhylek0QxoYzTkvdiaThUbWRQuw2Czb8cevXpU8xlUIejHK+W buj1zUdd8cPd40tbzoYr+v7mRtAzMuqZsJrGUg7f9jnTyIWojDnUq9TUmJwCzyth+KaxJt3jb7GB jPVXarKxC/hNUD+oEN0DabcQvfwWF3w4uqarImdYycYgpFrFy1lUmGp+8vyovvTJvncn2lWC4zqd MIolWJgKtodxKTs9uHZAhSfQpCVGIU3uXHl/2Xl8VZDp+qS21RjvmcjYQK1LpRcwD1sNEcbQLAgl eAdSf146I1YcSN1t1fYrx+pTWu3DvgCze4n9wPxs1V6ncelpJXYxTZZ0/WoXUpdKeJEPs1MZf/tn RXZXOTUKVfqOs/eDGm4nu+GzT0SUScJSCBH7IO3wW81gmGGUiX2Y1Vy9ayuxJSKxe/8umco2+eWk tIZ6D9m6ox5AbDxNmMqQVz1QYzL0LsteueMaEKvCkojIQCLu1nzRbpX2LHm2ISEsXGJVcAxG0rgX UjdUPTqlDiKnqKhdLoaGyL/52tBOVHh1SveAArDeZa5GDHEBtVkRfBh7lJB6trkaMcQNUrnO9e5R uSS4IliOIZUCgU4IuzCYC7akcduvrwhk7xlE7/baQ3sNzK6lb6bWm+8HIWLU/gLMXb0Yq9BoaLw7 61JDVXI9ajxzXraC65l7jA/hHtxGhglosMXo0m9AFTmrEOIe7JTF3s4GeHRBMeaFacnTBWQgK6iW zaul2e6j9HWBVzQPdAcmgZDhOXWxS1c4ilpYOcuD2YZcBFbJeBqoDUyXzDWc2FyotvFe+6ZfjPe5 7mn7/o9rD7WMrTxAPYzY9pVFNbHtgbSTAN69rOaPncJju6lqNVbEEegKbIexKy81SXxix3kgOrw6 HyLkIALVLIhAa+17WaHlQHGV4D3jTDjpQZZ/Q4JlP4xPyvFrCLGrPsFm/YPb+QokL7v8YV8jas5f HnDUUwmsW8QCrYDyOFU9Z7YU105V1Qrjsb4uA3W0hacmUO0bXGgaXNLMMrcT4WL6byyjQp9bKSzv 2Hff7O6ztfv1k9/tro6KVtvPGveybF/W8nYMXbH7dstw1D0de9DEXo7HOT04cgBpN6YXkAC42eyf 9EsSXsXfAFB18ac8QPlxpK+E2HDkDqTdbrY7CXuX0X/ZJWjrjvXqG2oJ5GODIY19JRX/1rglSCXF NkP5fNPLNTI6/ZVcnV1dVA/ZWB2VShrXwA9i0PixKC5RabkCAWi58beyjioTwobyrcxfK4Ibuh/1 CEJiMc6+nqA8jrBhQ2ply/bd5A3RA7stbss0MOoBmjvAGzdZyp2mgHPkn9Dmz5uybi3yi3E5BEvd sUywPa02IF0qcA9IaB99w7W2m0TjIvATfe4r/brh2ob0PxUcHUoKZW5kc3RyZWFtCmVuZG9iagox NDIgMCBvYmoKMzAzNAplbmRvYmoKMTQwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTI0 IDAgUiAvUmVzb3VyY2VzIDE0MyAwIFIgL0NvbnRlbnRzIDE0MSAwIFIgL01lZGlhQm94ClswIDAg NTk0Ljk5IDg0MS45OF0gPj4KZW5kb2JqCjE0MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl eHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4xIDkgMCBSCj4+ ID4+CmVuZG9iagoxNDUgMCBvYmoKPDwgL0xlbmd0aCAxNDYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4Ac1ca2/bOBb97l+hSPTGYVJGfIiiMtV2rDZtWsco8phZLOrNfEjbBRbo ArP9/8Ae6mFbGkchlcpNgyJI7RiHV/fce+6D/TO4Cv4MsoBnGctUKgKVxIwbrQItUxYnIg3+9yX4 R/Df4PT1dx7cfw/i8uv7PX7NvpPrOK7+afOT1EzHkpvAxIqZRJvJ/beguA2S6o31t9tvwelbznjA g9uvwewgjMiUREfB7X+C81vAegzYxB+YlkymUsg1sKAENukF9jd3SLDVxNNWWjNpTJx2ILVtNenY 6nC6mq2OPGy1/RAnbg/RaKbiJE28gFEvW2371cTBr3iiWayzfkjB7bfJtl8dn5DpCxKyUxqvZpxT IVVIaBILd6gDPE3omEkdZx3r9Xuan/V8PU1yEDqWogOp39O0SsmJIVOanZ394m6xAUSQacaMQARq gkbFzX54fhbz9bd1HBMqZkqpXYi67vZS5SSkf6dC8Vde9rLgJh5B1qQsi5UMerB1w8a41uI6ZSaV WR+irrWOf50XU5LT16vZKX1zTq2bvXU32xBiKsOSRCd9KPdrNyljJpLMy27vxGr2gtDqz4W7wco8 MPFM5hnjIn6Ko8lEsMSA2kJkLBWZDjjEAgI5dIdhUnE9ID9tPlRmLJF6Fzm7D/LqrG2qzWf8SGBa MK2EDoQ7sHGZuY5jaZoyzbXZZasuNSNJKAmXc1WEEX395fIjRWBb0q8LMi3A2EjRSBY5/azKV6Yp csTqqJjm0Tld5EX4gip8wnT79ZyqkJ/SYnWEXyU5oUcTV6237R++IjSFxMpioVxEaHO61dFqVvAP bW/pU8kDIpHhTCcik0EDsHoqP1UiNMI9RZRMldiZ8bqkoseH7nbqPEgX1aegCxAjYaceUF3v9RPt 28LAljeA1VvgIJ4ZlZr0MUhVgTOpCpy7K3pc8ymn11JRZSJ4WWjJUEypug4pV2w1iwoV0ss/Pn35 fEjnZLo6UtOTikYnq9l8bqllyTcyeRKWpFytD+hCHgQMcblaCfrl5cG41FE8YYaLbA3vOVEH6Twx z406PaB+FnX6IbWpc28VYuX7NTMMWZODLClYQ41SEY2KE4KfkKiuJQmJzUobUjGJV14geRlyqvAW m+JGplHdCEk5gphbHyQn07RgBMdZhMvVbHraxAl7zKOpOsHx6HxaqDq3roOCssGiih54zZ7NGmPc 80mO2MwRB93P5xGZByRVKdFxUlo3iHYpnW4Ci9So+UsqwVJpEEsrI+2CtF8OSpWwNEEnoB9Ri4K8 SAlN0UFZEKpKBWc552U474bFWo3EGZPQ6rss132YqCbnKoS4BNdzSsr6cvmB0o/gQw2/FLOIH8i1 TJasAl/mKs8LMypbhDZMGSSt+jguOZUTymFohLFFTsZNqpLDT1XC1/ieUVLVWcyyzK3I25se7QO1 X0Kv9egjkFqMvrsrSdGu8eBrETmZI5Equpgj/0SEFlG+lUQt7ZvkUkYC5FRK1k1WkIpz8O0AMaJA gNhLiacN+nM6dpozAGAYQik06hvZNCTXWwf8uijYK9Spv+WE0EvCSj1+8/u5PU4ZOsDE0gJN/KjC yodxj5ogZNu85nNUj/A8JNU24Vmj4cF5VofnR+pXn2JxAKh1segDykOSoH71TWMbcrbs1N/Yvrtp k7NWvbvoaclYdmEaJTiqI6J7x2JjeNAY2CWLlfq8J2jUMmLy+NCv0z/wmkbqhKMy006NoE4YeyBo NBZHV6yMGY/GiCouWkssSanymw8e9Zmt+38acwz0YV0eWRP8/+JdVXW1VCijbBiFzIIwRBBtR8ON JfLiRYicYH+tmyb2lR1QaUqZOR37uoikWkT2QC/xHTKSrGZLyC+mwrJbY9svoz4snkKG8RgE84AN uHtqvQhMETOFPFSjc9HkHnmow2+X/uDGuzmHSEx3TgK6euwpIrHsDz7SIdzkIQ9QfnlocNNS90Nq i8Q39N3L2/gqu3l/UTG//vHqAk0IxchyUc7v7HwAJRWkEdoqik5L7uyifKSu0dRY5uOSaOMTMYcy VE7K0Ia6kkX/zsdvYWYJy3QW6BrfM6JRYiQGfugO7F7aaS1X7I1GPqD2RKNHILVp9As9CIuosInw QP/r4OPxZVVLgENpsSxblvQTpk5HSDU1w+4v2vX+pG/+1ImbLroIM2cWc2w1NAdxkQUeoXyAel/T NtEK9Gh88JmUFD6g/HxwcEnRhvRISfGWJiSPaLyYTglmugLdYhS3aDXbERO9PBA2fGOKi82CECW/ dcP7u7P7C1qEjC+WVvnYBvqSl9Nd1Per2ahKSGLdS3CsajSndHFQ4FTn1HJKVfnKvUX5JIdNFBPK 1JP1foedQlLyUWGh0NFGY3cz8YA1sssqlsac8w6kfpctpzkR+TWqnPH9GVTHZv5jJ0K8IFV3F6sI J+RE2TIktEoEej2HE0zL4VBuXQF/l0vEYExXoVDG9dymNZIoCTGvXRx3Q7eSjk1bLh83CfByXiJM 4IF0XzlAYAad7FTz3ab/U2SIS4mxVvPJw5i6FYYfnQaL+X5ELRFyc0Y/fq51BxiSzwnDLg4IVM5K QY+q9VsvGPTV7bZKLhMGRo703cG4XDIJ44rLoD6pC5c8bD8k6BvDsIqMUPawN3Q99PBDQaLVkXvU 3xZ0jhvbKsbSDvYIPWB5GGobEFawXGizkXOYwRu75udQUuTFfJiVyr2wElbv7g6WiOIUlwCCxAPU cDs5rRNxFmdorDwGqcVm2Cm/sIMWcXkcVzXD219uLjyCM56or/BEuYBdy7jfeF3fR2qu0i9jZI4m msFQEwoIQ000BiPMldsprvc2ygC6CqghoxE/ep53F7KfFbeDtxcvFJrpGldoXHjxlBzn1bHyATUy L5o1u0cgtXhx876cPdpMlxPM9CH3UPVYrytyeWILn2q5Mz9vhni4FNKsBOACErZbkRDrNjA+5cO4 2U1xJrCLETRHdElvHt45gC/rqI0NRyxn7/LNv9DFZ6o3IJGs9dfDkH6S/OoF1PbLzCol59ttHStV DZ1Jb2ZLkUYEBLMDpoBP7J27p9EXmCyeyebiX3mHa30pMFUsVrFK3ADhEuBk9iSZtL0YPnn4dmKm EHMlimMnO5WwfoidHrwumWEpP8NEtcLjEgC8NNKAEMCxoYQ5FG6DOoeA4SZyyZgcu0ncpI2NdsWk bgDABKJcoUT7Kqcvj+NPr18f68PjQ1v8Y26LWw3l8jUqmLzII5sXbMpA2yCsVj7slmh0TXCZa9wE 0LQKlL0+FbsNZwnHwg16dOMKp1RiyVohAzTQKrP3N7c8ctMA/bnJTUgJSj+z7oDqAdV1z+F8caoo 1sqpH1I7Q1259Qfck9iA0CMwnNRCIjq3kPc7XXUlohJv2EbYbHz/Bj6jxfFisbUZvSc6S8MyKZwG j7ZNaSc/uKWM5svvpfqkfxx/Pqz3Vu3Cmd25tS3Cu7M3b3aGtCIsTop/VptpVd90X01OJQz69MZp r2YjxUtfqxV6PqpLcYHrh/a2SAPUKY41JcArQso7N3Yvn0xHBSrguLhwjYBbW9QFqF8g8S347boH Nr1Qn7Qg9bftbeOd2porIu72KgWv39VUgemGwjaDFziPnNnR4C5CBfqb4T+YgHLqsVc3F/jlzO1u g0su2ORM3LqNE1xE2N2Fa+WCp3Ubymrl+32PCEdwry71KRdQeylX1nuajpDKyuDm3qvbsMlMdbKy CwFoPoyak4QtMGIM+puDuZQY5TrPznbIdgn7o3cSJIqzRGV+UD3oM0CQrOkjM/QRs4Y+/YLEA9IQ FWzwPEUqgzak/qC8Den/EwkHkAplbmRzdHJlYW0KZW5kb2JqCjE0NiAwIG9iagoyODU1CmVuZG9i agoxNDQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMjQgMCBSIC9SZXNvdXJjZXMgMTQ3 IDAgUiAvQ29udGVudHMgMTQ1IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+Pgpl bmRvYmoKMTQ3IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjEgOSAwIFIKPj4gPj4KZW5kb2JqCjE0OSAwIG9i ago8PCAvTGVuZ3RoIDE1MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzV1b c9RGFn6fXyFmNMtYsdvqi1pSYi2xggm2cagQJ35gNvsATmpTla1i8/+r9ju6t2z3dAs0E3gA7AE+ nT6X71z66FPwY/ApyAOe5yxXqQhUEjOeaRVombI4EWnwv/vgLvhvcPrdXzz48FcQVz//+oC/Rp/k Oo7rL/V/kprpWPIsyGLFskRniw9/BuVtkNQfbH65/TM4fcUZD3hw+1uwebZchetwdRTc/hFc3ALW LmALf2BaMplKITtgQQVsYQX2D3dIkNXCU1ZaM5llcTqCZMpqMZLV8/V2sz3ykNXwEBduh5hppuIk TbyARV6yGurVwkGveKJZrHM7pOD2z8VQr746Dtcn4ZKdRvF2w3kkpFqGURILd6gTNE3omEkd5yPp 2TXNT3q+miY5DDqWYgTJrmlapeFxFq6j/Ouvv3GX2ARDkGnOMgEP1DqN2jbt8Pwk5qtvnR8TKmZK qccQjdXtTBXhMvpnJBR/4SUvArfwcLJZyvJYycCCbew25pUW1ynLUpnbEI2l9dW35+U6LKLvtpvT 6OVFRGr2yl1sUwxTZSxJdGJDuV+5SRkzkeRecvtebDcnYVT/eO0usCoOLDyDec64iD9H0WQiWJLB tIXIWSpyHXCQBThy8I6MScX1hPjU/6MyZ4nUjxnn+CB/vDRF1f8bXxKYFkwroQPhDmxey+z8WJqm THOdPSarB6b53JSVF0esormVIyo4CylVFvhg8qNiQ3dPpBWgrJDAfDOVIUDugFTT1kVNW3/6NXor w6hclqsS/CJ680xERXmyxO/L5Ul0HK6kuonKItpultEz/a9nb7+K1uFv12Gx+qE99cVusjs0EEcW LlKO54GxtY/jwsJbSPPwb0hYCEoM0iRnColBrYh2VnR55a6IEwJCkjLOBdzvbkzgT02yErhDmkCF kKZkSvIxJDsVIi08qxUruj97Fr359/v7j8+jLIxW+E4RrtOShfiOhq5WX7orVHEXrdZheBE92x5V X7sJq08xKOtSraKjhWsyNkE/+6dESE6VUC76WVKWeI48MeIKKHl0U1ldsVrD2oqL6iEaKcwKXuC/ 56kMUg/sHt5rgh4L0HuepVCaBpKLbUFR3DV5CijJmU5U6gXKwwdNMC4hJUGClzfkZDeugTVtN4bO Vbb2/dlt/OHVTy9nlaXMEjBX+E4P3K+jd+VK+gm0C5uOhYLejmXGYvEouRgTMXJJleWGN/j1pFwV Vx4gJygiPDzTmeBB6g7SA9HI/bkUM/pYyJH4tqHQVMMxJ8uv3DVsBKmiP7sIUBcKrZDAfxAJG/7j Fwk73RpymMXTlcRet3YhqgqJCyokUiB8qyIZbjc3KFz0cRCWaw2DV9FTcbCPOrMGlf5p45xJJCcu EfHpOPhW/WA8/azYBedMiQxs0wO7h4VNsHnBJUGCp28guUTEIZ+ofHvlQJ/yVwunSvUDU3QooaPU qaUEwfjbiLNzWDqPWZ63GbedvP/o4bEmHHFH3ndj2jt5NyGZjn0cD8ln3a7Vcee1vrt/85a4O6gu 6okryh5vBsZM+rjdqrNIVcR9VsuW8DAInTpoH8jFK4XugWrCsSM3QtKGPLKF5GLZHs5mAq2UAhGI czmCZD92ymB4uPbhPo0v8akUS6VZIkDCTWnZoflJaxjXvciPTgXVgR6t3o3ZzwcPX/LA5e6uSPW+ ZCemqb5kKCaXilRHCHaIyahIbbfRv5AUP+VKfJRtgmlyZCmoMCaBCdkeJfyUzbfx1QeuBJ4sfVzZ xh751+nK5mQALdVGKvokptoA9q9sdkhjZTtT16uw07aebrehqyJQ0EfxZrsVFaVS2Wq7KZfI/bZH CHrzRi+h0GGQmGdonsolenno4wQTkQI9f3TuWkR18LK7448KfODnIgyjNyFblWoZffPLvCh736Mk Q6tGuMTYiqYQOeEKfdBoXanG+XaDeQVUwinStSkW8YPZ2LOIUyZzxQPdYD/8oQvi8USaW0gu4mzK sTcKLVKqx/Z5aJ2mnHMIHFVPtY7ebTdFdI22Q8ZR8VV7Kt0iRWFCKacBn8bqQWVn5YY5xR9IGwNM NTYXQXuY0gRumMPZo+1GM1VDSHaLr22ncpAQWVQ5ACpfhOuLaDmrBEUsWA7AI7j2EK4iMw68KzFr 0ycwZjRdeDUTHbJlAbnSrFor4MPbe086eMJi9BVd1PAnU0zWubwJgadnuDsxTSUdvtysjzIGJLtp gOHGagkOwVYd7xgnzO9kyWTUfvWEq4xyrdNZuYbIoYYp5hx08zCHV0MBdyhSVJdbSC5qSK6nCiQX IGiILeG3CN/niCvwQ3+c3d8PvSWKt1/YmHuVwPRo4lYE/X7eNpbGcKxOckixhlQL0a6kHt2+UbLq kj8gRc2zGLVNC6Jx/vz8qgxX2yP32DHE5dgMggVoITXI7d9FUjkVUjOqfjyNaCypojyfJqWqrbG7 1MDjjIYOQAatmIxMa7o+VfGTWj+WRgtKV5jywrSvC6KAV42Wk/X19Wu4iA1Kk4j0KY283HjLzaeS xTNU9OPMS7uGzspv1N3FDqncoWJ03e1yMyaSK59ahGByNMBwXC6RP2M+6Ehxrt7R0BAlUEiW8J3t psr16ipvGFX1QrD7WaOYwnBeNcfZPNLhg1gXERK4l0ymTbXQTkjPSYBV4Twqj49DSphQpqgk6K6j E0gWLkRgvgAD/T5g/Yzbl2RxCFDrJBlBsscv8CX2gjJJ0sbiPGTl9qicVXI0maFA1EYw7cfMoiZJ rgjfvPgy0IAcY1k+J+vnfnxPVuScIPmdLFUNGIpvdLBhdzuisoyZi8MSbBQjSmO49hOeV4Jdnoar LijEtr7Fbhsvr9wVbUiiQA9cgkqXp9kwHag4vAOSQVneQ8PWbYZGQ/7b/xBRKJeMX99Q9RclK7hp lLbWxxQKaXY2C+V2k5aqaYrNVyIEL8xIE5tjP3yU6zUR5/9ES2zcpfhmX4r4NKRD6aEVkaGGKBe8 uT4/V+sVdK4dC2orA50ydnMev5+EiEJwh0S9fm8MfaYR7TzD/cicB0n9NIdXQhmD/CUY42kQuWS6 6rwiqSgZnEQ+ifiESiouDDBJrWwPeH7catiidfHVMuEwVnIkVoU0EoB9JOIS0/95JpQN19ibzCyp VIGroDrmIam5E3FJt1xTbpUSHJzhTqZLySUR73MdTG1kdF3Tfne6ysQ7dzWZlrhMI4C8xUpn8FYu 0Jr50HmlBf8Zo7MCd+UCqalbMLVMw1OULViI8sX1kodFUZHhOpNwl+GE7FBwzdIcc30m4EMyYIE7 eGmOuW0Tkp0Bdy3J6yWGbAv4fhSBKKGAcFnoUT2bIEOpcMFOop1mArbLcFWNyhHD7Ixl5mRHxRor FRLEKkM37TD3leyIjCkYzmPOZRwVXu2LY1owHYpk2iEZYYGuUKE/0lQjBmZR+xZD88hKWhc0cDdf vpciEE5ULKGDzZMcnmEKTRVTxLUWUq2DdrPwoZUTPApdlUxQjjch2T3g9MDmQisFyFKCUrcVUm0V /QqVffBKaiiiDN9rlIsLmVlWYAE8x8ih7fjGspqdWWLeByOQdp0ag5ouJxf+JjniZoYezw45GW6t i5YDP+XXRnG5eYRxOFRjOKil3eMaadTM0kLUzmOsKNgByZDWwK+/9gvlXd7p2Gjt8wTc+wR7c7p2 F367CpcFTQ9WfA2VtiLC3Tv3o53gWzEJCHzYH5EYQO3+3k92vlVzTkeLjVcjSHZ/3xkCZIdWZ4ki OkbtLiC/esqkKST19DIKcfUS1c1s3qETqdCVQL+uexiXEO9hOhOOXCYSm4Zw2dLnyKl9fB1ezKqL EsXeFEMTJi77ufupYmfGjqV+iY0caUYNHMM6TEjjMAGNct6SNmo/ODljrBaSoERemDw06gGk3as5 em+HyV7cvX9qFZPhjNfh9ggr5ZCP0oBsplbSJ+OrUPqtyuES3ChPkZhaUI7Tq3n1q2sqKDQv4+RJ wRmB9fLrq1kVDAtyOLLjPNgNauoc4tAOXbhRp2A7IBkK5pDyfWwbCVHsLtIJLlcILAfg2Gpg4rdH 2T4JxYjfo8xgEM1mnTnpxZ/SQiiXEEaz7n0cJgu/Xr5YqndYbkIzC2jfNLn4wxCNNP1hQ6i9prKn 56RlaXHqdMP7btiQuosG7ZZm+KrqZen3b9vOKtUh/hg0sdqmV/Px+iZB1YOlT+7pgdEeicFTXY5W PHt+O6u1ZLh0iD2QWHZagzp8DosxskxSu8YGacwDPr7HfqmiqFbBZerm1M9re7PmhOr/glbEuktt X9ENWz1y+fjukbHULi/95GSGkqp4Y10j1ke3naD2H93skIzoVt3UeqKiOat1cuiXzmIomoHWHsuo 90A11kHAfTq8FfU4QFHfqtmTA0RlA60Wp9hG+4R+zfMc7Sl6LsOX310XYTtlO89UAs8V3aYBPfOA 7MH/J9AbsGomMJ3VQXIpGtOc7ayKKjDGjekN7oXKQ1ATBiRoDYuO9QiRmU6OMxC67oGx47uWJkSD C5vdDRos06GRrWYetBHrPPrXk0HkxLhKrl04A1NrrMo4V8sbmqCmBXjNmjvDeJrpH+SBc262E2hQ xsjqA+XxAB6RcoIBdXmgxKJ3+XgaONaLy89YN+XS4+gCpQVTHbz3HiftiIwwiemybn7xuaAuM1Ud BrtaugmzRiHrJaDNTehUYSvjrMoo4aQkbqYFzTO5GNO8uihxwQBcLWsRubBvLFCloO3uzodFJseS usQbD3BVrpOUC656qJCCdHvw7hAnmHHnGvHOAJbhCpFLHKzSw7Y8XfGJq5eXl+hB34TsAivRhrt6 vnwLmkI3RqzSoIV8eAWkl10AkugguUix3btw+cGnijjhjAX1wlAa8ELnYbETWEUfPVIswtfYKfzI UNqD8OGz+2toro6l8z58WEAdKn7YIRkBZLR7tzHUoi+9zepROApuOsMEnTQg25OteTksXirD0hhD mSYkO4n9jJ6IC1fhuGgjoPlWTONKg5+YzDrD7p5IlaZpLEGziQmQDGVrumxVWnkP6lLFhiYdnlXP JC2VwHWlEVq7ns3r1SQu36IiichkqL5dz46v+aqkBGll1N7KEGtYZhVgH/qxOx2LZJwWShTwJqiL gJdW+zh4+SLkp3QHB83WQjUpUgN7nmSuLiagPS0b2H+H8K9R3yBb9pBky9pnPWNBBZcUNwx9kHmo 3WeFfgWvTJskXEL/Z6zqc/HGfei3gDpU6LdDMrwxHDCccNwmiy1HR9H1rlxi2Q8uLM2qb5iao5tm oJoGaLtT9otqvl0GEeM+TYKamgnJ7pSz00/h8uZcYT/WwyrWrBKU2PQiYxQmTbh2CeJu/7ygsGAu 0QqczuNY53UjyPcJ0ljT7MdazalhjZRRwptVcn2QxYsLYo1+nMMLApuiIlbY41UwKFRgbQMqz8dF dINuNN5MgUXkx1HIcdV6iVm7WQuPaJjAnmE8DfzDB1t6PRlWmcNAPCRaL29qRukhNUzx1LdLhkN4 K5BYSJtKvbMKtdcJgUdx23X3czP7x3wWokyoFXBQ2DjH1mFZY3MJzn7+e5iVuIRmjtEnDsuxIRrn SfdnHzG/4W7YE4oFXEJQKanh04Iaw/LziENBuUwccbyVC4isRzfO3jr1nywrl/k/epGfSDOwUKus DCYzXalIVvhp306EBA0lbKS6DoiaW36fURDoIAWfFv1bbSuc3RtvOb2uEgs9HSHhFbeLzRcQkuWt u5ymWhIsPW2E5OL7ByOS8KO/7KGyieKhVWbjKuLQCP8PJrEzGAplbmRzdHJlYW0KZW5kb2JqCjE1 MCAwIG9iago0MzE3CmVuZG9iagoxNDggMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMjQg MCBSIC9SZXNvdXJjZXMgMTUxIDAgUiAvQ29udGVudHMgMTQ5IDAgUiAvTWVkaWFCb3gKWzAgMCA1 OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMTUxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0Y3LjAgMTcgMCBSCi9G MS4xIDkgMCBSID4+ID4+CmVuZG9iagoxNTMgMCBvYmoKPDwgL0xlbmd0aCAxNTQgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1ba2/bRhb9rl/B8LGWx/KY8+CQTMw6Yuw0iawY cZTsYkNkP7gp0AWyQJv/D+yZIUVKrErPyKbcBEFiQhHO3Ln33HMf/N374P3u5R7Lc5rLlHsyiSnL lPSUSGmc8NT745v3T+9/3tmrH8y7++HF5vePO/w3/Umm4rh+1P0kFFWxYJmXxZJmicomd9+9cuUl 9Qebv1bfvbPXjDKPeatfvekzPwijMDj2Vv/1rlaAdR+wiTswJahIBRctMM8AmwwC+4c9JNhq4mgr pajIsjjtQdq21aRnq6OomlbHDrbavMSJ3SVmiso4SRMnYMTJVpt+NbHwK5YoGqt8GJK3+j7Z9KuT WRidhj49I3E1ZYxwIf2QJDG3h7qHp3EVU6HivGe9YU9zs56rpwmGgI4F70Ea9jQl03CWhRHJnz9/ YW+xPQJBpDnNOBhoTRp1bA7Dc7OYq7+1PMZlTKWUuxD13e1cFqFPfiJcsgsne2lwEweSzVKax1J4 A9j6tDGutZhKaZaKfAhR31onL+dlFBbkVTU9I5dXRLvZa3uz7ROYMqNJopIhlIe1mxAx5UnuZLef eTU9DUn96429wUwemDgm85wyHj/E0UTCaZIhtDnPacpz5TGIBRA5dEdGhWRqj/zUfanIaSLUruDs X+SHfNtU3Xc8JjDFqZJcedwe2LiRCUnHudZjaZpSxVS2y1b90Hz79d22sZxEoknngyIRVmIS2dwC FPJWIxK9B0DyYoAahiRoJgW7F1KtWye1br1+xmtlgSTJo7A6hor1KTjt5/NV/OHF3ds3YLfqN5KF ZFGESxJIUpSnPrQIEfKWBCI8nthK3s0wsdXiTFCZyKQ1s40Wd3DHPShYsERDahHt8sZ+5PLrquKk EHLBlkRUU3/JQm27cZGiXmgcAjI9j3mjAIZVHNUy8x0hK2nvrHtYMec0VSAwL3XAFpHwZTWdzVl4 RaopYTDk6cKkknnnug3syf0l2B7+yDmkVJqqFvbT+yPnXENiLaTaIYdvOXwJixU6oEsfpsSfitJw 7lCT7XHngqFejmXqhHTc+lUwSRlDTbbthsOy/ZfO70RYTZegzplWgODIUWOmi2dUkkJBiFjU/4a1 q2mhA0aUfgAGHxUk40orVPCjA0gHuyFoXUtHxrVohlzbhjR8yeBBmM6QdM3eyHyRXAT1I8OSOhnC qs2/q+kFHOFWIEHO4RUXxfjJEdTJUhRR63M9PRkJlQESqqg1JBsXjcJfF2ERgIxG9cwufGRCVYLc YxE+XY5BTvxLsWTCH4mzkBtCaVRhxFGuws7g0uYwT3/3XKE8Ejnc0cG+pb8sEUAIK0SSH9YKs/RT eWGeRCHb8InJ4/d6swQ9VV1bOJhRc/0Gqns60Hskys5TRYLq1U64FWGUlhRWO5YRoXI2W/jGsqX0 yW0ZiC3EE6dy6P6eOXru6J5oVdwgfnp3ZFmmIbWI6mgfJv15KCEujbnIsiyqaVayMihRDkEmab1u uP7dlikHxw97XL6AxBSZhDJ2uHwHf9wjgbadxJQpmmbxzgq8X/OcHNmbqafEbbrpEu06ISQidwBT vyvgJiY3G646BO4rwNGoyGSGFvU9kLYK8I8f/0WOQh25BVmav8mrb9c3ukpMDQWeMpnpmuzMyA+4 JBz02/mzWriTWPpBNaXBe7KWoreipIJEIXJS6Rdk1CzUOUasKJdWk7IUhymXNU19eE5mpQ9RVZA5 NCrEKWIsKGe1yJJReVqaVkMtsag5a+mX/qn5oLYCiA4Riy94N+5BJRw/xs3an9MhJPdhifWQUplO OvS2hZhxCck9MLUh6YLJLSRdpX8bktuQhrPAx0tytIjK/ejLdj6JpiaGzInnAqzxeyoXEUoTWR2b 0j1sR4QmTK4aGtEVn78k80i+1AnMkEqxmM9lFJDzk9XJ+YGoQaFri7G1slEEASbDPtIuDaBamgNo Sjg3jckoXDZ3Mk5zhyWM5hwixgWyg//uEVIskVhsAPGsIdmEeXbWZQPTxv369uubcUUL5oUwHc+d cDow5ENEi0pyqgfHhiCHI9+FIB+iWQYgPZFkGUa0rVheuF1cX0ZBSv24QynXbdyY5Yl2GwejlRz3 pTwbTB6b6PWbZahFwJoeLNZverdnKpx4MjhfyRnNYoZ2iw2uZrwyrqVa+aUw4dcTyh0uDn9aLyoZ Sz3AxWsjmSHU5K8ur9MAVpCwOzWZOlDozmsbHot1EqBGZJOHPr4mNwKTMF3v+bqlU7f5kHRvzWOd kwr0z3Vt3YzDtCiFhg0EKQvCZBHoEQXyr/4oGokRfsIeT0CWEsnYl8Ghsi/G80Lk3ObUUUjDEkWH hpz8doKG1zN7DbRPcoOYjlkCDdSAtEluED0aX10RwNRiAcMv5hvWXl+MriMi8qnE/yh1kTCD+cPl Z8yQzNbG1cb3mBHnuAVEq9dZTpVlqQTHW4YULUgoH+NT+kr0cepmBLr56PmgnDKHx1MUQ9oNW9s0 F6qLrUjOzHmX0tSFRjxqO5redm2KA50/zmiOKZCNQ27Ww8tIzs0JJEao9QlNfOH4IRSt6XrpA33y w9vPPVvAbEfjng6enMdYBFEOp8OB5vq6tI7XyLuDGa0+qtRtM0eSY4UFA02b65A+mhCS0kVEdFBp zIbZEIUgviCczQNTmksz4tZR+ceffE7zac9RDcea79YDtFG3CdZBiHUeqpSwYsUlhEWEuEIIdmG0 0vHUdFyukBR0ywVm0LyOlnVpujQNJaFag8fiaMVc4qrDpfbG9d1rc5hyB7R7oKOncFWZWbVq6jDL zgARvfnbJux0M1k/WZ+HwBijYmeAzJTIvMQB++w9uV1bHmCP5LVxUhj7YrMUevyRAk8TyjPGndA6 6MQ9Em0X7UmG/m3W9G+HVwSIi1LcA5TEwiyWB4WXOIByk4rO3SKOBm6apT1IwzXj5XPyzei7Suu7 XV2XepKAti3Gx6eyy9AgA/DmQm+QFgsQiJ7SS9Isev8b7VtDp+2TUWOscxFsmPLEKh/c1N0arIxp 2DciCkMC2OtVdTxbQbsUAptiYED8+GURZHIBUVzvsidYvrjQ5oCorrdQeq0sTakHOjVeF0mwyWmT BjGq1vxeFsJweVXpsW+Bs28FzOMTCxOMSoXgTRzAOgTMHjHMhKSYeKgWko2Cv7zUAvY61E2+cesL 7OTLDM2ztcFs0Pnk7d1mgnj86S6D5JIKkysXWA4J4iG9sgTVicBbUbs6Cf0B37a/32OnXuFuNeFr E8QAqAO3y9oEMQxpq192+VY3E0jHbUvoQ0aKIAL3FeT6P1++/XJE1JcbLRLnWmtCS5vFvJomVzK6 RQm4JP5Cv8uCHBHpFSN85EDciJpGqdROLJujgRsDDOTGfBcujSFkFJadkwadTWwfKIhkHtMk3t2O e7IgGgL1REF0D6TtIMpNEG0oLcglKAnejLeaKGqlli5O0RNgTN5qhdErOTeUFzp4dZlzmGCSyElp zq3KL4z9KdYIu6rTNGve79aIR5IoVJ9HCL1FNOpZ9CtbKsPo0uksHeqWzz6BBhmBAlwWn8ftdmhN K5DVXBA7kMUeyqnV21Ixik7E36skcwHloDD3UCZ496ouybYh3VOSfWgqjCaCGnIw7dS2mYO2Bl7Y 1ksymiA0X/R7o6NGEV5owntfGDavD2ZTehzKJzEzyVlmtVOyCen/p0Y+KAplbmRzdHJlYW0KZW5k b2JqCjE1NCAwIG9iagoyNzUzCmVuZG9iagoxNTIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCAxMjQgMCBSIC9SZXNvdXJjZXMgMTU1IDAgUiAvQ29udGVudHMgMTUzIDAgUiAvTWVkaWFCb3gK WzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMTU1IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0Y3LjAgMTcg MCBSCi9GMS4xIDkgMCBSID4+ID4+CmVuZG9iagoxNTggMCBvYmoKPDwgL0xlbmd0aCAxNTkgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1cYXPbNhL9rl9Bi+DFRmyYIECQjMNr RNtpbFnNxLWT3pVNPqjpzHWmN9PL/5+5tyAlSoxKA2qpafIhsiV7Fovdt2/fLvN78C74PSgCWRSi 0FkS6DQWMjc6MCoTcZpkwf8+Bx+C/wbnl19ksPwSxPbvlyV+jD4pTRw33+q+UkaYWMk8yGMt8tTk k+VvQfUQpM0H238efgvOX0shAxk8/BIcH01DFrHwJHj4Nbh+gFlPGTbxN8wooTKVqLVhgTVsMmjY P9xNgq8mnr4yRqg8j7OeSdu+mvR89Syqj+sTD19tXuLE7RJzI3ScZqmXYdzLV5txNXGIK5kaEZti 2KTg4bfJZlw9P2XRGZuKcx7Xx1LyROkp42mcuJu6R6QlJhbKxEXPe8OR5uc930hTEgkdq6Rn0nCk GZ2x05xFvHjx4sLdY3skgsoKkSdAoBVoNLk5bJ6fx3zjbY1jiY6F1nqXRf1we6lLNuX/5ImW33j5 i4ybeIBsnoki1ioYsK0PG+N6S5pM5Jkqhizqe+v5q1kVsZJf1sfn/OqaU5i9dnfbPompc5GmJh2y 8rB+UyoWSVp4+e3bpD4+Y7z588bdYbYOTDyLeSFkEv+ZQFNpItIcqZ0khciSwgQSZAFADt6RC6Wl 2aM+db9UFSJVZldy9i/y3bttV3W/4680zCTC6MQEibth42bmGseyLBNGmnyXr/qpmdzVdcLvVSUU r4+n5T2LSnrB9Tw809X0jLN1ZRW2suLNBa+mZYgXYVUfh/Sh+piHFT7Y/iZ6MwpLfAWUDBXjJxNX vrcZI75ENAPNKuJEuxDR5jBVycFHT6spzsEWt5wf1Sd0mPW7EROsytiC1yeRPrVnKevjU8YXetQz JSDoSV7IwOdMp/VxNaXbW/D7KlR4Tb5vLmbGokovrjnqVshDfagbAZdTpjAuN0K2xnqK0BHhd1xH vK71Sz4v4fz2JL1QvOZVyEul53LBc4Zzl+X8FJ/G6eyX7S3m+IXf4GrfHi4OdSpMmiYupy7nZ2es RPBt3RNHYH7kiMt5yMpbgrOJU7e0R/ZIoIXMgayZh9UeSLZH9e6QLMmELtKkQbInaPXzZ9uwP9Tu 7mGUBnFFEVdB5mHUuF0lCm6uszzrmTRMpq+W/Pl0MQO2A6AvP9+9JUgAvhFqtGjHkUVAdl6GEQPY lVxP+cu3Cf/25UP87uPHF29uR8U+paQoCtl52iWPDhWRcSEUCMXfKyI9jDpURG6Z9EREfuRGRyhe 0j2BW6DzaaUKLaSUCmHlYRu/O0q4rk/qExb9gBwhgtTkQfH98g2fsjPdkCA9bbMJpcfWLFQhsPeI Mcoeqm1tUo2bOitNzhS5MEnspMmt07wpnGS9LTmjCXS4BpScVAYrK52yySs4vGWTteNyiAAm3kme +40G9yk5vdLsooStS44ZMKrP6P0SfFMsIckXZg2KvuuS84RJjeg7aUTfq+83Sk45n810ZLuGTFeC tTWo+S7/9fbq5gbMj8v6+J4/2qp0Ouc/01cVuDkS6Rx5FTFwwhB1C7zpQAll0NRq49RbrCAAtBXA FqKzqtEbVWgq3nNolJqsbs4OzsoXrBRRleN7+HxbYm/egLCOe7A4FZlJksB4HOwoJGIKgytI07lE b6FhtJDzBVq8TtKfjDdrMGkhoG66MIL7asHA/UFryOOi5OXcNrnob+vLl2tzJ09NIHqJ6zIakalG 95angYe5Hnm7B3uVaSZAXtXKol3aQB/e/p2uGq+2AI5bFRIo1yaH/to6zcXEzajzm3C54O+6DzFQ hknZ2j3g2hpE/JmaYOH3CQDuasKgTVv46xFafxTsSOlu8meHOOupYFcSHCwK5ITGgFdX/K6SwEKG rJzNIA6XFWjS40+2ItS1CKusCs/5MxYyvMZbpyxUelG+b8qF+fEt9fiWaOHNThgYFzPXJAFirlKF EwxZKakEnDdSW6MsQeT4hpS2UuNcEM5KfsaArdP6xBJhe2Kc615BlyLIxb+zGZuS1NZqIVbVOIv0 HPgWjqtFqQKloigyDIvdj+2RmXvAWZeZsgDP1S1dG1YIFggm0voYV/qeStcs0gKRZ9m5vZcO4Eap Cqi0SSqLwLRGu1SxQ/kxlqC9bn70grg9LreDOA+j/DDOtz3oMG7LpCf62ovdtPeoFc/5JYIPPSJl 9ePRZQttLT/muQZxtHRwWVy8afSZw6BbWsQiS2MnqksGLl9ffYQk1PG/JyrxHiGB/idNlQ5Wpu2q xH364pE5varnxQ3SDGMvzGh3mdTvzbwyp2eUFznwMcovc/ZuGJ8waYuwXL3enTkkR3qIRHsEmsQI SeepCrbNHS4sfh70xR6MUEUax0nPpGHsIVKB0darsOFLIEoWS5Y3L95Ra0mzEPZqBm5FAzzSroh5 2IwZbdCwrtmpkWDTTjOhjtiVLMpILVjBo7WXZLUmJsacL2JRTqQ0z/Yw3CMk9onSHCFBqyqtRbuw pw+HYeWO0D3occFDCZIoVeekXSb14XAVoqSMzk+vv1ZCPt68Xr655ndtD3B1e9OB+hgMrQvRFAol ZuguDO3u04+ff35mR44nc1mfVFKOL6DC2YWSQdra2Xh7GKU61z25dIn790WpznVKYQENyx47muV+ TP6ZeugSlGsmmQ4Y1Y9Kj9Tt5YmXgPqESVv18OLF7nqYQeLS2wLqp1sMJjim/Q13fH2xbKjZeLAu sXRB8+PVgVxyxiMW94DHLhYlNpNp8chhAdhHy9/DJo21OaXQYKUeNvmFom/KYsUk1zlWRbdNGiYW Fzf8yPx09PY5Cu8vc2wuoH2mSRemyE2B/vzSQORetFLFh1ssMIQfoFosSP/GF/TZ9kcb0gGJFt+b hxoTQLsHgR8YXf1eKTloc7D3ljkpOQ9gSOwVBuIzya75B/dyuke4FIlIlKRwaQ10CeF5NP2uvYbb Upe3qEURay4ADq3rksQju7i1wAhlQbPNa7oOrGPyxx+/vMe9lDOQQRqurK8rtBoUMa3DdJ+6UOin tFP3WR8vFqQd8nsapGB7QZ9Nq39hkmJlf5xs+WLJH40OKdKglL2H1GMVtbD5iammSMO0aXnxPX9M 5+U5/4THE9pOHALjgY6cY5HDaVSLRydwyTQqamZhoPgldqDa1INQmOMMdKd2owPHumiPXwvBZiD7 NLTZPmI07hmhCacqTgPtfMb+ERvddNRsWxcMPBsD3pc6FYyFBpghgtYtCeWIvY9TJhBm06o8vW3N BlkdY8yUS5FhvS5Ymf03Kr0aI7A4dvOkFw3cA0zXNNDHqJFr72p1a9ukJ2pvwY+mWHokqGuBGrV3 FXbX9lWTLZd1/R+AeDOZBQ5aJSDXi3P+SC9/mGG8Xk3fr3GeqvUBIV4rgZB1QjwwXKwZYxSEGWR3 wOasLY0AHLYI2CIfnQQsC0hPk6OI0b4BPkQ7sfZXNFo/51TQ7WfxSYwGrkdFQo2lF2UkkNDj9Afi yVolUHzzVsMcbiPJYU2QtY1vU5M6h28g9V+/CECPn+CZwzxYmewCeR6pvAe6yIymYipbm+RC1fLz DTf99Xq5pMessgIPenrcrIeb9hAIJBGAQvcsGga8DHLvHEplhscIVoxHRxUmJnijizgIRxJL+tFm jttCbGnhqFndMYckEbEbax357rURaBwyGejGpCYchx3td/WbMwBHGUYaBS4wYFFfhYGsi5VL2hAA Q6enMrZAfdzkwSI81qpBq/4uDsR9Yg9eAfX+2KK+A7lPmH0lZNlrHdwExCPh2MQa9hJs2tKx9g+z 9dbVwCIKYgzPshMQD3qpsahdROnCrOkIabwgK4YHZWwPRUG3QBiuYhFk4pe5fZZRAG2ImQCIyutD 9YmgEKmUTmLFV2WaRkCbRtu2hY6KQLHJ9fPRnRVkRsXLBA8EmRS7/USHXM/SdFWzeTTDY7e0SvNW odWF5xk9ZEYnJdub1n5U6zu0jzEiL9z+y4OvYgi2U9toJ1iIMhxEhHMqaN20yzLUJgQ7Iqsqq6ph I0pNK9Le8ADU1krsYc6usB4Q525P2eWMOgta07rmkPfOaUrCoJ/pc8RdO8KDOzZTzF4vjfXaDse2 MuOeDM8D4El+Ffic7EDMnJ6XTzXGag4K9qZJ/weIzStoCmVuZHN0cmVhbQplbmRvYmoKMTU5IDAg b2JqCjMwNzkKZW5kb2JqCjE1NiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE1NyAwIFIg L1Jlc291cmNlcyAxNjAgMCBSIC9Db250ZW50cyAxNTggMCBSIC9NZWRpYUJveApbMCAwIDU5NC45 OSA4NDEuOThdID4+CmVuZG9iagoxNjAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEuMSA5IDAgUgo+PiA+Pgpl bmRvYmoKMTYyIDAgb2JqCjw8IC9MZW5ndGggMTYzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAHNXGuP00gW/Z5f4fZjSYqk2vWwXabxMjHTwJCOWKBn0AoPq1VPjzQrsdIs/1/a U1W2E2cad1XAAfgQ8jK3bt177rmnrvNn8Dr4MygDVpa0lAUPZJZSpnIZ5KKgacaL4H+3wbvgv8H5 008suPkUpObvpxt8TX+S5WlqX9o9EznNU8FUoFJJVZar2c3HoL4OMvvB9uH6Y3D+jFEWsOD692B+ FkZxEkeL4Po/weU1zLrPsJm/YbmgohBc9IYFxrDZqGF/czcJvpp5+irPqVAqLQ5MGvpqduCrB0kz bxYevtrfxJnbJqqcyjQrMi/DiJev9uNq5hBXLMtpmpfjJgXXH2f7cfVwGSerOKTnJG3mjBEuZBiT LOXuph4RaTxPqcjT8sB745Hm5z3fSBMMCZ0KfmDSeKTlsoiXKk5I+ejRhbvHjkgEUZRUcSBQBxo2 N8fN8/OYb7z1OMZlSqWUd1l0GG6PZRWH5O+ES/bEy1/auJkHyKqClqkUwYhth7AxrbdYXlBViHLM okNvPfxhXSdxRZ4283Py4yXRYfbM3W3HJKZUNMvybMzK0/pNiJTyrPTy23PezFcxsX9euDvM1IGZ ZzEvKePplwSayDjNFFKb85IWvMwDBrIAIAfvUFRIlh9Rn3YXFSXNRH5Xch5u5Ouboat21/iahuWc 5pLnAXc3bNrM7HGsKAqas1zd5avD1KxDyjbbmEQiJlSGYUyjeEvqbRxGdXROZLMwb/GrpuFkjQox cO3sK1NKjuKV53kRdEtwoZTPH1+nN89+evvi5cC2Ubp7DKTkTHu17G2z7v2mtb5j4EVWUgkGfteO H2YHefjA3U/7GYu2wIW+SRR4gJ0Ixow6DEM/9r1f4XWfArNGOxUAk5KFQliN+Akm2U5lZjuVi9ek aYgN/GZOabyO6nBFmjmJ4ioi1NDMq3+9v/3tAV407+s3l/G2xgOTcq3w8hP76edni5lrx3Pgc6dW jBeUCc76BbrkjYfPj0gXXe+YHHf5YWg+eFnHUbM4LjwdGx6BzrdQpepd5ZIzHq462D2XjBGZoKDD +ahJhxmzXG6qmh7nKsdMFkpSoUnUPWkzaMSOd5VLJgvwYVEweZ9Jg0y2KXm0q1zskoyB4ah7QW9g 15e5CmZ9upk5yDMFuHAh+ef6mk6emWl5poetF8CycEtafKs267VMIkMF3iXR2t2XRyAHK1FooVIF Q8PHC62fL32balZKWqRgtEOT7ula10+m1W54CkpcCqD+yA4fYqyfo/YrrQuUcQZWnAJcRyw6RLI+ 5t7ZmJs8wLjKqFQcTG5g5bcMMK4UlWUx7rjDrayiZp5MG2IizWkhoCYNXTUe+NOGmEDUw5pRi0ZC TILGybB6ScgrtDyTAtmuIROKptyJnW8q9Fi66w8j8kZu2JZU65jWzeJck8s+VfAkipJabaLY9Gjv +ncm5ZlcS+uaqNgFfXuWybWwrgXY1iIXMlfJTULjd5d7ja2KNbXXPfCyThKZIDpOFBkg7rLMuEsv eWtCo9GhUZFKmOCIf0B02LpsO5VImiAhtvcIJVnKRHf3qObkNVnrjiTG13VfH+OJ6PqV6HyNbJi0 R+mbVQZMUanTcVHbWEGS+PmNqGEuq5c17Ndbtd3gfEQnc69S6Mbsl0vkBk5NkEb2G/qj1jc2n0KZ LHXvdk4g4W5J9sfDl5OuW6YQ5BkHhHqs+0Thl5eK5hz12uGAzEs3OIL29bqBj1F+pcaX9vW6wdCk 8ep3cUNsphoQrzoKDe2sWchkUlhhBYfGLHCq67GvS11YmsUGh2ZW09BZdEmsMKhh8VDR2CUYvrit q1Y2PBF65OZEJJcutce0MNVGVfHvG11QqYZBCOp1SM44lr3d4lSiIqGMACZASaldkcRKyggVoGks jGjorMM6gqzDjJqjHdB6zEhBbZM0KYr0XCKHuIvT7dxl/SrGatbAea3pNvP1OpE/1AC/KAb6xUWc nJPXj8gWpzIVeVNHwixfO00usWJAaIElT4uOXEEuLICOPus6FTpCLdQnqXeMNRxScS9wPEIi2oHj 5206JL1+2Ljf6bkoHjtsHLVoIHhcfBhC49Pbq1ckf//KHRThOl8QZ5mkaJIBip839C/buWZgHrHO hz2xt15aKDTp05EMDRZASeDFWXtWsg8tJ8IE9LGyLLkLJrQYWGFtFt7aBVg6fAvJu6WWb5p5He0j QjNfyg1Q1JwJ1cuY/AwcRVkDqK715TSWLOtQtyQnWjZmlwolnYgk7Kzl9pJUm2bRLGpa63qgCzIM D3VvpaEO/6RgiygKprPWBYHK5ZrFUfyL/txW887QhMS0qKjbbslwyK7Hs1yXeCpUZCU4Ixrw74oz ehjlh4u+cLPDxYFJ93DGt7ZF0SMSzR8IQPCxyhZvd2w8gnOzDEoYzudzD1stm0g0parQiZkcMiDZ LBLwBt1uVYAK9GdxUQNDARLABoAK9GObhQZBTgQRqaIlS53YYgRMM7QPeGB3QBO+Gr12vQrxT3Co jiTdXLwlgI6biwsNFmvoSfG0gMAxE6cUZi0hrjov6ESAkJU4UcvS9nxhXEX1MOmIUt+T5CwHRqEy dNRNaUYTZOahrfW8G0l9H8z/sQhWIpiHeODBXA6e6ePIFQtQLO3jG/suztBXYjYHddHfxIGIfkjx gI9i5lBfx3wkmAs8k/0zZj95bj/SzNvHxWKmvwn36Os87F8113tmX22v11790r7Y/pcr+43Wqs5W jAzpy7XfaC8+/OKju66tzfo1uH45c5rQPaCzxtX3HMhDcqCY9RBBt1Edc9nfKPBZzR77jTJb4HqI fgQY7qIHqKhUR/y/j4AGD8j0BJVLL3KFDXf108HmuZzxgGxCB86weSNGnbgZYZQXSqj7TBp0Iz8Z xo7a1BYqwwXXa1ZDBjGyohVXITZKgk66mStmNIJdb2D1ElMBRczWlkJDpTV1b9oCl0G4k6zoF9wl 0NjsPdr/ApNdiZGDIw8o/qJkgsKdpsqJLrbHzBVB42F6Q3D1Oa1ZDTqOriLuZ7yN43XXNamTORM0 LzD/gPsjzBpcnEyuJLjPvzdJXW1ras6aCDqkQrO51QYthn1phYnrJLSnDnU17TrQSWB0Uvotwx1C vig6UAgw7+d0/uEDa0fYJHMNaxgMyjxsmraXgOoDWMNUydCk8V6iJBwynz7dSBBivf6cxFSuwvqf +2mkJ9UYqXCQGK6QdNAvDJZVOoLBgOcVzlY0n8c5yVpCECSTpltffyXUayakE2nfSsyVawF3tz5Y vASPfyVA3QEUoX7XKKGsBoXfgK1Pugw9qZ8p9O4+yyDq3Hi665laKamrJT1yd+uZdAW7jYDWLp1U JcQR9CLIyFtoJQlUIDtRzCQMHhzR2QVOi3cc6okoMQ0pne0/UTGU6EswMv49kbjPm/SNKNyoQQMC 95rs7voyjADyiVaUkew45Eie7DXsVy0pu32ca0FCg9pjq2BMm0lc6Nsscb+l2XgX/uBRUY4ocoKj yqUMqeEcibePz/oD9rP817NXOC93bi+OMbHEeEAOautuokf2HtHv7OAw0/ex3pG8badKWTs6Tnyo yoFFffs8MtrZd2DyXovMbbezuUdUfc6ekTuBYYVtv4w9LlF+Q37TpYHh/HifgnTp2xfz7dSVAnPz Be6bcDbcI9SOif1uRkYKDk1NuWlqPtF2hFG7aPMwyi/gvEX2PuAGJo0T4w/kgVGkd1Wib+knBTR7 AAnx0WdTUcMwV4GTqtUm6eqYrlpCc3Oqz+FweG8V992Yk3nTZtS0Za0PU46BE2jTLilv24yfq18M KddFuueKyPKuoszu+z2AI+CJobUTUmSB9DD3VImO305I86zlhPdojSdLdA+jTpXoA5PGE/3tHi8c 1hc9qdOH2hQ/PcEKBp1WIdQG9o7vK24gG2RDm9e/SXBZfXPjh7Ise6unSBDBJc04plA7q13y+QV6 7Aemel+1AoI5u8RKelu1h7/2LaI9GxMlZpEz5tSe7kPpFrei0wgDUG0f0HWkQKDJzjuYnptO8XMr PkYP/fi1b2fd+bHIKG65cZLgvIjtl1AN4WHUiRBoaNI4Av3YHS3oibtOittJVJBJdOIM8uRr7y9+ s4eqPEPIebiy1wIh/KkYsjWDEKXnffTM9aTmcg2cRcn9zHU3CbTBl2TuMiSXVOou4Y7W7y+TY3sm /R/peEZ4CmVuZHN0cmVhbQplbmRvYmoKMTYzIDAgb2JqCjMxMzIKZW5kb2JqCjE2MSAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE1NyAwIFIgL1Jlc291cmNlcyAxNjQgMCBSIC9Db250ZW50 cyAxNjIgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThdID4+CmVuZG9iagoxNjQgMCBv YmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+ PiAvRm9udCA8PCAvRjEyLjEgNDYgMCBSCi9GMS4xIDkgMCBSID4+ID4+CmVuZG9iagoxNjYgMCBv YmoKPDwgL0xlbmd0aCAxNjcgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1b a3PbNhb9rl9Bi+BGRmSYeBAg07CNmDiJI2szdtx6dstNPzjpzO5Mdiab/z+zByRFiqxDAUqpxv3Q +DkHF+fee+4Dn4Pr4HOQBTzLWKaMCFQSM55qFWhpWJwIE/zvY3AX/Dc4f/6FB/dfgrj678s9fs3+ JNdxXH+p+0xqpmPJ0yCNFUsTnc7uPwXFbZDUP9j87/ZTcP6SMx7w4Pb3YHEyD0lEwtPg9j/BxS1g 7QM28wemJZNGCtkCCypgs1Fgf3OHBFvNPG2lNZNpGpsBpL6tZgNbPYrKRXnqYavdS5y5XWKqmYoT k3gBo1622uXVzIFXPNEs1tk4pOD202yXV4+XJDojc3ZO43LBORVSzQlNYuEO9QCmCR0zqeNsYL1x pvlZz5dpksOhYykGkMaZppUhy5RENHvy5Ad3ix3gCNJkLBWIQNugUfvmODw/i/nyrY1jQsVMKfUQ oiHdnqqczOmPVCj+k5e9LLiZR5BNDctiJYMRbMOwMa21uDYsNTIbQzS01uNnqyIiOX1eLs7piwtq afbS3WyHOKZKWZLoZAzlce0mZcxEknnZ7ZUoF2eE1h+v3Q1W5YGZZzLPGBfxtxBNJoIlKVxbiIwZ kemAQywgkEN3pEwqrg/IT90flRlLpH7IOYcXef2+b6rub/yZwLRgWgkdCHdg03pmG8eMMUxznT5k q6FrMl6QeZjTIqTPP169pRFh6mxe/INQ0mbUTYGUSvMwKuZnOX5iBV/GL5ENTc/pq6e38f3Ldy9e 03Ix39Cr3379+OERPZ256rtdTvgKTwNZlcVCuQhP74OVCxoSTj8+PanOeP3y3bvXb6Y9V5xARycy 8DmXB6cOiKMdpxBQjRJNctwjcK6mVV2AIrS0dvIANa2+TzgTJpXpANK4rPmBXpHIFIzQVaRMsSGR TZHlv7efUqmWhPa9Dx7H1Lw8Lc7WqA7CQs0n5iRPWMI1bw/m4mvH4iRSapI6crKfEvaUwt6iO0Up LAwY2YM0fv0+XjKIki5lVOclI5iG6cDPS3aVtu0XANZox6DzknFIdcdgVncMXtKyREHXpaO8dpqc 5ivCCrgCElExr4L0+yfXl6/rRJaSLpdtJvYRAR4iFrW3/z35CBdMCUcf8WHkAcmkY6QHKD9G+jpu x8gepHHHvXxCH883K1VAOF3QqqO1JDZMh4Q+Ijag540YasK76MK71VigJiTUqlxEYG6oqLTKiRM6 rbjYdutMzJmJnZp1XLE6x/REH3yNFKFEt4AVOCxVET0jipanKlpO62gCjqaVTUbuZzhSLtKpZAlC wAMt0GF5Qn3c7FsC/wimvyjujyPqhf3LS/qYI+jb4qSqTPSvb630MSQK6c818+A7lnnuqf2AoCWE tlUtD0awD2+48QjAq3D+At+I1JLCZ2ovoao8pZ1z2a83Z5jtb4gPGOHVqddGsFRK7ZKgNgSd+mUx byLAkjAbp4p8SfP1aoWyEVkVXfyZUxf/ANDcaMYzlQU+oLd2nGaw0FZDOlFMm2034juphnxAHSmr 9iHtyaoZRZ58VlR9wp0iqPMTNUfqBAk5vMd60KbJtdCAf6eK0rfwI1RSz85tRrUpGGmL1/TNZbGi N8haR0qyWkmGxpdwcbRqXlEuGGRDTuckvFHRT3kVLOoD2vYfU2u+seFvTlgIzXBRCwwbOfpntH9M TSskBGIIT0Xgc8abqsOEgKjSsFxAQeBj0rDduaqUTKhtZh531ZZqbx6k05yiRp+HVckRXSAMMolr qLQePRH452aDzhgkYQj+hRTayRLWHnWd182yKgM0Nz3tJW3VnsZtGe7Ew4Z6VpFuYz+paNiapfI6 ewZ8kEYBX1BiMArBldpv1K1BdDSsf+qyfFvz9F9C03AN8vL8WA7IOcsy45Tp6uta2uEEPlSas3VU n3znvnGT4Q2Z9NJ4miLjaR1oD/Cw/S6rtpdYNWPtN5pq2Z5s22WaVqRLg/ZcKhKvUxwpGCSZhP4x zRRhPBh4yfQDhGVbDfuAOlLe7kPak7ev6T9RDNap12bvhmY7AneYuLexowqVHUW3/KSV3ifz3Lrh pB7XZokE5RsX0ilO1uGiKYGti+E4jRahRXv8TS037Per+MkHjVxbLmPqklMEmwhZZcdcP99U9rS/ eqTToyxIMGZ2USvNYSdN3hgxc2MQQpIGWF1Wj/ur7aO3Q568b+1fLmyXYjcctlzDPyAYLeNs0rPi CmYvFyt8fRXVPZ0jXYLmGKw7JayHCQXJYbGHBYYGNv3aT6BBOJ823vPUbn+lPEjcD3CscA8VbjB2 /p6aMsnXMf1FTZlxRP2mzL2N9XP622PMeBHrLMU+xMIqXut8v69J3syRm978OVyJGpBwXXPyrm3j P1XrEPPku6ojUv3+kdwM9UAccyc/u4OcX6l5Tt7Cp+6o7diWi6Xti9SyFrK+YvKEPZCEGWN9ywN1 fRf5mlv77qSVKuNEtdnfUHqCENFdTvXNTZHjjCHKmiPdBYoTpVPPXvRNgXEQ6iq7g1DVwQonjlr6 VVW+tcHI7eXEFtHHOiXUvEmUU3bt/OPR9i7u6HINr8KBmVquONi3uei0BRiKi65sUXtSd4erdbTC mlo+bfiX2LbF/jBytccxjxT/FeR+km03+sblw9Hkvg+oI8n9PqQ9cv89/dCOhawL1oUxksLVybRr H1wnWM80adCHu+daSW+IUHkRZgjn6MescxsfX520UhbN9z9/ST7OmMLafQvaRWN7XPsBhae0o06J jpiPHR+9KUhYnra2mmJvX9okZ1Cd+wDzsBWGEL7zYcxKWJxhfN6HNO4iebFyt9NgMuKy2SGVYYlG n2gM1HHFpMR7EtQA43YCpJ6abPuKB1urWjnZs3QiU6TfNOHfk7W23VmVopf+4NB4aKtq8nmOrh4j 2EJ0fj2zyy7XFyF4P6BSDNm/Dm447/RI57uAsO7pRPfWWlphr/iham5Idq9kPoDkwqm2d6fGIPXI 7henhptVmPJ+uZ99/S1Wu8fiAKh6iTVbXL6rSgCrlD+cXNUjs6WqGt92cGGfz7QOWktL++Vt665d GLY1kP0b6JcwskHHDpMeLGOdTFtBQNiJKtxU9v8OcmrLUUyG4zhx6jAfI6cmBtMvZIoerPH0dThT XbwZL6bwaipFphiBNPRnbHmgGWemjXt4mJRlCnFvBNgw8k1rq0ywjNs3BmOQhrZaYRPNQ6cNop/L FfIYEx4j7CvSXbL3WTWEdbilXDZLOYpPYbd09kDqhWQMyg9KpLvPFEZiMserl8TwxA1TwGf2fey3 malKE8HnWfdIt3pv2T7g5YJDpmnpCglPdmcLRHYs2XLi+wBp+Jp4NrobzK2CTJK9caF3g4cLj3Zt auQC2+mQkniYobZB/Q88ryE1F/ht0qOCNZrpO+nhAWpaVnXiww1SxarLF9sOZD2BKdBmjTAO6zTH cGq4Kz8uupufomoXdpQhUwTe5kQuCgP4sIgeNkrKtl/RrevOY/dE0AkvsJGUHm3ZV4mEcRT8Tvjt RNJKuT9oPDzeQyNxIAnRP620n6K2p1yLwGrchM7qDTrlm3o8IK7KUkzcgjSo8LSt8DxO2xEouP4/ tKWIWAplbmRzdHJlYW0KZW5kb2JqCjE2NyAwIG9iagoyNjg3CmVuZG9iagoxNjUgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCAxNTcgMCBSIC9SZXNvdXJjZXMgMTY4IDAgUiAvQ29udGVudHMg MTY2IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMTY4IDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g L0ZvbnQgPDwgL0YxLjEgOSAwIFIKPj4gPj4KZW5kb2JqCjE3MCAwIG9iago8PCAvTGVuZ3RoIDE3 MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBxVvvb9tGEv2uv4Imlxd546y5 P7i7TKxLxdRpE1sI4rg1DuUVOCTu4QLkgFz+f+DekhQpsjK1K1dK+iGuQwmzszNv3rwZfo3eR1+j IuJFwQplRKTyjHGrVaSlYVkuTPS/++gu+m90/uobjz5+i7L6v28f8TH3JNdZ1vyq/z+pmc4kt5HN FLO5trOPX6LyNsqbB9u/br9E56854xGPbv+I5idxQlKSnEa3n6PLW5i1y7BZuGFaMmmkkJ1hUW3Y bNKwv/mbBF/NAn2lNZPWZmZk0tBXs5GvnqTVvDoN8NXmJc78LtFqprLc5EGG0SBfbcbVzCOueK5Z potpk6LbL7PNuHp6RtJnJGbnNKvmnFMhVUxongl/U/eINKEzJnVWjLw3HWlh3guNNMmR0JkUI5Om I00rQ84sSWnx/PkLf4/tkQjSFMwKINAaNJrcnDYvzGOh8dbhmFAZU0pts2gcbhdqQWL6dyoUfxnk L2fcLABkrWFFpmQ0YdsYNg7rLa4Ns0YWUxaNvfX0h2WZkgV9Vc3P6Y+X1IXZa3+37ZOYyrI81/mU lcf1m5QZE3kR5LefRDV/Rmjz52d/h9V1YBZYzAvGRfaYQJO5YLlFagtRMCMKHXGQBQA5eIdlUnG9 R33qv1QWLJd6W3KOL/L9h6Gr+u/4Kw3TgmkldCT8DTtsZnY4Zoxhmmu7zVfj1NzfJEcQUc79KKLJ C6ZAER8wqaGIs4Yi0uuAor0ZUpu8dfYwbwU0CC1zGXkZFfGZ461h9HCzBG1Q6VlPnmse1BHrnDNh rLS+JoFKz+ZvXtCT6pRWc7pM1Q/ntFzg5yQhZ8ukjJ/RRNEyXpA0oVwx/EOpYmqvEppIQu+rijIV G3JOVu4L+ifcp5LL+qHmW09nvkz9oavwaSEMLsUooXxaiFf31+/o1YKsT/LvxYb9XebPdjUWe5jL lWJKWBGFmFudqpSm6qq+lGoer2h9gMb9OAOuZsP+RN1U83S1qA8nrqtKvKX0JEHprP5Dj3QX0rJM eHVzoNoLF2aMX60IvanPUibUEl4Sg4LvYm0QW5bgaRdxC7LEOXF2Qj8T1T8jSTVfkfTtYY+qcsZ5 piLjf9QAoNyDr/TYzcGPt+PkuMw9Bid9+rAeJx+2aVxOHgeTu8pJD5OTFg2qyZvXtKrQEPYhpuy/ CEsWNCWMlAYAaM97EK1zE1G6QggbKBUrh6MujJtcPGxYIhqVkShMzfF8wPBYYZlxZrKt5fv7heXD Nn2vsJy0aBCWxXP6qSvL64h8dd+Vr526GMpXqDTAFWdWScDew3aObxOlFpUqqeaA7TJ2teys5RLV 3KKo1blxRhKp6jy6kSWTI9hHQVscqXTpImNFIbVP5qwIlMizMiarS7q4gtXOzM/i+pLihPGVU5HO KanlSjyBGm7xAPAANKqaM0YWCxqT5EalLwERS5SwZ6BgTSVctUXusGixll+1hWyhM6+CLU6e3PrH 2B6FLM/RAyLE1kZtI/zjGNu/aPiUsRxKQGHFtEljwKCffqN3TVjfUcLJGQLBETF396tV6ch0Q5IX 6iplhCoQ8SHZGSbLuqx0AXKk0NDoxJX2otUNLzt4gBiOqYFWPNKtbU2ETEumYRESiotGMS24yEcm TWuSLkDQIZlyRVb+GVU3HWHKDBeaCV4gfgcOm7YuzGGb7apPSnHoKBDY5aRJ45Sy530mBTosTDLl Tv7I7aRxYwgKoFGjvtHHXx2712CwuRu7bZ+UDSYaj6H3tTKzQ5vp6H2IUfvHlY9c1PH7HSYNmdQb +g78/A6KQGgi9vNOn1vkmWA8y4FcAbd4WIfBHDSyEJV3mDRwmCNxwQk4HAzPJlU/zjFUVOhjQqx6 nKMQXd8+Tmh+cBL0Ryg3Xia1ml8r2tzRRqoAHcCEbF3JFwTct2kN+9ayUXNqwgvB242INtWfw4oa igvMIgF7bXT6cOAA2NuDC/awJyUTSrXt43SpD4K9PYzqYS/AqLDgDOUfPewNTJqu8EVBBWTfEiob ZLd4xZ3mC57aTsGh+HKOiZvTSlsZGKrbilSn1fyKbyqOZUtd60/QlcIXxirpu74jMVUhmOHCJ2gH enUtqDrm7dTqAarN/uJ1FxBEJjNuIu1v6nnvT1ySIU5napvlGhiUrTtrd3X4F0ug3qe9UnVYvAB/ Y1Jq1A7/8xwLL7BQlOdiG0v6E3F7xLDIp+j3cPGwTWOmG4YWm+Q7jCRNWjQo+cV7+uTPqd/CA9RO KB7pS2gbN2Ui2wD92n9gkGPnXQVE5xMnQI8SHzwOSOSFZFYaL3kH7Wx4e7ZHPbGcKW6wrbQ27vv3 sxZTKilMMTJpup5ABG91jk7MOLgWwI1gyqogO/dPLp905yZnqrB20qRxvn/67e2g8oQtWtZmTfNp a7FHkesgowKgetTR+oBQR+2wOsi0MVv3MuCnAQoFUbstRu0i+R1Wexl13MG+p0n1YL/4SN99uu5w 1jW2rtUAnCUYXPX8gP7i5vkLQug1fu/m+6/fvvm1j8VDjMBFgVWFgkfr8/gQNnoirp9m9KeL2+z9 6xcffm42FeKACN0Dl/sI1YoVGguRHkvAtbC/BCez3HE1DjoWu3GHIb1Xd05m9jCWC8UyzlFEAowN 8B+SKbQp6f2nNLNuoXSLZvXd2Fg+YdQYnvevGD5I2DVvO0waIGHxO1I2NSUmB2jinIactmSs5SwI vpheX/zTDaBSN1dy04UypU/0NRI+xWQa2xZu1MbdvgQWLZRrID4pdHtHomKIj8xar6FTY7B/idwj gTRYmCoyJFBrl0+2HyuBsJFdCHAKjwQ6dDeDUYKWBejNhE3HzR+FUYKxVu4yaZg/H6huZq99D7Mi i/IZprkUG0mNDldvViE/FgmGto1CsE4litE1xtdYxoK2h57npsSKCBZC1LO4/Ac5Vg5lBpMd5TWd Gyk7B02mQmHXAyW+Nc8nbhdN6wgMuiB/XBF4/P7ipGskHAA4rLu/0C2U0buFWtzRJCUEY9WqigF0 q6Uq44QuOaowRCh813GgTBWYpOMNJx8qs+UkmwcGDJfxqnTrlm490QWg06a6syHggPSJwrKE+30j udVyscP7Ix3X5uBDxktqG0VdfVWOh2LbtDkdfnabELiudoWiPROi+iWu0K0+NuIcgRjezslxsdcn gl6oqwMfGBUqB1VVAQfGtbUbiAHFYY961bErhf5J5MJLGndSC29FGjhxnWH4sV0UrSrbu3l9IfDz xqm68GyWM7EInNE6AK9AdB3rrUPYqJfHAkFsJ+BlAZ/cq9nNNi1qSVIXaWd1qNVPQc9aLhtVFRDf 699DX2z600Wpc+iBQ7J9Y1Ll4PtZ7gU5rUZMVodtQSDFAAONxauhjW0N7O8Y1vjXoce0IErmWFyD AOLBoB4jMvgoRJ3IMGXUcSlU14LsMGlIoX6k75QbCM15U7sVoAVSQ4rCixcpsR+7Rnjif8l7IKFw I2wNEXBo/HTcrdoCi1ceFkvCnAjtaq6TQGqAqHVsYNv6ECtVz7SaGcyRUhzjIi59J1rNPiGwFziE Nk/dxBsyjzttNb90jGiz9nZ0teZKDZdwO4yOSowKd3uXcJcb7R3JARiLY/HOi92u5w/O/Lpu/bKp av3+a6OFIVTB7TfQHudZI/1lE8QOxq2jn/1MHu8j4N6PtYGqMowo/A6NgSDWasF2Xdk9aI4ZN+nj WN9urfPB0Y67rckryJ/bs8F7nJgfu9pak466aN6oK4AH5kgNd1+vvw6rbZ2T7n6OE34SsyK8fOhV YqdZ/bruQk49xDtFeDMO8loRhRi8GS7/B5jbulwKZW5kc3RyZWFtCmVuZG9iagoxNzEgMCBvYmoK Mjg0MgplbmRvYmoKMTY5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTU3IDAgUiAvUmVz b3VyY2VzIDE3MiAwIFIgL0NvbnRlbnRzIDE3MCAwIFIgL01lZGlhQm94ClswIDAgNTk0Ljk5IDg0 MS45OF0gPj4KZW5kb2JqCjE3MiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4xIDkgMCBSCj4+ID4+CmVuZG9i agoxNzQgMCBvYmoKPDwgL0xlbmd0aCAxNzUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Ac1da2/cxhX9vr+C4nLr1VgecR58JWKdpWPHlrQxpCgRihDoB9spGiAFUgP9/T2XbzLr 2RnalJwiaaO4xuGde+859zGTP70b708v80SW8Uwn0tNRyEUaay9WCQ8jmXj//eDde//xzl98FN67 j15Y/efjO/zf6FeKOAzrH/V/p2Ieh0qkXhpqnkZxunr3h1fceVH9C5v/uvvDO38luPCEd/ebtz3x 18EmWJ96d797L+8A6xiwlTuwWHGVKKk6YF4FbGUE9jd7SLDVytFWccxVmobJBNLYVquJrZ5sym15 6mCr4SGu7A4xjbkOoyRyAsacbDX0q5WFX4ko5mGcmSF5d3+shn719CzYPAt8fs7CcisEk0r7AYtC aQ91hqfJOOQqDrOJ9cye5mY9V09TAgEdKjmBZPa0WCfBWRpsWPbNN9/aW2xGIKgk46lEBmqTRh2b ZnhuFnP1ty6PSR1yrfUhRFN3u9B54LO/M6nFcyd7EbiVQ5JNE56FWnkGbNO0say1RJzwNFGZCdHU Wk+/2xWbIGcvyu05+/4lIzd7ZW+2OYGpUx5FcWRC+bB2UyrkMsqc7PaDLLfPAlb/8dreYBUPrBzJ PONChp/jaCqSPEoR2lJmPJFZ7AmIBSRy6I6UKy3iGfzU/6Yq45GKDwXn9CBvvh+bqv89viSwWPJY y9iT9sCWjcwujyVJwmMRp4dsNQ3N+ZBIIILO7SRiEmVcQyJ+AlItEVe1RGTXDqQ9dKmhbl19Wrci NchYRcqzAuWJFelWN3k4pKCBlF714rnSQZ2wjgSXSapSW0iQ0qtt9i2TG/3dOcuDTRJscrYLNuWp 3pwV/jN2Vm53O/of1//89cP7J+wqD5jQvNyuC+0zna7LbeEHe1aebvQZW6uAlVvOgzxnfrC+1Zvn 7HRlK9E/dQY2tUOC00i01Da1A31cBbX9uEvGTspT5uvBpxU5viTB14lym4pFP0JkEc/iNPFcPiJ4 CXxsH5Sn5fZKrAfIf86DgF0HvDqhny7fvPmFvfhw/ZalAcuvdjtRBPvLRb8HGRq1YOz2PQ4JZAaP 9zkN9BmlshFnRwS2SwKZAapPIA6g3BKIq+rvE8gIkllWZ69YWbLdIIewW1VwBQddr4Oz3Trv00i5 9SlZUFzlbK3Zs2BNftxGYu2p+K2SYk+pZODgi7ps7x8CdYVdC6LFjOyBz8+vCuTCVAQDyO2vYLf6 SuwpAClBdj/ts+duEySFvsrFOWzTJKc+tB/oy8OMK0gcmwzaMcBYIJkaQzPigyqEME6llzTQatY/ ErREWBu92xTwPrhQa05QlhDB5nKEeGVCPIOOoFI5SAj862DMB8p8cRbyLGuV7xEjPlTmcwH1QJlv DMmc+W6+YT9c3IU32U9vXiNbIbU1f3vzmvIhD/ZXVb3a0C/E056S3kZfkWtufRZ07abKP/EPb8vt Zp8/kGqKU3Qq4tCq40qpS16XpfxXzj5cnIwDydgTnhH6lSLKvBbfIbk/rdYcwmgS2TbNxI4gYtRr QmTyEKS/FEUuYTQBVRVFR8qiTkC4gHILo2kFcqxS6wTEEUijSu3mDXv7/rpXqbuAF+UpdCp0BNpj rYygMgTRkxfPfCTzg/FzW6wVuz6RVMOwH06WZc5U8SjB3KL9VBvmdLD+jLBRaMNHaRx3kGwY88ll EazL0xExful41mHC0c6JnIA52ArB4yp1+4iGz8JoB/u10ySTFzt7O00i2ibNIKLDBDMnLzaAmqYZ NzvNiOgwkyI5BmkU0bBT/prKann9NKxJ8ZXbQMC7d2s8CqW5Ql1nMtz0NH96zaoyn1IMmha7RsAj uWC4iByzLpJgWZ6TOOY0Vk6oH4rolOJSQ8sensaOpmaf12qrAsPY/+uJzgHU4mFRt9piM6RRWNxk VaOJyC5Hj4xaaEFeeV2Rq7PARy1cl8Yvq0qx1oRt8wbj7k3FieA4CEiizGX7OAod6SSMQHDNJ9oQ nIN3ziG4dlcgFhEP09Y7v5ZqxgGUm3e6klsvw0aQjlQzNySZrDcqhvRmuSVA5XEUC9CbAyw3Sw3p zYZxE8k1qnUoEwOkKeM6S6YZtsoU6gyVgHcNwKaMtqytshizvTQ2H9/UVp8jmWyKIAFpGYcSWcpg pymo+XayGVcJDCxjkUCGmyGNuAEpPdVX/r7SJBdPw19fvHgaP3n6hEoetAwLvxq1UGGTF/mauIJo hGvfr1v9OfqL69sA9dKyVU+XgbGtFdm1CwOBPoe/zpfVUoniqdAKErBGdki4TOPFga2GIYwJoU1u 6UoMlBdcivBgiTF1zQfTUi6glo2Xjq2OQBrFy827qtCfjC6p6QZhhU4BXM6ey2ZIEYEEje2ExBuD NkuRZresEnb5jw7eNwOg1AAYYn3CBaADJASEsyzB7oqkVU+M8DEiPBwQ0xh945A2ZgRplIBnJRZq TJjqIMVGXLN+6tm71gSSDX9g8TTVShyFNIqHN80Um/q09SwOlBFsMFrC/G2PaYhgO8yy/Zyh6kgD hR9g5q3xJ9rSG1TAWHtc51XhsSyBgByVTHsf+AqqCiEJkp64gDmUaxtXxZnQ+nk/abJ3jRlB3bsG /Fa10xyzrq+mdWIwa6i9IUc5iTyJNgcVm4uiRr+ch9gP9iJ71G6ZyFX2i0wTImFCNGXmbupZRQ3F WYCJzx6jW15Nc/ZYTCz/jU2MoTcofYaRcBV+i4ZV7xg6xthUWc1xaxdwyK8zPDbFBqVA+zBqcD2+ LMMgFIgkvNEAaXr4tCBUUH+m8DGeK9Z1h6ZPAj8y/LFoEEnMlEWWTmGbs5QDpBl8DsmNJhGWeCOZ YpCIzcwDzcIpn//P3koT7rTR3NhZlCJNQC8GSA9L5/A3GYXHIY3o/MQHK1e7Mb875OYZBhMKLWhp PsJpMOg+Faqg3O4r/UALcykuAECHvG83BO2PekZmkYngWZKpyVGbA8KtknEVuDLRWLLQcgLJzM/p ub2ZZhwwhA02nqlQORoR/f0qNzMN2ddG4EpcR4gijVRmhjSKiA12HXHny+fLxgOGSOgnEWGZsY0H ILNP0MZcSlLTBW3TI5BG5mrHBtXSSRqg5KTdXSecrt7fJzpcHspI41vQAVFogUsdZ1f5Giu4a1bU mS/Ve/x4WW1ClJrh2lXkgNfNhMPIsKKvllE1rlgm8WETTtPxfEa18b6OUY9AgvehQG6W7z+vQAas j+8Mq/edox2HVKW0avX+xOfiClulJNx/DwYUdl97XLC3D445bIXN0ihUyhtjflS2krhpI7BgOYZ0 jK3+rC8K3IPvUf/cU4JZ1HIqxH48qcwxzMe0nELiCEOs7I8hmS1Hu6j2hhoyveV4TUm0VpQUTqjm M71NPsP1aVzZMttpms6q/Ui0Ju7ZDsuQ5fYsQB9rYSbQIW5Ww9EmpjP7mBsVuLJpV1zpVGCrGBfi LNh0PhXYnGZPBQZIj1RcmawESCNtRDdIdxUR9IUMxmy4b1BtuNJ+K7qi1B17r6/fLqxBIrpi6png TytoN7+bL0HQU5LxYb+bxux8v3OTIGZIjyJBjkLqJUhZ7nH7ZcsuqgXwtnSullZJldiTwxz9EeKi qcxADiPA5gzXhcPCMaCR4Wjg4YLNwVzg0vnZV0ccOwZfVfY1QHqs7GuGNMq+FwENotAzJ5+/CH67 wg6cvetXushxNxTTxhhLbJ42oJwm2WV1kUDvKk5IehsgTZMs0dLP9dU6XBPB/TnYbzjL+YV1qYQk Oo0lPlzEbZysjj+SM9Scw1vQhhu4fSlGC7go+m3GeZ+4o9Xfhhl+1bJLjhKvDShc6PCwOWKNvzXp Mu8O9cIPF2klBpO18DNnajcCds6GbVed7vb2kA7VO19iSG6jRXvHM0CaRlBNvBQ39W5tLfJ8XHan +ThdHKG7WST8zgKOEblf5Gf5ZXvcy0QQrkXwJMF7Ma1tbSKohbSMB+JVr3pPQ2V0IcHOA7NL+yQ+ Q790exrHMc11QdeogJCq9zTGkA5FRd9Zp0EiOWA9OtwEXD/zi3+gAUo/HKbtwh8SJNUkdOXf3y86 RlYhBnkSD2y0n/T4zqiwMAJIqoNkkw73GhalbnI1sF3UMfFwFz2GJ5zwURXQFQKLwuudFEMXFWHL pWojmNmkKU1e0si7GiRApG1wOX1bFcTNSyH1wtGi7iiR2xORZJ5qwD++O2K6TJCiDpKNPc/wREex w+MAXb8hZ7cYZlEWoKcO9sN1AjRUF74A3PtEgsmStno1hdJTh35RjxVorka4dqJqcLV9zUnVgQ4n GtdGagiBG4L0uKEB0VRprKEe1gx/qRP78l1ygbvcWYTmrwHkA9c4uCCb4RkYA6Cp1ea3yC1Xsumt HYmX8FxAza8EbXpbWOnhaDzLI4hGFXQjUu/pYsDmObYv8mBdZ2NK0V2UMqoSFw1VhR1jiVsOJvBT p1s2VhXqaSAyhsHU69ok3BbX9iab0Vjqcy8ec0VmsWos5bjx178gg9olD375C2XUKac7/eYrFipa dIY6EDM51XzFV0DMdI1A4f5HC8mGmNH1r6UNNfrtz31G/UJTTI0XOMfozLSGmH7blQqI9XMilASN M+0QRDOw9j4aRWiKtO/tmTUjtsC6DZ1xGnJZcJqBVsSgZ5Xg4B3QOhhwRpALWBCQJojMhz2wHs63 eRgLL9CJK1qpo7JxlNtxc53qG+z34wlZrKNWw3iItEX1OJY9MfcGVzWWfvyoVyD0MMTmaQvJJurr 2nvRcO9DSGOfzPLFOSR2v8lHVGqdXDcPqXUyskvu3Qr6B7w91hZpe73o4cvqxlMIUzef9PinX/XO JNb4W0g2p5/rJp6mDz52sTTwDGwhfeFHwnrPQMdZ6Cy2MWMb3U3bqGtvVHzQwQXXf3G4Au3oMMFN E1CrNVyH7Don4SeIeXolpYVkc+rtu6T1nP+9w0X3GQiljHhKD/G4IGyjnVdarxGlvZof6j3qySwa 6xpNt5S01Fdz6H3YYKVI46FCm0OvHjyt+lb9c4p9Dv35evpSaiO4Br+k8Be1My6QYu8ITTlalKKv skkGy0YX7kICEvXcHAxdNa/rh7kwPXn5l5eBQWeLZqneO3CXLwvtHgIGwQLpBle4mld0+5dyq61p dODL7aLHT9fQ8MiOpxxQ94Zc4l96IvDIA24OI3M1kGzCzAHSDDHdny1WWMThlWhTk+H/bixwQgpl bmRzdHJlYW0KZW5kb2JqCjE3NSAwIG9iagozODY5CmVuZG9iagoxNzMgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCAxNTcgMCBSIC9SZXNvdXJjZXMgMTc2IDAgUiAvQ29udGVudHMgMTc0IDAg UiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+PgplbmRvYmoKMTc2IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwgL0Y3LjAgMTcgMCBSCi9GMS4xIDkgMCBSID4+ID4+CmVuZG9iagoxNzggMCBvYmoKPDwgL0xl bmd0aCAxNzkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1ca2/bRhb9rl/B iORaHssjzoPDYWpuasZJk8hqYFdAgA2R/eC6QAtkF2n+P9AzfEqMQs2wodIGaBu/cObOfZx77h1/ 8u68T17qsTSlqUy4J+OIMq2kp0RCo5gn3p+P3jvvf97q+WfmPXz2ovLP5wd8m/lKpqKo+lD3N6Go igTTno4k1bHSs4ePXr714uoL6/9sP3qrl4wyj3nb37zFk7kfhIF/7m3/8F5sAesYsJk7MCWoSAQX LTCvBDYbBPYve0iw1czRVkpRoXWU9CDt22rWs9VZWCyKcwdb7V7izO4StaIyipPYCRhxstWuX80s /IrFikYqHYbkbT/Odv3qYhmEl8GcrkhULBgjXMh5QOKI20Md4WlcRVSoKO1Zb9jT3Kzn6mmCIaAj wXuQhj1NySRY6iAk6dOnP9hbbEQgiCSlmiMDNUmjis1heG4Wc/W3No9xGVEp5SFEfXe7klkwJ/8m XLJnTvYy4GYOSVYnNI2k8Aaw9dPGtNZiKqE6EekQor61Ln68zsMgI8+LxYrcvCDGzV7am21MYEpN 41jFQyhPazchIsrj1MluP/FicRmQ6p9X9gYr68DMsZinlPHo7ziaiDmNNUKb85QmPFUeA1lAIgfv 0FRIpkbUp+6HipTGQh0Kzv5F3vVSWPczviUwxamSXHncHti0kQnao6VgqZckCVVM6UO26ofmb+sg XBFfkl/l7Vtyn/uC+CIgWRAmOQ3I45UiYUCDPAk23WepKbFvCHkrgvOZLZHbvXxbhhkpqlN4VHMi G4bpYOQRiUVEGpBg2wZSZeThio/ct2Z+Pr+EPe2jeAy6OKFMyM5gNuiekOePuHsdTGu5zj1BhtOI 13V22HLXrFhQuF4+J8WCXMm1HxARFIsNuAr+vcGn4LvGY2ufnNQfOdc0jaXykvoI398f0cdxbpqw BBUvkXZWvXszqRcaJ2Qcpe44JnDVujH07CGNoJ2d8+2ZaZh2Ir2Rd/kcudAPNpPCYwxtmEz6tzgM z61jdWXFjKVUKtS3/Uvch9SvJnr16R25LhZoXJcBGv0qbucr8kcgmUSI+rmc/9xGcFNZatvOjqsB Y4oIj1AX06Q9yPcPWsG5gSRaSDZpWs67PFdlbPX+7alSttA04gcJRZ98oYws5SYvznPkZhmSTcDg CWUG9+EW8yz330yLmqVgZoqhCNqjdkDUc0EbRaNL0ggqbUfMHhxydA+SF5WgBsW7LkcPQoJ2hxQ9 q7Q7txS9m3BaOXH2dTmxS9HHEJVq4syoiSZDX4fyxxW5/e/7x1/PiAmJyv1W4AdIPDvJKDPZaDcR NXkom5Q0CKgKKWPIP9W5/gHpR3KDCOnn65buh3WTqo0N3RRJZwErjWgSGw5rj67jf66B7NYldz4a pVSgrzzUYvVN98SH8FH8XvJVw2IPuSCaqds1FcZnd4gGouUba/acQ1sFSUxq/N/fGQ2njjga+waS TS001D83XAKNKGmJxW4SQBlaZyg7xTlq0KTx3fqESjVVPLIag4ToZNAP/lmW9PYAO1d/ZFwzojdk iHqFvstrcNoY2i2cXEOdSUmVTnUP0j7H7IcT8n2Sm8ZPQ7dA4D8WBcmEXDN8pLr0ifkF15gvpek/ yZAtwVAaEraKrJjah/EMw4r0NF3gEKaqgRjbBfYpBmANkp4uVAfMBEjVxLJmPRfQxEq1gTjMknqM zMZeLGJm+hB7x+3VjVPH94CGkh2zF8NgV8boU45A2rNXUWQjOub9qyztNXiVDNwe8utRaHtDwomt JRlVMdRKF2s92QRzP/dX5KerbXR3l354ZZom0ADSfqbWuyYtDiLCIDPG1HAf+7A4N21xEBEHJDSd +5CGi4Ox4sPDzcOrF8aMWvrixYnVTaUw/JDYrLDYOcjnlK1rDTN3UJjGVH8oTFql3j68YWMazyzO qyqLcSc0V4eKMQajlpQnCWLawYYTO2Gz46JihuFWc63DdiO301YKSJhcIVq9IVB9aW7a3Afr8EQL BOuAnfqV9e4DOQvMmCmDSlSOm8pBhCgWSWAapUsmtZk0rYihy8VCMzOQelIPAyI5x8eo38mJ9yJH CxUGy2IB1ZYk+N58My35b3cHFLp8zD5t+qmyJbl7Spb5HOOMzEgUmV9SWT9fBuX/yDC/zMvmphxr EFqeNZ+bEVLJeWEFKpfXRlrL3kza3ggeQ01D4rA/oENIjsgSncmhoiaQ+Q5snfV7htNF5Ncxfa+A HES0x9zufqmXpxB19FnWTNa+DDQThBCE8qCZCkMUuntqCMrMaqevx45bdXBg2ZCDsXPjhtVxbOKs DTBZnJeMKmh3xKqoWq4Rd9MGT1s+GKNpmigb3CHmm8hjJs7rtBgGl5ipbFiQZcQcpoJfnOML/bVZ rAHXqSf2uDXkT5/clw3xXIZIhiaD4lugh5Q/tPpujE3NxHfS8X17etPaKGmtjKC5B7xMIhuCwaH5 qjjyLvv49tIYkzGNMDz3lAPaE6W6GJID46DnFqTSKdeNyL8t+3AB5cY+XHWkln3sQxpmaXc3LfvY px3XQZjlmQ+fI0Xx/qqkHEElAlRrCHzSqOFJhNW1SHnNYWxyhoN9R1w5TwTFMl3cQrLxwxE6wAho IkrQbmnpBM3BWihVrt4osPaWKCF6kIa9sW33OzqLpL4N5XLSvl9inQkLLbyHdbjv//lUWS/BQiG2 X228DaqwH1AzaIYsfEg+Idk6r3uIkoDjEcI6LAk1Oo2qJJYFp+Tg5d496o6pwT0u3kxqJs0BLceN FUNbYUUb2mOU7K0lAD6ZY38vy0AgctNJfUEuKr7QnhJf0yxdmdOXlpm4w8AUQCRaew6HPZUHSoEW w2rp1Kns9giwjTzcld2vY/pOLUY8iGi/xfiBnK3Dpo2lch2ClH6Fn7+o6W9m4nlTzvlzcN1JA4+n MTb88E6nPpNN7S3ZQ7a+vpahT64uthdXp/JOIfDUo3HP4Zxd7d4YvQRT09qiJr6vArQRYbi33zYB twZDS3mMKl1DtrGrQ5UeQRxYLPEUDuPQBpJNldGrrjyXgv2H1x9evZm0QuOFCUzHUyecDg44huA0 fV2MybU2e/0WEszUmqgymihGyUOYTpsfZWo0UQ0eOGCmLzTRl+QRrTw6D7xm83upr8w0mxy13Eih 0EQvpUmlFXvZkQOyapUEugCpFZ3/QBItF9Dbj0yaRjv+ggkiw3Mvm3h/W64HmnRkcL8VYRAQ4G5e 9OFjW2yDZ4LgKQlWCwl5v/a1XKM0VE/+jJmfGXvcC7zNMhxwT/CZ9sAayxWJ4dEOB8YzxRz1bMqn sO1FYNsUXLp53DZcK4KsJMp5JoIN6G5RsAxqDG7j4mxSsEwYmQhE0AWsQ5UYkeqgB1GpsZ20D2m4 l7u5MSOKW7QjqLXktcsm55hChrUjI671IA5fsYPXjbBa53VJjEdvdovDJyPQcgDUaStEq1sdgbRH oR+emndXO7kNy9bYgst8Q6uz3g4ctKxl7tf711Wa3Mrw3qjJZL42T34r8fg6QOc8bYZsSAN8Fa8D bQpCdTAGLQ4zrimzJBS3RCu8nKuw2dAZtwDa3W6xafa6AJL4xQEJ5K0DDKvvq38ngGxWxtsOVDqA ckvPu3ayWVDqAmgY0n4AvS4DaIdmVQ0mxyK5aTDrVfKWZ5k2CZIRY/LesAssbUiMbg/QLiT7ioqd KJBEDPYdW4lD9USvOA/ltJFkxlxYgvJkDc6mq1qWOhu/LQo+sbSIF840FRFzgucW6q5qMd7qSmVe 7Ur84gaFX6NyKNTrebZsX8v93/4WR2hNILMpTIVbHMBUpZ9TrW6mjEbavHM8Amkv0quC1/Y+42xm +YtUGPYjIo7rGwL4xV7COEh4Pm1TRVrXwrYy3t8PFZFv4Vk2NaT1rGFIuMVTPTtqHesoou7Z0Zkk SvrkDMxkHWq3/NCWOFu/MjWOy9QbwDfkVn8B4F5vPwplbmRzdHJlYW0KZW5kb2JqCjE3OSAwIG9i agoyOTUxCmVuZG9iagoxNzcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxNTcgMCBSIC9S ZXNvdXJjZXMgMTgwIDAgUiAvQ29udGVudHMgMTc4IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkg ODQxLjk4XSA+PgplbmRvYmoKMTgwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0Y3LjAgMTcgMCBSCi9GMS4xIDkg MCBSIC9GMTQuMCA1NiAwIFIgPj4gPj4KZW5kb2JqCjE4MiAwIG9iago8PCAvTGVuZ3RoIDE4MyAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVtrk9M4Fv2eXyEce9utTivWw7LN 4GlipplpMimWpoGtJct+4FG1U8Xusvz/qj2ybCc2wUhhnAI+BKfd5urq6J5zH/5EnpFPpCC8KFih MkFUmjCea0W0zFiSioz87z15Rf5Nlo8+c/L2M0nqv5/f4tfMnVwnif1qdyU104nkOckTxfJU57O3 H0l1R1J7Y/Nx95EsH3PGCSd3H0h8L5iHUTg/J3d/kOs7mPUtw2b+hmnJZCaF7AwjtWGzUcP+4m4S fDXz9JXWTOZ5kg1M6vtqNvDVWbSNt+cevtrfxJnbJuaaqSTNUi/DqJev9nE1c8AVTzVLdDFuErn7 ONvH1cUijC7DgC1pso05p0KqIKRpItxNPQJpQidM6qQYeG8caX7e80Wa5DjQiRQDk8aRplUWLvIw osX9+z+5e+yIgyCzguUCEagNGvZsjpvn5zFfvHVxTKiEKaUOWTSE2wNVhgH9mQrFr7z8ZYybeQTZ PGNFoiQZsW0YNqb1FtcZyzNZjFk09NbFw1UVhSV9tI2X9JdramD22N1txxxMlbM01emYlaf1m5QJ E2nh5bdfxTa+DKn985u7w2oemHmSecG4SL4HaDIVLM1xtIUoWCYKTTjEAgI5dEfOpOL6CH7aPVQW LJX60OEcbuSzAbZ2z/gzDdOCaSU0Ee6GTXsyIemEMHosyzKmuc4P+Wp4NI83yQhE0PmoRIQhSkte kCwtmIJE/IpJRiIqlsysRvyPJ9IPyNbZ12VrLlgBpGcONoFJCZ8Z2Uq+3yTyabbTzrUM6nR1wVmS 1zv3bTc1SnoWW51zp6LbbRxt6Ita9lxVwaZ86WWsr8DgcGCuUjnqv+GRPB5mLoqxY/BMIdPgqfgK zHqK8XiTXJC/M0kkLFEIhk1ylNeJVWo/rOAXjFvkvybxX8/JpSRxgA9B4qx3tT3HJSfICeznrf3p mf14aj9W5zPzgMTeAvlrntPcInGluituf2Fpb9nGzWfzcLjnUs7ii/63jXmX9tvmo3l694TBk57h ZjVrbWj+u+fmSxLX/wuJGzPvzsk/yN2TyRJDkQC6CaJQ1tuUWbMbw01pUlbj7gmz1R1SEs2EOhgi vzhO2612N+oI2gWXKGV0Z+ZulF8G7avSUwkCMYWKEYuG5HZD36nfn9IyjLIwgvx8jwsUH9ZRQDcV 4iUt51EVXJZ0e64iGnYppPmFioXl+cx13/dd7Fg+EajF5BxVimZBLtUTj5h1hGjukKjzHIT0gyHR w6gTIXHEoiESC3rBga9g3qBQv35KmQoAyzl9wSqgjc4VvQwVBRDNB67qr18Cm5Fa0LkMa5QuqNqe Uz4pMmXKGdKVjDQLdEGmYtt4XqmgNtQ9NH0XSqEuUedrmHW85rIJUXZcVEFj5CJkchsHVbmg5Xq1 4lW4edIZPftWSfKIw84zzXihCqIbo118eqrTDtEpuJsfqRfxHLG7HfFoD6v8zruv4O2Yp2/SeMnq GTwVLIGuar6Ncx5S5DcN+L6OxUfb7b9oHtJ1afA4NfkUEvWRdk0/Eh4h4pMu1R8/1yfEo4dVp8Jj z6RxPL6lZ2Gtaa5pZVowi9AooHnYfk0RDjd/A/lsYwblU9IgnN+q6Kqkv//z9ft3Z3WcVGCrbUwX uHdt5NMinEu1oZMidSdKUECTshAuSAV7vkJJO4qqTfiqpqTd8auZtL9I2h7JcNKlCESSJNfgVY+l lE8o/btEz8x43ioFo1YbHdAFlao81TbwgmmkKS7bsIpUhh3YXMN29GS251XINyUAWG+JuHeGhO/u j5lTH/AY0oW/hczgbw+bPc7uEfRmelsiRdWwNcmWBcaD3LvX9NcHd8nbm5vHv8GTwaa+fHPzDJd1 TgPKsCQD3OPf5SpklXH2xCQiTfNQorzbLsYFE6cSNQlH6bHNpsf9e0IS8bDKA4g4G8eLmp5J4yTy Bp4asIORz6AFZNHIZ1arMMJZP69MKxFcohBrIwqljfrkLTpAG3pP0BUY5iqc11k5kuyWXyaNvB2J pEXCsjRRLkhtlran3JCxYXGXa/TlTa6DyHwPydiklqOMz2SqJfGx3FBcw990o9B4CxT8bXfq68uB MpjbeDLpinZ7kaNhgcTIZS+i8MMaAKIhSH0JujZSBiSCfTBpdBAyJNYIfvsLx2W75BAhs1yW83AB ybKNy7WBYqcIplXaspBM64yT1GO5JwqSKXpYGP5wyqBPFyR9rDpRkOybNB4kn38ZJGvO7stuC+GS WolkwqcJkHQDRIPKgdH9jBF1CyP5bNSZNt7sTqcpAinpJLebFKFeS1dGmWKyqxCI3kWSk7SxzkU+ bUKb8lRgpO7QN56mL/J1xTfwv+EtrhT4K1JqcU3ZOq8YD1/S21p8r1RZVsjjTcyf05Op7RQjKVrk Tmr7wUXy+tGjC312cdaExhpy/WVDHraq3KwsgFgEH4MiwocsRFTcxiv8/GFlwBbyJX3+5j4tPyDb AzhPRAtIjpLCiRWQf6Kuv6vcTQE5nWLKMUOMTK1dbR9vf8jxi/aM+yEYpDVe3c6UcxwHt4Elv/B9 hFVd4c7HKr/wvd8ycunBdoW7b5hkB1Sb4YNfvML3iypgfG3iB0VxP4xWUYXIbbXXtMcFUycCc7mk XZuLiroqTTirmOyUkTtQj0h2d1yCHEMIzP84zOH2aRJKO8AElOFGbqpSjdiD+C7pi/lyVaGoyhGm bu7fR0UE8d3cZDok9hfRPYmh/eyaN6rWwdNuSzsTrZBopEnmRJ+tTDWlNVUXehirc4x9DdCWqBoR 0OtgYEOhGCiamcZda27vubZivn36idaN+c4iU04J1o6MB4lVw7lGze/uMbtqvrEFyklXIxQmyNNC EeWxGmg5BfBOeqKExmRdIXaGuZwoj2TiiEKCyEBCBd4oaFzlwo+QT1EIuYW0rZYcgO7BrZ7Ul110 UnAqKnIHXl4Y8jpDo9C0cC0UccoaMDZb/6Qp1O5Q2pXRW9FV7gF6APrrE+krlWI0FrN4LoTRD8Zt zlLXHMMKy4xMuXFuYq2RkRGcY7Lwan5tYnGjM00ItgK8Cd7YcuvIuqFdb/2kp3m30RgKTrhwEtNN 1DS29os+dLGHSowZ/skv1XAj+HmREeVh7K6bXdMdeMSOvFgHm77BYA3YmrliCgMwtiiEZeZLKJhT 9XIU3joSRe7EEi3qNuo2wLwO6je292FO2SF8ToolYQbHzNsVPivwCMDfo7IUuhxc5s37Cz9KydvH Kr904OiSd9+k8WrOT12D1FYbWzWFs1LTfVtQNBlAPZnTdeTqKIkKZWYkyxzKFBKtbp8yhVDZq+9M Ctld+EtypoTTmYOqRjzPK17Nlz2d/d+bq0VNekaf4mWruoRgqstcTboIZA9Mp7ogymsR9USSrEx+ ZgapQEqRWtfNCrNXde5g+qtPe+pj0oV0uyELvEeDQXQXGt4T++2ISBPjTRm8q+cghB+QHtOWt0WW stRM0/us50QB0bxrlnaj1z9KQPSx6kQBsW/SeEB8/GV9pMZkq/aavtOeSPrGm8dHUJ7g5k0jrkjf 8PEdntaXguMcFFoMTBr35YFmVDeKYnN4M/zR1j5s4os5jylnJnbxCVlRgu6jS3xqe429OkvLlO0P Dyx20kgr8Bo4KucAicdKbMmk7TZayq9nV1oV2uAaM6ITTInunI8cTSaOXG37n5Dwgwao1R4QKpMC hmd4pyLFK17Sw2aPs3hEeODgpFzjNY/WJJcqyUh/mNL3AcOk9jZGvrG0Ms/UGQ08gomzdswN6xQv mLdLcTmOp6JXlSEKu70lsEcH/wexwdBJCmVuZHN0cmVhbQplbmRvYmoKMTgzIDAgb2JqCjI4NDAK ZW5kb2JqCjE4MSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE1NyAwIFIgL1Jlc291cmNl cyAxODQgMCBSIC9Db250ZW50cyAxODIgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThd ID4+CmVuZG9iagoxODQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh Y2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEyLjEgNDYgMCBSCi9GNy4wIDE3IDAgUiAv RjEuMSA5IDAgUiAvRjE0LjAgNTYgMCBSID4+ID4+CmVuZG9iagoxODYgMCBvYmoKPDwgL0xlbmd0 aCAxODcgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1bYXPbxhH9zl8BA4eI OkFHHO5wAJSgNqHIrUWzHjuyOxOj9gfLnmln3CT1/5/p2wNBgpRK3SkB2ngmtkhQs7u3+/bt2+Nv wevgt6AKZFWJShdZoPNUyNLowKhCpHlWBP/+HPwt+FewuPwmg0/fgtT++fYJH6MnpUnT7qXdT8oI kypZBmWqRZmbcvbpa9DcBHn34Oavm6/B4rkUMpDBzZdg/iSMWMyi0+Dmn8HVDcx6yLCZv2FGCVWo TG0NC6xhs6OGfeduEmI184yVMUKVZVocmLQfq9lBrE7idt6eesRqeIgzt0MsjdBpXuRehnGvWA3z auaQVzI3IjXVcZOCm6+zYV6dJSw+Z6FY8LSdS8kzpUPG8zRzN/URmZaZVCiTVgfRO55pftHzzTQl UdCpyg5MOp5pRhcsKVnMq4uL790j9ohCUEUlygwI1INGV5vHzfOLmG++bXEs06nQWt9n0WG6/aBr FvI/8UzLp17xIuNmHiBbFqJKtQqO2HYIG+NGS5pClIWqjll0GK2zZ8smZjW/bOcL/uMVpzR77h62 xxSmLkWem/yYldPGTalUZHnlFbc/Z+38nPHuv7+4B8z2gZlnM6+EzNLfk2gqz0ReorSzrBJFVplA giwAyME7SqG0NI/oT7tfqiqRK3NfcR4e5KeL/VDtfscfaZjJhNGZCTJ3w8atzC2OFUUhjDTlfbE6 LM0XFxc84W+aSPHnH37hQoftabNGI2X85cf3n29PeMl4Oy/aeSPbeSnxw6mO+bqpl+08Eur6dObK 5Ian70gxs6IUlcx00LvkQjE9ovwIZNlFOa+EBuvtovxAy29bs5+Tx7j4I6wCndea+kThYdW4lDdX CA9NFvsmHe/0Ly542wrB6pqHLHqj46c1jxQyjS9jXSAx+5d5wtp5vYrZmkst8ECjQ375+eUrjqcL StmIy1FzU6HFKDD63j2X1CSbI9iGOmvncc2mSlWYWmiUkcMctIvm22ixbBBaKRf81xdPgRIKnCfU COw24qpZN+H5O47HgAdlI5toYWNvSXjUJOj6FjBivYrwJNftKT0sZT0ucqhKiqIogRwb312OZ6rj ABXIS7fjQDlMhRweVk2FHHsmPYAcL+4ih21rGKJDkChKvF8BLwmDAFHzt+z6/Jov8U8dhshHJG2M 6uzhpeb1Sii8WPNcrlikNRrkuHDSqymFxITkJqZYvOuBEcbv6jLSPNEoR8bXrGiAp9TZQyaiUX3I lALxoC7k7gMAHMZGiiXXnL9SbODExrP1gImMav6utaeVUGCNLpjRdSfKLviAhOma11I34RAnV6Gk noYzSnTcPbZCYkYM+SjQscKmTnhT911uPTI4agUAot7l4ehE4GiqVFRVT/T/X2iVj1UTgeO+SQ+A Y2VLq8/ODbXq+FK9Wi51TKwECdsRFJLOkNF/5Scf02xQkHpJNKu+4h/PMBhgDLi9PclGLUmdGgER TwW9ty4l6XEAj6DaW5QwJUi3SZ0GgMuzk+txBwCoflVlqsDHKo+SfozU13c0g1FZyiq7bx49nN39 +M5wpHQUvLeTko9VHhk1NAlTrovgvZ2Ujpl0Z3B/zX9WWKVQTyFyDfEW/YMlS6kX6KmjJpsscpGT 7L1v8HGwLjHPMQwQsPcWpBZ/h2v+M/2rsS/WiZ0Z3tpGSV2VXl2CAzxr8E7EMIWMCjW7us4luqPR LlDz04cLXn9ZEXncMMt3sJqY5JXlA5uTsUQNQkpEZJSUk5iBHnS8Z4CvW8JTLuynbXTw1ER+Q/6G fOfiNlEdOkRL2ZB2OKCFncjDodfJCsOuLiNoR+HASyLVSAIhGwpCexrrZOvtVZcW1JNw3pQDE/mO SUOpysn5W/TEmsWjVpjJsSXJsZ3tzHJBzgIIsMkoW192+KGD2k0FzfY4apxcBx8da7WzDw4SGh/W aHGXvPbX7GkqU50GxgeTaaeF8s67Trs8t7ya1KABs04Ys+pDpOAj+MT1qFmVKShDBsqX8fBjXMTe gVsqQVq0E2nx68WPoFK7XuxhlV8v9l2f7nrxnkkP0OtPd7WHbi7sybWd+rqmRuSaIMQWVswI57al WrfzZFiwo6bpNidyjFxFnjo1vAb7AR1TQ6YSe0uWA9wtzAwAcfaHXzaRCuuWvAi8bE2aqLbCD9m3 hs1oO735nSxJb9RLJhpsPQQdC9o37TcsFcGPNQdmbg5xdMUyF9jbGy8XJ0KNvMBqD3toFwF5OtTw sWoi1Ng36QHU+MBNt+NAuq2TBhoQ8cNIQ5604IB0fcpILQe5tBy5rpvzkFT0Jxl9ZI2deg1pz0qV Hd78PSNi3b0zUbPOjQRtNC60EcyPPEjA+yBIErsDJ8YqkXrzqqkV5paODtqmLrfa5Vvw4XpVQrbg 2CNDzgRNpCplz4CXS8nebWjj7bh4ibsYuPCTBx4eP3lZT1WimFoktr4uJbrZ7Jr3r5AsUYSh0Q4j vZK8o1Tgk302Ic+6FEM6xg02bEUDNKV82yjLpAzxjc4J0Bz3KHppIcfMYrLSiSnahCMJrFNe0XfX tAtA4WEw2+PJNrk2C4C+ykamjHkpMgjnPv5MlVhZBsZYOjHGsZdV2OVhzQ1bcg+jRoZ+8OkcsH9g 0gPQ/xPPMGoJRlBoGYpp21dbvMOi1Qo7oSWKK8L4AeL3DCXkdFEjIuqC0W9T0yjGGi/HU9WfxJo1 107UkWqMtacDmvjAneTHTBQoowprqCDfGOYCh+0pFmNbnmhPAtyWzAUD3GylehjkOA27sfqyYnGn 0tw+edn1a3tThq7IADaFjmP81slEqxzjiiOD3yRNZzyM1PGa6IX1F65gJAGvoMQC0djHxX7LZX2n t7vl4rhQr3C5vER5OTs4ES7qMoNhLsqMHyMeCsi+mra7TX6g6HuldjtF/3eD7ujZP/InEUnYP5yl 7y8vz8zJ2QnSD/xkIGD1DRuv0vhJd1E6kiw1dvzQv6xsXEGUTUBXNImP4yYnbpnorJRB56cbB0at jYqB27keX/QAJcydKGF/P2fH/UDP17xe1KCHdd9diK4zovDAwMHUQSjRXxYCftRLNCGMLEQHqRXZ O4akOI57Fj0n1BhIjMqcOOFH/YZBOKX5ASp2f+XjNfRdNNJ1n0NWwL4bocu2/QdNMJGWzC7zgaO4 BzAMYUc28a2EiVyHolbJ0qkd9/MXBqsaRUREwl71ahKaA3DA+F+MO19Ugf2zGzEfbyKJq1F9ygot pMa3i+irSq4+2cK/HrW6MnyFKpe52trlwjA8Cv73LFo1RLIix6W3e76I9b9btPpYNVVbOhKoO43p +71NSVlriW3roMohRBAA9pMlip140g4FetbEwnV3Lchuy+ytH9xLG7WIdq0A81LqRtP7Pa0FdVzg tM4BAPClKiA6+CLD9A+hBrBAj2Qv25bUKDSL7Se2t8PpE0KTRBOx9dUgJhN5jSEAg4DTVm+1JIF4 eB9ro8IB4Pu97PWoZssSW6+i0IH2MHuILP8Bs7MRlwplbmRzdHJlYW0KZW5kb2JqCjE4NyAwIG9i agoyNjEyCmVuZG9iagoxODUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxNTcgMCBSIC9S ZXNvdXJjZXMgMTg4IDAgUiAvQ29udGVudHMgMTg2IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkg ODQxLjk4XSA+PgplbmRvYmoKMTg4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjEgOSAwIFIKPj4gPj4KZW5k b2JqCjE5MSAwIG9iago8PCAvTGVuZ3RoIDE5MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBzVzbctTKFX2fr5BHrXjcHrfVF7UkQIczAgO+TBHASSpBgQcgD6kiVYT/r8pq3SWM 3C2jyTnnYRhbM1691XvttS+tb94b75uXejxNWapi4akoZDzRytMyZmEkYu+/X7y/ef/xzp99596n 715Y/v/9Ez5mruQ6DKsfde+kZjqUPPGSULEk0snq01cvv/Wi6sL65fard/6CM+5x7/Zf3uZo7ZOA +Cfe7b+9i1vAug/Yyh2YlkzGUsgWmFcCW00C+5M9JNhq5WgrrZlMkjAeQRraajWy1XFQbIoTB1v1 b+LK7iYmmqkwiiMnYNTJVv19tbLYVzzSLNTpNCTv9uuqv69OtyQ4I2t2TsNiwzkVUq0JjUJhD3XG ThM6ZFKH6ch60zvNzXquO01yOHQoxQjS9E7TKibbhAQ0ffTosb3FZjiCjFOWCDBQQxqVb07Dc7OY 635reUyokCml7kI03m5PVEbW9DcqFH/qZC8DbuVAsknM0lBJbwLbmDaWtRbXMUtimU4hGlvr9Pdd HpCMPis25/T5BTXb7IW92eY4pkpYFOloCuVh7SZlyESUOtntpSg2Z4RW/72yN1gZB1aOwTxlXIQP 2WgyEixK4NpCpCwWqfY4xAKIHLojYVJxPSM+dV8qUxZJfZdzjm/kp8uhqbrv+JXAtGBaCe0Je2DL embLY3EcM811cpetxq5Ji0IPreWgEm2iOYSmUobBXFC5ibE+4RvZCliTwjWSTEVG894DqRKuq0q4 Xr6gz1SSc0L3JM6ZYbMvN6/d7qhrLOdGpadQ2FNAx7s/IXQXqDjfkz19m/uSFhu6JUwWm3Webamv 6BnxaUB2pNj4uIYrhn/kak2vd3vzo8xcc7KyFeh9p3bNHGLo4jQUyiZz8KGG2VPqS0K3qsSripPy bXVD6P46yNdn5U+Y2u448UtL4FZl5ufN1Vgt51fLrg8aLJJSeS7rc9hKMwJiRw6IjLEStcq5R6k6 kcMMVB05OKByIwdXn+vIYQBpWqCmj+hr7MvPRzf05uP7L5+PGxc0ztc5WECKE2S/a0boW5kzSXck 2OZ+Zq7KrpOMBfmu3Nml3y67RZvkPZYJC4VV7l5sdmCWXZAblqDFSc6Ry8O1rgYBZOUQQGzKDBzO lIYoVTggPZQvcSQzd8fZMSvPj7OWiXznSvag3DypH2atIn8bZn+OaCxH0kt6O9hNLkUrG1AxEnbk n9hN9qBUQMugkVEkfX4VVFuntkc7gx+hnhFIIj2FdrzTlr2pPIbIj8JoCtH4pibn9kb6QU2UN3VS zvFEsBDZxvQdHYi5+TZqGWv188IoTyLGeQjZNrnHmrroytRFu9Bw0aq2myNBsffwckMzJsmWXJTq JiNBjFoNMmrFYyNtWvOu7qum/mBehzJvHKZMIpeyEmuIht2SKqmcXe92KvBNsLv5Et2ET46iU/ry yW34Jn334ZURnUbb7bCsMkKS2Dhb+fvHH969uqL0FsZQuCY4kDrVacK0CK1i42H4wNReQp0Ir4FW pXjTKs5ts7vqJRBqIrjWI0jTeukBjGBD8ompysL5JjGNWcrNTP1gaJNzJuhJJKa+MrxzQzMB0oCm +i5UEQByMyRyPt0rulY+RGPlUn3xWHGEuCmKsva9suqyzOEFoRiPEQmaFdnwArgNxXksISbG4dss lJ93JOa9Abf+YhHZpj+6LKhqq4xzD63eCnbDTV+eHBnUe2SW0O3oL+TDDHSLMvp+2dRSqAgkDM3p spC+be/pA84QKZ1toVZiBaVu0W5z08MzULV6WDugcuMAV6psU8shpCEHjOVcmsJUZWaZSXXN9yZn LE5UsO3llTFKGrmp3ZgqjqlzsBwlqu6CjMbI2ehnhYJVgi2tAkIRXMvkzYTjw2SaOkoZGlM2NNFG U5qvqUmQzeKKTVJsMnK1qNrhImZKR+Bpe7SHci+0p0x5/Y4u+3jTuHlXn/xds01tD8rNufoB1ibm d871c0TjkJ++of+Q6OMZbkdx0VQK6Zr4b1Xw1GR8axNiO7Kvr/Kvi43ZgosFVnRHWSyNeqlWYuUw nbMPC50kuIADVQL8QG6ORpeUqZWfG/2C0A8K2oOWis0197uFQPGbolr3m7q0hgI3ukmm/4pYjDcg Bco4ftClEApMkaBU3/GIYcUDrR9JnxbKKmswW6quXptVmLf9/ddtPtjihhD68mjRNQjBWagwpaId 1uDg1jPCuIDKDKMIKrOGZCMujq9y4hcnbaBYYshIKMWgfBEoHIA52Aqk7KovhIpZzDH6MYQ0rS8I is7LjhgJHTGV6rGlpmG5Wco1WAiN8QDO+aSlxtGiOEEHaktMdHDtxbvNfEjQVhqjouVyHx1ESD/e o2NnE107jR9y6CP1B+stawdU83eWTZ7fyZBpSIM8P/1Ej3+Mf3WHGRFuW2yCp007d0t8uTCzIQpg jMwbWnW6yKT237olQDrt62Ke+v28Eh9YBlrSax8pc46lLBrH2t0apSGLo9Aq20em0fTNFzVvAgfi McYbG3A2Ec1t07oGjkQxJUWcjiBNM3RyTglHTRpF2qa1Lo6OHbo3M9SA6T6oRDnhdDOdayThsQlu STIJaRxJPr/vkth7tcmIrcvxlnsGXHiSYPAKbaPhFhvezzGo+QHEhhc7lzQNJIw03pXGAtKAF+en se0gymqyddQWiSIHVPM3VNlsMfduonnUBhArSB4vu0fpB/pamdZJ2TPB0GCxydcZ6sM7Bd/sT78c fwwF2pimgXTR+G9GczMuY1zZXFpeYopEvfTpQHStOSoc2ibhZWqNhZ1dQ5KVVa86N7xGFli2jC4v H79CZsh9FM3OZBmM9gg9+AxDknlu6koV25sV14MNyy4Sew2jXOAu+0XWkxYsIFXk3PDMwUtn8Gvn pRGObGCG0CY25eiL52drE9hN0cR34LYZEFG/x8Ql5i4jB4gOVpuRd3VWkxKz943VhnT7/yvRYRLN GtV8brPJIjpum4A0jkvpO4SBQW0uq6enmu5XSVjlNGbLY6XDm3r3sj5t5pqRqXmNiW2Yy2EvznAP KVB9S3Gep4Fk48H7PGNoXQXnVJXzZ4vqX4npCHRnQYSDTTCdXjgY7UEOjMw7MYPqf6gae+SA6lAO PAHpBwd+3jqwrorrTRfbROuPp5iWrBNG09muesOoCPeUSjNUOXD4ZT27GY9E8ohzEbFVNbtyHkxz Gu3UqQszFVousOy/VdorW7hLDNQhQqQDeAcPm0NLjT0VvD/VTRfrHqc/2PixCyo3D3NNxdsQOYQ0 rSXSx/T15xt71u6nlJYNP4zUCJ3iQJULLloGZVR+sh1hdeHnrWm4wdF9skWsgfgux0D8IEfu0ks4 /jIW+HCpw3i8QkYvIruJ6N6ECJby12pyzzBa3bsyBGeKIyYl+fDo+fNXFGL5yWn4/tmzU318emwW j0GSfJv/Hd0rdH/8fFu2sQ60VK1wUMtGtJDMtN95nkmz05BA4kyFWoPFljzHzdH7kZAyqDcDplVM tsfT9wHXIrhSOM4dI5e7QyaMo9+DahhWoro5YOWCyo3E+kUxm2JPR2LThhoUe9IX9Aiu0ttetNt1 ZZnRdIhznlUDbhAgdeqPxwkY9kCyX/HNsr4TRihfydhrrG3jPWDApZ95IEXChEpVi8tG98Ns1Rkx de2Xhrd3nwdpABlBZaM8aTEn1jBNSa0G5lNCdiZsVDpqAPiXnzxBpQbD5bjXNWCbe+3gWTNsyEGF PI11C8nKhmi8UEPgfm946t668wx0IhR4EEgCxna4ww7C8yGpHXouTOMpJXdx9g+1mcG2cplFtSHs tlwkUzx8Q3ZhJCnrw1H1Uj3fQjQPTnnvbf584p1Jb7PGi/A22eCdGXY44x4eF1K9vq1+e1y9oApi Prmr3oXVJZgONt9TX4KW4plq3/HqSpzbMJeYeafytfzyFeYFSyCn/Z96m5d4CwTDj9bfXv+t4R95 VKGq4bDqS+s/WX+uWQ6OKPfQXVSX1h88wzuxatZhsP7Tu72ye7jMSATYxDYhNIviNPbuuXsmtuHu 1aeHXYZR7gAFYJNNg25L4SyMNuPBdyuTKuDWTQN6pF/P3ujlVr0HFWQAD1MVeZh8t0blwJ8/M5T3 bdU9pah84Ez7BCM8WgaqUtoiwiOLVptLerre71S+9iE9yucXbQl6CeYM5HF9FLxM72/QVcHBcCqq 09dB179HY2aHFj6CLfS+OYi9x2zasjKlybclGlvcrgHeV1TVKRxzPByNEoJT5Dh0Uw0VIw87I6qs cWwXLmKglKmV5p7DGvrB5H+DXpO4CmVuZHN0cmVhbQplbmRvYmoKMTkyIDAgb2JqCjMyMDYKZW5k b2JqCjE4OSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE5MCAwIFIgL1Jlc291cmNlcyAx OTMgMCBSIC9Db250ZW50cyAxOTEgMCBSIC9NZWRpYUJveApbMCAwIDU5NC45OSA4NDEuOThdID4+ CmVuZG9iagoxOTMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug PDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEyLjEgNDYgMCBSCi9GMS4xIDkgMCBSID4+ID4+ CmVuZG9iagoxOTUgMCBvYmoKPDwgL0xlbmd0aCAxOTYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Ac1b73PbxhH9zr8CBg4VdaKOuB84AIoRm3DkRGY4HjuS3dYc94PizLQzbpv6 /5/puwNAAggN3TEGR/YHiRTJ2d3be/v27fL34E3we1AEvChYoTIRqDRhPNcq0DJjSSqy4H+fgvfB v4Pliy88uP8SJPb/l3u8zbyS6ySpn9o/kprpRPI8yBPF8lTns/vPQXUbpPULmx+3n4PlS854wIPb 34L5kzAiMYnOg9t/Bde3MOshw2b+hmnJZCaF3BkWWMNmo4b9xd0kxGrmGSutmczzJBuY1I/VbBCr s3g73557xKp7iDO3Q8w1U0mapV6GUa9YdfNq5pBXPNUs0cW4ScHt51k3ry4WJL4kIVvSZDvnnAqp QkLTRLibekSmCZ0wqZNiEL3xTPOLnm+mSY4LnUgxMGk807TKyCInMS2urr5zj9gRF0FmBcsFEKgF jfpujpvnFzHffNvhmFAJU0odsmiYbk9VSUL6PRWKP/OKlzFu5gGyecaKRMlgxLYhbEwbLa4zlmey GLNoGK2L56sqJiV9sZ0v6Q/X1KTZS/ewHXMxVc7SVKdjVp42blImTKSFV9x+FNv5JaH1v5/cA2br wMyzmBeMi+TPJJpMBUtzXG0hCpaJQgccZAFADt6RM6m4PqI+7T9UFiyV+tDlHB7kfdEP1f4zvqVh WjCthA6Eu2HT3swdjmVZxjTX+aFYDa/m8SYZgohy7kYRs7RgChTxKybVFHFWU0T6RL/uH6A3cZ2N WpVKxpNCpYGPVX78sFuDdlx69nUuDcrDBWDeyaKAzwyVLugFJwsSRgDWTz+/pvrDa8pUmJE4ones yipGI0UviaIqtj/wyD79jm7PY7WgkST4TcULqrbnlCu2nUeVCu3z5zNXgt691L6dQwaYzpRQLp3D hqBzWFRhY+SCMLmdh1W5oOV6teIV2bwyWTNz6iqOMJpnOKNCFYGP0R7X64gqt7/xKC5pLhrq8gD9 9LpeR1i1v14eVvldL19SvLtePYvGSecbut2GSyRXFW3nOSedC/L1VHyx3f6T5oSuS5OOk96hBPUn SQFijU8ud+hU6cgFU+LRpaOHVSdKx55F4+l4T88IIJ2U17QyGsqCbCpAIWmfpgDDzV+B9Ns5w6tK GpLorYqflfTnf3z49OsZnTYbOQcASWRj45JLNhrcVihW2zldwPo1Gne6IJFUm26eomp6139XVpJw liVOuhVq53s0yXFcbch7WyH79XIQddpCBClfUfp3Cc3LuFlX5UM1tyonPqBWrNNFwopCapcDWsUq g7+ba9gOTWV7XhG+KZF/NgDiydnttBUXlUTILAt8bPa4uUfUNqNNiRSsvzWpJrTjFffXD/THp7fJ /c3Ny58QyXBjH368eYOHlrmhYNQlBlmG38sVYZUJ9tQlxIh/Eu1Z64xLTnSv5gOa8hHx3TEanQmW y7bfG4+vX8NwhFU7RuNjlUcigo0ey2j6Fo2XkI9gNIPaYLOxX082dZmhq04P9u0xGPos04XmQeuA S+5ZOKrCS/oWchLdoPzh2mznZZeboUEwLU3TJUxb9HaYCi2A80K4+NBU4wZa61peoWzvy0ntF73L 1xXfwFug7zlXKr6msVKLa8rWecU4eUff2rKyUmVZgZ+izjyJ6OnqSGoqvnZq3Z5eJB9evLjQZxdn qBw4mkNuA/jaemM8CwGDKKpQDclzRsgGCLnC359X5mgJX9JfPl7R8jeQBqTCiY4Z+jD0LZdTBo0h cfmqc4W+PVbqFA1AlqEW1XYd0laG0pgHeg9aZJfJzR69hWBggocs+oMA5dWOHmHUHrzdjfLD7qHY 85Aq1najetSgnib2Sx+63fOqGzDHkSDnKVM6Ay34un3DvDJ9xkgtuatCxtcGzCj0KhKv4gqg3XYo BskqJq2OY/qBE91mtCxFkTkR4X6FxFg2hCxvihA3nRZEt5AwI52V9C5arioIaRwIdXN1BWkN0G5e ZCS2+o2Q3+bggLXPG0VDdTKX0e8orZwanm5zpmz3wtgaDqDj7JSqEU0OB4rSTKMYbWp4ueZ1Rb6u Ga/99EnPWWEpIZNSBtrDaZN8U24m7AAyRReWpYmTYLcPNxINbcGlPQYj1NYEwMi4+9eYPLPCbiMD rBSS19CCmIBGIE1tKcW5HHzXpEey9z5PWOLWgjIIu0bhrt0y1KHttK1jr5reuutxAystmyg7wRkE 8PpEUJNqzK4wk3dhDn2oacm4bRNJBTdj0yFGBkkMP4oRHKPyV9G1QZqWVW7nkx4kZnuQwvMi8HEs rElfA5bIwvpo7QTCZmNz82YP7wR1i5rvyCFNMXLIcx8MNLYObl5n+mDBHNpOSWLoQ7U7RuoZvANH EymmeFvl8KH5EtUQWtekMnHbo6QYtYjUqdq1SbdRb8MyAm7M6wmRuWSH0nNSB4QAVph9Fg8HTgXi GCcX6MxcNKDTaRSph1V+PPdYjaJv0bhG8cNOz7ajlJaF4J5MWpg5OniVpsiyRxM9jv5OZQODxoNX LsuILKChg3itYyDMjhZAHPgUMkyGt3Pc4GU98DW01LTjIZjqpHdYYnQqE2z0tdF1KYRXdAGKHclT XWZeYEUTOyoOu6IvP/6nwfcNVg5JO2GxMm6GCIPrmoGhEaLopjJ1OmLy1aQhFhLjQGlKcuOHS4hP FVow8Jbqjiewh0EDDuAkT+QQTEQmYcPXDBqqE39GnLDrMQ8syOzEiVGTelKAH2YPtQkso3y5d1hE cbDHbnTP5t/tELuW9jqQXfceDRyZ5r+/Z2JJLfAnM+OPCG0yYMtOA5kCs+2pupPenV1fotCVpYmb woceH/c6r3gFOO12/f+9ebawTYpp07CPbLVM0+PvwJjKykghZg0HABGrddTGxgoHZmL4utednch7 rOZmhXBixob/TlqQU6ywJdgCD1RjlQsuo5SZfaB2CaMh5Riat42R5dwHesWJsTlLWSqw/N/68oiw WWmOuiGaxbzHMmfzscoPD4/lsH2LxqvYS3oRbiz27ZYvgG9gZivbq+86Q/TxklQxRZu1B4eJU7FQ LFVJHrT+PKZUVBKE99GloodVJ0rFnkXjqXhz1QhkdnSGYVqrEO2LEXTEnKAKcwiHpj6j1apz99qq MkbW6CBoTGspKjQNxomkCwVum6W506ix5iCNUmaQ3igstaBhRNDGfajvk9ZUDiLBRQHE9zDd9DrG Yns0HI2D2YeC/gJygOGKoQoVhFCI8Fb02x/g3V4GntSpPU3CXChRTsfRiX5MmLoMq78hCXuuvbPK pXH8D6lmknZZJ5zZp2KAT7ysHgRjhARQPVkKmv02zp0U3MPnB4JrjI+qBWnEbEIt3ZsW8HluvpuZ 80B5eODRhh2xTbPLI1lgER9LIC7U7nT6mY9VpwH8vkUPAP7Nrh1rNk2sKmHkCIwJ7OwELKTWrAEp b9FoQSYyVH6yxXmRYtVHiSJo/XDhHLsvI0Akh6TC17g1GH0s7RgL25SQXdAmYUP7hBK6zI3G4vY9 56bk1OUI0EeqDMC3B+2eJ/TOHshG4SWmU4S/pfnmRg0ZTAHxy5UK7fy8Dsa7GhVPg/cyw6Qc69wu 59bNthWJ7S4W/EEJNvPH+uCoMn9pvmuCb6fkVpU0r6qdmxYRBbwRCb6K5ONWFxH/D67JKVIKZW5k c3RyZWFtCmVuZG9iagoxOTYgMCBvYmoKMjcyMQplbmRvYmoKMTk0IDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgMTkwIDAgUiAvUmVzb3VyY2VzIDE5NyAwIFIgL0NvbnRlbnRzIDE5NSAwIFIg L01lZGlhQm94ClswIDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5kb2JqCjE5NyAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8 IC9GMS4xIDkgMCBSCj4+ID4+CmVuZG9iagoxOTkgMCBvYmoKPDwgL0xlbmd0aCAyMDAgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1cW3PUOBp971/htOVNIjqKJcuyDHiYNoRb 00sFwqRqpot5SOBhq9iqWf5/1R7Jt7YJjuSMuwYeSGgndfRdz3eR/woug7+CPOB5znKZiUCmMeNa yUAlGYtTkQX/+xJcB/8Nzp9/58HN9yC2f7/f4MfMk1zFcfVf3XeJYipOuA50LJlOlV7cfAvKqyCt Hqz/ufoWnL/kjAc8uPoanBwtQxKR8DS4+k9wcQVY9wFb+ANTCUuyRCQtsMACW4wC+5c7JMhq4Skr pViidZwNIPVltRjI6jjanexOPWS1r8SFmxK1YjJOs9QLGPWS1b5dLRzsiqeKxSofhxRcfVvs29Wj FYnOyJKd03h3wjkViVwSmsbCHeoESxMqZomK84H0xi3NT3q+lpZwOHSciAGkcUtTMiMrTSKaP378 xF1iExwhyXKmBSJQEzQq3xyH5ycxX3tr45iQMZNS3oVoaG5PZUGW9BcqJH/mJS8DbuERZHXG8lgm wQi2YdiYV1pcZUxnST6GaCitR7+uy4gU9Pnu5Jy+uKDGzF66i22KY0rN0lSlYygPK7ckiZlIcy+5 vRK7kzNCqz+v3QVm88DCM5nnjIv4IYaWpIKlGq4tRM4ykauAgywgkIN3aJZIribkp+6XJjlLE3WX cw4VeXPZF1X3O/5OYEowJYUKhDuweT2zjWNZljHFlb5LVkPXnA7JEESkczeKmKU5k6CIP4FUUcRF RRHpkXrfV6A3cV2MokoTxuNcpoEPKj9+uJ+DWi69+DmXBuXhAmHeCVHAF4ZKv8npMclKZgLrl3fv abFZr2UUUst/5O703/T4z1hQLtnuJCzlksq1B5ecEnRTjjpAq8EpxtkQgBX01dOr+ObFi4+vAX65 td9ePsk/v76gfz66Paavjmp7WNxfL+zHGMdCRsYZE7HIW9wuhYyHPUwQZefLSGSZFDUpGRfl8duS hLtTd9+ZACyFqCQ03IM1zt48JDVQnku1AAYOFq7lKKRh1Dsjch2Vmbuk9oG5VlYgunku+SiwYeqa V1a5YDk3OWtMfUNZJWG4niYouJ+LBhGLGefwvhGbGoKaLieXtMW5YDwBx70HUi9ttXF2srBsPr0n o3KJ5kaCev0eaL3ieGZpSTQ3UoSoeyD1pLUlvMxIdF5H/NvbY49KvfZGnzpKiJhlKtWjIA/rjUIk LNOxnzc+f4R0OElatrXnGLuEQvkUo4M2ptIDSyvjLOXZeDgdhglI6/Xbyf7oErxEnjKeCz9/PBTp RsmZ6oY79JM0JNXzxwOSbg9UDwtcCPXfb1xItwuihnRf0vcJAU1l4N0FXZLwg4yeDQl4SDnZnRQh NU3In1BxQ3xrfisjal164doU36cjziQXWTbjiNL1af9JJJeDK91dHA6DDDx6okM7hj4Q3DjPFXK/ O6jp/uwSYrpaIOYsi39WQ/cy/oPc2QVUV0O7g3qYNwPVeFXflNCjgHpB780N/T3BOAruTCO5wWSK lgUlqzWX52RLNZyboM2LT293O1XVpr/jq72MgvDi3Z0YP4fIUpZKAaZSHcTFT2lpURYrW/t/4iY0 hQlqaWBeryP5a4lPQsLP6emcMaa1VJXHLM8T5YL94+fHtPi62Z1ADysCHRS/AXWE+HmBM5BGMbbF oQkNMRRbFmvzxDKkobTPtNyb4rBZuTXKO7efGHWZpw50bo0JAqpRl3ObsxmzekuRUWB20NA5BGCU tnfs1cZkER3uTqDi7phILsYsGS+NFHankVy1x72oDNW0g6Bw8/sOdHiFtq9U0uXwt2hMFSRCBdCo 0HrYhzJMaNekQrvnb3cvjmoFE08VKA+4UFUn+7JVSAHdVQHEaKwyWhNBOL48I1Flv/Zg1nrhkJmN NQfSB3quGAS6qKM7HJPL3Wl5toGX2Z7hijATR8piBdskYbk8g53hiKgO3s56DJFgZqCwmKDcj+GR hye0vrrohjmhmXPcse4wpCvT87ArXWl62cod1PQ87MQM6jw8AmhYpr35TB8tt2tZLsOCvvvzjy/o +YaRiV2Y5CNUFE1vu4vrW9v5rvLe8pzKaItQAh6NKGlyg/lJwm1oJYcKf+DV6Bk5+RtcLKqrA5Om Q5wP9QTZFgZ/FbiNp/FZPYxjTCQ5GpTKA3k7TMBQYQmGRDcF2Xow8gl+J9KUCQxOG5hOfrdH0fxy iIuJd5GAc/Cc7M6p5NDIp4cCxz5qS8mVB6rpscClkdqMte5B1CflH+lu16uuKy5rnKQacK0kqGJF b019bbiEza8RMYSn4hDIx8XuZLWft2d1ps4kwNpBgpwoYIlcKyNDzc147pNBDv83XIKXqxKxEK0D ++0Wj4DuNU/bL+wHxZqwEtGEGSmAN+PX7UVNMJVaZsW8yTpBFwxUA6TK4/QHytapRooUWIhyWAL0 89EJsaz1UR9Ufj7quzDW+GgfUb9bOKQ1b14Y3rusprNgg7aWiUVdsJGvG4LsVg2l3QPxBHFiy4/J DJP8PvjxMWnlMoZd0Aw8YWM7dPSaNBuET9EJQPa97rzsMJEjzbA/g2UvF8J+jXWqNRqI5H25Itc1 5bHVM46FCTqyslUKHttwy9o7im+DhGl34JBgSEeIMZ0o7Ifb0hTYIUsORJ1ShcWBzKlb0B3jQwly CAKCRbzQlrwSVhjRqLa+Ng2MiKogtoNwIPViO4JjLcdJva0xHjequKa2FYADM4kGFRol21lx81wx gXI+SD1wX3TZt7I8q53KkTqjWm+iNfYn585JWAPHYjtig8cBDpWTkgRLuliIc8lJ7hEUYwHf6I8q W8UiS4K0B2k8/D9kQcuFX3dZcgTUkF/7ZcnhgpZrd3lMTMOZ2psnP5a1P7byytWKbEuEW9OetQv/ ppKtOn62CDQlF28nTbM6fctiUyHAYrUTix22jHqstuqQ/cAUbHKqu5cVT2iX16hp8G7Rz9QYsj2b 97g6ZbgAowOf43rY2QRGg1siTJn7OA0klxCBMgFJ3D1OTMHVXPZJUVxmabMlfx/Tikq5pZ+aQcol Ov0E5oI+h2Upl4/xHzXseVb7ODSsYchBA9sl+1YQ62oqIrPK1ez1x5lGlvKQq4cJTkgJ2EPFCDSR A0jjKQHtOhOsTCFgVzZRAkTnoAOmSlhKsLKKrpru+Kzy7CIYKtH4zrscw2ImIoxgF2lbz02AtmKS pq/QjpM63tkPb7PGJ3O9KEc0gOjNYVxs90DSlVowfeckeihdv5J6f7HBtwPujsnPf/apghN7qRvg P8fzA1F4aasw4zxNX7sAza8nMWh6Y4BpKjq7z20rNC1lWJhR6HoNt7ug6PTYNFouGd9sCdUwYbPv bber7U/Maqit1+FuKYqc1KnI6VwKif7rpizKqg3GSiy1VwkCe7pbDJ3YrOA57ljFOtGBD/jfql5H JeKqwLk9ekdR5KAhYUOfzXBGpb1nJBb1Zz1NpwoU1SoRThSuhQ2xF7BBdBSXMDs0I9vN/Iv9rXws 5M+5RyBEyiSYUCA9zuDh1BP4jxAaF1hw/6iB5MLLDrGQLySmvEgSXsA8ZDWFQOAiGOc8GUAaJxCH WMkXGtxV5p1dVUocB+YnK99kIbTEXrLMRmU1LHV52bBmhwv0+ynV7graHDa6SiXyBEUIJoN9Y+/L aQhqupxcJkm4TsiU0vl9kHqjpDasNfeK3KnnvtQciUiCRQWuMQQZk9qQHuHi0+c8H1xYdN0ocwWW S9z7wP0mH2Az700n5k0UKa5YjGEampgHud3XX70he1+Lp8ucKIDABe6kt0PqNp3etnu7jpcVpQeq h/mi6960E6J6bzp/PKS46NvbPoBltUfq6o+nz7FiVGBqe0ZcCG1HH2flIp1VJAKND+1UhfUJrXvU mUBMkD9yvJ0F+b/G50JM7qDYDyG0bZy19PFA6kCHMpZO2nDis3ghzcLphTR3RBbrMCNvyuFY6ZU6 hY7cQXu48ASr4Zm54IP+SI3IhQh5s9l9STmmKvOCIlxxA/OoJOWCy0NS+4gct2pwMZhx3BsbATRM UwehsgmobK5ANv4xgsIsXnNcMBlBNJTU7EQWOTOLcWViHFOPNE43J8Nj78uduDzNMrzhyAlRnTvb 8HoYGovruHiDB6o3d8s6CIuVyHQp3irigWtuEou3qOG9aKOQhia/z2H/D3VFMrQKZW5kc3RyZWFt CmVuZG9iagoyMDAgMCBvYmoKMzA5NgplbmRvYmoKMTk4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMTkwIDAgUiAvUmVzb3VyY2VzIDIwMSAwIFIgL0NvbnRlbnRzIDE5OSAwIFIgL01lZGlh Qm94ClswIDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5kb2JqCjIwMSAwIG9iago8PCAvUHJvY1NldCBb IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4x IDkgMCBSCj4+ID4+CmVuZG9iagoyMDMgMCBvYmoKPDwgL0xlbmd0aCAyMDQgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1bbW/byBH+rl+x4Ustr+U195W7zqmJaDutLetSOwYO RXQ5FE4OaNEUSPOh9/P7LCWSks6hd+nIbQKYEU0pz87OPPPM7OgLuSFfiCPcOeZUKYjSBePWKGJk yQotSvLvT+Qn8i9ycvaVk/uvpKj/fr3H2/yT3BTF6lb3ShpmCsktsYViVhs7uv9MqjuiVw+uL3ef yckbzjjh5O5XMn6RpFmepYfk7h/k4g6wHgM2igdmJJOlFLIFRmpgo15gfwiHBFuNIm1lDJPWFuUO pG1bjXZsdZAvx8vDCFttbuIobBOtYarQpY4CRqNstelXowC/4tqwwrh+SOTu82jTr44mWX6cJeyE Fssx51RIlWRUFyIc6gBPE6Zg0hRux3r9nhZnvVhPkxwBXUixA6nf04wqs4nNcupOT1+GW2xAIMjS MSvAQA1prGKzH16cxWL9reUxoQqmlHoI0a67/aCmWUL/SIXir6Ls5cGNIkjWlswVSpIebLu0sV9r cVMyW0rXh2jXWkevZ1WeTenZcnxCzy+od7M34WYbEpjKMq2N7kP5vHaTsmBCuyi7/Uksx8cZXf35 c7jB6jwwikzmjnFRPMXRpBZMW4S2EI6VwhnCIRZA5NAdlknFzYD81H2odExL81Bw7m7k/f22qbrP +J7AjGBGCUNEOLD9RmbLY2VZMsONfchWu6E5HJIXiEjnYRKx1I4pSMRvQFpJxNFKItIX5u32BkYL 11EvKi0ZL5zSJAZVnD7czEGtlh59W0tD8nABmg9CRPjIS2l3Sd8qOqmSalL9NaOpzGi2PFweZiyd UrU8pD8LM8Xt5TilC0UTlVIvjdQtnS3H7FWGp1JFbUaRylJaVstx/RmHo1BpvhnOoTUD/MBayduF htQMCVZQlVmEqw7IGF30IHWUSqxlQL+Ug23zxS1+ZLTyhQ3MP2YZhW7HbuS17ZPOstgPms6TJOMX lCvmV6USylSyPKyO5/5N/vX1L+8/fTzw+4IbaTaZpdmC7ndTmkKulJYVIqiOs3A1hWVP50yuFzUF YNzJpulybHk1ldniaq+4eakZuB1xHI77uZyIw88fprvdbDWc7gJLvI7uwkENZ7uQCq9lu28D2s1T ztFrcFq6CrZbWcHt5lNoyo+FmDYxswoqHzjJwv+25jNEZDoH8dGNYE2y9Fblr7aCdq+u2rFL4ZiE 04bw3jaNgJ47Atl0Y6SV6ATZn7a51Kgh4b5lBNpNAkReWUDxs9RvD82zX+dghTrd+Cz18cU1LL+9 Odgllk2ndL0z+yUOVaA6KLiLWt+myR9ppj0l/RhXMOcaoduffuKoYwCqljpiUMVxR2x/o+GObUT9 /QN3Q+9UThdZWcHJ6Io96mTlRVH2egZPRZKF1+ZqOZ5cwGOXhyhYZZUcb2RqJGfvvipfILd7gaUS JPsZXjwPdxiL/oQpgvLzwpfa1ZT+cFS8Pzs7MgdHB1fhonqAq3BhmbBakwblSuo/4sDhkIb0mhpd Y1Crce7EQ9XH/y4dx6CKi6nN6iMmH/ch+l1Cvn8gpnbCpw6STulWELoqnzQ6d69BI0CjgoNGmzWF JNxWeU+8tPUUgMSVpBf0tkplx/+jx84shhRGra9qji6KUSF4PRs1KNH5zjMO266IzP9qomzFq/Sk 3gZ/Y0WAK3lUv3e888BOFvaMOJ3PZipPn4vi0IJFCyl08Q1PUwUWXvnVFaUvQM0by0WhlWDpqZcj q2q4Sr0YnMJAZba4gAmRHLLXYP4Zz5Ad0NnFEwyPJMdIF3v101YYGvQHpXRBS2+2aaYguqYXm4v1 1eOaVOGme3BUrjUzEtopBjDq2XarKgjBlhO2c9LoO+tYdFTQ6REiCmsX54+ab0Ca7Pabc+i8ct3Q fCRNRnXEBqDqdF4EqricNFjnbSF6ROd9oC/SHdWzDvnW42omyNE1W6chrwDRsHiVwSkR7k3Txn04 pZO6YlEWv0a58kw0UHBoPBWk8XI1T7cVal34Tk+maBu1RTEaSYtsWh0nSAyrbg2IzTMhyuOTWQV2 5AjO6UwlKJihGOeJl7eXp379INPnWbZGui51EZT1flG3WZnl4G1P4b7/5P9xgzYmWmmLrT3L1V7h i0IzzE5oEgN/d8/Olsu/+25fqnidw7BNFRJY57Ce7X13EBl+r6tpqUmjziikCUnCdW71LeS59W2/ JEUXmXNUHpNZ7pMrxY8cKdV7XPPsOqD8OhO6irOrvS5MYOpFcy1JxMKeKQtow6F3gk61IhDt6M+Q EqDbfBxnSd1CMqY+vlhf6qEL3QzzvCfj+SE5NmR8gIsm4wwXScanq1cnq8tyjKsiY8yx+MtPuOCZ /HB0LNr329Wj60vzjgR38eHrN64v3c2fyd1VPUO0Dz3OpcTxni6JXttjHQ279sDJVWsPLGqfY03d Fgn8l06sD9MekQ46R0gmdDWwYLL5NcI0p/fnp7RQCVhlQQ/yq8a39iMZO+AgNVXaIJY/A0xIW7Fc Unr57vT+Hf10vVfzci6YcKUjeo3y/6iBoRzmx7h9cDTldw2MevTpR/qfS3ru7unNS4dk/uGSHqHw rviPzVbvZ/Su3WplUSYUQYBt/putnTT3QzVX6ADveZ8LJO2CkwiIEUZ7CvcqzNYEDiANRxR1bq+U Q1fvwW1EQ2jr2P4vqJ9RLfuJqOHgQlIV1IkrLIbu+sFtjQcW1ZQper1WxjdvLm8iMA4oqLo4wNGk NpiFCRhBfZtn2UThLL6ocoZORKE4z07KCj8v6Nt/Unr+7vTmvgG+Z65WAnNeOuygas/MrAwqZUxs kAZTiDEbMwXw3FNaywonZBhxCmstt8wcTnBrOokZGcT0j8a0FYa8I7DFFfOxDWaErFbWlb2QdjvM Ly/Po+3Uza/XTNI7BuR8IwslXBSo4XYK4V1nIToNHL1n53Z5151fPsFMtbr/et8zmsS5ZKUMg1QP +Y/GTzMSIPXuG+cGAzrKtpBCCtWbDx/cM0sgid10tgiS6X+bzJA3f2M+TV0xNQnf0QHJCVSK+sFa EoPwmfhUgiqsaIzW3+6LgxTLWW0Kl37SE8euD50e7nLWcEgh9NBBUgoDDN+EtKXLngapDsYedugg CYww6ofPWFvKWk8ufgdI5Muo+yZS/aWS9ltKHaQCw/PuUUj4XtJo/F0gPf5VKWExFxZ4yhMBaQAJ tFYSJTrOoQcRG7z0X5XsTJkKZW5kc3RyZWFtCmVuZG9iagoyMDQgMCBvYmoKMjM4OAplbmRvYmoK MjAyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTkwIDAgUiAvUmVzb3VyY2VzIDIwNSAw IFIgL0NvbnRlbnRzIDIwMyAwIFIgL01lZGlhQm94ClswIDAgNTk0Ljk5IDg0MS45OF0gPj4KZW5k b2JqCjIwNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9GNS4xIDE1IDAgUgovRjEuMSA5IDAgUiA+PiA+PgplbmRv YmoKMjA3IDAgb2JqCjw8IC9MZW5ndGggMjA4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAHNW2uP27gV/a5foeeOTXlo8SFKykrdWLOTFmO7RgNvEqzVBkVmFphBU2A3KNCf30NK fmLiUE7sNAEiRabo+77nXl7/7v7N/d0tXFYUtJAZd2WaUJYr6SqR0STlmfvHg/vW/bc7vvnE3A+f 3MT8/fQBr+mVTCVJ+2j7P6GoSgTL3TyRNE9V7nz46NZLN20XdpflR3f8ilHmMnf5mzvw/CCMwmDo Lp/c2yXI+hJhTn/ClKAiE1xsCHMNYc5Rwn6wJwmycnrKSikq8jzJDkjal5VzIKurqBk0wx6y2lWi Y6fEXFGZpFnaizDSS1a7duVY2BVLFU1UcZwkd/nR2bWreBRG16FPxyRpBowRLqQfkjTh9qSeYGlc JVSopDiQ3nFL6ye9vpYmGBw6EfyApOOWpmQWjvIwIsWLFz/aS+wERxBZQXOOCLQOGq1vHievn8T6 2tsmjnGZUCnlcxQdmlspq9AnfyJcsp96yUsT5/QIsnlGi0QK9whth2HjvNJiKqN5JopjFB1KK345 qaOwIjfNYEx+viXazF7Zi+0Ux5Q5TVOVHqPysnITIqE8LXrJ7c+8GVyHpP3zF3uBmTzg9EzmBWU8 +RpDEymnaQ7X5rygGS+UywAWEMiBO3IqJFMn5KftpqKgqVDPOeehIj/8Y19U2z2+JWGKUyW5crk9 Yef1zE0cy7KMKqby52R16Jqnk6QBItK5HUTM0pQmRb6OrUoZeNldDOxJKXMMRFy5g3roXnMX2AfX 1B2EuAh34OOi3EHWfthduoejvZVXQ0e/F7cPu5VR+x4Y1rs0A1ylOxi3a0R76XZbf2i+2Bmodmm3 Qbfrmri8fbP7EChS776/a/c+dnX0V15jDbhL2xdftJeOx24bhodY2T3svnFfDAk2KzZCWVPTrQFm 1O9jt7+7y7uzAW2eoQTgCXf31es8r96uAgBRttj/FHyxLkoyJPNC2AWM053ABs9u/ZIjQBb8824p NmXSD1eA/nAAEo+ug5COo2aYRCzigsse8jshcTKNgRgTbvZ5Ytt4uyVWG18PlZ6MzzLUmRLI9vky c68cIImcjKP6WgTkl+QNWYiQePFiSRbRtMIjDXPf3NlTfYogc06BxTP3CNWHietCdqhQ9GkIbiPH hagrMpd0Ogr9gOC+mub/DGlAepSlp0gPSTVjReYeofVQepIEULNRenVLWE1DvwLobAb+nAB9BlFN g1r6FaHSD5pB7YdzUvu6RiQ//3jbrgtf0nAS4L4iQ+dEm+7VO1FZCqCaKZveSRWCsqGMAqE5jcLa vzUsN4NpIGRUgUvDF8hHBYwlddSJ4+6szCAqaezI3T7M9LD1E+xnE3NVmlFRZB1u/EJhvm/sxnC0 SdW+lvqoGWjz2bWeVgkQdxSSSSSzeg6TwhK8Sd42zYx4s7ckhzHBb8xui/fxpexKIhHmgtvYVbJS i9JLHxar8pZoElflU9Mo7z9Ns/BWirwHAFk+OVbtul2Ib9lHZEVKOUuUq3rQ/G4GOsuYl/EsVosZ SIawyYyv1GxVxlckfSS/eEsCNh7ftEyd1QW29oY7libSRu6eWsSlihdktkqQnR5bOts8VT7MFpr6 K6OQzcpYPXkqjktPPZEFLOwTWa7K5GJGxVMkYKtYdeXNkvum8W7AxP09+bVpyhLsLLx4dkvif2m9 tUq74fdefHVLPJXcP1xpvmCIRK0W5N678RZQ5WJl1Hgpx2ESxSuzYnLD1SO0BGcxunqYwYGANGCf noJ2bjZeVMaeIr96EAfYO685ggnG0G5WPbjR5GrDiltxl97TezjWWUHS1m0A7ViedyXr8TANV9du TbzWdPZsS0v+Ji4TaEPBP1Lv3ls86uCw9BZKmxwUgrcJhz0uvOQBJlpeyLDSQlCZSavIwB9KvprF 50WoQB6FQtZeE/YcHjzEWD3M4SAT9KqUcCAB8GzXij2dpF4dDHQTaZHxzzVV2kOutoMx+DqSQNan D47FuVsqcpqzYySZGs3R526pjNBMbAbcj66YrixVEI94EKEZ0QPm9j2MYFzQIs2Fe4zU71VOpjyh Kv2s+PbryU0FCYT9E6oKX5KJrGqDCKPwGhBwXvvXBo5ngN/1vA7GREakonISEolKHgBwTPTxJ2Oo n6ZYRHiEDyMsLHWlWun1500L6+ZImuAcWORWsUjqWqOrI8AfUDAZmcI6DwmFKXUG5Hz5KPcgItjU SQx9fHidwvmQPcX1CDA8gIIgW13n6XuD40cTFuo6tkPyEPe0apWjP0afRfiSyevxhbQgcRqPw1cr qDEPKxrVeVuyBntFOdjQ5IcvA12ig9fXoqaitbeuCiZTfw4lVlM8bwvkTod4t1XmZexO5jlVBbOq SnwZEJhYM4A/1bCznIV/wO0idCPgf3WAaneCst7wbKwSj3CtCAq1uX4P7laD7UmIfyCYsBma4llL CIWaH9TNcNwuq6ZnZV8mOJJF368P91CUfWT+mgJZ4rAA9bEV8mpN544gjO1WxKh4tQGiAqbhfKoP +l7X6FHgZmI6RXJtc3DFcpls2knoxOhKWSt5KGGhuhtzVkVs4KbEISZOem2KtLY9pO1k3raKXt2d VTGMcZpJNGA7Gv+PUJmUBeWbM5zDaZr9fIn+aw1D0InP4yWZ1xVlsjLG0fpnF5NNtTsLqWldRbXO LkbUxn3hzXgFt7TbatPUw9swm3anC5kMwFaqCqtgvRuzbnVW1+4Bd5iyYA0FwGUQhCP0GsHEWTlg hYY5GQyqBwcIoBCxzNf9RILZmhCaYOu+quYK+XVUV5VuiulwYLhcJ9SzsrT1Y45hhDS1yicm+SFG TaJat0mj8Toq5cgTa2QQoosKTsCFvoHxmlSr4xiyRY1w1bYAYZLa/jr5ICk3w0iOjAAuxDimfATn VhHMuJjE0aYt0D8hnWC+rUDkgpF1hLVh63ghf+aROwBGzGflByQdnzRiOBUwAQvgQsN7CTPRMUkE weSv7969fv36TlvP8E5G1+/qSbTNBcC/33zCkuspzRRzE2up2iSsC+EGUQCZ5xCvxWzl9vyt9rM6 QDA34b02s6BVAP+ZwCFRB+mwHp3VgzDiQrnAxN6afhuRmsoOqBElmgnbwI5tl3+M04DunBFHTmBC Q3ATQbr7C+EZzJYCz1gN4DaDyQRptI1kIBrRrq3wnguNXbmnx7bQu0IFsVMj7XyGUBiFv00x42Xq rrMqcBP7BYBrhgN+KwWu43sXzxH//bmu2YFlOQuBM3TBMJ8jR1cmiu8f+exiFR0NTAg4L5dIbAzD VG4fLnvE0xNCvB5gYxkGKtYk2Xg+QuR/NwFzGyzPMfWtJ0sxYiR60dcjWH7NMIpIMbymZffMkft3 arFiHg+DHs+T9J2GxDCyT5PPziV8jw6rwLEE2hXPqQ0yWv+wwTRY+1nS7gzMTh/M2f66wgzKb355 sYl6HLMbWfolivBTC+dbdKFtfv3BFXIPszvx3BXS/wDzc4GmCmVuZHN0cmVhbQplbmRvYmoKMjA4 IDAgb2JqCjI1OTUKZW5kb2JqCjIwNiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE5MCAw IFIgL1Jlc291cmNlcyAyMDkgMCBSIC9Db250ZW50cyAyMDcgMCBSIC9NZWRpYUJveApbMCAwIDU5 NC45OSA4NDEuOThdID4+CmVuZG9iagoyMDkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjUuMSAxNSAwIFIKL0Yx LjEgOSAwIFIgL0YzLjEgMTIgMCBSID4+ID4+CmVuZG9iagoyMTEgMCBvYmoKPDwgL0xlbmd0aCAy MTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab2WTW/UMBCG7/4Vw9aB1G1n 7Rl7bBfKR0sLV0QkLntbwQFpkcr+fwnvB7vbqArxQkkOUaIkevT4nRnfwye4hwwuZ8w+Evhg0SXx IBzRBorw8yt8gR8wvVk6mC/Brs/lvHy2etOJtZtH+zsWFMsuQbIeU5Ck5gu47iBsXtxeugVM7xw6 cNB9g/bZ5EQ3+uQUuu9w2xWsP4GpejBh5MjEOzBYg6lBsOfjkYorVelKBDklG3tID12pnqsXzayd nVa4OlxENW4Rk6C3IYYqMFPl6jBXakSuXBC0koeRoFuow1ydnevmQk9wauysdc4Q+4k2wdJ41COS RmKRxeaeveGk1dmrTRq7UtCWqYc0nDTxUZ8n3Zh8eflyvLEjCoFjxkSlA/1uGpvaHMarM1abt10f I2/Re/8YUT9ur/yVnpjXhrx7U+VrBacqmmyKmK1nGGDrt42nteUkYoqch4j6ts7evrtu9JW5mbVT 8/7WrGJ2N17bMYXpE4YgYYjy/3pjtkghV3n7QLP2QpvN8XG8sPUcUJXDPKMj+zdB40AYUiltooyR soArm4XSyMu+IyF7J0fMp/1POWNgeaw4+ws5//xQ1f4f/xJMCMWTAI0He9rK3PWxWHqsZ0pbV6V7 rKbu9rKem4R2ux+DA1W/ABzDHQ0KZW5kc3RyZWFtCmVuZG9iagoyMTIgMCBvYmoKNDk1CmVuZG9i agoyMTAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxOTAgMCBSIC9SZXNvdXJjZXMgMjEz IDAgUiAvQ29udGVudHMgMjExIDAgUiAvTWVkaWFCb3gKWzAgMCA1OTQuOTkgODQxLjk4XSA+Pgpl bmRvYmoKMjEzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YyLjAgMTAgMCBSCi9GMS4xIDkgMCBSID4+ID4+CmVu ZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDIxNCAwIFIgL0NvdW50IDggL0tp ZHMgWyAyIDAgUiAyMyAwIFIgMjggMCBSIDMyIDAgUgozNyAwIFIgNDEgMCBSIDQ4IDAgUiA1MiAw IFIgXSA+PgplbmRvYmoKNTggMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMjE0IDAgUiAv Q291bnQgOCAvS2lkcyBbIDU3IDAgUiA2MiAwIFIgNjYgMCBSIDcwIDAgUgo3NCAwIFIgNzggMCBS IDgyIDAgUiA4NiAwIFIgXSA+PgplbmRvYmoKOTEgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJl bnQgMjE0IDAgUiAvQ291bnQgOCAvS2lkcyBbIDkwIDAgUiA5NSAwIFIgOTkgMCBSIDEwMyAwIFIK MTA3IDAgUiAxMTEgMCBSIDExNSAwIFIgMTE5IDAgUiBdID4+CmVuZG9iagoxMjQgMCBvYmoKPDwg L1R5cGUgL1BhZ2VzIC9QYXJlbnQgMjE0IDAgUiAvQ291bnQgOCAvS2lkcyBbIDEyMyAwIFIgMTI4 IDAgUiAxMzIgMCBSIDEzNiAwIFIKMTQwIDAgUiAxNDQgMCBSIDE0OCAwIFIgMTUyIDAgUiBdID4+ CmVuZG9iagoxNTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMjE0IDAgUiAvQ291bnQg OCAvS2lkcyBbIDE1NiAwIFIgMTYxIDAgUiAxNjUgMCBSIDE2OSAwIFIKMTczIDAgUiAxNzcgMCBS IDE4MSAwIFIgMTg1IDAgUiBdID4+CmVuZG9iagoxOTAgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9Q YXJlbnQgMjE0IDAgUiAvQ291bnQgNiAvS2lkcyBbIDE4OSAwIFIgMTk0IDAgUiAxOTggMCBSIDIw MiAwIFIKMjA2IDAgUiAyMTAgMCBSIF0gPj4KZW5kb2JqCjIxNCAwIG9iago8PCAvVHlwZSAvUGFn ZXMgL01lZGlhQm94IFswIDAgNTk0Ljk5IDg0MS45OF0gL0NvdW50IDQ2IC9LaWRzIFsgMyAwIFIg NTggMCBSCjkxIDAgUiAxMjQgMCBSIDE1NyAwIFIgMTkwIDAgUiBdID4+CmVuZG9iagoyMTUgMCBv YmoKPDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDIxNCAwIFIgPj4KZW5kb2JqCjIxNiAwIG9iago8 PCAvTGVuZ3RoIDIxNyAwIFIgL0xlbmd0aDEgMjYxNzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngB7Zx3fBzV1bDvzGzvfVfb+6600q7KqrdR77ZlWbbkKrnggm2MC9gGg+nGhGpMgBBK 6JiEtYxBxiRAYkggOJDEgUBCCaGDE0goCVir79w5u7IkSAJ539/31yvp7jNz587szDnnnntuGRGG EKIkOwlHCpetG97A/oQ7F3IehXTOsjM2e2fs7sojhKkhRHLTKRtWrrvt/cb7CZH+nhC5ceXabaf8 8C3zaYToPiSk5sFVK4aXf3zOqdsI6bkVzi9bBRnapKYB9qE8Ca5at3nrsXtln8D+Cdg/tva0ZcPn KK8IEzLjedhfu2546wb19ewvCZkJ30e864fXrXjjk3vmwv5C2I9t2Lhiw9anZhlhfxchlgOQx8Av /VERCdkI9JEkKSJ5JJ9oSJR4iJn4oYSbWIiDGImeBEgOcUEpJykgUiIicaIjNmIiuSRCEqSQiImV BImBFIM8QkQNV1WSErimjMSIgmiJl7BEDt8WJnb6tdKbCUnvoVuZnw3kPHIT2UcOkkfIE+QZ8lvy d0ZBhshF5DHyZ/I++Rv5Em5ZypgZJ5ObPel/zvQF4nVEzT0O92slZPyL8ffS946/R4hYMylnD+xZ ReGTOeOG8ePT89J70qPpX0mURCecq2N/CVf7iDk+/gVbD2fqxsvoPnsJ3Ra+6SPpzekH0rdMeYYl 8MTryWlkAzmdLCUrYW8j2Uq2k7PIDnIOORes7QKQyMXkEnIpfH6HXE6uIFeSq8k1ZA+5luwl15Hv kuvJDeRG8j2Q5vfJzZB/HezfLBwlwpFbyQ/IXeQech+5n/yQ/IjcBvu3kzvIneRuyL0X8vfBPt2m W1jmZsi5C/LoUZrzAEmR/ZljuD1CDpAHQXsPZI5l9x8mo+QQeYggHyGHoYb8mPwEtPo46Pmnmc9D oPXDU/L/9RnPkp+RI+RJ8hT5OfkFeRps5ZfkWXKU/Io895X8r8vLlv3XV3me/Jr8BizwGPkdeYH8 nrxEXiZ/IK+S18gbYItvkg8JLYFH/0hegSOvQ+4b5F0h/+SZL06ci6Veg3J/ylzjbfIOlH+PHCd/ mfRt+F1/hFLvks/I52DzMsbOuBgNYySfkn/AvpqxwJEvGDls+ZgIU8DEmQSTZEqZaqaBaWRmw14h WUNOJVeBXVwL2kd7uBHs4Uywo0shj1oLavwuqHX3Tmj5AdAp1eL3QBf09zFBVz/9GnkfhSe9B/S/ X9D5V3X104wmfgHHnwELp5aRLUV1/7Mp2nsOrnafYIv7yQhYwk/AKqh+qXbpMaqN38FVjmU0gdJ8 g7wFR6iW6PHfCzr6paCl1wQpvwnH3wb9vSiUQm2+CFbyAugSr3AEnvFPcO5vQC+/EUpRfb8EiZZ5 GkrdD8dfFa75OmjkA9AW1dn7UP4d2H5U8ExvwR1TXf45c+xZOPIR+KtPQLN/JR/D1t9hm/4+ATl/ g/QXyP0rfMPfIdEyH8A9fgR29CHo+G+g9c/hyD9h+zNyAn4/gTv6gnwJW/TIy3AE9A/7X5Jxkibj 4BUZhmU4yKfbRDjnBFjZGNxpGkqmGYaMMRwjYiTgP2VgOQpGyajAfuiZQg5eBayKhVL0mEzIEcqT f0yU1zI6Rs8YGCNjAj9sgatqGC3s2+CTHpFnjzBWyKPHsuXN0ODQvBwGvD/jZryMj/wKPLmbfAb2 7QQL9zJ+OMoyLtDz75gAWHaUyWUKmRKmFM4IMiH4NmrpdUw9E4CcEBNmIsAYPB9YPFMDRxqYZqYF jo4z+UwZ1Ic6pnWKd83ssDdADRB+wKf/XqxhxOD/f8rOIFth/0W+dcniRQsXzB8c6J/TN7t31swZ Pd1dnR3tba0tzU2NDXx9XW1NdVVlRXlZaSJekB8Nh4IBv8dm0uu0aqVCLpNKxCKOZUh+S6B1yJsK D6VE4UB7ewHdDwxDxvCkjKGUF7Jap5ZJeel5w3BoSkkeSp4yrSSPJfmJkozOW0NqCvK9LQFv6mhz wDvKzO8dgO3LmwOD3tRxYbtH2BaFhR017Ph8cIa3xbaq2ZtihrwtqdYzVu1uGWouyGf2KxVNgaYV ioJ8sl+hhE0lbKWigQ37mWgdI2yw0Zaq/SyRqenXprhQy/Dy1KzegZZmh883KOSRJuFaKUlTSipc y7s6BfdMLvPuz39893dGdWTpUEy1PLB8eOFAihuGk3ZzLbt3X5LSx1K5geZU7vY3bSDAFan8QHNL KhaAG+uaPfEFTEoc0gW8uz8lcPOB4x/CXU/KGc7kSEK6Twk9SB9xQkwpZji7TeDe4A7h+Xw+ei+X jfJkKeykdvYO4L6XLHWMED4RG0yxQ/TI49kj5n56ZGf2yMTpQwGQbEugZSjzd8YqW2rnUm9BPmhW +AulRCE47k1x4aGly1ZRDq/YHWiGJwRZkjkDKb4ZNvjhjDBb9hcmoPzwEDzEaiqG3oFUIrAhZQo0 orQhAy4SalndNyCcgrktKVNTigwty5yVSrTAuWAiLbupYugN0msFegcOkZLx1/cnvY4DNHgbpPeR sjSBUsItuweWn5LyDDmWg32e4h1w+FL8IIhvMDCwYpBqKaBL5b4OXwc/oEDhLHi2aaWzheGxU9KQ zDvAOrhBqi3I8LbCR6CxBg7oUhLcpRptrPEOMA6SLQbfkilBt6ZcB3a4UFM7nAyEU5vaHT4wbuHn 39ySAx8AbiMlm7gnEdyE+OQ94ff8y1vD0vSGcr0tK5on3eCUi8KOcIOZq339fbJUFhlhwC3IqDrb 6TMU5LOw7YXDshQLzylkUS3avCkyyzsQWBEYDIAN8bMGqHKorAX9dvUFunrnDwjazljJnCl7eLwC j6WIr2vOQHaHbQIbbI0JeqVqFfbbhP2J3fZphzuyh727ZYGuvt30ywOZCxIv1CBQjiTcMXxZhSEJ lbUVHGWgdTjg1Xlbdw+Pju9cuns/z+/e0DK0qgqqwe5Ax/Ldgb6BGtClUO93OLbTrzaQLqZrTmNB Pviexv0BZlfvfp7Z1Td/4BDE195dcwZGWIZtGmoc3B+EYwOHvITwQi5Lc2kmLeKlO/RKs2FHJpR3 HOIJ2SkcFQkZwv6yUYYIeVgI8hiybJTFPF22HAt5IszjhbxB+IEaZlsFKgA/3OJdTtVz9uCq3UOD tHIRC6gS/pgUE6gjKTZQt59hJaqUIrCiMaUMNNL8eppfj/kSmi8NNKYYCwPCGQWftHsoAH4KTG6A OJhBsA4dtX425B0dH58z4DvqOD7ogyqxENL8gZQ8Bu2AONQJ5dpoGoLsttTOZcP0Pkg/VHVaMzuW DUJdyF4QinSk5HAFeeYKUKJVOIeaI5y0DHQDChTO3wk7qZ2DqcEY/dKB1fSOvF5dirQHqkDteE1x mH5RYnC3IVBMDRuKphShSyjkcG+kbwBzHLALXwYOlz6RVAV3viwAh5YNeUEDIrKsD0wdfamC6g1y VoBLFIVXCEnhyBwk9LG4kFKtSMnjcEH4o9vKOFwQ/qSDIBT68MLeJZkC8N26lBLuKDxJlJkTQDpw qIPeC/xdAjdPiz5BL9M7SmYHtoJrpDctfJUUDqfUoY5hcP54vhJyAhXZk+FashDNotc4grlS+uQq kDsXmjM6fndgG/UA2Z+C/ABtHKhhEschMGwyuHt6RmpBrCBfNj1XLWTv3i1Tf/0JKC+ZeoJwFegO Q299E/c69Gw56P1Xk34yl8w8WGApsMhqGhRsFekgUiZFWOJlCXT5GWY/bxCxoXIJ1+tQ6zf0Mr3N UnYOqX/l1VcWvfrKUeBRJvHK8ReO68ZeOG6orEwkigoZvU8vJJOGlUolkoA/zpaXl5WVlBTXsaXJ OBvwayCFS5N1bHkdV1LsZhlaFEsKuVCY5nKvn5jJtY4F2TO8zava3VxByOIxSJkcccCuTDRGDWpX IhCuyrVLZFKRRCGVRcob/S0rm/3pX4pkGrkm5nUGjBKRXKtU5/rsfqM0HRZrvvibWPPlPFHzl49y +rIVM0ok29RKViyX3e1zuAur3aaQS6/WqjUaqdPjlEoNWkWgtnfsZrnT61KoNXKdWaV0edwKjUqm tYz5CDv++PgXolPFJhhlCZPRR7hWro0MxKCKN/UPHAipgupRdievtoaVioDN6ifBoFUxyj4zQqyh UaaGd/EBv42DK8OwRFSr8qhYNadSGVyzDf3i/mjMVl9fb6hMEAhkY9ZKg7XS3nOcSRwDQeckDJWG yhKQuE13XF9ZWVQI1hP6765YVDgYslCNxNkI55NqONBNuKycQdVYpQHGJzpFzDjqysKFdgUTSNsv lhr8lbF4iV5tZDcrTKH6kuqWsIp9nUm/xqxdGswzizmZTsOI0hqjQiSx5gVEZ+vNSo5TWoxPjb0M pg4ud2j8A9E2cYBUkNXTpOZyEd0oJ3uoQGQX2c3yUWbbSLLPPMqcdYCPzqVCASnU04dOJJjE8SOV YHKOg/+5LDwmY0IbAwMUmU1ulhpkSbHFbNLI6NOD6Ymo3Ym2GV0GdbBqflPn9qH2hDXQOFTTtqIt YVTLRRKZQm3hF25uXPfA9sZwzxm3Hd3RumNRSHS1c3GlL+yrHj5n1yVVrWtaA+6g26iXOgO5AZcl 4DZXnTFy5qKnH7//vG5XIXR3WKh7RPQZ1EMbjLstnyoB8APscV6e4/XotDqt3DPK8CPGXugBrD3A y+dMSACUzySeKi45dhwEcODfFxQeXiMJ+GhdNEL18sFzimldDEAFrBOJPtMGqge23fzUpemHdS6j VPyGrCzEVNz43GUt6Q/93Wcuv3T/7tVXruspsnBVNRdfdumOtTPzZUavTbQqP1JzxgPX1K+dkX/i qpLBLefvAt3C2KXIC89WQHZPfTJeJzdbZBaLLBqxq+1qEgHtVj8UjUXMZp+MPmas1wI4wPsmP2YC TB3s/gjVuO5ocYluxyVHjggWL/+mZ+PziwI+zifoe8rWSZmIvJxEoTWr0sUQgWhUdMekSm/rZI6p VKwUdtRjZ+jseonoDXmZj73QLnpX4g5FfZb0EZNB6gqFvab0HrNJ6g6FfSa52WOh4gF5JGHssBR8 hJm0TJOH1kyUCrOSKERi3exMlYd6DnotKYYn5JVfPUarK62jVJFYRaVMPavzJcORIqeC+xRcb0k4 XOSSswGFTiEWw4foF9ktrHugH84E9+Mkc6fdj9qWoyFqtU3DyYyzc0aZLQd42YQqhBs7elS4s4f/ dRl6gyYNSHjyLVK5cyZOqqQyfEDnABl+yOh8JZFwsVPOPs9cr1Hul3qieQGLILfrszf85V8seM8g Q6kYbKqK3DntnpMJZVydby4wGtVepYJUWcw+3pvsjRcozfkJX5UsTBQWr8iohl9HuNfRr5vwreBc waTgseCvnknYwbaOQYJcfQn+Uh38F9earKMAQ51OOMIFuElqo37GaiyhTpZuSiUOTuUqDkUK7VL2 N+zYQVVLfUMlcz37W1btKgqD45Vxb4vNnqj1jvy6qFm0Q8w8aooW1eQ+khM0i0UnNe368s0cvVUv 8nz5RlaEovNyog6NNliVeyLNsZHKkF7jiORQHwwyFfeJDeCLNk2TaTCqUxYUFBG+WmfyuMtmu00E +tNaXdRTVK3K8ffm9EsEs4D2SRAdmOsxO1gGlRqVmfU/nZKREDY64XAkIJFIJ+QjxApUPhaLtaSs bMLORStFVk/ItCEY99k1j1lCelZh113Iat2JQKDAJuXek/PRS30JX47yCaNHzyodmrNYjSseCMRt MnahNWhTaoJ1hWxj066mmTf0jJ0KEpJI4EP0nURCCxVo7FDF+vL2G9rZpQqtXCyWaxXU9liyZPw9 cYM4BDMLCTJvqqQeg+N/BScehE8VcTGbR4x9uUK9kZ5sq6CZEpz0oX9VAKQBIZBociMkOOeT7ZRI 3OBt23zX61duO3Rug6/jjLtevXzboXMa0u87aoZb5124tDGqd9QOt829cBi2uEUDv3jywUtnl224 b9Pio0+O7JpZfvr9l9cuaw41rb3syl0ldUubgo2n7r5iFzwb2IBoCOqVB57t/KnPRtuhv/AqrzEq k0fg12SMjjK1D5usRrlMponA9kHe2qvBQAUaZQhVKtFVgzkITpqx6TIPHv0mJ2bFcLKmCC2Vxerm xODewuFsazWUUzF43n2bLuljdf5kOET93nvymnzGkZwdrR1uDqY/iBeak97Nc7dW9tbGHCru1xXb t6zuTaSXYqXQKkWXJxJSmaq4a8XiwlaNVJzucOTXNDahvqlMTgOZFJE6ctdUmTxktchU4igZ5SS8 ujha6XJXwG9uVFw5ypTzmtx8VdRtkVtlUpcrUAGN28N8fm+gX58J5lBI4G8qj6OPn5DSmL7yGHrW /d/+Uig3VgrVBaoMhDOZYC7OgcCyTucrjT4rOi3QvW1eYYO5VCRW+6sL8krAFRfLHHm1ebOXCS1K mEr2Q1l5kFmwYM+qivTbxrymxN6OHV2reBf3CX/OhvkO4+lL0/+0BFQKjVwkVhpUjKe4uyQnbZgQ 9PX5EX/rmm3OwoAxfXWsuY8w4+Pj73GPQX3qJJdOle6jRM++T+pJGfsxr7fXwy8J6cuaPdJ8aX6R apSpH2nuKxplNhzgPSdrlxAJ6oVoCEOE4zoaEfGKb35m1vCgxaKdE4gNJRkpctmgMNN5kdD+CXhs EfcYJ5GrdXJNXu3sZFlXoTVY0zOzpybYfdmTWxvW91c5RVKFRq/QJ1qHmqoHazzB6q4ZXdXB9p0j pxbP70ya5KJ9Mncw5DHluHLcRbWeYHkiv7Cya7h+8W1nNpvdPrdb5g1FvCZPyOtOtuSGKhJ5hRVd SxvmX7+uVmt1Gs3gv/eCnV4AduonQ1PlyCuJTGaSG20mo8w0ymzi5bzcqPFk6yrIyt4zdoRJvHCU OmzdURDX/n9TMCse34Qx+YTumwjCSIvoAtqqQ8x0+HkOG3QHNOjpn2iVkK8zqbirVGrRm1JPONdv +fL4hMs1WowyTyTXb86072eAj+2BmCRG1k17FmuM+Lxmi1IRnk28CotZ6YvJIFpyjDKbD/DiCTs4 2RBlYiftfy5PHyxbPzKxFCfBfsHJRueBnDU3Hz37wh+v99pvZLXZkOVGnaZ0fj2/bk615nus1pOE NhpqD/PK2YfPqW/Y+cS5HMk+6hjp2dARiHStbYF4MtPiYEzzFMQ0B+GZa8jD0545J6FUhtTBkEpR WEiKa0hR0KYqUhXV2AKH2WZoh/zsc7yHt5XPzptdqKyxJUL+YplLQdRWUTA4vfuI4Q2Nb3qOv3Jc B3UkJ2GD/iNGODrBBDJGwLu+zRVBeplIFIKbjBwjXFioH6wZg5uTYU6xxSKRiq9Q2PObSsqaQhom waZvUFjDjcma9oiaaWXEzvLi3AqH1M4yB2VGf3k8XuaUMcUsc69Y76vIjxUZVNoGm0sjEqntZq72 xDPCtsZtF230ho1isdpiOBHiXjZa1VDCZjoR5d6m/U+pJRaAdq5u/D1RDvci9NKryd5HuHau42Q/ Xe6SuUfZ2IPQxFTLYGOEhItG2Xt5lVFeHXHBZBLn68gbZfpH7J1lo8ycg7ymh+sWuudCV5SGkTRm P37sleO0OmU65LzyW5xNZYmd0/JytEh0PBYrHTmhESIDzd/JeIAt55aLyms9EZuUdWob56+rmrWG d9iKZ6y7fLBvZ6EOjrmjVhmb/nWgvyKvtSzXoZbbop78hbNqNT6zgQ6KXOltqwpXLNneVL/32kvX 1Lc0zjQbaMyT/qS8PNo0sGQ4112Wl1O6YFsLjYGCID8i3gB9ukZy71T58Qal3uX2eAPlFZXOSidY loFQ8cnjekVlhV8kLQHZ8epIp9OgV4o01lZNdw2I8QAv7cl2ZoUw8jhUYTq8kRCc0o5LNEfwx8DQ 8Y2HvvW1sm4Lgm9hcCmcHdOgkaZUqO+iTJgFA1UWi9ARJiDD9ZfPm3NeQgsyrImJGCmr8RaFQnGH jG0Tq7RaqaFp7rLiyjl1UZs8PSa1Rn0FC2bVqZ0g6Ghzea5Tw17QeN21u1bVNTZ1m40mkxiic6VE otQp0jdaS4oTBm9D0usqbu6aVZ9Tlu8sXbi95ZLy0gg/d8lS8OnV4+9z87kXSCk5faqUDzqdRB9N HoZ5UTFRMNGRRKf3MBOE5TwmZtYBPpSR5dix4/WQmMRRHBl5lCS/2RkoLSFyQDuj8sgMj9AOTKYh FHHzlQaHTuvMrStKzq6N2pVt3RWzKnP1MGWq1juqugcL991nTfZtvXlltJsvgqh8mbUqGbC5c+Id i5bM8/bOcQXADvQlyQK7z6774b211+zZvYZXmZ1WA7UzWk/XwVqefAgD9kyVAK/wFdT74YDcX07t S2vO93ORVsiUE5lEU0hrqLOz6mtqKG0bhACBDheVFAumRUMEzbe8wFdqqSgbHlgn+uLZaiqIr5xb ka2lDqGWVvbXRm0KWwnU04FIW3Whfgmr8YB1JexQV3eACeW2lOc6NMVl02pqdQgsprs30rB3D1iW 3hW1MC9mzWpsVnlFpGHe0FCsu6d0kFZXkGM1xFhPg7+LQ+tycKocH8orLpeIiHyU3cPLA3qVmzOZ AolR9ko+QgJ6var4/bzyp6JEopPwklmSIUlK8rhE6uAkEndep2qcd0/U2uzYJARc+koYjHuFdgGs lbBnpTWWD/33F8taI/QLzaZJlsgK45Mnx+qkSeoVWSm1Ve7phkt/e81CkWjOosbVM5MqlUKi1CtV /PwNVUNXDhXmVAzsuGP1ggvm5H5eX1M8syamnjNrbaObfbl9U1++tcDYO9toNWq0+vxYWKGymdTR 2efOa7ph766VdbG2BU3R0mBtX8IcLIL4tTO9h+PFW2H0/Japkj1gcOs9h9mt0MboQZz6jpp2vqOa 77BYOvhqEcmDEDZ8YEabG9xf9KFqT9DQ3g4NSvgAH5yZ9YRHwE7HjtTT8S4rDE4kEjSy1QkSxlFe 1Te+xIT/w6hWCkKinQNRplNAO1RZ86XiKzdma3lJZljearFwPCeWKTUyidHmMXgTfptM+wOtipOp NEblHd/XV88/a0ayVQErJSRypUYugWwtLSX/7gaVmpMqdEb1eqOubsFZM+zJPK9EIhYnJQ5/0GOU SCWGSF2s22hWeEMwVHrio75z+mM6qMZqidMHGSzHGqP1BexHepvCGwy5jMvm7JwbE8tVEhiwAPsu S+8R2vMa0kten6oF3hzU2R1sd0mytqZ3lstZ6yTOmto26jIMylxnsoY4ReLyDk9vbYkoyFN3Udhp MFi7YYtXBnuinNVoZe2cdZThIMDMakYYha+nFg4f1J/Qxipx5PgRGPSAbhxtrPTQUlWSGDV97f/e t4AaxTQk+Iq+YGTkG4YKCw3dZ+8/o/+SAp0wjGlQqQJVc+tLemtCMrVdKbRnPasbXeiWvho+UJek VuVEnIJTYhdcsiDuMMtMBonTD4rRw5KZYEVuw4DT15D0JBee3d4Azd/qupMBxadCQAH+yV8RMZcu 2N4C7Vx4/AsY0dpAGsiF07Sni+cEG2BINKC0KRuSIrFxlBngDXxlZyBHQYJxiTu31d0txvhLiBto rxqVAarATvRD3+pU6taz3YCysuwU1cR4VGYm5GTUAB1EGK1aDWF/UTiYsMvZU0USuclryR2cWafu heziYCgB4UI2dKDOHUMHY2P/smTz4hqHTOpXaOnorFbBWs2lZkvIoU3O39qUXp/NnhQ2XGcpLoob vHzSF25eXBFso/EsyI/NF8+ANb25ZM1UCT6Y6zG5YYSC4ZUKj9tt8uSKgjnaUWbvQ2I+2JGTiVxf 7TmuR7EdO54Ztnv4P5SlDiUjJ+wtZfeyjR/M7NqiVbG8UodIlt3i0p+flMh+KjNo7UA4omdCJR61 2lMSChZ7NRpv8ZfJ7KNz2xVaGjHh+BtDQmArn4OtJMkVU5+ULyCcKI+LuUVGsSHPaMqFXw9vcIuN kClWF3a4TYZcjzgn2JrTrZ5kMcJzH6EDllhz9QzE7TYdrcqZ8ctvcAXBvUqkzJQhl2wPecJmMhvc 5w5P+smjCpnaUxqNFjnU3G8Xc2goYD+MDGNMaig3MTMU1mBJOFTsVHI/0MV86RfTs21BhcqgEosU OhXzQjoqCApCdXEwGwOc+JhZodIrRCK5BvuW1D5iIDMzaZsmMx3MOfAKAtMOMOnQmqlIgkSoQKjz gso3/eCkKpJ9NCYAI6/FwTCtAJMtfcKwT1ow1neJC+KRBXREbXLvi7c2FxTEK60Wv2+Gf8EC+O4K v7KvUw9jjQO8k+/orIj7rApiKVD6F8xortSU1HWUdDsnHEDGA0CTCd44IWjQUHlEX1IMzyLo8sB/ c61JjwuzZaWZICOr3K/LygwfYLeCteIu9RPiW1gt9B+ChXY5B34iUBCdO7OWegmaSWW3RiIO5mcz s67jAKt2xNyeiEXKusytg6srqvrLXSJr2+Cq8tYlVXaZbELKrNVaYE1UJQfPbEqvzdYgyCyy5ldO zeR2ZIe19wQ6qkKe8s5YsL0qFGlZVBZoC2V88jugoyqyfZqOVEV2uyPMaUWakBamYgd4E1/WKdI4 QnZtUVjmjXV4u+WT6hd4ZNo2ojsWtHCImL/JWZk69c0Fzb0jl56WcSogy7VicbhguhueKssFp1a1 Lqm2sy8GWkNjL50UmK3YWDBNitMEltu6CMeHa2hfGOSUmQ+YbM10PuARYT7gEWE+wD9i7IT5gMDk zi7I5uR8wNcWEMTw7+cDRMRRteDcO1au2LO08ORW+oQ+UptfPKs+7tac3GI3tl9/9bnDFYkFF81t v/6q84bo1sq8hgJbpHHe0LKCvEbYapo3vBTWM7yW3is8Wx70v6ZFt7zaV1qmUpeqS21qqw27+DGr qqzUJ5JC52sOrw53WtU2r8jg6DDMhAHxb9TFB98LPuehb32ZSTKKTLIXYawkUwu/tnMPHa9oa3Wh YSZtlbBb/4WorM4TgdESp7ZhwbqqntUNrvSYEuKdiY690CtTsxdAZHPpqjqdK2JJr8u6XtFrOG5y ta+tOly68OxFEOWY6LDJLgx7hoX+WB3IlY4/FcAan1un1S5tMF7A16uUiriigCjiFTRS1dnpNieO duj4eFBkhmHvOSO+zmrAQd7cg2EpLoUA352JRo9Tx5cJRoVolHpzzbe8DhVsNhqq4/5TiJnp5roF aQr+rOrkIEnn6iaPrWjGuiu+OiYVayuP2lWlJUJImX48K0zGZykuobFOibd48OwuGJrafaowNGWk oVIaIsm81sGhxZEZ7ZPiSBXItYRsmyZVY1SvdxmcxOWkK2sSKg7W1owyS3gdX9BpcOqjrojE6u+w otuiMgSvRYN86rlwbBSkd4io/sMpk+xQ6IlO2OK0FsHCqUQyldaolBssdr2/p7VcNYsKDUPFEVaT 9fdOW31bd0jrcZglEu5+abCwJB9WIkmT/afXpU/L+quTrumKWHupG+JPsQTsjIEa/B4nBXm0kgum yuNRomW3Qcc0ye7ljZZq+CUBbZJ3tLwjVrzHd8LyEvJQXuKfvGPqQNLXTKyovuFpKJnsiBKdVYFV N5m5qaldTwi56UgKnVhhrRZOKtUYVepAcVNBoDxoLOke6C6uOu2W5YXzWgpVMiknlas0Mo2/bGZ1 bm3UWNQ5r7OobNW1i/Nm1icUSu5MVQKmmqwGgyfP5skLRWvmNnSft7hUY7IrZQaN3On3O/U2V47R n58TyA9Hq+Y2tG1fUKI0wAQDld/i8Q/Zt0T7Scv0UWLeVZYfK481yuQN8oZyeSxWWG4tt5LCxvby hhpZPvToD8pjvrJ2CLRnwwKWSYMklceLj1bSBQbwCcsNhIF3YeJPh+tYHvrGl8jaWgAGY/7VsMhE P54tyfbjhZ4/PJWUmt/P5nDicK7Nn2OQyZQymMGSB4sqnDUL6jysWMzNW6tWSXV2w6lRoVGlUQsb fUKv4vYqPMGgy5hepM1VR0NSuVSrNxYWhORynUqaUzanRuny+tTMAb1NX14a/jlUZ7EYRjx/DrM7 DJkH7aWNewpGos6aapO8Q2kjRTXFRYFgjo0obcGi4ppAjhw65+4OkOi8g7yuJxOg0pF29HIQ2B0R 4jxhjEn3zU4DyWW7eBMe7eTCAkGc0+Z9uGUQguV5aAjGOUytC9ZUtA5XO+TS9ZlKSyM3WCNg8kC3 b1a9rpvRZeuyLxtmXR1oqw5GmhaX+9tCbG42d+xdS6HFFnFqShed28mcn80GOa2Hfs5bIKciui5n clRxiPjYvBGDJXqYvRdquZe9hlfyloIOv9rRkenXGIQVLD0QWOheEaY/5dMPC8YjgfGzzBAaTNUI azCFSmc0w5hPZtiHe0sCK4zX7uhQOKNlwXLer2JWM6zcURKLxnNkTLe4pK+tzk0n+8KhRI6cu1Pp Nax96dizSzR6OStWmXWcX+dUmcxqiUihV42dniPvuemO1FI1LLQADwjPefb4FxILPGfX9JbwEClg cx90+42GwsPsHohDq5m/PWioMvgbD7N3woPng+9S8/62jtKOqJFXattrRscfPwCMA3kt3agxcjkR 6ORO6u6RGPzU4wQYXTyZGU7LyElHr/Z1p9XXf1ViGec+WXRmozQ7rwDjRielKLHIRKHB1Vub5a7c pD+vzKVk4p/JjKHaosJaqCk9DCNzlsYjINEYvNAVFmthMWsoDgssk4wk1NXO21mdtzgSguPcnVq/ aoqA2fDYH/UWlVgQdkRhVxhtWqkg7A2wUO0q2hGkMzlj65VK/qb7RuZmRQ9jlz8HG3sZZJ+YHuM/ SgLsHTCboGQf5eGVsqDKJoIXuXIYa+gwew0UV7OP8RremtcRVBncHYZuSTbeF1wbVM8EFa2wnIoO V9LIQ/W1halUjRMLTgWJCutNszOHVqMwnECnC9lrbxVLPFXxPOqG1r4h0QYqC2NJG6dk+vZKRI7K RC61v1UvSjTuwtx4uZ1TMx+lm/UWjZguAGaq00fkahksbjDrmUeZmwxWjZiTqBXpF5g8mUomEqnM MJQI9mhK7+XeBpkUklVT692BgMmYe5i9B0r52bsO2Gx00PwNEIMx3hGQmVwdpi6NMD5I1+lmKuDR ysTEaC2v+tpyJ+1q4umNUypjSaYuWri3JRL/zFPOn/OJ3JFbFY6V2lj1n/ewIrUnGcpN2OTsQrZ4 dnOljdX4ymJ8IXeb2qtfeOT5V89M36XWKyVSnU3PxLj5aqfCAObCKUzasSu7brzl9j7qdeD1Cmb8 gvQfmdMZH51T3q+CmP71EY3U+GPmdujDRDM+KKb75Ch0WZ4qKgxBfxan0mCBsDHjLpjTa6vuN1QW uwIakSzllloCyXCw0KF8pfMa/nGTXqI0aRnTtf48i1Sqp++MM6R0/O/MGiYK3+l5FJYimqGnZGTu HZF2R7Pij9EBcLAhYSEhrMrIjlMzayRqs6e2OFTkUknVZm9VMgLrB5/SFpYkPEaVLZSjKyyJe4ya nFB2LskG60w8pJJcMnWG/RBMkDzOy7VsD/gYLUceYZ8m3vF3H4QMb8Eo+/SDWm+BIgBLbkccfdC3 WXeAV0ysNKB2TrtwMbhBujTbwcuFi/z7M2BhPBQW1nkJIsSHysgQljcF/OCbxUKrXlZeJxbZVKDx 7kTdj7Yvv2wgCjvVXYXuzsFVNSsvnxtKf9nYndfo8CTz3GZlU1dekx02PWYFd3PJRdfdtOf8RG1n 2YprFhZdtBd2Ct0lAWPFKVctGp7vtnvXXnDFBae6h+a77J5158Mm6APeruTWi60wV3T5dCkVgpRs VEqFIKU8U8zoNRlNxK7MC8nMsLLk+wdCs2MwQFt7cp0ojMSMHYWoESYwIN7JBtIoJwVe5j+em5FV ZhkpzlKUGEFs2GKVhzKxNaxdtnDrYZ5Ba1KOlaqhaaPrSz+6612TXQOLRa16plaqy4l6wnGriPnd 79Sq22BtbtALI3ZSVyDsNnH1m+RiWOSvSZTkyx8UiTmGk6rkX/4WXnOldgoBIfcx2E/T9FVgh0hL 1npaQC78KHv0YYMhAku51fZRLn+kQh0/zJwD/0fBw1zEy+3Gek5W0meAqYbTJ8npCRrOCFO1dN4M PCe0SxmDOkjoZb/FNaYKTDAtFlolcXYsOzOzk7E2OgkkldIVuWdxMqXWqB6zmew6icQQcjNFNYN1 EPKo3KW5pUMzylXC2xHQ61C1LdtWv/o7s/3aUOOKK4dHmeMGze1STzDsMUk0Jo22uLbewSjLFs9q rSoyGvMCsFDTYzPLYIYg4FKowoGc0r4VhfmDS1aeecnM77lRvkboq7wN8p1PXpludwuz8l0IgvCO chFeTfpzSQP8y4jcBk5bNsr5RmZpVYeZbfCfLVqZyofqLPDrgEGHtSNd/dBZ1h4MhaRdfbBKaD2M vUzUXZi+OU4nKKm8aTMlvE4hTLSByU6SP/3a//nVJ9V5YaXrV3o9sP4+M7NOZ+Ay44yYlX03hnaZ pGY3x91lK593zr1riwZ7mx0GDSeBzqRCmd8yVN+2stlnLR9sOsukB/PVmtUbmtZ0RJpnJYdnValU SrESOlNNS7c1zL9oXl5uz2mtDYMVOczdiVOWzW+OKo0OndJpkbkDIY/R7rVH6mfl+ipybXqz1O2H eD9U35cob/KGvWaDIq8ooVKFgzmRthV1/Nal7fBtRS2zYS5CATHFB7COKQ7/NeTJ6ZpMgiYLqQdJ gkiLPIXeYpMxYYzJ5HlyuTEv4bF7E7CfIPbCRB5n8mrAoXiKQWuwZs0oB8vql8HUaKIe+k100Vrx EWhphcHqTGdqWndKGMnPumW98J3f6rqTNRbIBMrl5Znlbtk4T0r9Drzb7uNewj7VpoQw/BGiYUo8 bbQbaU/foGT9UleiJVHSlqtnb9qoVqffZ9O1TC+TktN6Y3w/25l/32yX+2Nwnxr2aTm8ZAI9J+WJ T23s0rGHBD+UA/XkC1jn10Reni5d6ofUVLrUYVTn18Sgrkh5LYlp82EJRYnWS2o4af0oU8ErQ9Go Iz+WgGoBg0g7RhK9Gft2TK4hdPkIeCMqbfgUZvIzb17Q6oHTI+jLlcJX/i9cf7LIoamfNiuNHowu QMm8t4JT2D4Ol0VxP/TUL73g7lNi/T1NOTAxLZVD3KOI1s+v6d40M2Is6W9sWJnnNso2yMJ+doVW DYrRmdTpZHkg6Vl93eJ85qOGnZuWtucq9Fa1FF7d8ESifovNAWHu8kpnSdSqckXY4mjAYlb4o3l+ S/oDThSftQFsvg/6tCZxEMadOskD07XSDVpRUa10g1bq8h0Nh9kHIMhJss88DO/5qfz+CDiqqocb 6vI5WIYMK6mrR8x9zfBG2GRXRdVgraSfVAMTQWU24qCX/rYXmiZqiKokYMkwzS8sC8isfpWiZCcG T7NDDSLu1+bCmdvuXDt88ZyQzFbQdsrlo5vbN8Wsek6sAKmr/SUtid6zF9QakhfOnntmtz/9hc5X GnRUlSdtakVbc15zaThHxZoKt561ZWF5csnFfYHt191z13c3NZt0cqtR6vCH3Ca1TlW9/OJOV7hg xsqlzrhPLzfkaOqXRRb2eIobW5qx3VgD615nC2vWYY3U5DfuoJ8MkjdSyftAPGKJ3qwT6yScUj/K 7DzIO3uVE4vVYYkKvGUjTHhl7Vk45V+WPik7WItHx0eFTsvkhbCzJVq7aexquS1cHimrczFKds/Y O/AWEZicWc2xLpPoTzB71ew9EYb+GCfVgeA+tlplvty8oAUiDo44wKZyoD3MJbWwquHZ6c/WB88m RKx98GzJw+yP4N821bHP8moSqmzSi2DPRFR5h9kU/JOmdvaZA6qQHsxsCy/PSzrq2puapIlRRgPx bM8oo5tuaLS6w6J0GtdmohFwstiPE8TzMKFf+l9c8KTYsq83sOUnm0GhcYO2LfNWKH0pz1on7EY0 HN0T1vU8akzMOOP2tcv3Li0q6D9rRn+Ptahn3RXzT718ti9/5pra0s5Cy+0ab1mkAt5PkzuLc0tn lTlXaII1+R1DFTZ9pKGodqDSwewMDi7ob4rkda/mGzYumxtK7uyJLZo3s9pf2LU40bRxcY/b29DW w840RTwGf7LRbcuNRm05pbWNY9+3xeMJu7++oTGYk+83esvbqB3SOfj3RDLQVynpJjdO19aMrA+Y AYLj464m9AFl0LeA/9blAh9c+WC8qEgKs0O1I+a5reAEQCl92XVAtN7jW29Ta/5BQq/3zc7OyN6Y ea8RhA1+9CsethzXnYYy0ob1phiHiHabCmdtu4NW97Asp6BjzZ7Ht0eaq4rNYLew9B0qfLSyO9F/ 3qJaYwmt8F1+RkwrvLMSKrxK1S5UeJua/WJShd/23Xvvum5zM0QpMrnFKHHSqEOj11Quv7grU+UT mSq/IrxwhruksbUZ4nAqa3LaAnbPEm3NpyRHRqVPnrxb354lrMjaBCupt0IdktOywg+cJ72Zvm6q OOuEduxh+fvwPvONmWOIUhFMljPPwduKL40/LgqTIbGSVHPvkBrWT5LcUlIjSZOkmIc0SJaIGklS dB7kHxof5z4je8WV5AxpA3lKVEnqIAW5LlJNt7m/kGp213gnbJeJKkiY+ZyEYTw+RClZT8I0D1KN qHL8NVqe/TUcjxCWfYoshvx53BNkvfgzcjb3w/Gfcz8jJlY3fgEbIPRe6yC1QlJAMmaYA+yDtAaS A1IYHu0ecg/8B50jbDH7CMdyC0US0Y1imfgaSaPkbWm39CnZ2XKn/HnFLMUnyh+olqub1W9q5ms+ 0dboNLof6HX6Rw2rDB8ZrzJVmX5lbrQQy26rzNpoPQNWLV6X02rPs7/suMO51Pkr113u+YJuSuE/ N4lJCt4nZ4kOBoqGwLzfYMzwCj/VHAP/S44S/n0eDC6R5oZZDR0DsabhtauXblxd0Hja2uUdm2Fn Gdkv50bZ20ccSc8o+70ReyngCsTGkZxy2DsdsQGxcMRWCZkLEPMRgRFrNWT6ET6EF+FBuBEuhBOR g3AgbAjriKUV3r39E+J1xGuIVxGvIP6I+APiZcRLiN8jXkS8gPgt4neIY4jfIH6NeB7xK8RRxLOI XyKeQTyN+AXi54inEEcQP0P8FPEE4pERM32+50bM/YBDiFHEw4iHRszL4dhBxIOIA4gRxJMCuOSI p8AzypUgihFFiEJEQtAtF8c99Yg7AScoBbBfjrgKQXFfIP6B+BzxGeJTxCeIvyP+hnh5xFkCp7+E +D3iRcTvEMcQv0UcwntRobk9jPgN4teIhxAPIkbRFH+AuA1xK+Ig4mbEC4ibELegtX4HcTniUjSw i3HvIsRpaMKXIS5BrEOsRZyKWIOn9yMGEQOIeYi5iN2IPkQv4vuIGYhdiFmImYgeRLcATot7nYgu hEUwItaMWI+YjTAhjAgDQo/QIbQIDUKNUCGUCAViDkIugHkcre4xtDo32pIL4UQ4EDkIG0KE5sah ub2DZvM24i3Em4ifo4U8hXgScQSt4GeIHyLuR+wTwNlR4WUonlLEMuGuOQvehBlhQhgRBoQeoUMw eLsEb3ccMYY4gXgDb/dPiNcRryFeRbyC+CPiD4if4hM9gXgc8RjiJ4gfIx5FHEY8grgXH/oexN2I uxB3Iu5A/BkFshdxLeJqxJWIPWj61yC2I7YhtiLORFyFOAOxBbEZsQmxFGvHEsRixCLEMCKJWilB FCOKEIWIIUQCEUcUIGKIPEQuIowIIYKIKCIigGPRhPPRhD9DfIL4O+JviI8RHyH+ivgL4jjiQ8QH iPcR7yHeRbyDeBvxFuJTxJuIPyPeEMAVoNXlI2KIPEQuIoqIIEKIAMKP8CE8CIVgppwcIUNIERIB 7MdokR8h/or4C+I44kPE+4j3EO8inkOL/BXiA8TziKOIZ9EUn0E8jfiFAC6MeyNoiinEA4gfIW5E 3IC4HvFLxH0CODEa33WICxA7EechzkWcg1iBpngAsRqxCu3lFMRyxH5EC6Id0YhoQPCIesSFiPMR 30XUIOoQ1YgqRCWiA9GGaEVUIMoRMsFQWCmiFiFBiBEiBIfI2DyDe82IJgRBnCWAGUekMXMl7o0h TiC+RHyB+CfiH4ifYIvwY8SjiMOI/SOmyyB+SQlgd6ACzhbAuPnndI2ezzXtns8gfaru9LwB6U+Q XlfN8DwJ6Qikn0H6KaQnID0O6THlXM9PID0I6QCkEUj7IaUgPQDpR5B+COl+SPsg3QfpXkj3QLob 0l2Q7oR0B6TbId2mWOW5FdItkG6G9H1IN0H6HqQbId0A6XpI34V0HaS98jM9V0O6CtKVkK6AdDmk 78hXwIP+YMRYDLgNceuIAeJm5hbE1YirRvQ8ZF6JuAJxOeI7iMsQuxGXInYhLkHMQPSMgAhHmW5E F6IT0YFoR7QhWhEtiOYRbQuc3oRoRLgQToQDYUfkIGwjoLFRxoqwIMwIE8KIMIyAPkcZPT8P+Amk v0P6G6SPIX0E6a+Q/gJ6fQ3Sq5BegfRHSH+A9DKkl0BHv4f0Y0iPQnoE0iFIPwBdXAtyH2VuQGFf j1iNglmFWIk4BbECsRyxDLEUMYwYQpQikiimEkQxoghRiEgg4ogClE8+QoqQIMSIH44YTXDX948Y HYB9iPtGjAHYuxdxD+JufKK7EHci7kDcjvgu4jrEXsS1aGh7ENcgliAW44MtQixELEDMRwwiBhDz EHMR/Yg5iD7EbEQvYhZiJiKGyEPx5CKiiAgijAghgogAwo/woei8CA9ChOAQLIJBEP4CsNBxSGlI Y5BOQPoS0hdgb/+E9A9IH0L6ANL7kN6D9C6kdyC9DXb3FqQ3If0Z0nOQfgXpKKRnIf0S0jOQnob0 C0g/h/QUpFFID4NtPgTpIKRR5gHUyI8QNyO+j7gJNfI9xI2IixEXjejjcPqFKL0LEOcjzkPsRJyL OAexA3E24izEdsQ2xFbEmYgzEFsQmxGbEBsRpyM2IE5DrEesQ6xFNCB4VFo9og5Ri6hBVCOqEJWI CkQ5qrAMoUNoERqEGqFCKNHVKBByhIxPgLaPg0ZehPQCpN9BOgbpt5B+A+nXkJ4HLe0BL3KN4ElO ReGv4deDi76IC3ku5OKeC5i45/z2nf3n7dvZf277jv5z9u3oV+6o3tG1g1PucADO2rFvxx92SM5u 395/1r7t/aLtpu2sYlv7mf1b953ZrzyTUZ3RvqV/zpY3t3yyhTNtmbNl+ZbNW67dcgwypHdseXDL kS0cXTtl2FJR3bpzy1VbWBMcZ8kWRkuzfVuUmtbN7Rv7N+3b2C/amNzIVr+5kXl+I8N6NzL8xlkb WboAa2Mw2kpLj2+02FvJRu/Gwo3c6e2n9W/Yd1r/+vZ1/c+tY9bA46yOr+xftW9l/ynx5f0r9i3v XxZf2j8cH+pfEl/Uv3jfov6F8fn9C/bN7x+MD/TPg/Jz43P6+/fN6e+L9/bP3tfbPzM+o38G5PfE u/q793X1d8bb+zv2tffPamfa4q39LVyZBybciRv+Nrh3uj9yi5RDrg0udoPrdddHLm6D8yMne66D 0drPtV9p57TwweJHjifnypxbch7IEWuFDU61wbDTwG7Q79SzhXpe/7z+dRhe19+qZ7VXam/RPqDl ZmqXaP+qHdeKHtAyD2ge0zyn4WZqlvCLNadpOK2G5nA6XhMvatWqPeqEmqtJqOvVM9XclWqGV8eL W3l1MNJar5qpWqLiblExvCqc2/pXxbiC5RVwgJeHC+DD6mglHOOFf/vN6ACcDGT8IGP2tHKPCv8g XAz/n/Gq/XP6YrGuUen47K6UfNaCFLMrFeqjn3zv/JRkF/wzzPkLBvYzzBWD9J8SzkmZ6D9xFfYv uvxy4mrsSrn6Bka4W291NQ52pXbSbZ4XtsfpNoEig7HFm7ZsgjV0m2KbNsPn5sWbIGfzFvgTwMAn bG+BD7oFy+1o4a/7wYvENm1ZsgVOhRKLN22iF90CG3SHXvzrzvu/vK+TAPN1mf+X9/9JArYli8n/ AxDsxR8KZW5kc3RyZWFtCmVuZG9iagoyMTcgMCBvYmoKMTQ4NzUKZW5kb2JqCjIxOCAwIG9iago8 PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5NTIgL0NhcEhlaWdodCA2MzkgL0Rlc2Nl bnQgLTI2OSAvRmxhZ3MgNjgKL0ZvbnRCQm94IFstNDkzIC0xOTQgMTIzOSA5NTJdIC9Gb250TmFt ZSAvREFQQUlYK0NhbGlicmktQm9sZEl0YWxpYyAvSXRhbGljQW5nbGUKLTExIC9TdGVtViAwIC9N YXhXaWR0aCAxMzEwIC9YSGVpZ2h0IDQ3NiAvRm9udEZpbGUyIDIxNiAwIFIgPj4KZW5kb2JqCjIx OSAwIG9iagpbIDUwNyAyNjcgNTA3IDQ5NSA0NzAgNTI4IDQ5MSAzOTQgMjI2IDUyNyAzMTYgMjQ2 IDQxMiA1MjggMzQ3IDI0NiA1MjcgMzUyCjgwNCA1MDcgNDIzIDYzMCA1MDcgOTA3IDUyNyA1Mjgg MjU4IDQ1OSA1MDcgNTA3IDQ4OCA1MjggNTI3IDUyOCA1MDcgNTE5IDQ2OQo0NjUgMjY3IDUzMiA1 MDcgNTA3IDg3NCA1MDcgNjY4IDY1MyA1MjggNjA2IDY1NiA1NjMgNzQ1IDQ4MCBdCmVuZG9iagoy MjAgMCBvYmoKPDwgL0xlbmd0aCAyMjEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4AV2UwWrbQBCG73qKPaaHoLW0thMQgpAQ8CFtqdsHkLQrI6glIcsHv32/f5Km0MMf8u/szM43 9jh/PrwcxmF1+fdl6o5pdf0wxiVdpuvSJdem0zBmm8LFoVs/nJ1152bOcpKPt8uazoexn1xVZc7l P0i5rMvN3T3FqU1fdPZtiWkZxpO7+/V8tJPjdZ5/p3MaV+ezunYx9ZR7a+avzTm53FLvD5H4sN7u yfp34+dtTo6OyNi8t9RNMV3mpktLM55SVnlfV6+vdZbG+F9o698z2v7jarGpK8n7cldnVVFgkfdF ki2xiOhGNmCR99sgu8Ui7/ePsjsswnrZPRZ5v9vKPmAR0VL2ESt5/mIb/kVc7mVbLMJaVx0WYTtF IxZhrVTCIqw12WMRD6nJkllIRPUQHCasAEtYJS4XsrBKRKMsrBL4FoW1NN6gNhiYyftgD8FaGi8V iMIqMau9LKwSlR9kYZWwlgtrabxgEoVVoiu7DGtpgDRDFDiJdzXYAJxEKT0UAJTItShwwQB3QgjA SRDZZeBoXqXUM/VM5GrsAUAJBIsCFwwwaJIBOImoPm7OqmBEUGOhkaisSTIwE+/aZYg4V1QfdwBO opT1DBzn2L0+UMqbuGwWuK0BkkIUOIlcAdKpiVwB8j01MZzW9uHvF1+roRX+XLnuuixsm+25LaIW bBjT50/BPM1aKNMfX+YOqQplbmRzdHJlYW0KZW5kb2JqCjIyMSAwIG9iago1MjcKZW5kb2JqCjQ2 IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0RBUEFJ WCtDYWxpYnJpLUJvbGRJdGFsaWMgL0ZvbnREZXNjcmlwdG9yCjIxOCAwIFIgL1dpZHRocyAyMTkg MCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDg0IC9Ub1VuaWNvZGUgMjIwIDAgUiA+PgplbmRv YmoKMjIyIDAgb2JqCjw8IC9MZW5ndGggMjIzIDAgUiAvTGVuZ3RoMSA3ODUyIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4AaVZC3hU1bVee+9zZiaPSYbwSCDAmcnJQCATEwIIhJFMHhMC wyNAgAy1ZiYhvDHBBBQLBkvxEVCoUhSrgLU8KlBOJkKHRyV6q71oLVgfVa8FvGK1tlrq69oKOfff JwGkX797v/vd2Vlr7fXYe6299jr7PEKMiJJpHQkK1C+PNpGDiiD5DSCjflWL+3PfO3ejf4HI/uKC poXLP73pyCNEjgNE6taFy1Yv2Hf71veJUgKwuWNRQ3T+199b/R3wcfA3LoKg97Dkx8BfBJ+9aHnL HY5xbCBRah/wjmWN9VHyo1EqZGRbHr2jyXaTay/4bPDuW6PLG5KKtLHgy8EPb2psbjFzaD74JvBD mm5raLowdutPwT8K6A0ZQ5O/ZLIBMIeUqA8i2imkAQaKrZRJZL4HuAD4qGuyeUldSnrXEvO8kDMc 7AEiL22jnZRNF9kIep46aTLtoRKqoq00kU7TIUqh1exlUkinctpHXqYRpwpKZyptp7fpZrqNPqDz lEMhOsvSME+QmqgfjTP/BByi+8yjsEqkMvo5HWPL2CzKR7+S+1guPG82OymdcsxXzLfAPUEfsGyz nSrR+yP1oqHUSj+kNFpCL5mXEG821dFetob9iTwUoY3KKKXNXErj6TC9wULoTaXV6lsJh2kZRj3F 0lmnec78kJ5VGDVgpu/TfYg4Rp38BlGm7kLOhtBNNI2i0H6P3ma92QgRMIeapeZ2SPfSZzyXvyjs iCOXJlEtPUBPIhtvoka+ZElsNHuC7Ud7lX2qvoXYQrSS7qR1iHwPxh6go2wEG8HTeTqylU7DaDZ0 m2k3/HfQGRZiYdbJnhO71YKuYrOP2df80DRpONUgwp30HHx8wQpgAw8iS7Qog5UWtfDy3VjhfHqc ztCriOMs8v4lfc2Go73H7+Kt5lxzn/kBYnGQRmNpBs2jRlpFt9NPsKvP06/ob+wbngDL08oL6p3q RfMh5HYIlSL26bCehbk3YpdiFEd7E6vsxdxYxVg2jc1kC9lmto3F2dvsbW7jHr6CfywM8bJ4V7lR Vc0izNSPBsOvTnNpEXbgLmT7Iax3H71Ap1hfNoTlYUVvYvxXfDwvR3uKn+ZnxQaxWbmk3tN1vuvP Xd+YbWRHlU1EHlbS08jCX1k/xDCMLWHN7H1EvoU/I1KES+hitCgR1SIs7hNbxb+L3yq3KfuVd9RJ alTdb4923dr1qhkyf4BcMFwhg1FJPhpFY1A/C1BNSxFfE9pttIbupjZ6EPXyEO2i/Vj3STpFb9Af 6C/YAWIexLwY3pej6jawB9G2swPsOfYCO8XeY1/JxrPQcviNvJiX8Qq+kG9A28rP8Df5R2KgqBet Yh3aDnFEvK2QoiimWohWqW5U99petufYK+11jt9c+uTy8Mvhy2e7qGtA13e6tnU91/WhOcdcjfi9 lEc3INJ7EeV21OButKdRiUfoRZxfv7di/YxxpqLiM5iOavBh14rZRDYJbSqbgTYbbS6bhxZldWwR Witbx77P1rMfsAfYj6z2KNa2m/2MHUH7BTuG9gY7x/7IPmafcRQxF6hmLx/K8/k4rLSMT+TT+Uy0 hbwRrYnfxldhh/byDn6Uvyl6C6/IE1GxQmwXPxfPi9fF3xWu+JR8xa/MURYq65XTyqvKW8o3qqYG 1UXqDvV5W6ZtlG22bYntUdsh20e2S3abvcpeZ19jf91uOrw4sX6NdR/Gnl775dtOs2a1j3IHP4fr IkM0qfey2ciYjVeLZeJB8Tt1Abso3Owd1iYWi6XmU6KCfy0a2Rx+kmUJTS0SC2gTmWw/f49/wT9U +rJq/ieWo/yQ/YI3ijJuk67U15S+ynr1IyL+eyria1knf0GsF+vNX1KRuoOdU3fwV8mtnOe96Ryu 6ns57hz0W76Yb6QaZZT6DS1G3n+m3oF8T+D3seHidWUHfSB0/jm7yLbh1HiFTVay+S18HNuPE/cy G0yfsBXUxH5EAXac/YHFibF9Yi+bwpOxWwZ3sjE4/l8RHva6SKSwjJEN4X1ZFb/IZ4sTtjNiNGM4 JX5HdzLBClA7V35ddCuugK18KM60IE6T11ghZdAjOO+/6DohT2z1LXUj6uxJ4aOZVEDf5S/jPvkQ TpoPcE3eQ4V0DDV4HxXwR2mNuY7Nx7k/FecnpzhbQvksCadlOmJrxf2iH8/CWVgL11/j/H8Jp36I fUq3MzeurE7KUaRmkxLEyRTB+bsRbT59F9zj9JDtsPoaTWfpRIq7aweq/F26Bfec9+F/AO6jP8TJ 9qTiQ9RunMwrMOLxrkoKoN1DLzNOaxHzBFznVUolTt5t5hKscDHuUVNwTzxFi81HqAx7N9Ncb26k WvNJ82ZaSLPMfTh/V5kxupHuVcN8jpqrjMIZe4r9Cvej/2AbcW5X0js4j7wsgz5G+znin6Aepzbl 9zg7i81N5hvUF/nIQobqcBe9QMvpU+StUnTSyK5pvN2sEE24Q52jGeZeU2OJtMhchpP3BO22qzh7 1tFgdTdqlwKls6sDxRNu8o8vGjd2zI2jR40sHFGQf0OeL3f4sJyhQ7zZepbHrQ0eNDBzQP+M9H59 eqf1cqWmOJOTEhMcdpuqCM7IF9QrIm5jSMRQhuiVlXmS16MQRL8liBhuiCqutzHcclwUqussA7Bc 8E+WgW7LwFVL5nLjOSfP5w7qbuOVct0dZ/Nm1KD/QLkedhufWP2pVn+L1Xei7/FggDuYsajcbbCI O2hUrFrUFoyU5/lYe1JimV7WkJjno/bEJHST0DPS9aZ2lj6BWR2eHixq5+RwYonGAL08aPTXMRTT CG8wOt+omlETLM/0eMJ5PoOV1et1BumlRmquZUJllhvDVmbYLTfuxQZWQxvd7b7Otk1xF9VFcpPn 6/OjN9cYIoo5gkavXPgtN9LvvJBxjcXkaWU1935bmynaghmL3dK4re1et7FrRs23xmZ65AzhMOYw uLci0lYBx5uwT6FZbvjiG8I1BtsAh265Drmm7tU16EEpiSxxGwl6qb6obUkEGzOgzaCZqz2xAQMC R83zNCDobquu0T1GcaYejpYPbO9DbTNXd/QPuPtfr8nztbt6dae1PSW1p5Ps/HanASnv1lk9y1z2 QjOv5pXJiPRJRgD1VO9GJDU61jRWooax1FY/FunHL8wwypiP/VhsJJRF2lxFkLuwRGaoXpfubvuS sP/6J3+5XhLtkdi8ri9JKmWVXC00Aze0nqIzcnON4cNlgdjLsKOIcYLFj87zrYpzQ29yuUGQPqpC bqPhonwk3+OR27sxHqA6MMa6GTXdvJvqMmMUyM8NGzwiNZ1XNH1nS826K5qrwyM66vgZ3K+J+hqO IVf/Ul39egcXFRms3/+gbujWh2bpoRnzatzBtkhPzYaqr+O69TKhyBt0PT3WPRAJNxSvYfNO0lF6 M+ehjrzyT/VW6MHFkUpcaojR6F1WIzI5JpA9nimsqVC/N8+7Mp9kapLlXIrXZtX//LjdgQK2JMxd Ybgild04nOjx9Fxe/9uguHlRjrLItWE9azaKcntW1b1GY/x1/HXhJbeJUDVOJx6qntfWlnidrgLn Xltbhe6uaIu0RePmujrd7dLbjooaUdPWFMSJ1b39cfPYxkyjYlMYS1nEilDknErlxVhWXdMTkpVc BCWTTThT8SSAhjdIO01t5+w4fxbPlnZ+MkaqEufPPiMo0S47hxn1d9jUk9BzEmwYJbCl7BbKyHV9 5b/sn+b6wj/1sp+K0XddAhpR4Onl6eUFYrhrXnKLzksBlb7BE0UnXEq3IvmVrW/bDtem+r909HdA QPTC3l6VV+jVyIgSLHupgNDu6QrSXBd909I101V0VSO18sdteEfl3X3r7dSy4PQZom7EQjm58K42 B6t+Ce+cArycNa1nHhueG6gqVB2cW5JbvXh5Q/O0httnNi6P3lo1a2q1nL17YtMj32P/xU/qBeFx otrsFO91BIOFgTho7g0WjeUMKzwqFbEBAwt/Kd7jB/AIr0FwLtYv09KcjZWW9nRuHNvd6RieV3iu JFGcpb8CuDgrzuF2bI3qyLmh8GKJEwIm7qJUPB1ptEv8gQwAp4B4pyN7SOHOk+I30L8kTiFmOexU zNmrEBP+WvwC69bwBH+4R3O4I6VXIZU0iweQjk7gM4DzgIsAhRrFXmoFbAYcAiiUCqwB8gHTpUTs F/sR526MTwXOBzQCNgMUqhZPQ75UYrFPLMEjhSY24ZW+L+hG8bBFfwo6APxPIMeLl3gSvKQ7e/gf g0r9Yz3y7eD7gX+0hz4CeSb4beAl/VEPv0qstMa19NBdojk2WHOVDIbeDSgACPS2orcVqdsqtxGY 4ZF4mRVBO2ghZlzeTZHItTGPbu3R2o70/oW7kNK1SP1aZG4tMreWFNisuWKzptsmT6yBzRrYrIHN GmSlQDTDX7MsLWAXwA0QyHsz8i7lBnAn4AxA0A+AtwB2SU7cjjwOQ1T3iyWxHA3FtrBjXKCw+Dje ABimXdDRf1Dh5mtcQqIsxAUdCSk9NFXaNli2DR0JyVLa0DFgUDeF1dKSFFFP3wNw6gOcDRgFKAco oj6Wna8dE9NouYMCKVorbxWtSquqFJSztJOikKpwWWuUJvLID4NhWq2fjYkkNCWsSxCuBHdCQUIg oSpBbRStYrMQmsgXxWK6qBVq3OyM2YtGggQm2opGbknalWQkdSadSVINW6ftjO287aJNddsKbAFb lS1ia7Kts22x7bIlbLFtsfNIUlPSuiThSnInFSQFkqqSVM3OdpVsEHVYJgG7AE2ALQAFOa6F3C1u AdRiN2qRtlsgJ2AC5wKcQf88qAouFXapsEuFNBXSVEgJWGqqABFAE0Bq8aIFLDVuQAHgPOAiwAYY Cm0KpCnEIU+BHD3AZHBOcE5wTlid4ZcQoQvYDagCCEt2Hj1UDfAVXUGPPgJqI6m/CODWOKkLAAS/ FIgO7RzGjGFs1zC2ZRgL+ItLCgNZQGlpabV6rbc2p3a30qg3ehtzGncr0/Xp3uk503crxXqxtzin eLeSr+d783Pydyuarnm1HG23snnKoSknp5yeotROaZzSOkWMwdZ1xHILCi2a5ZX0cKz/gMIxqSXj +SEspxZ4J+AcQJAGnA8oBjQCFH4IWOMHIT0I6UGaDqgFqBhxEONTgaVe6qR8J0C1eufQ49fpBRZ+ IFY0cnrJZBy5tYCdAIG5D2D8Acu6u3fIkhvA5y35dGBpvwsgozxwdYzAATdPxgGsAYoBtYAmgEqn xVw6B0AcwBqgCXAIoIh5aHPFXH4Q7QA/IHwB54i+GvXrh3tHWi+Hq8TFk1EDTrbPwo9a+H4LF1s4 O5Ay2fnVZOezk533THYORYfnUAkGbLWwJ5BU4nymxDm9xDmsxInZ0slDTt7XwjaJ2Z8tPM3CvkAf j/PvHufnHuffPM4nPM4VHudNHjluIK5dJ+9j4SSJ8Vov8WQLDwkkac4XNedczTlGc5Y42Q6GGKjU woMtnCkx++yZ1PJUSjjOPsNHMCdnMf8wLc7JIsyM+Uu0OOuK+SeCXI75d4D8I+Z/WDvB/s6sWxr7 KpZ9QSvpy75gk/DRU2Of99C/sUl4wdTwuWESXnU1tof8zAv605j/bmn/FMY/Bv4nlOWQ457Eq7Ok O/EBScqf6Bn3eMxXB68/jvlWw+tj5GPS6pGY7wKkD8d894M8FPMtA9kc88oAl8T8w7WSXmwhZeMJ SmP15OUykik9Hisx8zLwE7sHB2M+OapcOoizspg+AmSojPIE06nKcqfFdGuRg0i3ghtIuhV0Jnkt msJSreCdlGVRR0y/G7PYnvFe0P7Lf1wuHN82U2M7tPdPYH1zwP4nmxTbr716VKYrpp32xZn3iPZb /bj2QnaczYlpnb64A4qTvjhnh7V2JNmALWdHtEO+hdpB3dLu1qHFVu/052k/1udp273gY9rdvhMy DFqOFc+BOuyboE3x79cqvHEGdcAPZ4FErUi/TRsH8dg4m9SxXxuRHZehFGCO/Ue04fA4RLdCmT3m GB9NdrYy4LO34OvYHPsM+3j7SHue3W0fZB9o7+NIc7gcKY5kR6LD4bA5FAd3kKNP3DwfyJXPb31s LklsOLbxuGn1XTgaGS5AifGc6+C4dozeIsRDs0qZkRaiUHWpMSY3FLebM42xuSHDUfWdmnbGHgyD M/h9cUbVNXFmStGGTDyN1xzFB6v8DQ9kSrpmwwPhMAsZnfUUqnMbX83COhJnzDNUvTSD+q0qzihO m9BrXEX5v0ARSxgpz732y7jWRS9jkLEtNKvGeHpQ2CiUHXNQOGRMlK/QR/GFujFYfpQ3SRKuOcru 5CuCM6Wc3VkevmpGWbwJZuSXRJp1UJY0oyzWYZlNsWZDmWYFy9uzgKTR82ySNEL5PG8ZLbSMUOMr 5FxVksCMD6Zsa65sPliaoR66J0v99mTJxFKtyVKTyZpsoDRq93rhzwcUrmkf44VBu3eMpd5/Ta1b 6qMsTNLgKP45E7b8MMtP9xQ53Taogh4b7oDNdWn8/zINpf+HGVhH9N359UF8yIjowQZAxNi4alGG sa7O7W6f/65UuA0xJFJXv0jSaIPxrt5QbszXy93tUWvcP6nrpTqql7dTfbC6pr0+0FAeiwaiQT1a Hu7Y01oWus7X/Vd9lbX+C1+tcrIy6WuPNe6ffIWkeo/0FZK+QtLXnsAey1doZikLVdW0O6g0jNdn i3bwpERcD5FMT7i0n6tpgnVxjPdk3JV5TCHctpLwfSEZ36OcAHnd5JXklUgVrk6pSpGfqnpUGXeN 92QeY/t6VC6Ie+ml+I6bEVxcfvWvubm5RcLKlbnALSulEh1ctJ5ZIaMCHxcMv+EP4ltNeZjJXVvZ 8yurCbhO+k/7eaO/1b/Zv9N/yK+uXBmGOO1k1uksXpvVmNWatTlrZ9ahLJtU3FxzJODfmfXXLLES 1cRa8AtKV3ANij/JtqxEMM3NBCfNgG53uStzy2pKsqgeT7sMT+Z51BugA0YCZgFU+jfg1wDvAz4H KLQe+GHAU4AOKcG/F/LwmaNcegxjxqP4/l/YUTC6cGwcNLqgm86a102D07qpv6QwA/pY8cjEklQ8 eDM6BvwS4B3Ax4B/AFRRKAqtyRGz/IWbqTmXIVsEpkWi5twW/AsTK5fpbmnOzYWB5CEAh9xa6QXf 8yPWvJKQCmwICIwsebMcBh8Ye+VH/w1/0skPCmVuZHN0cmVhbQplbmRvYmoKMjIzIDAgb2JqCjUz NjUKZW5kb2JqCjIyNCAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA4OTEg L0NhcEhlaWdodCA2NzAgL0Rlc2NlbnQgLTIxNiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNTY4IC0z MDcgMjAyOSAxMDA2XSAvRm9udE5hbWUgL1BLVEVXQStUaW1lc05ld1JvbWFuUFNNVCAvSXRhbGlj QW5nbGUKMCAvU3RlbVYgMCAvTGVhZGluZyA0MiAvTWF4V2lkdGggMjAwMCAvWEhlaWdodCA0NTQg L0ZvbnRGaWxlMiAyMjIgMCBSID4+CmVuZG9iagoyMjUgMCBvYmoKWyAyNTAgXQplbmRvYmoKMjcg MCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvUEtURVdB K1RpbWVzTmV3Um9tYW5QU01UIC9Gb250RGVzY3JpcHRvcgoyMjQgMCBSIC9XaWR0aHMgMjI1IDAg UiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAzMiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcK Pj4KZW5kb2JqCjIyNiAwIG9iago8PCAvTGVuZ3RoIDIyNyAwIFIgL0xlbmd0aDEgMTA5MzYgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1Vp5fNTVtT937m+WJJNkJpnMJCSZJbP9ZiZh kkkIhARIMCwSQUSEgE0FDBGpERAQlfoQkVLU1FoQAZdSDCi4URarEa1L0C7S6gNtecWWtmlrX6ep z6K0GCbve+4kWLu8z/u3mdztnPu7v3u/99yz3BkSRGSlO0hS47WdC5cLq+gA5S2kN669eZX33F3L 9xOJrUSGr3csv65zoWv5ZURaAPyu6264tWPtrrMNaB8mKjq9ZPHC9g8nfWkXkfvr4NcuAcH0h8Hb 0P4e2oElnatuucVsXY92Eu32G5Zdu7BJn/I8kWcm2jWdC29Zbqmw/gntu9D23riwc/GvMxbtRLub 28uXrVwlnpRfRbsX7dnLb1q8/Jbb3hgBViFR5iOgCXz4z0om6kHppVZFMSjq32eStL8n/R9t40We 6WLt/1cxo5sFKYMyKQtzy0Y9h3LJRnbKo3y0HFRATnKhhpXgbztmP5++R8dR20uZhmLDVFpLt9Nh tB+mp+iYIVNso3fFBPE8bRGbxauiXWxWvY/jaYeMY2yreFWzGJJ44hnQNtMmOi5+rZ2in9E06qKf yZ10q5wAzq30jJgvJ1IprdAcqt2NPu9iV+tkPW0TmeKoOCV+Ju6hveJNgbfLVvoI422WD8vnMMvN WhF9JKulAW/ahnc8ocbAuKBvlwaxW7wv+uk5cokO8Yyw0hOG7XjnGnGeVqP/ZlFB99P9YgItoEXa LtDWY8/48yHesp26xA+x7i6kV+Vl6P8MVntcFGMex+mwWEHt0iLW0wClxHmZI108Fj2KtW6iLbTd sEFMFvcbSukXCoEu5KR9ou1Of9DwALd+vLOLfFo/f4w5tNpQjJmgD6hdJodpjnjTUCGeF28C6XaD y9AlOul1PFsk2vkpmYl+9xtmyHXUJd8xFNFRtNfTerFW223oNnSgZcVK7hPbDfPx1DZDPc2itSaH lgn81AfULl6pYarxuHGcsRRr3iYfFvfJh+llYaIilGvpUbnNtBGYrRH7gd7tjD+tAGrt2i7MdBk+ K5DWYqxWWgrsltAyaaEvYj8wW8zaBaQyGSmMsQJI+WitcQW9TCsN79BKlW8BWrfSOmClcFo3iDlt pzupstFsMmrYSCr32g4Ygpe2H2i8otX7vXm+ivK/a3ptZu8Bmnkg+1bv84ODM1u1YuO8A8aSAzJo OaAF/b/8V8xfVpS3zGz1Pi8umdQ8NOykBc0gXtmKN+CfyXjdpOYKLJAM1JHapnUYu6G1zORqzNDI JCxGg0bxt06/VUW2k2+dfKsy3+6zB312X4dGAytl8cBvUtvMOX/56CZTRI0hWmWnXG2cjzPop/GN Ya/bVZBjNUpLHn1nhOVQwO8tHlGQZ3I77TkZFkkmq0FzGtwB28nk6aSrzp7nqsOLBhr6Eq66SlEW CstRNbX1IuEsFTJH+H3/QJHWIqfmcTkXOl0ezVmU2lTkkh6na4HL6UZTdhaFxAprUWFhkTV1X6jo 8y1MWNBO0alVG+LQG77GPGuWJjXzO/S2LddiJi1L2mwne9WUzvZhQvlloXGiprbax/NxmPzHHC6X Q45zjXDni84i59J8pzN/aV4pjyt2D34kY2IONJOjMUOezDhhNRWTFevE+s4mK4MYJuEswCBlIbG7 c+68GzpbW2/ontG+aObMRYuwF4sGB7TVkEErldO8xrEZLusLbtkbLaBed192saVYi1liWr2lXnuy bF/4RcuLWmauu7BAc+b5yJQdqC7Oq/FmU64zUWEbSCYSfYmzybw0vG0UTyYTJ5O2VMOxyqBbVCdq R9WE/GUmsz0GxBXedsyKKzJBdofJDOQxyzXeCe5PfvPbC/GqgkcrgsFYQ56toSIYjj36/l+FftUV LT/Z57imS8rTf+w/ZZCf9gcCYbfc6NWD/tR3U3/a2DdnxhQNeL8MXZGDdZXR6EaP1/aCqy+Hek05 Fpddy83yjjCRVirrfLmOrLpcv+10X2KARSEtF/FkAmupDKZx8w3NUQxPVvjSiMaEXW6bHotNv/Ct eCBUPv1Xv2oZGQpVGK6JB4IVLb/qKtUjnkBAL5UbPZGgPxCIeAb4gAPzTYO/0zbJw8B8FG1onHub 8R7jQ8adBQ+YnzR2m7uDT+r7C45kvujpsWePKC0alV2VQdZoUUSeOeMUzoGM8zbvX0rPhM7ZTkQ/ rYrZx+b15Mmq2MhRiWxJIz1FFI7MNOn+/Frb6d7k2WSiD7KeV1dXxfvRNzDQZ+tPtfXX1dnxDzJS ZZsYCeBNBQ4n75FL7QJ2Bat0pXcsjQCv2j68dD4gzaOvq955cNmcdacss17teOA7fz499ubxN66a 8YqnNPT+UwcOV02p1PVHSgIm0ZNnX9La3Lpx6o+nzdi78dFncm3mlTfOjgfrZx16NlXvDgcCZV7s 2QLgUgFcymlt4xc2ltyXu8P/zdyHcnbkdZe/mNvjP1yeackyC5J27fKsa7KWZbWXrCpZl/XNrGez uksOuDPdrvOBLPsZLXoucKKiOa/ZOTtvtnNfaJ/eE+rRLTkOqvKZZzv08ByW1bO9STuDYusb6E32 2lK9bbz5dkYjvXZ18rDMv8FmdO3o9GnS/GU0qoYAhtwSwjaHQsXhksrN8x5+/cUtl9xam+9tCnrC qXefOJX6hfD+9LIdcoHm81S29ASDnqorrnz+Gw+8FAxai0aFPZfvEc633xYuVmoG6sD658Mql0Cn vdQ0gzrISDcj7VXJSfvgF+xDv+fQNkN7nmFtgrwA1v8FugNek0C6D2OdUeNBPYB3Dr1OUICa8eRs pL3wVPbBb9kH3bkPTxxBuwftHrR70M6kYsyAPZlS+Dcl8HvcpCMvhG0qRS2P5lBgGEHID/4VjsmB tt62pK3f1g8M+bwH0sKijnUaLoIiiomgT2EqHJZDD60WjlK3Hh3Z/u71fal+Ufb7E8IZX5J7YbHh ntx9azc+J3Z//ZHbQyWlla6qGmE+9b7IG6TnxoQ2rLn/XkwQsz2Kc15v9FAV3ddUTWGssxDzdwKX AFAoJta4L2DWuaAJcgoDaIPKh/sUWDmBaDaw1IBBJtpEETyhUSXQdWG0MEo35DEMShgYZcLzS+Bg JQZ6T/b22vqVzEBuqijen8DBauhPQJSACI7VsP74O103JF5plYxjVyqg5rnls8udkVgkfOEmzvd3 Ryqi+qM/+u3yL40M5G2uWrFILIrEykOpvfcFoEwCyAzXhlBrPvJYYpRHL7zmxjoco/AFdqSxyxtT K7SN8lHYhdH0x6aFdAlF6TJ41Fei/ALKG5BWov5llE8hPYb6UZQ9kL1DqLM9iFEt0PAAAStwKAM+ tYJAYYTPQA5YznRQz4CXJyTq5yguNBoDWRNIRsibQDLS3ZCc/RRCCuANIaQAJKoWqFZjPCvqMbwl jJYH8mulZ5EMSLPx3jBkOEhjYCGTZ9v6Bhp67UP6zJZM9sG+9APx4Z2o4/N7UZXVhGA901Ylfaah 38aJz+s3ZfWVWBqmbdi7d8Odjz8uKkvKxvxg803XV/uLl5du/fK4rQte/HigZ/qWluLSB3U9MSlP WnavX/fYY+vWdV+ouHd1+bTp5ZWeeO5X99w6ZeJfv/vKhbqxUwscfr/OOq0d8rkWXmEdfb9pKmQt zL494gkBjAOQKF4f23GOMcJ0HtxzqA0CjzLEFRK8TykBvEvQ9gOdAtQL8Vw5qIxcHTCzoF8tMGTM OM7xwEf1Y5cLaS56xpHzfobBuxLtq9F3FnrNo7G2gT7YhIY+W1+qTwktq8C0VVAlxLqh3wXBxqFO i7oyGKMvmkI2CeNx1C9aBnad2KILu7L1wwZjiFzdn99cHQlvL3Zfet/0B5+OJ8p1PfVJ3Bep8y9d fN1D/oaoL576JByON3dp5NUDAWd+qr656ejeVL0PIu+J6KVi1+q1d3ekFrjDaevKsr4XGM80LoCs h+m2pihyP/CS8L4zhJFKgK0fUjkCGHyK9TtQ8+J0B4CkFe1sYG7CE6WgEnxuEzWCItQ+hdHPi346 znzvQG/bSRiNYYQYKADEzsLZJBqV7LKlj3JZKH/4UCs4qn1DiLFLV2DIDDeO14NNjeEXRFM46I8P /EXXo1FR9XokpusiWOzRjt4wJt46JxIayPbBb8BhLzOsD/r9fifCTYHogLTtkKkG+qRpMna1nCYh TaYKmgi5mY36LJQ7wd9J9ZAOHSvWsY5CrD0b1HIqAp/wpI7RsqDvsgVHsTpyL5ByQP7qMVoW8KoB l58YgScqQDVB07JlCOCUV2HsWoxFQNwOLMexy5HoOwndyNIC4YFLmBzAEQU8diVaqCAsaHJSueA5 Y0yU9fg0UIwpSA2Kg1ABZRE+I8y2pCWZTJqNXM6rrBJtAt7iPziRgqUwOFLpV4W+mc9+rlDiyfpV bcVoIQ74RrwQ1uPTKyNzEpHwd4vdwufzlEdFbkhfmJ8VWZS4X6ydEwtGwqn/KdfD4dRPxLrUKb2S fTmNPBGWygvVH+WUudzusrKGTIPBOKp8XardG/QH3b7isFWw9sP9hcbRYDHNa/IASZBgZwYvSmFa 7izgmMFimdTwIUgdS/FMyJ1AYkoJNF9v24CCFDBeFDoI3JBjxqu1qyUPr7LaZ/DvX1gVCYtpWN5Y uN3xCzgxELICrSu9hE93DIsW3iEGU5jv7+B7XC5GNC2lrdjdBzCnLTRe6aBLMMNi7D3L2uXQ/DmY 9ThYlmroI771kNBcY7F7RNWQn0bUz0H/R/kUouen1ILzlQMpnYjUQFehvArlYqTVSCaagDUL8Fpo KixVBexCDWSjFE/x6RsH650HWcsBNiZYMUKva5F/AX29tBA9spBfQteAOxqtL+D5uRiRTwHTwnh6 JkKis319yYStD+rO1t+nHBe2JHyOGVcu29hNblA6L8FKLwHyUA/EZW3ic0qNJXCcsA9HNUNn/6IC HI4b4EYrFZnOhzWiEl95qnr8tLl54yJl/nUxT3N9RUtxsCFaVgkdGIw3O/ImV+v6Dl+BIfLF+slX O6M3Tlm/xjY+GvDfqocMFV3X3rE8taAUWlKfWCr2zmiZO6rmwinWi/6gXmpY79X9flewPDpu/ISG J46m3ezKGhZE1h/r4GfX04+bpkEj5EAPWLDDMdhZCT6hfR4nWlkl7Kcdu1mOvShQsvApdp09VNYB XtScOKMO0HjXsjFOBqSkHpFNBnqPgceUPWSVvNiPAPamCHvjUDsUAy9tlRywSmPAx/Rglxo4Mv9n hom3aDj9E9tUV3nRMhk4dP6cZfpMX3x+Ew1pDf0RLFM0Hl/wmWmKN7zfGIiOhWXqeBiWKTD5udpI BJaJkQ36nPnNw4Yp7HNHw+7PDFPUzRuAVc+HP79SHoR0umhSYw2dyTWdKTiXe6Kw2dyc1WJsEbPN s7OuNl4t9tv35+9x7cnusffkH3EdybZJ3dqeoefNKWQ/O5kOU6BG4VMOBdEI1oSDhsMQMnTsPPbG jh3Heg2Pp07//oPUaRH44AMRXPn6gw8eO/bg9tfE/PdSHwrbe++J3NSHwNhAE+EfboB/qAPznzfN hQ8YQArDDyyFHxhACsMPLMXp0eETB3GqSrAKG2SFPRIzaGdAjUNOPGSDyLiERmYhKSjMoJzD/rfQ SKQodnYkUpT2wCffC7k5gvI5lBbojQTGtGNMCzRdLnBiXcg6rxxvLUONPR+2LmXQFw7wr0SvK2gU /JYEe4LK72OR4MiNUUr29bG54U9iSFBwav/1yUzLCMISRHSh8OfQbf8wFArGU1P0SPWk/PxJ1RF9 u7u4ec813xc5g/Tm0oMNovaeg4fuvvvAs4OEOwhvAP6elsOHzlGwcPLk1IfHj6VaJhueveer3z6w +e4DfO46ce6W4dzFaENTHCvTsfoSdeqg9xlDIKoDV8aP8RzGeisQ60Y6jCRBZcwYMQcQzB3CLI2T A0hlgVbO/kovEFKqDfEJR/8wxQMXEUN88jmLAY/tM4U1fHTUtRFf2Rg0cRl7KhduCuuR2DPNCyvD el9xyTU/WjPvxtE+V2dsxtPXdw3bE8N6T8TvL3DsX7Nqal2wbtyyW7D2g4O/11xYe6O4uukBmoKd nYxVzEU5B2UXNMadsDd3ApU7gck98Ms2Q2vfBb3yFfR5BPwtyh4Voyyhh8DfAf5W8LeBvw2aZAdk 7Gn0ewz9HsM4j6HfPiV32UCvErHHSHoR/EPgHwL/EPg94L8AzXUYvkwQ2AWBcDGkz41+BI2UhbHz MD/WZIVKNrOwP2NwzxrEba2OcxQUjeh/Bk8UYtfGg3eClmNvIMfgNME/qsEbsiHxHFNmYVwLxsRd pxq3ALu5mL6Jtz6L9F21vz6cnTioBH3bxB7VSYTVbIXUNtqSbbis6k0m2+BVpSV/WCnCQI1WcY7L 6eL4m1XFkNbDCUAbefpWI/zZtQZ6pkPRsIqLDvqCkUJbdrT72qV3XHf76Lfee+el6bu0rPHuMp/X 7y73OEbdcsUXV978+tuvnDxcd+9Sf8LuD049WB4aU2avbZozeUrD1zbd9Y1YOJFYPSpe7c+ril3Z OKFWM27q2rS7oMjlYt9RUOtgv7ZI6wEiu5rGIkLKplVIdyFtRepGMkLzuICUGykHOigOfVOOZ9kD OA+OB7QXQAmp2w4cHWEB9QR2MQSbxLbJhN58R+LH7sVR41g+F3SBVGU72QbXFCdkyLjjrrRvoK0B zms6eh82MtAdaYfeZ1eXY2lFko4ocTEE4z98ZtR9rbo+XlNVEY2mvnTVdVen3CXhqvpFj0xa/c2w w74/Gqq5akUwXF4m28vgy6cOdi9Zqpf6qlzhQMs0/4J2j5gB8N3HR8UiiXk/ZJymDiZhPx7Gqp5o YnkMYlUSkl8F2WEPzA0cRoDC8XcI2pcgyTnQG2VAIh9aegTWXAEJD6LmAD65kO3P/KiRoBPw5Pie fSQXTmMe7pyi0LKsc4PQtAnYn74BDhGhTVmhsqylbTCHPmAAMshhmsd36elLxIu4sGeaRi3tLaWD 779li86lKzsf2hz2h6Lvhjwjq3D3gfhwwebL9uwpaE6EIw/6i8WK/1h19xLxiM8fCvgaL8zyBtkH b542+tlvi9dY45ZUYsZiMDn4vvYO8BpLJ5smwC8xYy3sTxBdj6ThvPqBTQlQ4NinHidToC/f/niQ qmH1ioCmBTiWUy5wHA3qCfQzQwpH4CmBZwlP1GAUP3pXQ1KtaF8P6bwO0ixQy0fNSvW2k319+Oco yIbz2pB0JWxvwEoBIo5/8hCRTlKzCaCsxqeGilFjKzsCpYXfaVSBTzqfx1EPfzXBF69poVOxpLrf iOEbtbSLWSyGD3xauZuHHjEsWJ+p6wHd9puMaDAcElm1IafdXuEd+9T6LD0ciNhu31MYm1QZqBFW jyeQ+GV2OByI5oiBVDDkDiUMp3zhsoAnXOjXjNqFJ8ThkDtclVpgaEVA7g6UhbyGC/lMYplVqW/D 8UXX5DZ8LOz8xSnRscftU4fLwSQ8j98Zu9Hm+8r0H0qTJYXOpm3nXz//msl9kTPUgYq049SBRNpx 0YpyJ8rdKBchvYy0CWkBEvc5irQRqR1pL9ISpB7t+GBqqD4f5USkTqSDSDzeVPD5e+0yfG6Dn/KG SIg7DFbDvTIkD2o3G3XjLtNNph+YX7GssryW8eWM81mUtdVabu1XMy0S98MW3AapMsBHaoTOIfMH md+CNKURyRtajwnnlpqvnNR86czYJctW33T94pvwhPpLbcFd7z/74/haYmT+vjkMyWyG5ZxKl+J7 4BbEQjMQj83ESZ2FU3sVbOlc3NLObxo03CGaIIsSNgh3d2I8pZCPU/lYjulEHWyhFGMUZbSq11Ib KKNgS6WoUfRqRU9AQ0tRqSgVKi8XAZRGEVWtCH0JfB1WS4qwqofUO4OKyz2l8KtRvcIDdI3Cq2hc l0LdLYpSUYL5G0Wp6sd1KYqxOilGqHqReqJQuFAaVS6Fk15VLYfi5av358GzkMIubLASRmFXHK5L kavqVpVnqTxTZMAWGFUuYT/+jFjFiNKG3mb6T4xkRNmMlkn1N6pcG+qnqZZUuUEhKuBfSGw38EOc n8JOG1XJfS6oqIhpUtUlDXBv6Gigg/n9Fd8JG1Fyi+uS/gJdLOFRfAKbaETJnHP0CjTSJ/Qxol2j 4kjkd4D2MZ3FeEbFkfRx0yBkUANNrUnxpKpLfLfMUdyf1Hj99EfofyP1qxbXJSXpt7AERpT8xj/Q f6sef1Atrkv6PeyFpA9wRiT9DvePEk/8BhrLqJ6Uqi6pDx4N8ETJ4/xa5b9iCaNfqvoZ8CW+rWbu z1X+M5X/FyyVpFP0U4XIKUXjuqSfKM57ivIuPLYmjP6uap1U+Yn0nkFj8w7w/kl6R3HeVvmPla38 kRrluKq/peg/pB/wXtMPVYvrkr6PX284QPu+onFd0pv0hqJxLukYSzr18gnB7wleU5zXYTPRGuRd em1o/cyRSlIlvpN8ie7FqC+rUV9Wu/kSIq15oDFHIufdPIpRQ6AxRyLnvWSKhL+aXncPfEgJD4hx eV6N9h2VP6fWdQT7n+53RFGPDL6NEZgi4fUeVHM4pDiH1BwO0rfVHJgjwec5fJsOqDkwR6LFczgw tCbmSFWXsFU6pL6Zc/xShff0aTXyUyp/UuX7IR2SnlD1x1W+V+Xd8NFxTlUuaTefU/oWtJqkXfCJ oQ9QMr5cl/hdCMvKI/gFDZ8VziXuN3eAalS5xO8duMcDirMV1mUsOFvVeFtYI9E3FP9++rqSac4l /MfxyL+GCCSC3l9Tp5LrEljwaPeo/G6Vb6avorcRkQm/m+sSv1ThXl9Rkr1RycRdtAE0o8olohnm r8dcJHCFxkPs8B/Q4EaU+9HiusRvQtqQ36LGXaOeuBk3Yzz/m1WL6xK/EeGxblR5J77ByQW/E76D VHWJtzN/KaWw/xK+yBLoMiNK3hWuS/gmo5F34Hc/fDY7WLvRYvXWdtwbc+92tQvX0iIgZsQtG4/I dQmds0B55gvhU0pVl7gtb1OSz7lElJ8e92r1FNclpIdHaB0avVUhOxf+Ft8SzVW8Oer9Vw31uErR eC4Su87PzkIMxVpqlmpdoUaYqeozlLRPV89fpvIWxF8SlpGfu5TtFiwl16conTBZ6axJinKJ0mIT h8aeCOwlzgfveyP2ldFpVM9PGGpNUCMwR+I+kvMGNU69yseqvE7lY4BxIZ4fo5AcPfQGpvG3NCxz NWqsatU7ofIqlVeqJ+Kw8fgmX1GUvUWb1xBTeVT1icA/5O/b0jKuq7WH1VkJca+mbdBErAX521DW YwElq341QpnKfSpXlljtBn/PyTcKRpQsFaVAUcIbTdNKVO9i4K2jR7FqcV3CY06/oUjRuM7fnPJ8 nSpX1hmeCMcdRpVL+DE2IM0eDeOdC6t4GVq5amVcl5Cz9Mqy1RhWoMYninMJ7DMwtlHl8NYVzTzU 36ww4GfZY0rP3ag0ANclPjyCUHJDysIKUbixS8T+jf/o32vu/LOl/wWn0m4dCmVuZHN0cmVhbQpl bmRvYmoKMjI3IDAgb2JqCjcwODUKZW5kb2JqCjIyOCAwIG9iago8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL0FzY2VudCA3NTQgL0NhcEhlaWdodCA1ODcgL0Rlc2NlbnQgLTI0NiAvRmxhZ3MgMzMK L0ZvbnRCQm94IFstNjU1IC00MDkgNzY0IDEwODldIC9Gb250TmFtZSAvRFNFRElQK0NvdXJpZXIg L0l0YWxpY0FuZ2xlIDAgL1N0ZW1WCjc2IC9NYXhXaWR0aCA4MjMgL1N0ZW1IIDY3IC9YSGVpZ2h0 IDQ1NyAvRm9udEZpbGUyIDIyNiAwIFIgPj4KZW5kb2JqCjIyOSAwIG9iagpbIDYwMCAwIDYwMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDYwMCA2MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwCjAgMCAwIDAgNjAwIDAgMCAwIDAgNjAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA2MDAKMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgMAo2MDAgXQplbmRvYmoKMTAgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvRFNFRElQK0Nv dXJpZXIgL0ZvbnREZXNjcmlwdG9yCjIyOCAwIFIgL1dpZHRocyAyMjkgMCBSIC9GaXJzdENoYXIg MzIgL0xhc3RDaGFyIDExOSAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjIz MCAwIG9iago8PCAvTGVuZ3RoIDIzMSAwIFIgL0xlbmd0aDEgODg2MCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAG9WQt4VEWWPlW38+6kO48OSRqS21wCyA2Eh48EW+iQdBSi2EDAblDo hg4EFIgkvF8tGogNPkBH5hsdxZ1ZZx+j3HTi2FnFZHXiJ7s6g6yvWWcF3367suKsI37rLL1/3Xs7 JpmsH/vpbnWf+uucU3Xq1KlTFbogRkRWipBEnlXrQy2UTldD8gqoaNWWNvn8p5//Bu0PiVJ/tbpl zfrNBfaLRGmPEGXPWHPb9tXFlmeeICo4hT6e5qZQ+IvI+geJHHbwVzZDYF3Cu8FfB35c8/q2bakk JnTchir9to2rQiTjQ4428KnrQ9taUnfkqOB3gZc3hNY3Pbfhy1+Ax3xU3rKxtS3hpjD4X4Mf37Kp qWX8+9cWgv8MizgOGcNHFCulgohcQpKqUjFRystUnqz1PmZlmUVFopl4R68/TbYvbk7obaKLbwvZ 9ynpGCzI8n2MiLH9tJGsiasThxNfUi81U0GiJvHjBFY/QtmX2ENn6DSdpG56kh6md9Hup+eph/6W PkD7JbSepB/RSoz9Of2U2oF/Q4/Tg7QJcoFC0v/nltnEIbILdIGOshqaBxxeHoQV5MMllo8TJSP0 fDcxlnbRLr6Zf0ib8fkJLP6Sjg3quRbtv6RW2kn97BytZM/RaqynA5lyH/cl/jXlJBVK26iQNlqO iUwYUh4iP22nsPRI4gvkiS3NRzZ+PPEFbA0t39VvI+ZOlh46xDJpD+I2jW6Er3OSiqGIGF7AGlZh LfvwOYrd6MJnF+Y9PLhnap3gkn6nk5GtyTxKudzom/gE+btNb/eLeJsZ+x5twQxumkylZEuUIW+u SzQltid+mjiBbBC7/4SZFb3g/poOs6PwYCXdTEv4K+yczm0Ev4TmsTEsmx6F7SuMGZO1eaokgxc5 LkrSP4sZRfNswUujJMQdoxd2hI1CJF6mFymu+/MIHaEoRRCHNuT3UvLB95k42Ea/j/QcFp5/22c5 NSL3UJCDs7Cedw3LRp3yhn72Vxvcn/knzn6/9IIxRkTRKLjikuVV7KRxGjoQm804f6uwsxf00yP2 rx+79jhyLalbMqB9Sd9b0X8WTRdeJGYm9iD2v6GbaCPvYhPZnRjXkZxoEP4S0mQmF9G7bNYg3eDm 98n7XThD/fTQYHM477dQ0xDJMGZ4/IapR2BTzjENcThNv8J8O/ERN/vw0oP87kecdtACqqED2Md3 cT6acYbDiPhpJmN/XsMtNlIJwe4p7MpGabVk7vJI3ZAh4jNCSTlnCNOJWZD5A7mb7GrkbpIbgrNS JHqb5SE/HqC3kRNP0jO4S9YIKbLYKP+7PdpHG2iS+SGPZ+Hc69xXz6yuuurKKy6fMX3a1MopkyvU SZdNnDC+fJwy1iWXlY4Z7SwpLhpV6CjIz8u123KyrVmZGelpqSkWiTOqYEVaUa3fu04rrg1qVqVO scuadf75Gyo1ynO6lFx5RmVgstlLS1E1ym/QCnz+TvJUBbRUdXiX+ZpUbv+DC4NvcMpezVKOrzIv FNYmLvS7FPubzgF9AGa1klq/y+XUeDm+c6HCd15IDmt2H+RQ6JK5Gvn8guKJ96sgpCpXAPVCv1aa ZAPCmrGUQU724ET1DXNzPovaO63FtXUaFXSS9X2NHKLb+SrSyK1NVOGIHS3dGlVqrOAPGsvXmOMG LGnoFGLY2aoRYuANr1O84bWIaDj4bUzPGxF1yVE5utCfO8PpculON2gvL/B3ZmXWKrVNmVgF6QLq zMyCJEsIsC0tncw6i+kNbvXO7OSUno3w5Ql3vYLWaZ6DQTSUOsQNmvxvNfFE36HBKsIwoxOhm95i +pxaaq2WZjghr9U8IY0Oyp0VfdFDcTutDKrWsBIO3ezXpBCc6iSp3NvcqI1u8C2FCE6Ags2y2O46 vRKbJ3ub5Sh40TeIWqnD0KHycHNTUKQJCyp10GXU+g+4+pxaHtCr5apaNoZn7/jQKUW9RWtlwUaj B2Tt2AL/YK1L9EESFE2ukKNeBbPBmHfdHLFjlQPbpmfj3LC+OZ6DIVmLrFyHmOEbOpTMf1fUrlm/ cmF3sD8YKU6HCLCgcHCdWMo6jLQA5OjBJn2ph/SlIV9l77o6QWIgsp8WY/RSv7dZ8SKe5oQICMZL 5cPHulxasSoGRqNe4WIoDO9FZPAtVnU3DAZnwqky+FOreRp1oEZ9DzCjJ1QXMEVmB2gs2AfNE6wL BMSijA3Q0soPpExR5Kgwn1auFah216+h65tc0bDQ760T2YmevNZ/zbki5zm0G3wDYlaEPtHKcyJI QrNIaVhgZEGziI+ogo3GAUbUzJ1HV7O/bvXVIuerGFuv1Aej0XpFro8Go6F4IrJSke1KtNNqjbZ4 g7J+8hnkf3fQqdUfCmj2YDObiU0W+Va/sEHLX7BMbE+93ByCBN/ZiqvK6cqFaaMPbo6R1eY5Q8Yj 78U5i9o/w4qtuJGccr24XuK4FZyavUocU3iy2I9zsApTeMN6hfOxCMad4qRIgXLv2kVmgJwuTKkn jLj3FphSGHG5xBk6GPfQSjBaZIHf4GVa6YyRp1LF3gWFpi+pcSwWmkhSMzA8qGCvihowv54T/1NO 4z4fyOdorpInV4vLHN7hOzes9TVijV9XaemImL7d+bV+yclFF7S4UxKtTBV/EtzaKFUfKGKCWzJq V+RTimZXtZRaf5/THZDtubgg2UAymBZFmtpPKSeZuESpwK4xt8YKxbEiXKoIIy79UVVQDgyUvdGg mX2D14euone4eeAcGavAwRWLRBjsCs6t04hHbp4ilvqKyPbkX4XyenGosDd6xOYFtBzxx07L+Uyv sDhnrV/GNYRju0BvyF65Wey6Jgfr9Psg4BT6pDieOBusE/efH4mGLk4zv5HlCJt5JswwNDT6k62F /t3OHYHJcVpU0RCnDPwlZezeQJwl2uNUN6aHMkhasRzqxgpZ9q6tw4RgFldAMMmF1pIK5KZIfb8S EH9J5oajskj+MJalIxRN0UAl8nWRH/cl4RxqnoBzoNkUCMyEnZuEHQxB92gAFtaZFoC6qPK/0Mlf 0YCbarzPj8s2UodErxNHGMvtw6nqEysWCwkMeAqPd68tMn1eCp8Dk6BfZlhBrkZgIhCNCpuL/ArS PBp1RrEOk48zGi7wmII4iSFYuDfOIj6MBSj6vw+8iksRkQ/UYaqbEffkLRWnW747wssH/MbIFfB2 uR7h4A8U4dClRHjlJUV41YCnQyIchs+rRISbRo6wxsd/R4wHh9RjhNQzQkhXDwnpmu8OafOAo/Bq Ldxr1kO67gcK6a2XEtLbLimk6wc8HRLSDfB5vQjpxpFD+n+RtC1DInz7d0d404DfcLIV3m7SI9z2 A0V486VEeMslRXjrgKdDIrwNPm8VEd7+/xfhHYMiTIRfPXjlwwcvmmlU8Ewqt5Cgyldff1Wvpk11 5bpyy1Ex/Nb7k0eK/CmSQt+QxxLBSP39MJWlvh956bEVNvcfmdP4zdv/i9zrhFrgwAyE+1wwogDT nrvow7to6YUtF2qzxcvj0MKNt09dKJMMFD04bQXdCF8Z2WkqfiFTytnsGfBeaBnl6YjXUcon8tf6 6m6qUa/fvGptOHTtptCGsP5znaMnSqJKvI2OUEx9nG5X47QGdAtokVqTg+nryQ7itJfXEeOzuRvz qXwWd8eY+vmz/BoIrwFTUEYnoLODODvAOmIlZZ44u7vLXlhNNTmsg+wgzu5k7bClsrtM3M/aY1yN PMv2wuwZtsuzmp05Wzhq9OtvoNq5q9Bp21m2s3KntHNX8WunIdqyFdX6FlS3bUR164ZC54oNe2/l t27Yu6mkbXOBY/SadahWr0XV1FzgvK/pWNOpJqmpuf32kuLWwh21xa7tIN4jLZTmYWb7CamefCBO Hqk6lpVT3ZPok6piOWajK8Na7avJkiYTk6ZK0xB1lX/J/wOPtSr/IPY8V+P8913Ph7FW/k7XtJnV AmPKBGEFjYICvfG72IxqszFpitlwKWZjVLHZyMnVG6diuWjwCN8m3KtReRv5QByhvQWtW9DK4teT E3QrSALXAK6BOJ+JNC6kMl4FzANO59NEsPlUEyuBpZBP4dNipWVyHJBXWN3DLrAPYpKaWSOzL4mx z9m/i1F43jPwMxP/zcRP2SciDOxjoAX4ERD9E//APujKgus1YyBgtAX1fqFiD7IjusEHTDzC7ke2 quwwMA14H1BMeC+7H0vu7QXLqAV1RCjYTbEjFjXOFsUOC7gxdlTAlV17JRUJVh3LK6quyWDjWLnu lJ3l6mjxXP0nhO9r39fc83FJSfVPHpbURx62qA8fzVQfgL3DR1LVI7D0I9CPj3L1oaOSeuwoe+zo 8aO9R6XnpOukuWJx0txYO1dFStR22XOry56XcAjorKilK6TLETW5Jk+aQVNBHpAPZJFmSAXCCWm6 iZVSAXpW9oLFmUX2yCDOz8dOpCJ/3o/1posp+HuxURP1FHgvhlyI87OxA5nQn+nqtWCp/K0upVzk 11sxBzYN/U/H4FJNNn+J94t48hd4n45/b+Ih4ftzfAvfKpbCt5pL4bcbS+GbxFL02sODSaPBWGaW bn1FbFSR3lgeG3eZ3liqj6sp4Mv0gaK28XmoC/lcGg/ilMEnUzGIwz01luvQx13WlZ1bjWxTRLad 4GO5LLabu7gcs6gnYU/GHVKKWhyuMkPLvmK/1TfyLHsaV6GLnWFPx8a75Dg7Eyt1VdeUsH9hv9ez 5h0T/9nE35n4NntLN/AWe1Pv9yZ7Hdml9YJl7A32ui78J124tiaLncY6ekTNTpu613QdZjwVwyXQ g/z+rchvtZf9jH4O6gZJibPsiVi+A9vA7mGH9AkPmhgFirReEtuPa4ItjkUkQGNsfwpgYeyAgAWx DgG+WIfQzY+1C7hebFScVcUOCJgW6xXCsYYwx5MF5X9+Y1G/EZ0SfZ7MP4rE/Iqd/YoJNqPTMbra 8xFSXnBTjmfbquGpp9vXHexu6Y5093Wf6j7bfb47o/t4uOzTTyzq3dE0NXowVT0EwpBn7p06vfre ezAlhhfcU6pU33OQqwfb09V9d1jUO8QaEn1dkXk3CPtdkdm1Bl5ebeDEKfq81sgYpTqyh6t79+hW Pdbd3rnVu8HsgSVhWu6A6Q6s8AAE+9tT1TvvylTvAra0R9p5bzuryZQWSY2UI/mkBajnSzeKOiaF y2oWS9dLN5BNckqjpTFklWySXcoFWqVsKQc4AXgZZUsu6BVgKfQycAK5JReoFOQE2UBWcvMn+VP8 OFn54/wv+M+Aj/LH+DFgD/BZyuZd0D8N1KCPAXswpguEh0L+JOhx0KOgO/g+yuF7+F7Uu/huUev+ buY7+E6cFTvP5Xmwm81zuA3IOOcSWdlFlsBfYCtu8lx6GMRFX9z1dnoM1As6A0rBzZ1Ns0F7QRKV sYs4N8UY64RP+bDpABbDj3yQHZQNSgUxcqOvm51gz7NezNfJYqwL+BQ7jl/iVnYS+I+UzV6Evh/Y B/0LwJMY8yKoT4wFdYKeAq1nGxj+m5GF2Eq2CricrWBBnV8dG1VWVjOHrabZoL0giW2HdiestWLU ZmALRm0CboelVlCLsAhaDQqBloMq2GSysfFsAuqJ7DLKYZOYirqIFUOSx/JRFzAHJIX476EclsJS UXMmocYRFrXnr5AqFxM251WOoisdjisceZc7bDMc1umOjGmO1KkOqdJBUxzjJ+RMnGCbpOZUqLax Ss44xVZaliOX2Wz2XGtGZpY1NS3dKllSrIi0lSRPfolCUn5ZqjS6rMw227bXJskSK5NulHqlhGRx sjHZRWkl2Q77qOw8S0H2/U5W4Z7knuge7x7nHuuW3aVup7vI7XDnuW3uDHeqW3KT2zeDaXkN1NA4 R8tnwEVztBlqQ1ySF2rT1QYtw7fMeCOAVOMd+JHcqFk64hyQV7t0mT/OisUTQruzR6xbawi23xPA +/AcjXVoCn4zAzz4/S534PWq0d/J2Ry8k2pX4d1C9AqoY7SweEeKjAlo00Xj/jEBPI3NXKA5lTnq 8NIqBK1tOnyr65w43qtN8oa0Cm+w7luxqhIYOOzVLnpDccaVIcpkx2HGkmJgK4rJxvkub5zvgBm+ Z2QzA+Pi0nxvXLoeXSWf6NrWygZ0IzRa2yBkej1cq0/ethmODNFAgNKKMIihIh46DKp0t1sNBQ1W 04ClpDSJgyYZtGzTphjVqrJavzOg4ilYU5AkyQGmRQEsznaJ5+c4223AHgP2GhAx4A4D9hlwpwF3 GdBuwH4DDhjQYcDdAsyV4V8lV+tS7jbgGgNmGTDbAI8BNQbMMaDWAP2dPM69BldvwLUCEDesrbUz Q2S/b+GcBi0dD73pvmVaiQLmZTBXgrEqc+i/AWm+esQKZW5kc3RyZWFtCmVuZG9iagoyMzEgMCBv YmoKNDc0OAplbmRvYmoKMjMyIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50 IDk2NyAvQ2FwSGVpZ2h0IDczMiAvRGVzY2VudCAtMjExIC9GbGFncyA0Ci9Gb250QkJveCBbLTEw NjcgLTczNyAxNjQxIDExNjJdIC9Gb250TmFtZSAvWENQRFdBK0x1Y2lkYUdyYW5kZSAvSXRhbGlj QW5nbGUKMCAvU3RlbVYgMTAzIC9NYXhXaWR0aCAxNjQwIC9TdGVtSCA3NyAvWEhlaWdodCA1MzYg L0ZvbnRGaWxlMiAyMzAgMCBSID4+CmVuZG9iagoyMzMgMCBvYmoKWyAwIF0KZW5kb2JqCjIzNCAw IG9iago8PCAvTGVuZ3RoIDIzNSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB XZDBbsMgDIbvPIWP3aEi6RkhTZ0q5bB2WtYHIOBESAsghxzy9jMs7aQh+cD/+zM/lufurQs+g/yg aHvMMPrgCJe4kkUYcPJBtCdw3ub9VjU7myQkw/22ZJy7MEZQSgDIT0aWTBscXl0c8KVoN3JIPkxw uJ/7qvRrSt84Y8jQCK3B4cjj3k26mhlBVvTYOfZ93o5M/XV8bQmBEzHR/kay0eGSjEUyYUKhmkar y0ULDO6ftQPDuHeeWq1KNXxq/8MpaPniM5JdiThN3UMNWgL4gM9VpZjKg7V+AG2acBAKZW5kc3Ry ZWFtCmVuZG9iagoyMzUgMCBvYmoKMjIzCmVuZG9iagoxOSAwIG9iago8PCAvVHlwZSAvRm9udCAv U3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9YQ1BEV0ErTHVjaWRhR3JhbmRlIC9Gb250RGVz Y3JpcHRvcgoyMzIgMCBSIC9XaWR0aHMgMjMzIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAz MyAvVG9Vbmljb2RlIDIzNCAwIFIgPj4KZW5kb2JqCjIzNiAwIG9iago8PCAvTGVuZ3RoIDIzNyAw IFIgL0xlbmd0aDEgNjg1MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdWH98VNWV P+feNz/yewgQJoz4ZpgkE2YSEgKBADGZ/JgUGIFAAsygNhMgSCo/UhNRrB9Brb9GlLS6XaVVcJWu hW15mVGcgEKs1lKrxV90bbWWtrLrb+kPsBXI7Pe9FxB23f1j5+V7z7nnnnvuueeed9+9ISaibNpC koIr13X2kJ1mQfIy4Fy5sc/d3nX1avDvEVm11T1Xr/vHs2//gcj2AJFl29VrN63+/PQN24hyiqCz Zk1X56q/b1l7H+pbUZ+uC3JPy1Oov4B60Zp1fTfYZ+oD5ryPwr52w8pOmoaHck6gbl3XeUOPZYV8 G/W/o+5e37muq7RkrUKU60Q90LOhty89kf4d9WbUS3qu7eo5veaYH/W1mMQyyBiP/ssmKwAbusSy n1wGfkgupYRcROnj5zB8Tfq43ja8Nn1c/CcMXGLCsEJ0I/2afeykk5xPe3kCvURP0lvsp5voFV5F BTSOzogicrMF4zmpnXbTS2yjKCXTH9ATtIw+Vpi+Q8e4jJbSy5yLKC+hh2kBj03voY9YpI/Bwixq pX4eY9loeYtvJQtLcXu6gnLQ8zYaQ3X0A3qDb8p4Kn2UZtCzyuXpP9OD7BR+yqUe+g86Af/KRY24 Kr2OOmkzPcdW2WS5P11G6+mMvCP9GDyxURvG7aCb6Z8xah0Pib2WVXQJ1dMcmkdX0Tr6If1YrLac QLQEldBa+P5zep9/zG/L9+U/FLvydWWrpXi4HmNOpKlUg5l10Arqpa30IB1EiFVezA9Zqs7egpi4 YWEKdLbQrXQ3JdGay6N4LC/lh8XN4oj4VPmR5a30EWhNo43w6TZ6jn5GH9Ff2MqTuZJv5UF+TbDY JL6Q7jSln6FS+hotpivperqF+ukhStAziOZzYr5sktdLTflIOT38AtZ7OXz6FiXpF3QU65bPl4gS 8bH0yNvlY/JleRIzGa3cBt1jmEUlfLwcTxvm34t1vpPuo0dpD+2j/fDnVXqN3qbj8LqGr+Gb+BE+ wKf4C+ERE0Wt2CD+SWhiv/ijLJCLZLv8pvye3C5flG8oo5RGJaw8rOxTfmstt75v6xzeNfyn9IJ0 JH1L+rvpA+mfpt9If0oZlAMPvFRG3Yj1NzGvzYjkT+ggnsPI79/Qb+kdOo6sI85mF1fzPG7jJbyW r+X7eBs/wA/yz/hXIlOMEmPFQtEqrhZ3iMPiiJwpZ8uUUqpUKSFluXKN0qfcYanCM9+y1fKEZbdl j+WE5Yw137rbTvaXz/rPvju8Znjj8O/Smenc9KXpynR3+iRZ6FKsXiddjZh8HzF5HNnxbzREL2BX eI3ehHfv0O/oXfo9PPwrneExXMBOPC4uQ24t4G/wDXwLVvFB/j4/xvs4xc/w8/wKv8qv8ev8Fv+B /8gf8qd8QkhRKFThFQHRIdaIzXjuEPeLh8R28RLy5Ih4VfxavC8+kQ45UVbIGjy1skE2yrjcI19V xirjEO2FynXKjYj4D5Uh5TnlNeVPFrI4LKMtRZYyS9hyj2XI8nNjzrlWp7XEut56m/Xb1l3WlE2x Fdim22613W37vu1R25v2MXavfaf9AGZRyoU8fuT9NwhH+EXaKy/nKN/J7ZzDcY7SGBGgR5VvinnK D8Q24Rd7dFXrTEXTqfwR3SdZ5Cn98jv8AD3FTLPp21xH1/N3sdIvcg+yq4y2y0NyWLQwtgV+nGvo lDyCfekoojWNp/DXaJ44rPzK8vMr7xRF4uv8G+Xr1gzlRbpfHFBiSrXCiO0mbHd3yXtpOn0qe+V7 eCvWKf14I29ihS4Ts+lvoL9GDjm4WEymep4rC7lVrubxmKfe9yh2iW4xIOrpBX5AXCNL+VtcRSdp mJKW5+khy2LlaHqB8lTaDcmN+sxoN+xgjrxVxpRJ6WXDn/Od0imekyXiMv6L0im6h3/CC3maOC6n cK/o49Oc5FJk0Etivmjg8eJx5P5J+hg5dIb+TAnlfnlv+l25Z3iReIaKLFfS69jRrLRI7Oe/0hvY Tw8iK+zYc3+sTKen5Ho6IWMiJc7y5+JzeoR+gl14r/Dx2yJIn1g7lGN8fEMuXypXY08TtAu78gr5 KTWk/0Aq96WPpA+xC+/LfuxLf7Y8LzbQd7FfHMSOcjP2sU5k81rK5k14A3LxJJH7f8H+MA7LY8Ee uh7v6Xbsl/uxXxzFrvE+2t+hU3h3H6K3BVOr9Qfw/AT9FPP7gu00SFX4ZuTiXXovfUp5HbF7ku6W TM/bRlvrlDvoWcshWx3tTs/Avr6eJtH3aB//VnmCDgYb24P1dZfVzp41s2bG9OppU6umVFZMLi8L +CeV+kqKi7wTPW710gmXuMYXOscVjB0zOn+UIy83JzsrM8Nus1oUCWfKQt6WmFsriWlKiXfOnHK9 7u2EoPMCQUxzQ9RysY7m1vt1oukizSA0V/83zaCpGTyvyQ53LdWWl7lDXrf2SrPXneLliyLg7232 Rt3aJwY/3+CVEqOSg4rHgx7ukHNNs1vjmDuktWxcEw/FmsvLeCArs8nb1JVZXkYDmVlgs8Bp47w9 Azyujg1GjAvNGhBkz8EctfHe5pBW6EVXmJHFoc5VWuuiSKjZ5fFEy8s0blrpXaGRt1HLCxgq1GQM o1mbNJsxjLtbw3ToHvdA2VB8a8pBK2KB7FXeVZ1XRjTZCRshbVQA4zZr4258z/llFcbzmyJ3Xtjq kvGQs9utK8fjd7q1oUWRC/q6PLqFaBQ20FcUt8TiLRh6K5aKnRVwTndfn4o5qS5vSJfEvuHWMryN 3jXxb8SwIOPjGi3e5EmMHx8cxFlifMgdb494PVq9yxvtbL5kYAzFF29KFgbdhRe3lJcNOEaZ0RzI zRthsnMuZLoQabPN4Ax1nQsvPh9O1j3yztWCyKOVbngS8WIiNXrRVUPxlTWIOn5RRi9tFZahW8to isUds3Q5QsmapdjhdcdPEpbd+8nHF0s6RyTWYsdJ0hv15DifYBp3nuO1QEDz+/W8sDVhIeFjnVGv Li/bmBJLvT0ONwjCR60RdIvOqkDMPR59Ve9JBWkFKtqWRRGz7qYVrgQFKwJRTcT0Fqya2TJ2id6y 5VzL+e4xL9L3SePcOVazl5z/y3MUjA6tmaVxwf/R3GW2h9u84UXLI+5QPDaSquH2i2pmux5QxA1t IxybHRFwTSnWrMVzvci4xcsjugB/luIWb6g7NgdvGHzURjdFpEvo7wE44ZKGKaTtlcvP2dMrkWzd llJs1WeI90cibQ0Bu1s0R2yOWUYzPZ6Rl+p/9knZ7Bd0SqVP6L0M8mW3kSlrswIjkzKnqM2+qH6R d9lxGW7HpiTC7cvj8cyL2lqw3cXjLV53SzwW70ylt6zwuh3e+CBOiE3xnhA2KnP1U+n997i0lq1R TGUNz0KOC2oc8PJdiwaCfFfb8sigA7eGu9ojCZxAm2KN0Wg5EfZT3Hfw4Etgo9onBT9ttaXEyaCT LMrTkjJtytNMhXar5WkhtYxD7zoDjlO1Z2sXOP5WO/9sLdWDd5xBMaXSM8ozqhgFk0Jn3HLoTNBC p8mtDGEEI4cwyMF5Zwc68mpP2gvtupR+9q+j5pyjF3iSYejrDRDa6oYXUFPW1NN3fLE460PywM8L f8IKJTHTEBk3LqOvwPdN4CxvQemgCtwRSPlMdMA1YVjNHxnBSoVEreH20LKGQMO13Z1ryxs3rF01 t69zbffK+e2ID04tfwN8+t3sK366NUk00F55QC6CzaBcmJg5NZiSC5OOsVWgrcnsfJ3OT1ZMNWii Tm+enwzNNautRjWx3CRdU7fojS6X2Sd/jEmzcqryGsbK+bQZ+AyQVI9yIbANSAMK5aHU24W8PMkT 1dizMox6GHMIyrnJpqaqzYfkXNoB/B6QhrTScGpusrpaH2husmKKSX0+k04sxsDZUK8HNgNHAL27 xeieMbqqosEj56FpHsbZhvIQcAT4PfAZYIFf86gCWAjEgB2AKdV1dO/mJSfN0seblzQnPC+Z5ahq bXDIOTA8Bx3mwF29ZJidA7NzjG5zkhmOqvzB9JB4JxFsqDKZmbUG826ytqHqzYZC8S46VYp3KAi0 AjHgVeAYcAJANqHsB3YCGkwpM/obJopfol+/OKyvqcEHDb7S4CsN3m3w7hGdXcRiF259/TgH7gSE eDxY3HHMeswmDlkP2cRe616b2GHdYRMLrQttIs+aNyLLa7hKNiJAjQhQI2bZaCxlIyLeSB3AXmAI SANWqhDTaTMgKA+lCuiSemAhsA3YARwC7Dg+Tof7eSgrAF2nA9gMpAErOUQ1atWGrWroVCMw1Yi0 LmOjtR7cQl0m5+FplI1iBp7peKpFNeL+csIzzQj3L88xL51jfnGOOawzqfRQct34WoN+ML5a78NX JMDoDTeN0I0jNDZCJ5s04Z82FWoJ/1STVJlkikkqTVJhEr9JJpmk1CQek4wzSYFJxppkjElGmyTf JDkmyTZJlk6S/hFnfKYzPtMZn+mMz3TGZzrjM53xmc74TGd8pjM+0xmf6YzPdMZnOuMznfGZzvhM Z3ymMz7TGZ/pjG8kQh6dYhWKqtWU+KVJXjLJL0xyOJiFxnVFteoHuhJfEVRBbwI2AjFgMuAHfIAH SMn6xH2TQOqSbq/a0ZAhL6MNwGZgG6DImUm3R1WxH9UgbWuQqDVI3Rqk7Q6Ue4FDgDzfJmT1Ptjd Vl+L8Qv3wZXP9WE4aXjIe0yy1CRLTOIKLoDOF8CHwOvA9cB6YBlwOdAEXAZUAzOY8o/xCRb5PbyF +1niVprBODnTuHHYoPNH2YMHRAG4DHF3ons0xn4qUXo1ZsBPUin+G6XiJtdhUI26DbqHfFwM+W7Q paD/kvA/gm47Ev4qkIcTfgSIuxKlE0BWJUrdICsTpZUgnYnSBpArEr5H1IYMXkY+uz7AUvLzdtAl Cf/daG43SVvC34Saalq4NFF6v9qQhX/GdePSrbKLfAYtJFzCE+oXvpTCCfUfvpTYs0/93L9Q/dCf svM+9QP/JvVoaUpwME99c/Ir6uueV9TnSyvUn3ZDM5ilDnW/oh6E+kCRYWC7P8VLIX7IX6N+x49k mAwx6tej60b/HrUHpjDcBtXQXu9J8Xa0rvPdr3b5b1FjPtT3qR1+v7pscoqLE+piDAO/Lkdt6T41 jMHnjgz8NX9AbcbgTbqfCbWh1LAYhAUOutTLPO+ps+HDjMkH1Gr/bHXK5PdUrz+kTuyGoafVJTkZ ORkz+lPsDU639f/O1n+trX+JrX+arb/C1h+w9ZfY+ott/Zfa+ifYxtjz7Q57rj3bnmm32612xY6L tX1MKn0sWKafIcZYcfRhsuL/rTidGLwDX279X4J6iVOQXeD6m6+NlmERbmvUagLhlC29WJsRCGv2 1isiA8z3RXWpNrSSwivc2qk2b4ozFy3XLN5G1vLDFG5vdGrirhRTewRZrne43YVzXGSQmAtvv9c1 QqPRpsh+7NEFxL1RKthY76zPrxs1s6X5K4qYIYw1B778Ob9kA4Fw66ZBpMkTSZs63YZqG6r9erVf rzonaN8Lt0W03ROiWpXOpCdEw9rdbe4rI4PCKQpCzYNinE6ikUElKZyhxbpcSTZHo2EssaFHbsib B6lIJ9DLtZNb1yN3rt3QE3tMPRV3VeiV6gR6zl2kGnqqc5ehp7CuN9DtDjUP4EKs63iJug2dbi9d oDPIHVQErSIUutZO7tC1uMO7U9fSAoYhnw8qk1FABf/Y9hmGfHyJoVL9pYpnRKXjvEqHobL1SxW/ qSLxqptW5G6oXBjn/y/f1RjqbmvkcGtkwE6NUVxADFrg6KkzMiOnsG6Xaz+9Lj+iLNzKMnF5z/Li w1+PQ3YtV1yFDonNzFdFDe4znbNma1ao2QA9t2Z7nDe79ivETxgWsiHOGWkqbyhv0JuQ87rxXIjz RpqcN8/2uPbzEyNNDohHYdyvmmZvb1+g98KGr9S6UOF/58kZ6m42/3ROB8xfZ6Cvt0//9Yaa8ddH Yc3fFtZqcHEcsNlCuIY3RyGbfE4mpSEbyMgA7WyO9o78An3X9WF8xC04JYhTQxBHhqC/CpgCVAIV U4P4gAfx9Q7i0x3EdzuIj3YQX+ydDZnGeW6ncZ7bYfA7xOHgVA76/eg5CVqg+JoH/fmggL8UFPB7 gAk4QfuMwjP1oiDpvl0YlCgFMGtIMOXrRoJ7XYB7z4nP6/YF6L8AeQc8XgplbmRzdHJlYW0KZW5k b2JqCjIzNyAwIG9iago0NjEyCmVuZG9iagoyMzggMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlw dG9yIC9Bc2NlbnQgOTA1IC9DYXBIZWlnaHQgNzIyIC9EZXNjZW50IC0yMTIgL0ZsYWdzIDk2Ci9G b250QkJveCBbLTU2MCAtMzc2IDE0ODkgMTAwMV0gL0ZvbnROYW1lIC9QS1RFV0ErQXJpYWwtQm9s ZEl0YWxpY01UIC9JdGFsaWNBbmdsZQotMTIgL1N0ZW1WIDAgL0xlYWRpbmcgMzMgL01heFdpZHRo IDE0MDAgL1hIZWlnaHQgNTI1IC9Gb250RmlsZTIgMjM2IDAgUiA+PgplbmRvYmoKMjM5IDAgb2Jq ClsgMjc4IF0KZW5kb2JqCjQ3IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlw ZSAvQmFzZUZvbnQgL1BLVEVXQStBcmlhbC1Cb2xkSXRhbGljTVQgL0ZvbnREZXNjcmlwdG9yCjIz OCAwIFIgL1dpZHRocyAyMzkgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDMyIC9FbmNvZGlu ZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKMjQwIDAgb2JqCjw8IC9MZW5ndGggMjQxIDAg UiAvTGVuZ3RoMSA3MDMyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYVZDVxU15U/ 5943H3yMDIiAEJgZR0UdiARFiY4wwAyiREUBnTEkDCiKqVQMahuTCElqPgaNJmnTNNrGX7P9yIfx ATYdNFsxNW3dxpomqWmb7GqzyaattabdmO6uMm//781opO2vfZfzfe6595573n3vDcRElEp9JMm3 pqutm6z0CDSvA3LWbNvifH5cRyb4D4gsu9Z1r++qebXpPJG1m8i0cf3Gu9a9+8bsCJHtPSKR2tnR tvYv3o1dRGm/RZ85nVAkvyTuI7I7IU/u7NryxaSn6X8g+yFbN25a08ZmKod8C2RzV9sXu5UMy0zI TZCdn2/r6th5zHMR8hbIhd2berbE7iLY7PshT+2+s6P7lQN7HJBPECUPQMdo+pVKZgDRJl2jfESk PE55oAWynQqItLMJeD+2AzbYY6OaJt5BD31kHeJXE/ivANB4SZzSWnqbuugx+ip0s/hn9Bz5KA22 t0lisCB56Qn6Av2CmrU/QeuiZ+kiFdHN1KnFKJ16Kcb30rMsSKBXOb1FHbRXeKVHOY+5zuAS+QLf T8WI0kRPUjadRsQZWjLkIZEvvOjVRD+VrdYirUT7M48oJ7V2+iZ7xRnlJezaBZ6kUOwBrV/bp+2n cfSJzB/9oXaT1oVezRSmrXQPZtBH36BTHBILxDHtEcwpiDn00vfpp+xRSAlTBq2A95foKRqmH9Bp +iV9yMxpPI37+C1+20SjJ2IntEVau7aJArSUGqgP1nyewlVitVwtD8p3Rv8zdk4rQOwm2kZfpLtp D+2lF+gd+hW9y1IkiybRLA9SHi2g1dSObD6BOT1HJ+ksW3k2z2MfP8gvim2KHD2B2lRoAjJYh2hr 4bsPOf0WHaIT9Ab9HDH/hJxKnsgebuYWvpd38qP8Zf4Wv8gv8XlhEr+UUt6n/Eg5HzujJWtPa89h 3Dy6gZw0HTtTTrdgP0/R77G+GVzElfym8IgiyUrqaCw2S1uo9Wqvae+Qmwrhu4D8WPMSWoVZ30UP 0FH6Efqeop/Rf9FfkCXJyZyBXDjZzSu4kbdiFgf5Io+KLOxfudgoBsXb0iNPKauUl0YPxybEBmMX Y5r2gqZqP9ReN/Z3DsapwQ7cRt3UY+zY9zDOa7gLf0eXMIaZHZhrHddjvU8h/lm+gnKyih3iRaHJ BXKvPKlMVJ6KLY11xZ6KDWmztSWoLUkmmkiz0eahmpophNj3I5vP0vPYmSFUzxn6I+dwAZfwIl7J QQ5zJ2/ibt7Md/M9yOpzfJiP8hl+l/8oFGEWE5Anj1gj7hdPiMPihDgjPpAkG2VQbpZ3yyfkYfmG /K1iV4qUEmWJElbuUrabyCTNWdbXr2Rf6RptH3169IexG2P+2Odi/bHjsTOx97UU7Zj2Ie7eEswx ROsxx3tRmw/So/QM6uN5zPE39BGdx57/GbmQnMS5mLHD2LcazHsJZr6KQ7wOrZPvQP77+AUe5Fd4 hI/zSf4pv8nv8UXBmP2NaPNxFzSLdVjD0+IFoYpfoV0S/yunyiJZKmfJChnGah6SD2M9X5XvyQ8V oUxQblIalV7lxyZpWmt60rTPdML0E9PvzXbzrajQeLt6goDK18VxpUJupAPUIKT8vXhTePlecZm/ I/L5OEbLlw2yQdSI+ST4KKq8izIt+8wus0tkkt0S1kOJr4liuUqZKlNpC+43EqvFgyJM3+ZX6LKo Q6Vtk6fEAdEq9ymPKxX8DvViTBI2/pSqqIorsHdv0WbsULE8pPxMj2iyyiumLmHTHlI+Mgn5Js7B BSzkv/FqvsANIgvZmi8eJTdkO18AXYQ78Feo/GFeReXKOblLLBbvQreRnuDjWONR2iiO8jexL+W4 H+/kBt4vb6IdvBkZuZnuEF+mSaJbTEI9N9N/8/08AXfuZezNZLGOFGkTa+htEcKuv8EZ4kbegTrt on6OUBGP8gi9Lh6jOdwhf3Bl4ug0wVcu8ICsowG+rJxUTgoFkY4jmyU4PXyokGdxRjTjznTJqaia cjKJItT/bTgBb6F0cYnvERtpAz8lf8ffElW0jDpkj6jlJ2OXlCo5Cxk7gtOkxnyzlUxeU74yGzv+ EVWgGtfjMdWpnDXdr/PyLfmJFtJcsVbTuNh7tB3ZqcPp1o97qY5+zVl8Oy9XNFGvaNpKekEcUt7T sjmVXfRzDXdY7Hvs5cmakzdrKbwcFX67+bnRryn9yk5lq3IPnk+XcWo+SI/T0/Qqnib/gudWIfJ4 C7LZgrNnA54RJVRKZVhdBVXjVFoEWwOtxHkaxim5jj5Pm3Hyfp1epAE8oeqRj9vRbx3dAX0PnlB3 0w7c/w/RLpwBT9K36efiefGMdImHxWtim9hAv6Zfyx9LH6+kt5VHlF5qpMm0nMdj5LnYJQf67dLe wmjTKQ+n/2zcpah87bx2Rvvu6GnE+zbm/ri5ms6ba2gaLeNPlVw2+aqafJUVC7zz591cPrds9qzS m0pm3lhc5JkxfVrh1CmT3ZNcTkdB/g15uRNzsrMmZI7PSLenjbOlpiQnWS1mkyIFU1HAXRt2qlPD qjLVXVdXrMvuNijarlOEVSdUtWN9VKferw2mMZ4+eK77K09f3NN3zZPtTi95i4ucAbdTPeV3O6O8 enkQ/G6/O+RULxj8EoPfa/A28C4XOjgDOZ1+p8phZ0Ct3dYZCYT9xUU8kJJc467pSC4uooHkFLAp 4NRsd/cAZ1ewwYjswLwBQVYblqjmuv0BdaIbXRFGTgm0rVUblgcD/jyXK1RcpHLNGne7Su5qNc1j uFCNMYxqrlEtxjDODSpWQ/3OgaKRyK6ondrDntS17rVtLUFVtiFGQE33YFy/mr39g5zPRATPqAk+ dL01T0YCORucunMk8pBTPbA8eF3fPJceIRRCDPQVU2rDkVoMvQs7Vd/oxGhiZyio8k4M6dRXoq8q vr4Od0DXhO9wqknuandn5I4wtiY3otKKu1yDubm+Ye0c5Qackaag26VW5rlDbf4bBjIpsuKuoYk+ 58SxluKiAXt6PLED49ISTKrteqYDSY/bDM5w17n6Fdcyy/qM3ItUHypqjRMzCbqxpnIddZRTZE05 NgBXiNFLXYsd2aAm1YQj9nm6Hktk1TTF7nZGLhEqwH3hD2M1bQmNeYr9EulGvU6ulZrKbVd51eNR Z8zQS8RSgz3FHCsMuay4aFtUbHB3250gSB81ILdtoXkzkX6XS9/g/qiP2iGofcuDcdlJ7XmD5Jvp CakirFtGrlomNOuWvquWa93DblTyYbxEEE1QrVOv/aXZs8YHOuepnPUPzB1xe32ju3756qAzEAkn qra+aYwUt+sJRd5gS3Dq+JqgzBPQ6ZzIk4YVRdmy+poLhGCqqkzBn9ko6rVRixVVaWjYWavaw3Vx HEp2uRL3zD/rFNU+1nsZ5LNuiWWo8zyJicanrc4fI4+ZXmpE1jfhyBH1TasjkeQxtlocZpFIrdtZ GwlH2qJaX7vbaXdHhvECMjXSHcAxFN/RqHakP0+t3RXCUjp5HupWUPWAmx9ePuDjhxtXB4ftRM6H m4KDeLWpCVeHQsV4l8TzSllvwisIWah2wGyJcuphHKEmRWckJZtNYF6WUuQmWXTdy0wTrcvuzvEs tX/iXTLqXWr/1LvEPuqlSu+oV4ebSmalu9KnuNJd6xW64pQjV3wmukxOZQSlIegx7azilX2UQtlc 5yvPyFKyMrOz5Ek+mfIL8a7p3y2/SDF/zrIhXXSIDmWDdUPyHbaN6R3j12VbJ7hkmitJpiRZUl0U 1UaG0iZWGnRctkF9tgllKrEdD70wlhMVD/lyMlxmH9zMPvhsMh8znzafM39sNpmj/P5QzoyDOVEu 2umxf3obezwXRm/b7NEpVVbaL9gv3FRC9WpKY706GSV5lLK0TyhT++SwPXNcZvYR7X0ar70/ZCtI LyhPXCG6jTffRptRZ76UrEx7XmWmjtKj2qe+8WkFlSmZQNZkIIuOoP+DLz8jpdKSmZIBI1BWZnp2 RaaOxmemZeoeJ3wZYJKTU+3oCSRkmsPLHvKMvUKcSe5JVDabZpWSZfZU9yTzhMysWaVzFG/swqsn Yn/kjBOv8vjm3xw48Bsd+NBI7GNOPzbC6bGPj3/jP85+ff+5s8ati0L4UuM3w61p3kvWJCs2jOi1 76TXXaPrsXt6tRAlGf46h1tefy/B++J4zaK9qVy+ZtGt+iWUU7Qe8Bj4cnzPG33wJjsJ9fAAvjkE 2Wkm3j5IPmNahS85YXhkJOKY8WVHdY21C2uWemo2bb1zQ8edSzu+0NC4BB/huieumBtvFn/v0u0r iI7gtWNEjgw2z/JFQeYZZGjc5NI+iEMpNoMOJs2qrJopR6gbcAhwGqBQK3BvQiPJAa4SoGv3ABQ6 II+SChgBvAHQNUegOQLNEWiOQFMpo8Ty+/LlwckOzODw0MTJpRercuUQaQAhH5P9+BnAIW9P0NYE 3QM6A/q9Cbpb9g/Od6RVJUFmugisAQTWtn9w4bLSYYOZ6zWYfVc1+4agcVRNlPsxq/2Y1X7Maj9m dRGYEX0f9Pug3wf9PkO/j9gI5ZqeCJVg9g+mZSU0YKqSZUiuxBumA99zcbpKrhwsdRyrCstmhD5k 4AOyCfweA7caeJmBew1rr8FvMvhNBl9p8JUJXu870+Dj2GHwaTqWK2Qj3i0dcrlcbNAGGaApkJdB 1ulSucigS+RCg94CfQ709TKAXzAccrGsNeRFkP2Q6yDrdKGsHfQ7Sqq6IbfCht9hpK73YyZ+bKYf SdI1ewAHAGcNTStwL+A0QBqeLP1oNWhVsgo9fIjhg8VHUvrQKtEqZAUsC7CaBcA+6cV6HcAzAZWA ZYBWwAjgDYBFeoGdsoxKAD5AAyAMMCFOEfoVYV74lsHXaTFNRiyX2EWZoM4EdYh+fCk4ZIHoHyxw +KqSxGF8dR6mMKAb0CcOD5oy0qoy4af7zgQsA7QCegHPAA4BrFQJDIsvRVSKSrlMLJMKqnv6kNdb atBZc+L0hvw4Tc0tTau6U05HmqbTMwCJKU/HlKdjqVclBziB0imkY4DTgLMAPeGFSEYhklGIBRai f6HhZTb8LkLSAJI2AfcCrvfRU1OIJRdirM+i6Npp0ExDzGnoMw3xpiGNZ4HZ6KHbGwB7AMcAum0S bHsMXAm8DCAQYxJWoHNpwA45aVAkpUWRX56XVjUXeV8GgFHsRjZ3I2+79QpB9lDbsFQmPPaAHgKY 5DDadLRCtGlok9BcaE40B1oBdm8v2h60R9F2o+1C68duZB7yHPOI1rJNZb1le8qeKTtUdqzMclS0 oYVF2JdMWVk4FTPSrblVdnwWt5CN/8/ABw18p4F9Bs725bbYPmix/aTF9rUW21dabMEW29IWW22L bWaLLcrtvmyP7V2Pba/HttJjm+OxlXlsszy26R5bVTp+YFlFNvqBgasNXGrgSQbO51WDNkp6hW8l lxUVz4WHXfc5PnRFFR50POCKWkHuj0u3xsl8Xfmyo8S13lEU10yNk8muf1UQgZr5RbKwx1dkOWlp tfgsN1tutBRbplkKLW6Lw5JpzbDareOsqdZkq9VqtipWYSVrZlQ75/Poz6NMM96OmMyKjhWDt+Pp wdg2HeNpZRW0mNTxsl7UN1ZzvTqyhurbneqnje4oJy9frZrc1axm1FN9U3WOOtdTH7VoK9RyT72a 1HBrcID50RAkVTwcZWoKRlnTVTvz9E+nYWK8h+zOS9BQSO8THFB49+4QZW2rzKnMqEi/udb/d1DY UIb9170Q5FzHe/SZ5KtP1jcG1efzQ2qpzmj5oXrkWf/SGsbvjXMC/mExVyeh4HBynygPrND1yX1+ TOSqHzmh9w+TSyeGHzl1P3L+lV+BmKv7TdFJ3K/A8CsY4zewwBXwD7iA4j4LDJ8FY33Wj/VZb/is T/hIY/5GiKtxLOfIZfi4LOeMuV/vUxAf6x/6TPm7Ptels6P6OuFvWB6mxXxmoGZ7AJ+pYXegAxBW +7d15qh97U7nMNXwGd3kVOXUcPuaTp22dUT5jLvDr9a4/c6BxUbXsXZ1u25e7PYP0PZAU3Bgu6/D P7jYtzjgbvOHhha2zTg4ZrhHrg43MKPtbwdT2/RgM/SxFhr9/mqsg7p5oT7WQX2sg/pYC30LjbGM qkdZWqk6hJdcgw6JlGQUcDjPFarOsndXGNU835WzI++IQvxdSsEHZCp+crAB9EIvriqu0k24y3TT OP3XiIQpZ8d8V94R/m7CZIc63V1NOYENfvz19CSYuPhPcU9Pz5bbe24H6dli/PVs2Qqq7xl+2urZ QlhBVarxfHPgNNbP5n7ALuOMlj09oS3xl+yeraSPvkVH1wb9jNuK4NxzfSWQPuSYC1b9ld0AhOvZ io8MBAcT78c9+LeEB2HQdUtChzPn/wGnT+WZCmVuZHN0cmVhbQplbmRvYmoKMjQxIDAgb2JqCjQ3 NjgKZW5kb2JqCjI0MiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA4MzMg L0NhcEhlaWdodCA1NzggL0Rlc2NlbnQgLTMwMCAvRmxhZ3MgMzMKL0ZvbnRCQm94IFstMTIyIC02 ODAgNjIyIDEwMjFdIC9Gb250TmFtZSAvSFNGR0NOK0NvdXJpZXJOZXdQU01UIC9JdGFsaWNBbmds ZQowIC9TdGVtViAwIC9NYXhXaWR0aCA2MzQgL1hIZWlnaHQgNDMxIC9Gb250RmlsZTIgMjQwIDAg UiA+PgplbmRvYmoKMjQzIDAgb2JqClsgNjAwIF0KZW5kb2JqCjU2IDAgb2JqCjw8IC9UeXBlIC9G b250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0hTRkdDTitDb3VyaWVyTmV3UFNNVCAv Rm9udERlc2NyaXB0b3IKMjQyIDAgUiAvV2lkdGhzIDI0MyAwIFIgL0ZpcnN0Q2hhciAxMTEgL0xh c3RDaGFyIDExMSAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjI0NCAwIG9i ago8PCAvTGVuZ3RoIDI0NSAwIFIgL0xlbmd0aDEgMjY1NjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngB5XwHfFvV9f+972lYW7KsbWtYlmRbtiTvEY8Xr3gmnsFO4sTOIiFApgkJBAJl NRD2KJuyaRiKMlBIChRSWgppKaSU0kKhTVugpIRVSojl/7nvSLYDtKXj9///P5+f7KPvu/fdd8c5 d5xz7n0ilBCiIlsJTyJLzhhdw/1cEoSYA0AXLTlrg9v/YXgBIVQgRPrJ8jWnnvHd9xoeJkReSojC eOrpm5YnQoKUEH0rIUL/imWjSz+8ZtUmQrpvg+fLV0CE5hbZhxA+DOGcFWdsOPtPG4zfgfDfIPzO 6auXjL6pOHQHIT1vQfisM0bPXqP+JfciIb2DEHafOXrGsrNafp8G4bMh7FuzbtkawzN/ux/CdxFi yoY4Cn/soyYywtJ4SAW0xEy8JAfuSIiPZBMn3E0nGcROLMRFsoiW+Ikb0ltJHskkJhIkNmIkEVJO ikg+0ZFiIiclwJMAKSUGUkbSiJ5wxEEKiRJyl5JKoiFVREFyobQC4AXUP3GdWAv8uoBcQG4jO8ge 8gT5AfkJeYV8TJVkhFxMniK/J++Rj8gXUG05NdFMmjftuf/wMvEt6RlEwz8NLbMQMnF84t3EQxPv gty002Kug5BF4p+KmUifOPrluMR1iXjipzIV0YvP6rkXILdj9OjEca4entRPlLMwdym7Fks6Jr8j 8VjizpMasIasI2Mgk01kMzmHbCHnkfPJt8gl5FJyGfk28OJ8uL6cXEG2kyvJVeRqcg25llxHric3 kBvJTeQ75GZyC7kV+Hg7uYPcmbzHwnfA343iXXbnbnI/eYg8DHgPuZfcRx4gD0L4e8D9h8mjEIcx GH4EYu4i34XY+yEdS/UweYQ8Bn9RspPEyC6yG2SG4VQoTp4me8njJE72gTT3w7j4PnkS5Pg0SPYZ MY7FpMJ/PyWmf5YcJD8kz5EfkR+T56FnvEBeJIfIT8nPyL9z54eTubAcXiI/Jy9DXztMfkFeJb8k vyK/Jm+S35K3yO+g173/lfuvQYrXIc0byVRvQ6o/kHch5VHICfPBNL+BPN4m74g5HIa83yJHaBr5 lHLkCzIBV0x6N4oSulmUI5PeLSC3e0U+M3k8BmEmIeQ6k80jwPNHQL5MMuz6lqQ0HoW0O4GvKU4z Ln+VNz9Nygr5fQDSMF4wfiI3XwIOo8xYPk9OcvwFkU8xUaLPTMpiSgqMh4x/vyQp7vxmGg//QP4o coZx9zWRd7+Zxj3G5SPAQSYFlsfJvP0dPIvSYc8ynjOepp5h916H8LswO7wPnGb4Z1ESfyZ/mrz+ U/L+UfIX8gH5VPw+Rj6E+eRj8gmE/woxxyD0AXyfHPvlmM/IZ+Rv5HNyHCR4goxPC02/ZnfGSQJk TCilHOVJYupqKpbdoRIqpTKY09KogiqpmmqoluqoHmJOvqOavGP4yp2pp6buKcR80qmRZsB8aaFW aqcOmDezqJO6qIdm06l7tsk7brjjpTnUl3zOLD5pm3zWRd0Qg7mwtHk0QjfCd5CGaBiui2gpLaMV tApiCiFcDOFquBcRsUFoWbRweMH8eUODA/19vT3dc2Z3dXa0t7XOamluamyYKdTX1dbMqK6qrCgv C4cKC3L9vhxvtsuaYdDrNCqlIk0uk0p4jpKCZm/LiDvqH4lK/N7W1kIW9o5CxOi0iJGoG6JaTk4T dbPnRuHWSSkFSLn8SykFTClMpqR6dw2pKSxwN3vd0UNNXneczusZhOvtTd4hd/SoeN0lXkv8YkAD AY8HnnA3W1c0uaN0xN0cbTlrxbbmkabCArpTpWz0Ni5TFhaQnUoVXKrgKprrXbOT5tZR8YLLba7e yZE0DSs2yvuaR5dGu3sGm5scHs+QGEcaxbyissaoXMzLvTIKdSaXu3cWPL3tirieLB4Jqpd6l44u GIzyo/DQNr5527ZLo4ZgNM/bFM3bfMQKDFwWLfA2NUeDXqhYR+9kATQq9em97m2fEqi89+j7UOtp MaPJGJlP/ylhN1kTJ9kUpaOpawJ1gxpC+zweVpfL4wJZDIHo1p5BDLvJYkeMCOHgUJQbYXeeTt0x DbA7W1N3Jh8f8QJnm73NI8n/s1ZYo1sXuwsLQLLivy8q8cF9d5T3jyxesoLh6LJt3iZoIfCS9A9G hSa4EEaTzGzeGQlD+tERaMRKxoaewWjYuyaa4W1AbkMEZOJrXtk3KD6Csc3RjMYoGVmSfCoaboZn oYs0b2OCYRVkeXl7BveRkom3dpa6HbtKQEEaYvWImhtBKP7mbYNLl0ddI46l0D+XuwcdnqgwBOwb 8g4uG2JS8uqjeW9BcfABAYpPQdu+lDqVGJodlfvS3IOcgx9i0oIIdwt8eRtq4IY+KsMgk2hDjXuQ OkgqGZSSTMGuTsoHAryvsRUeBoRHG1sdHujc4ucfVMmBDYBqRNMm6ySBSkin6oTl/N2qYWpWoTx3 87KmaRU8KVMIiBVM5vb19eQYL5LMgCqkMXG2sjYUFnBw7YbbaVEO2ilGMSla3VHS7R70LvMOeaEP Cd2DTDiM16J8O/q8HT3zBkVpJ3tJ/0khvF+J96LE09E/mApwjdAHW4KiXJlYxfAsMTwZbP3S7bbU bfe2NG9H3zZWuDeZIXHDCALhyPxto5dXppfCYG2BidLbMup1690t20bjE1sXb9spCNvWNI+sqIZh sM3btnSbt2+wBmQpjvstjs2s6HTSQTv6GwoLYO5p2Omll/XsFOhlffMG94He6r6sfzDGUa5xpGFo Zw7cG9znBitGjOVYLItkSdwswHLqhUCamN6xTyBkq3hXIkaI4SVxSsQ4TARxlCyJcxinT6XjIE6C cYIYNwQfGGHWFSACmIeb3UuZeM4dWrFtZIgNLmIGUcI/jVJvHYly3rqdlJOpo0rvsoaoytvA4utZ fD3Gy1i83NsQpWYKzInDnLRtxAvzFHS5QeKgQ9A79Kz3cz53fGKif9BzyHF0yANDYgHQvMGoIgjr gNTXDulmMRqB6FnRrUtGWT3IAAx1NjLblgzBWEhlCEnaogrIQZHMAVK0iM+w7ggPLQHZgADF57dC ILp1KDoUZIUOrmQ1crv1UdLqrQaxY55SPysoPLQt3VvMOjYkjSp9lzJQQN1I3yDGOCAIhcGEy1ok V0PNl3jh1pIRN0hAQpb0QVfHuVTJ5AYxy2BKlPiXiaR0JG8S1izep9Ioo4oQZAj/7FoVggzhXz4E TGGNF0OXJhNA2fqoCmrkn8bK5APAHbjVxuoC/5dC5VnSH7BseuKk13s2TI2s0mJRcrgd1fjaRmHy x+dVEOOtTD0MeaX5WBTL4yDGylnL1cB33tcfn3jAu4nNAKlPYYGXLQ6sYxLHPujYZGjblyOi84OF BWlfjtWI0du2pWm+/gHkV5pmEiEXMDPBCl7P/xosRh7s5yrSRWaT/gNEQ28Hc7SavrC7qSmtUP4k BDnipi+AVU3p7YJRwmkcjnpvmewKvsfQVi+/gusn9eNvvvEcfB1KrwofouE3jr56VD/+nKEqfPTw 0aIINXgMImVoOblcJvNmh7iygL+8pKS4jisr9XuztZwYV1peUceXFDs5HlJiTB3HwpT/9Yk5fPN4 DrfJM6OvSEqDPovLmJbGu5waX4lb19HlLc+1SyVpMl6aJg+UN3gHNrZn/1RpDWRmBaxKwKxMwPFn pNrjH0m1X5wiafriAPdO1WBdjmyTRsVJFWm35zpNOUWZtR0anUaqdVjsmfI0g1aZ3zo6frPdZ1Eq LT57po/l5RufARyxTByXPCvNAG+Fn7wNw7hxANbZnIl3dqt0tNMbn3hHcLIrn1rjtWqImWrNfpXS m60kbomXGrx+X5zmC05BRdQ0nVerA1k5Xq9TqQFHSLZVnp7Vmz4gHSDW+vr6dEtVpaHEAJwFHbbE 3nW0mNrCC4ft1kPFJVsuPXiQWg8uHMbLoggJBqHrTK/GHlaL/6S0okgwOOQzm1FuAd4j1/LebL+/ vIKisCxyL++R7FTLzJVFJVVOteSUhL1XoskqC4ZKM2RqepVM760rmdESMMieoY/T1Ytz8k1SXqHX UMm41qiSyCz5Xsm5BpOK51Vm43Pjr0P/58HLQCTl0Ded4O2pJHemOOzirttjV5lMKhLnbosV+Evi 3KaYyh6IU35XUZE8BxgvSiAnTn2CQt9TamXtL43TvJgg7weGAgOD9UeDwM6jVTR8tDh8FLppehV0 U8fOfzObosgQzdBKvJ5sf5mhtLzEAz3WxPq6k6elIc7rNbCObpy6lJT7G4fXnD878aCnsNBDmzfe t7bGGmoMVgw35yYetkbaai++rqqp0NzorJ7XetuTFR0VLnpR85q5dbnGQIFkRUEgt+fc/nBfU6le WTznNPrbQF2eORF1hOvHPy+cFbEnrrYUNhJYyuZM/FmilnphbF+O/ItlkuCT3I/AoWalo+AM8ye5 5Y/TkZixTwKGxeNlEZFlkThdHBMUc0WWjQcPH61nX8CxwweBVQf+3QyAV74MLU4Bpenl5TC6ZYxX bLSzecCU4YQRj6NeouZlSnP9/LGmi1+9sXvwjjcuLl860ORQyniJUqvQhdqWtXRtGigIn3JOV8vy trBGqU6THLR5bemWHI+5955P7r6PkkfnpWf5HemZ/kxnvl3tDXrrx+5fse6B08s8ue40K3Ocwlhm fe1p6Gvp4G1ci5x6ihi5W+GmnbuWKIg1ySdrnIYEhbbHIbLIEaf9MUE6rVcx9rCetO8bP4F9hzup 70in9ZSnhx/9/OHEC2I/6Xzkw/vmJo4FF92w6eJvn379kiLultj4XR3YJXrufO+eBXdsmHni6sq1 D4LsoU38FdAmMOywRax3c9cKOoXRbXRDm+xWDYwM+xM0j3WDvRra5ffLbKnxYxNbqukJiC2F4RWK CbJpLYXxEzwapGEYOlXhsP5oMbR6738jS+wgJzNE7CAeQ2pcefESmqfUKcbPYrzhLlFolVIpdItE Mb1UoWPXOkViE32ZXZ8Ki4AK2aS0BZywFKgSB1UWWBz8FmXiOpU1wPoB8GziOL0B5nQTyU/NN4S7 fo+g1PfiZEzDMH1AS3elIlK1ZSuaoRS7rYneoHEWB/wlTo3GVewPFDs1OUq9UiaDL8lzqSuxPJBR P5RnJx2p8kzc9bAmKHS9JpHxpjgdns54Gj7Eyhf+boJUhXAuSlZI5ByUpNQpxx/zFGqcJWKt6E0Q IT3TmedQA3NuStXsiw9UNublFvkhWwt9qIb8CusnqDSRiCUcVoasVnucW7o7p0itVsLF4ySnvMem Vln300JQXEITx3brvVxnUXzimOBmVxY9+9bgtyUcKQrJXLk9roHJZY6tc0H4sAWuuLiehg8fLTaU QMeCta+qNlxSYiiBhu/575aS4pYoPi9lC1uIC1CvIaV/sOmcKSAWWsJWO3Zpkq1VZUV8OZFMNZf4 tiTdFcnOjrjS+cSNnMoZhvgsVXnhw6GGiFtNrRKarXHlVfp2OgK2ab0g64sjGoOSl6r0KknmF79P cV5yQUm5zluVf2Kcp/nVOTotPJWUgyQuTSe1ZA/KYW9ApwzpdBlxrjTmDBUD7CbOyt48xu50nZ/r zMsNZav17EqtkunidMvjAaUtu8c2EILrqQ4F2kVVFSyAVUHQL6qCyHXgeRiYztgd+y/kmeIxstbv D3jNZtNXGWx08pYSP1tAk51WEtc7fMY13pJgri3xZGa1hZNIVI5QjjdkV1bkbveX5uUYT5iDuf50 yvPqzFBOdsimXGDJsaq0vvpibrh8y4zWqzrH5yv1KplMBUPv8nBY4ywLJALBvr7u3JbvNHOLlHq1 VKrWK2EN6J54V2qT+mBfKTC1BmRwz8BAcMK3ktiSawDMjAtg/PV5xQHqFQeoFJdJUbOYWgO+6RPA IdAfTlJ4xSVg2nIotXXf8e7NN719YwfgLde9fVNX4n1319aR0Qu7Pe7OraMMuRu/m9g5POfu4ztu /yK6cPbdn+1d/sDGmW2b75l/2kNn17eeex80BdY60Ft5GNOZsJe2FXvTzhzZfu462DnL4n4gKIjB J7YMFNTgLplMzXTZpFJLg7sFU49a1EuZHsWUKFgDDh9Nzv//2oOpZp882mCSl0xfAPmmC7+/9fTk hKouyqVFob4NG/sLEkcjLV15a86qHyjP5C8+48H1NYklk+PoinBYbqlbdP7ipsF8VaItu3Zgsu1d 0PZy0kRux7bv1ocMecr93HOQoIK7NZZXb4hz18UyQ/pUs/WgSe4SBEttKqIWlMm9gqfHktLQJ1kh KpSHQQVgowmGz85/L5fUiGFzER/iQX9M9Q7ULs0WJ5/ULy0Ws5mW+gN+f1LLlHSlOauL84uz1JIN ptwiIb83xTpQNOeUNDhmbzkl5BEW1mSVFOYaz9ApE49UN2SUFJ51SWV/ZWa2SqeEUWZQU09RZ4k9 YZzk6E0FAQmvKj9lY9fMVf11Rm1uVVtowu/llwqD6VJZ4hpHURNwENaM+ol3YWH2kTayHzm8j8zk btqTU5xTrHYwnZ2oQ2yRqCBKWrjXUAF/5poUa2vitFBQz3RI8/rMYic0x+kgqFiTw4tNV0GYr5jK oQdt9PBRiAmH2Zp4gIT+S9mmOmZ2SFKWnI3QUg3JkuEvq6wy/orOCx9d0rh+cIZdJQGVQ1vSvbot 0lmWGelavGJxV6R57M6h0ILuugy5lOPlGpUq0rKgIigETeE5S1csnR2hFy2/5dRSsyvbXhRy5dtV nlyPJb/OX1BfFIzUDmzoGd4+HNJanRlai9eelWtXZ3ocJl9pVhDvrwe+qyeO8+9B384mA8lRTWRx 7vpdVoMsPcXe9Didv1vImjaCi2n44Pgh1lX/YaoURzxTPdHD1kzGHaaVQclM3TrANAum9yQOKFEd U/JXMwVMcndWnk39xdHJ7mRU2/KynPk2lcqWj/3miol3JY+ALhQkp2D9DxA3dzXcM3PXCWqlv1ff O6l1L5jeJWDRQqVbUP2DRKkWiCt9aokxJI2NaYvOIy2X/fjCzc9cMkvtAhUOVDf/rCW1dYubfGrW tCKnmv5u44ELm2rP3XcuPzk6xiVda9t9/rZVTbwq1UQ2FoITx+UZ0KYacj62SVCElWpSE4moYc3u EpQ1aotV4/N61dlx7gYhXbCqK3rzeyNeFf8lD0B9PRj91sMw06RX2cJVVelVVj3r+zbQv3GuEXR/ 91E2nyRVG97Lp5QcsOCZ9cVZjCXGpCGfvAJbXy79rcyU31BS1ZybLv0Zd1CaHmisqIaALPG6grNV lYQrMpX87+n7Eo2rvDBS5dJKPuF+zyszS8MFRWZe0WjN0kmluiwrX3riRUuWXryWrMzJM0t5lcl4 wsO/ZrRqpBKNNeNELv8bvUUjlZqDPlifZsH8cRb/SzjPIdA85FpMYSmNc/N3k0CAVMe5ZkFv4C30 Ywu1xNWl9EQpLY1PPC0o1Bow9EtDM/Pj1Co43sqm/Jbs7dmckN2dPZLN67Jd2Zxakp0tyYpPvCVo 1WD8ZFn1tCvreKidze3gLaBdtUcEdZeEWMMpPwFb48DvMjy8aJjN6uHg8Nqjw2uhyx2sYlYPm+UF 3f/j2jD5ZjD3DKhPZUn3GuviJWXMkJx0rtVJRPVVjma2uaS4vII/KyOYX5hnqNg+d9bGUyK1m3Zv PMUQmBmpX9JZolcZVDJlZsvC1TNW3jBS8NlI7dxy26z6sqGQS6uXy/XaWTMafG2nt85e35FTnl+f n5GZnam1+y2unCyv05g3cMmC19NzSjyVQjkcPeLIeTC+iXQNnNepJTcm5ar0lO/nRtiBHu4iUDxM yvIyj0QaSU1X4ILoEDT+dkeLvrNKXA6q4rQdxn5Xyo9Tzzw5Flh2RRWECWPvv5vHtAkikHJITM0L BhwhKbVMbjAD/+o4CSldfNX8wtmzmnNgInO68mxKNdgGvkiWOrupqTV3ybZTchNfGPIbS2yRknJn 2WhZUVNhBn1/45OXtBr81Xmj4nqr1Kmk3pSamjCCNaGdc8musarTeou02eW5ideaZhV3L4f5pHXi Pd7DvwonnJLaC/hzAk9yG0R/jgucFynHH3i/XDFju+QJ2kqKYGyoVLSrqEBkYUGctoBfB1kILp3g pGPnILPhmWPnP8tJ7I0pD4+oy8NqKTp8vNlw5Zx070BTpHJrdfspoVPvPL2i8ex7F+d2NZaZFVI+ Q2/wl7YWL15hL+kqKe2o9GsUarkkavdadRaPXS9s2b3hkme31sGCaNZZvbbqMHS9m65tPbPd5/K7 lA5YUTjSAfPIi3C+yg/erxuS/U3lqNrPLYQ1JcytE5RGT4uqKuCQaPNTHQ5mjjZBYW2fdBq27Ra0 XdJO5odlSh72NlxwcOgr/t08kEuo808fs8Vmy6QFxINWN80GqOBfVFrznO5cm6r5pgXLtw/lliy+ dlHH5hpmjvrAHD1evqS8aFbQlJ7XVGovKil3ozoH3WtJey/0qCWs29XOoGBvokk0XtrUWtS7rKzy tL5iXXZFLuNbO/BtL8y/QVJKpci3XUajpyDONcaCpZI445yHLzAWcI6CZyVs4rWA64hI9BKus1sy IuHukkQlYKplhoGru3S0i6HghjThI/5261+JVq/lDLxWYVXTLoUVEig+FzJT3TF4GCbbo8BnNu8O r104HDy6cBhm2+I3YLELs8lW8X+3bHFakHk90/otzA5J/6XYuzlToFyUk5zfm5cz/rZjxvDMhqVt EZ1CncZzkjRN9bwNDRt3nT2j7qyHTltz5/LIJ/z8RZFZYRtHj4cKqoZnZhstRnm6x2Z2mXVaq8VQ s/mJLRufurilYeyuhe7TNuXU9oVh7NvgLN93pGeDLrE+KRWznoBCvWhXJN+njNOsXeWz7P5UTwaH rmuvEGl1d8JBT7aLwLpvcT1ozAdLxg+WMBfuPlDAv9lD06ZGsT+axHUExvQ0wwQWH1EbhDVH5IqE +44kTSmTG2zZFkfArr6HqYEZxnvUmcU5OUVZqjVGoxSiVud0bewJtORqFRLJR1leo1yeJjf4ZgR7 lZbcrIrweIh5qJjfins5XJGVa1F2zP/2/BBs0dgCsEfgSFzH382/Qupg52oR5ZAvwhxdRM5XettL 2p9t513ttP3t58ETo6bq5/uos49a+2jfh4fgaJKJEpPexOlMppFK/vOa1nx3QcOBBth3pg2HKtt1 86men/+i4J6Diw30y/qjw8PpVfWiHsBUAggOvyoCrEGsbw5ML1nVTv954VNl1zS82MBJGqjuH5YP xaZqcFIFhsUagBsBhALuFdFe9AdkMN+aLUlrMbWfVgFaAmy0sW8mKbPFU8xMyEmtgO1U+AMBLZiY 4hrH323WrzQbS0e/3R+cbVIbS0K/6tzYE6ze8NjYuu+eGjZ4Iq5guDzoza9YfFlvfpeHOgymxPe7 23yVvvTuWf5Kn3FGa/0uu8soW7aganYkgx+JhKy1ntmb+oImrSbHnOXj0uD8xMKahrG5xTnCUJmn pqLYYpkTnjEa8C5um33OQKFSUZD4vLXbFqxyNc2x5leMzy2McFKj1+3UF5da/GGma58H9s/LoF8U kzOwH+wjKm5RrDgfnGQju8DUmG7QdwkKobA9p8XWiZM7jo/0pP0Ooox9s/TTZ3GDqGxBj58y1pPz gwEVbRP/sjqzKMdXlKk25lT5I4vLUrpCCmde2jZ/S1d2dqrT0/GZ7WVZLY3jj6VipusJQn3NisuX sDl7Ffitt0tngyLlIc3Y+qfAbnqKHZYG/UpJXPScPYJN34atfRUmg5TRtO9r7p3cqmQjjGwNZz0H ugzdnKpxCo11/QMzagf6aybrzm+GdQccbzoljXRWV7Z1zqgS/QNMTvtBTqVkcaqmRVDHbKKGb9j9 5PbuKiw0g0/5cUErEHO2SprbltlimBQUWDug7omGUBg2mYuPsIGn+rpk05oRoF8jleT2JSgnckrN Zn6/Kqs4N6/Eky5P/DLVrhTStLQMT5HfV+JS63SJL2hIrfKAxSuVsG3MVxO5X5XPiQ/pEnW6OHmp dNnGxGuJwows7Kd0M7TfRNjhD9g1FnQaEwUFTaWkGkJVEtjYHGFbDi0orOSWg2iDDMPGQzJ6WuOm tNSvymVSHFMdB+sgU8Aa3012YB12thjZSuJ0FgPjF8W66wJMLy+Gg+Po+gMfWFeso3367moXiGdm e11LYWVbYefUOALxpFQl6GJV4ApjG63icvMfZXZye5lZc9JI+0pEsteakjYuqu8mmUKdGfH5wUVv 8Jb5CheUg3xzmLZuyC7PCS2YHJBKe57LnW9Rtl/XXTHYXGzI7eroCAxt7nBP8pMzFH5paH41hj83 1S1O7e62BGt8wbqAsebUbV2T8xXIoJhckJRBvpEx3SlOW8QJ09WxXaC2i9MWM1aZDAQVTFv5tpy2 SYbDasCW9qQXNsXof+XJf8LZkxn59+ewSZbd3PdP5rCT2ALsGIV5gQPb5l2JBPjxJf/7GNx0cmMn +9/t4H9vn/S/Z063CJk/OrUHO83//g+fAA78M/+7RFKzOX7OxuiGytrNj59zdnR9ZWLcVNxXX9lf 7jAX9ddV9Zfb6bvrDlzW3nBe/Kx137+0feZ58QsaVveG8uasngVYmDd7tdjO8xI3SAi0c7od7CkH DzTawRf/Izu4TT/nP7aD/1ke05gR+Oqkafp7djCYIgsDM2tr3KkZU2nLcznBHg50zO4LL2Z28HFD XmOxDewSZ9lIaVFzgYke3fjUJa06V8iVWJAySSRvpsbMytzavIyuS2Ibq1b2FumYHfx6Y1txz3Jm 2yVu4F9M8jBl27lUQWbb5ZMSZqGYfG2q2qBLog+lNGLY+ALbzt5eKVrBlRDaLei7pEy7S01YoEOd ZNv9u3lMY2GZAd1tSa2Ys6QuTF817tjUBHORKod5DhjHSpdeO+JramorUNly3c48q/IrBl7i6RTf 6IOeItFtIBp5OlChR1OMBP8BWnmrepNWXnL+4fYDD0sInPpm69BOvw5WHkFN7DqlSxlW8hpeyUw4 mIPAvOgTlEKw3a8zudtMoj2cmuhhYQKjIjnFK/95+mnMYSrn16hL2Mdk3H6wnZRpGTZnuim/EJSm pGMlNdF46yorMzVOt1UllXB8Rw5sCzLjIaemYPxwqulTU83q4pl+HS9XKNUm5nCmpG3iXe4jaH8b eRfbz/YpQpP7FE0CaCSSEA0dqYCFWfknQ4XAJuMKdwXHi3sWuhoK2xbHBAc7X1RzhO1ZtJv1zAcJ h730EvNHk24q4FBQ3GcNDos7F4uGg/qjw/B/0vaF4P4fLm2K8d94V4P7qGrFlX3F81sjZrUkTa1Q BYWB8uyyQIavtqunq9ZXvPDS/vw5QoExTcLzcnWawl/VEckuduv9dXN65tT5qbNzw+yAzmI1FRZk eU1ym9OutefanUF3ZnaBMK9eWNWZr0436XQml8WRnSE3WU1auzfDle/O9BQIQ6KcLBPvc1dKdpJq ch3K6XGDQTMjj3gLmaZi0RSmBnghmLy7vK1ZmlSEhjnBLK1FcToLzn4lfYbgWjgERMMl48UHi5lH V9RNCpOKzr+UCXAUzjJJRMPK8GUDmDNNN5NFS4qZzdyVqnQvOM87zmzNXmXMYKbtaaostAqeYd02 w/hsaEaG22aQy1Qy6eaCsBHUaP+cs3vp82gB/wiGvBRODih/hDZyYritTa6Qy005Ir82Mb8X/xzo FauS41oFyhxzerm4RYLOWNgWUEltbbBNDv0W/IRdX3JxsXEtLqGiRav9JsmRDyf7siadWLjHUl4x GQFeLFgaPDCdtd/cu2BLl0dsPuhg6T4wikYrUt6sSVULlKeaFd9ezk1GJNJaRN2L60mNcxjPZrAr dkG7C1L7XzG9xxXnLtormDxumccb54YFtUDcntw2j8repkpOYmxfxW59Q7Qn7Po37OBmgg7x+JcS JceOfPKESHLvS9w+sVQk90/4XZSXShKfSA2BxvKyRr9BmvgEbAtVZpEvj23IviCT/ZjXZIb9vrBd yd8p1RrM2hO/MpjUEqnapOcDGW6tDFokkSoM6vG1Nht3ldoAJoZSx+Yr78Rx6SvQvmZyU3IcZGal hwoK9PngmRNUWfpKrV7CV1fra+JcUNAIvH5mW0mbPqLStVbHJ17aBVgAKGjZRbWet/jaLJ0KkQvJ ozcn7zGJ+0qpTSa24cTsLB3L82uerq8XOSSTp3aX+MDUZcrTwLaaJnk17VL6iiztL1K9p7aoqM6r l9zIcdskupy6ouJaCL2vkEL/8OUWZ6r4nRx3P6+xh32+kEPFx3jue5y4ZoYdSv4ulds5xUvOqVCM /26Ks1keFVhrEomSMVatZoxlbIbjUKerkiHYtRXHjxv60Xbgc5hcgXw+QLK5bfDqcQ6XLyhCVvgj FpU6zo0KOrBPoUeYVe4w8XpVYDrtYXFuVV6bV2XIaps0WsUxNdXP2Kad3ap/AxYG1t/gLm5nMw5/ 7bNsgJnxgEiAT7K4wggaRGoHT+yAbNuO5y9Oo5nVkcIKl05y330SbVZpfkGplSo+O6Kg9qqigjKn VnrnHbzaXhgoKLNQ1Zul0AnhNK5GSWsTzyo1CjgbYjbAMd3b0m1aGS/TKBOv0vw0OFkp0doyEqtE HplB/9oNPMohK5BHe6lCoSV2cEc27BVy7G6l3Rrn1gMztHZXm01pbFN2SOaQDtETCUvhtM3M5JiD eZjtQgvqr00O7ffwuLFVYYQTRNRfmmo57F0yJ5Y5Q85963RFd1duxMrJN2pM0sQhjRW264oztfKX +adlxoKKYJUjLXHQZpbrrQYalNm0fKnXZ0rj1TbL+A5u1G5ISzP7xPNWWyY+pvfTXHijXBFT8J2k HuoGO2xT/o/7Z/b3CzMH+oSrh4X6wYVCPbAFxugMehVXyQ3DG+mGGJGr9lEPvLsQBl8LPM9cc+xQ XvJ8MFdptiZGbGazjd6lNqil9LPqULiqMqS0ghee5bWJX0qXSjeCnyB9H3hx8neppPpZUBOYm1lm qd7gR/tMTjuVZq/d4TUr4D1JTWah21OQqab8lbBOSNnBQ/qUuGzAF+jPkDf3uph3HnEdgNxl0FQP J9ubJ3X4Z7Fi6g/ByQA4xT9VVBmf2jX/UuFmE/eswpQNZWeAT98B7xwWOJSJ0xUZUJ1sUxpUh0XO LOKvTG2NJ+sCVUvMPDnOZIK2c6Qf1rCXpDngI2olR7CH7YONiacf13FdpJ0G6+Pcjt3qzEx12RPc BfA+O2znsjvANThNr+PVMOGh36I6Tut2RSJS8IuLJvF0/3i9oDAONYnLYFOcCmBELkJPL9vmSR1t giF6GPYgoHuKR5yGg449UAEd/98qAfgLRaTMT6aYsU3ak46XyL9kciV3IviXajZ8b/W8SxbX+bS6 4OxzHjvb39UQ0qXB+ZI0rVLtL2+L9KxpcVNzVePsgsVXDOUnEum5DeHM8tKIyRqeFQ41h6w0uviB Tc15XWduu3t+5/13XXMGnG1O1+iNmRmuPItSo1fXnHpZpzYzQ1O+9Mo1JV1lDiVMCquu6vdm1/Wx M/q1opx8cGKugsyizpSk2iae3svk0UYj+7nV8DsOudxqQenUeZ0Z8KesfILbIQpNiULT8aQhzl24 W1lWK52uzRkFhW2oWRRQc5yaThYQTJpMS2G6NUgHJlD4YkeCiiIgI6FN0UgVDVQxk6YJVCmhsllU 1kJlzVTWRGUVVFZOZWVUVkplJVQRoopCqiigiiBV5FOZh/JuqoK66/h/sT4oS8J2Bk76UDGUkrF4 aKYixE8agjCUUy8K4P6opbycvSuQ8sCX8y/VboyuP/P+NZWemaP1Jb3Vzooz7j191c2Lw67K3tLa kQZv4s2MYH2wv9dU0BJpm+O0lXWXhVpClmVLF4/S+YPbFhUVDGzpqRjta/NkzuxaUD77/OHiUP/Y rPBQ96wsd2vfQq7WWxnI6Gpyl0dC9uDi8b2+2vJiu624otY7u7efzUccqQJZvyqejwySH6UkXZiU dCHNeIK7AYR6WJgSqns/RCmJA21CR2pMslPzMF774LAg7Zo8MTgA4k2d8hIH4KR0UaLpBITkpgol 5TIoR0A6LENmnP7LGUOfgQ9ke5JImHIO2/ugzU++hCDhXy1eu+dbFz+6PK9k7Z4LL35seW7iM6XJ VVCZPaOrMN0cbi8N1BQ6jXLuiluPRxfO3/HZbbfAyUvAhxZsX9EKc8i6763dtmdV0FbcufQ8mJ2u h0ETlVpIKHWOV9Ao8qgil6YFKLwWDwcf4BgLDAohAq/u58Fp/V1Oq8oQn3hzD0QajHB8a4ug8Pbm 6fQUVgM4nzl1khcaVVw/DqtD8BDs8MF6A1YmGWZdzyFY83JpHpQzrShWwjfJj/XpYcxneJhZO+xg flL5LQETRYbKXYUv6WCFN13gNFhUptIqxsvTtGDBwNWHL1myDDIuTaumZqnOGnD5w9a0VxRw6mFp ZoC9WSW+paXi29erpIZ8v9Vl1qbtlkh5Cjal4otX2PF8SuD3ZfgD0P/qaDr2PkErKaASGLTVVFFF VQIwT5x1BGqOc3/ZW+KDP1L1BPcXopp4D7ulCrqNCjb5V+41VFa53VVf14VWCpoSsyzUp5/0tA1N cRm2UGGegeVBfGeoClZ2cQI6hBoc66ls+APXHfCe3PTawWEmHf/fLHlqsoHSThZMBbxE96WTPzIm FvHIqFw8rndACuvuuNXszlDI9LaMtxp7QwZTXl3+jPnNIY1CkyaFF29sjYvPEpbdtLTI2rlt3U00 AbqzbFVWnl2VZinwesI+r+lYy/pF3TmeGQU2p8+lzgxnW1wWg9XntZbM39Jav3n7jrW3wjE/kN0A zB17QXaDdCbK7vG0WVTZQlXzUkKbR4vi3POCZnaff7bgnz3bL/BaxxMc/BgOrORsmdDCaEchws9U 8Nrm/XQumUEUdOFewwz4M5cnZwOG4mnl8jgdiLX1wXEXiWBwu6Vt7EQp7Zo8Vjr3pAkHFvijsH4w wU6eLWWiheMx4BUMh8PgKcDFhQnYIWiSDSDzoDb/85WZknZqzpKJO3FO8TCNKOzU9m7ypUq2IYI6 Iiw0U+I3OXl+b/tF8TMaNgxVpyvkvF6vLOpcPrOif0aWt3nlrDWadDgRDweA11bPq3Wbg02h0gVt JWqm/3MyRUbdwnNaF16zpMRZfUpV0+kdufSc0RuXlxkznfoMRx745xwuhz3cmFfYWpIpNwdcWb6M NEfxrKBnRtDm8rnlGX6nzWPWG/05toK+TZ0zlndXavm0su5lsL7kgN11BM5K5sPs+HFyhGfIQ1Qe pLJMKocfJtFSmYaqxElSxbpEBFgf8ujj3Km7AxIJKXyCU4AX4CNBAzfNjtDkm0tzd0uglcE4XbZb 8PQqU6fXQeQl48GDoOcGjx6Ca3jtBGZNkHlyAXcI5QEdDYRoIEj9mTSgpwEt9Wvo19RJrMo3LxGl mSxGVA5gCItb95MHz8pSs2zqJUsTzKxm+IkUD3/ElL5e7Yz42SmKhEFr1snhQLGSXiu1BhvCJa3B jPV6S2Ill9hBT6EbSsreS/lI3pPbwgF32J9t5H6o0Cgk7OWTE58WcReNP8I05xEYo1E4P1xH3kmO UWk5lZadNLFWxDn1ntzi3GJt1hPcQVGHEyVBxDEJyrZvV3a2dPoQXBor6FHAm4SPG62iIgcv0E0N PPGtQnyLQJxI2WBjw09U4nCcGfPLaX4FTVZFnEX/k2KmxhGbNZOGDAwlNKKSh7zZ3iIz9aZe5QTL LbmHz0fbLt6/rub0uRUG0LQlcMRHmdc40li9qCHHKSxvq16Un2WDc6bLFOCjM2UkSr3N/pX3rK6m 966EVzx1Fosu3ea3s1eRLZkWa1l3ZaSj1K7OCnDFuV61PeisKU/8WcIVLdoOKtfERMoOAvMsBBGU 9Ih751o46HdHSkbpVGqgKk9qHvVQGA8vwGsbJsN+7ifwkAmMI1FGJhgtJikoEzg9GsThYO9RpYZD EAYC6/3iQatpEtBKsQjigQz+4fNTzBU5m3KWVVDR7AUWi0vPfgk4ihNzZUbwI5fVZXFp9Cfjb5lM 7KAAT9OtWrnkzqygz2M84dPoFbxcZzHwH1XUOIOZarm1AHiStDmAJ3DsA+aNBui3T8HaEiEN5DXk yj7SlLQVm2gWrCvX7CJaLWGnfqeU0xnw3vDjPkHslEKc5u5yu+XTOy74evL7JvssKFrylHYK1iFb Ldg+40HGsOmmYRPwCBSRY4ISlpqpzAUFy10Pcd+4CCwjiDxl/GRu5pMc9xXTTvqm3pmZ1F3L+af0 hXO27NocHGgpMivBv6NQF9R3F/VvaM3mQhf2n3r1vLzqdd9bM+/S0Zk+ONBgjbRGwvDGsTGvIVx9 KvfMnIfuvvYMQZ2eYcrN8eSa5dp0bc3yS9qzguXLr10wes/GhvzZqy+7o3jV1XNzPDW9RWU9ZXYv iAP6KJMJOVJ6wUeLdDWfEhv8FCB8fviAoXUKE+vhVPzZkFbB0oofeE5+B3vzW3nOCV1iVPGemFPy pgjVEi1k/zN4U/dX8Ht455LtkhoyR6oi2/k/ke1cNuBisl2WINulzUArSbekAdJcAPE/JvX8X4la WkWukAskyH9MZkk6yHn8EGkF7JDISTt3GbHxLxAHi6efkVWwL8TwPNmF5DwWJ+kS07LrDu41eLaI tMErQxYIb+KfJ2bpX4mXf4S4+Z/AsRsv2cKtB1/Qm3DvQrIJ6t0PVAtUBXQ90CDQAFAO0AgQu98D xNI0QGvhF/PobHqMu4j7C38Z/zScrTwsvUR6XHa2PF/+x7SWtKiiXVmufE11plqpflUzol2uPaKr 1j2hO6F/0tBieCJ9QXrCeF5Gb8Z7puWmV83bYK65wvKg5aeWE9ZOm9tutscdczNLs1qcMudLztdc 81yL3bgnRmCX5RH4XYiH4fcgOKKHETYCHpVMOhPcWEyyFN6QZkjgdwSNhHQOdbf0DQUbR09fuXjd ysKG1acvhVs7FXyc+zzmzALv+99iziDAZzFnAcBfET5F+ATvfYyhjxA+RDiG8AHCXzDlUYT3MfLP CO8hvIvwDsKfEP6I8AeEIzGnAirxewz9DuHtWFY6RL4Vg2k7zv02lhUGeBPhDYTfIPwak7yOoV8h vIbwS4RXEX6BcBjhFYSXEX6O8BLCzxB+ipU4hPAiwgsIP8Fin8eUP0b4EcJzCD9EOIjwLMIzCD9A eBrhKczzSYTvY+QBhP0ITyDsQ4gjPI6wF2EPwm6EXQgxhJ2xzGLgYBThsVhmCYQeRXgE4WGEHQjf i2UWQZKHEB7E5x5AuB/hPoR7Ee5BuBsf/y7CXQh3ItyBcDvCbZj1rQi34OM3I3wH4SaEGxFuwOeu R4B3AVkbrkW4BuFqhKsQrsSst+PjVyBcjrAN4dsIl+EDlyJcgnAxwkUI30K4MOYohWIvQNiKcD7C eQhbEM5FOAdhM8ImhLMRNiKchTCGsAFhPcI6hLUIaxBWx+xlUIkzEc5AOB1hFcJpCCsRViCcirAc YRnCUoQlCIsRRhFGEBYhLEQYRliAMB9hHsJQzFYBNRtEOAVhLsIAQj9CH0IvQg9CN8IchNkIXQid CB0I7QhtCK0IsxBaEJoRmhAaERoQZiIICPUIdQi1CDUIMxCqEapi1ipoXyVCBUI5QhlCKUIJQjFC EUIEIYwQQihEKEAIIuQj5CHkIgQQ/Ai+mGUG1CUHwRuzsBGeHbNUA3gw0o0A2+0spRMhCyETwYFg R7AhWBEsCGYEE5aQgSUYMTIdwYCgR9AhaBE0CGoEFYISQYF5piHIMVKGIEWQIPAIHAJFICLQCYQE wjjCCYQvEI4jfI7wN4TPxGLpX8UW0U8x8hOEjxE+QvgQ4RjCBwh/QTiK8D7CnxHeQ3gX4R2EP2F5 f4yZva44/QPCkZgZhgz9PcLvYuZKCL2N8FbM3Aih38bMTQBvIryB8JuYuRkifx0ztwC8jvArhNcw 618ivIqZ/QIzO4zwCsLLmNnP8bmXEH6G8FOEQwgvIryAz/0Es34e4cdY+R8hPIfl/TBmboCaHcQH nsWCnsFa/wAzexrhKYQnEb6PcABhP8ITmPU+zDqOWT+OWe9F2IOwGwvahRBD2InFRhEeQ3gUs34E 4WGEHQjfQ3goZoLpnj4YM80EeADh/pipC0L3xUyzAe6NmeYA3BMz9QLcHTMJAN/FJHdhkjsxyR2Y 5Ha8dxumvBVDt2DKmxG+gw/chHBjzNQNed6Aj1+PcB3CtVilazDl1ZjyKoQrY6YeeG47prwC4XKE bbGMQbj37VjGEMBlsYwFAJfGMoYBLolltANcHMuYD3AR3vsWprwQk1wgPAZJj+maXR9oW11vqWe7 ngH6AdDTQE+p5rpiQDuBokCPAT0K9AjQw0A7gL4H9BDQg0APAN0PdB/QvUD3AN0N9F2gu4DuBLpD ucJ1C9DNQN8BugnoRqAbgK4Hug7oWqBrgK5WrHBdBXQl0HagK4Di9PyYEWZIel4snY23DQjrYwbW SdchrEVYg7Aa4UyEMxBOR1iFcBpCDcKMmJ5lVo1QhVCJUIFQjlCGUIpQglAcA37GaRFCBCEdwYCg R9AhaBE0MZBBnKoRVAhKBAVCGoI8pmGSlQnzAf8CdBTofaA/A70H9C5I77dAbwK9AfQboF8DvQ70 K5DCa0C/BHoS6PtAB4D2Az0BdDtw/jagON2KnN4cM7CxsAmZczbCRoSzEMYQGhEakA8zEQSEeoQ6 hFpssgkhA8GIcA4W24eS7cXSexC6EeYgzEboQuhE6EBoR2hDaEWYhdCC0IzQhJCN4MEKuhFcCE6E LIRMBAeCHcGGYMU2WBDMwq3QF8aBTgB9AXQc6HOQ89+APgP6K9CnQJ8AfQyS+wjoQ6A/Af0R6A9A R4B+D/Q7oLdBgoeAXgR6AegnQM8D/RjoR0DPAf0Q6CDQs0BxoMdBqnuB9gDtBtoFdKso4S3I43MR VsYMIRD0CoRTkR/LEZYhLEVYgrAYYRRhBGERwkKEYYQFCPMR5iEMIQwinIIwF2EAoR8hjBBCHhci FCAEEfIR8hByEQIIfgQfCiUHwYsgRZAg8AgcAsXhRoS7QToTQAmgd4CjrwL9Augw0CtALwP9HOgl oJ8B/RQ4vA/oYt7nuogPub5FQ64LW7cOXLBj68D5rVsGztuxZUC1ZcaWji28aosD4JwtO7b8eovs 3NbNA+fs2Dwg2ZyxmVNuat04cPaOjQOqjVR9VuvYQP/YkbFPxviMsf6xpWMbxq4fOwwR8nvHdo8d HOPZ5mb6WOWMlq1jV49xGXCfI2NUx6I9Yypty4bWdQPrd6wbkKwrXcfNOLKOvrSOcu51VFjXvY6D VLvW5eS2sNQT68z2FrLOvS6yjl/bunpgzY7VA2e2njHwszPoKmjKadCklaFTB1bsOHVgeWjpwLId SweWhBYPjIZGBhaFhgcW7hgeWBCaNzB/x7yBodDgwCmQfm6of2BgR/9AX6hnoHdHz8Cc0OyB2RDf FeoY6NzRMdAeah1o29E60N1KZ4VaBpr5cnhHmhIn/K9xbnUec0pUI1lrsrg1WW9lHcvi12Qey+TO d1Cd/Xz7VXZeB18cftlctqtsd9oes0l14gWvXpO+NZ1bY9hq4CIGwfCS4S2DhBjuMnC6q3R36h7T 8XN0i3Qf6CZ0ksd09DHtU9qfaYURfo52kXa1ltdpWQyvF7ShohadxqUJa/iasKZeM0fDX6WhgiZU 3CJocgIt9eo56kVq/k41FdT+vJYPlBNKTlDCjQ8UEwpuQkEJT90UfiteD8CnAZd3U5OrhT8AUeyH Qim9emd/XzDYEZdP9HZEFd3zo/SyqK+PfQs986Kyy+CHVufNH9xJ6ZVDzAnbH81gPxAshi/evp1k NXREs/oGY/xdd2U1DHVEt7JrQRCvJ9g1gSRDwYXrx9av3xBcH4QvoIXrIWbDGPyLQOEbrsfgi13B b12uZ78Y9nUfdgNo/diiMXgWAgvXr2e5jsEFC7Dcv+65/y1x9H9LQ/+/a6d1EZzF/j8bfRkkCmVu ZHN0cmVhbQplbmRvYmoKMjQ1IDAgb2JqCjE0OTIxCmVuZG9iagoyNDYgMCBvYmoKPDwgL1R5cGUg L0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgOTUyIC9DYXBIZWlnaHQgNjM5IC9EZXNjZW50IC0yNjkg L0ZsYWdzIDQKL0ZvbnRCQm94IFstNDkzIC0xOTQgMTIzOSA5NTJdIC9Gb250TmFtZSAvTFlQRlNZ K0NhbGlicmktQm9sZCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvTWF4V2lkdGggMTMxMCAvWEhl aWdodCA0NzYgL0ZvbnRGaWxlMiAyNDQgMCBSID4+CmVuZG9iagoyNDcgMCBvYmoKWyA1NjEgNTAz IDM5OSAzNDcgMjI2IDUyOSA1MzcgMzU1IDUzNyA1MzIgNDk0IDQxOCAyNDYgMzE2IDUzOCA4MTMg NDczIDQ3Mwo1MzcgNDg4IDQ3NCA0NzQgMjQ2IDUzNyAzMDYgNTM3IDUzNyA1MDcgNTA3IDUwNyAy NjcgNDk1IDUwNyAyNjcgNTA3IDY3NiA3NDUKNTA3IDkwNiA1MDcgNDIzIDY1MyA2MDYgNDgwIDQz OCA2NTkgNTA3IDYzMCA1MDcgNTYzIDUwNyA4NzQgNDU5IDUzNyAyMzMgXQplbmRvYmoKMjQ4IDAg b2JqCjw8IC9MZW5ndGggMjQ5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFd lMFq20AURff6ilmmi+CxZmQnIAQhIeBF2lK3HyBLIyOoJSHLC/99z31O05LFCbl+M0/vjDxePe9e dkO/uNX3eWz2aXFdP7RzOo+XuUnukI79kK1z1/bN8p7ss+ZUT9mKzfvreUmn3dCNriwz51Y/2HJe 5qu7e2rHQ/qiz77NbZr74ejufj3v7ZP9ZZp+p1MaFuezqnJt6mj3Vk9f61NyK9t6v2up98v1nl3/ Vvy8TskxETvWt5GasU3nqW7SXA/HlJXeV+Xra5Wlof1UKvxtx6F7X5qvq1J4H/MqK/OcCN5vCsVA jIrboFgQhc8fFTf8C+y16pYILLa9D0QgWudHItA5aW9NBO8Lr3ggAtW1YkMEonVuiUC05yYiEDda 3BGB2BED8oLYKiIneJBaBeQEU2lvQFAQNUbAVWAkhYCroNVWEVfBYo0RcBVUG0VcBTEq4ipyv7bO uAbz3TyoiqtgsQ4n4Cq8Z3IiroJoQ+IazBcRqrgK7zmErIy4CgT13IirYK8681YNjDQzL8qgqtOI uAqqOjqkDQTlG3EVLLbOuEbzLayKazRfjojFuApa6TQiroKprIprNF9mo4qrQP+giKvAyGbGNZov f6niKhhDz+X7YvAgTVXgKqjqYAt8Bc9VK965QRV97sPfL378dA84u1LQVd8ahjY4CevKKRS3N6/x 8TeYl4n+66oLpx+Gj4vcXOaZO2y/Hna9dW37IX38wEzjpAbGHwCsJKkKZW5kc3RyZWFtCmVuZG9i agoyNDkgMCBvYmoKNTU3CmVuZG9iagoxNSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAv VHJ1ZVR5cGUgL0Jhc2VGb250IC9MWVBGU1krQ2FsaWJyaS1Cb2xkIC9Gb250RGVzY3JpcHRvcgoy NDYgMCBSIC9XaWR0aHMgMjQ3IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA4NyAvVG9Vbmlj b2RlIDI0OCAwIFIgPj4KZW5kb2JqCjI1MCAwIG9iago8PCAvTGVuZ3RoIDI1MSAwIFIgL0xlbmd0 aDEgMjkzODggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB7L15fFTV3T9+zr139sns aybLTCYzk2SSzEwm24QsN8kkJCFhCQGSsCVsssmiiKAiUYgg4IKKKG5UWSxtHwfQp9hWS61atGK1 Wp9+7aK4tFalon2ePlVh8n2fOzMBrE+/v9/r9Xv9/voOOcs9dzvns53Pcs6FUEKIhowQnoQXXjm8 RvGK8hdo+QnSiwvXr3OfTSY5QuhWQpQ3LllzxZWv/XZRBSFqgRBt8xUrNy754bMvfZ8QWwchHR8t XTy86PP3V1xLyPww7q9eigbTc+bdOF6K48KlV67bsLzV/RyOd+GZi1auXjg8+MaqJwkZOofzT145 vGGN2mVqJGT4AI7dq4avXPyH7OXrcfw8O15z1eI1d+k+3YbjDwgxfIQ2in/spyVy8iOUHtJP1KSY hIiblJEJREZy0EZxtogUkDxSSQQSIEbiJSUYsZ5ESC7pIZPIdGIm5aSa+EmUBEkh0ZFeUkP6SBtp J92kjoSJheSTGLECVpNJBZlGFKSVxEknaSZVxEEMhCN2MpWoSBPxEZFMIVnERkpJBzGRbKIkDcRJ Gkk9mYH+zSK16G8LcZGJZCbpIkR2G/pMZDPwlKA0GiLYUU//+J+k6mPnxh4iZIxBSvoley/WcfdR ksU3kCz2FM46do57lxjG9l96Rea+iyWPa1JHShQsCeywhWxiBX4LUwXKNVJtZvr42wvg9f/171Xy Evkx2SLd9xNynICWpN/3yVNklDwHOtwgHQ8AolvJfuR9aBkE3GeQeWQZzq0lB8jB1E1kARkCRiM4 agREd6RbXyYfkX+n53HdA+mWi8XdeMtV5ATe9AAwsQz37cZo7yHfI4+AKm7B0cXfW1L1XW6YLCdX k8MkgXsXEUbZBDR0E3A9B31rB07XklV4+yB5gjxJFpOj5H60/wQU9bD8WaLk1jFMjf2Nqxv7G9mJ e+/l1nE3cbfzI2QduYE8TP5I/pPcSe5IPvevsSe9919nd5L7MIqt5HbgdJBv4KfyQ+O4/dd3EvJD wOtngM0GYOUQ8PIwuZP6yD6yjWyiWvIQ+QmtuAw6/6fnfdv5H5JdePblv5+TpwG3g8Dv7YDY1cDL 4+j91MsvAuMXUTXoZjkZpDryFZn/zfP/nxyvAS1sAMXdjPdchZH3kyWgrmtQLkW6JvMOWk0byXZg /TFaRj5Aewu5kayiHhomL5Lt1EGuw/UPofUe8iMaxrVXkydpEfkSXDUbo/ynH+QB+FKSBzinJNRG XmW8yX/FLuU/zsgDdsRohBaSU4RclAfUS7NAbz8kR/D+R8kD1EV58l/kDEnSEM0B5orJ60gvAm4/ Ij8D/D7FFQ7yHzQlS9ljx3/f7Avu2ClbLMkJXPPPfQG133ZpX8AXh8mD4K9NoKEnwes/I3eRf0e5 C0f7wUF7yQ9AA4dASyPo6/hPNghJTGRXsFyCgY78PC2fcMyfZO1jr4+dZmdTOaslbx+v/wbc/Dvw 81TIiv/7+78Q+P8RApzi/Puyd7hOmV5Gxz4RjiiE5Gz6X+jAQXD83civx78rvr1D/AX+I9kTY3+V /SjZIjPKCpNrkzdgLvsP8r/Ir8gL5H3yBvkNeZn8mQ/zL/Bn+C+EIUEuOy17lDwllJNryb3ffKqw SlgqTBMOCINCuSwADsrBXNULHWQO5soFZAXkGhEHFs2fN3fO7MGB/hl9vT3dk7o6Oya2x1tbmsWm xob6CXWx2prqqspoRSQcKi8rDZYUFwX8vkJvgcedn5eb48p2Ouw2q8VsMhr0uiytRq1SKuQygeco KaWOhKO1v215wtk6lNB6416DO6GdfK4nlCAml8drdEdDA2XpqxKyYIKYJyUsU/uPErF2ICEPfvOS yQneZ/jCg5t7XO62hODDn7dreFGiqLff4zW85Ro/P4DHJrJb+z0eV4Lz4a8Tp/DXNexelDBMRTtO SC2dCTK1n6UTY+/VopHUegaQ9/Yn8jKHA+xpqaFc0smnIXpOfqObk+kOw1GtszWeIJajRPtegljZ ZedqoS7UJ4qC6IgBNelpJJSgli8S1Jyg1h4M6fJXsNverf0WGLQtWu5tW7QMEF00dBGm51IQ9bh3 uHf09hujLo9H6vSkxKlp/Uc16lZv62I1RkGkBnJUrUGLhjUALWuOUm0jlSqctq3uKEeUWQCfiXW3 jaXlCXHnECreOOCGM+aLZ06Mndx16SmC21IXEVwm1aj0zoS8NaFIdcK9LCEOJ8hO99HSkzt2nTCQ BUNB7SLvouE5/Ql+GJ06Snhf29K+RM6kqYNoQieQhpa6GbrjUsaQ525b6t6BY3btEHJvHLde3r5o 6eIhRiZ0yBvHOVVr/zbPSVfChLItYQwmsnB71nUfuPgdbY5lbna4Y8c2d2L/tP5Lz3rYNSACR1mp e0ebF2/Dw9qWtzCMhcbRJlFj5yIJOeLOYXdiZMFywAx/w7sy9O/ZYUho/+4BdoAf3Mm4gwGYpUVD y9lQluNOAYV7x87F0lB3SUMDvbrblsdZYjeC+skM3D3Y37bU2wZ4pl8IgOB+3vfNez2ehDPIbtyx o411cXgRes8ggz9nUOpG6gA84QpS9Kc1IfZJBemTcIA3isPxgXRT+gKcEYCHhDgUHxhgg0ohIKHw bZOVe9072OMVvoQlaPA8j3Mny0on9fa3xRl14kqutb/hrMN1FvVJU8ebqQPX7AidZUBiZ6Z7J01L UcFSBh+WDfWlGBhQS2Mel6avl5562uE6nXrDnP52b/vQjh3tXnf7jqEdwyfGRhZ43QbvjqNa7Y41 bUNuif0p2n+005Vo3zWQMAwtpXUShtjrMTje1947KWGeNpuhqt29dBgt+GvyempdHuP4NZAi3346 zXOgfvAA47kdhk8xei2kk8vdzkTNCUgIV8JQy1gWHZrRD55YiFe0LZIy8Mp0PNzFuIYf8LUtm54G lsuDV0rEw2TgtHQrHuLxMH7aeUIkC3CQGJnWnzp2kwWuY0QMBYHHIXbmZOaMdQY7M5I5M377kBd4 c0zC+yX6+J/oG7J9nLZ3GL0md4wJdvQOf52LEif7MMZ/1CaUgJiEenNrP+/i2CWocS6e1dRBTA/1 CXtQupHBBBJzh8Hrfs2bMAQTstb+k676AbfBCGFJcU0HLmSUanjN+xJlcpRYDAlan6A21k4gVwE9 yH17LU6OE5K7bcdQmgAvHRYuZVcvWjrOSqnOg3fZ2DB6gxes60qBwWjyshG+wgg+MzH42hlfASUS oLoGEjo23yV0n0oZ+utq7XdDEoFzp0kVd5t7KUN2wj0Ul0TCgIudzzSfGHt3KM5EYD9oEJe40iQO Qk+B9nJSLCv9f0roIyD0m3YNLK1Dn8QSjMBdhdcyoLf29afZTcKTxAR4VycbyuXnx6GYuQaCDezs SYSzX3KAULMdEleneHf8YiChD6MZR8ClL5POZciD9STRjvk/JQOkniUmSsfS2Nnpjm+c7sychvjY 5LoO12EiaznqpdunHRXp9umD/U/DrnJv7+s/xlGudahl4GghzvU/7YYOJLVyrJU1skvc7IBMonja MU4pXe96WiRkRDorSA3S8cITlEhtqYvQRsnCE1yqzZC5jkObkGoTpTbMJ+him2MpxFu/F0hflBCn 9t8wsHTH0AADNrGlCBCU7W0kCc7beJRycm1C7V3cktB4W1h7E2tvSrXLWbvC2wLyB3O4T4DVdwx5 wf4QwP3ERQcYCTMq53zuE2NjkKCnIXk9CblvDhIErCo44E7IfF24biJLQ2iemBhZOMz6wcgU9yp8 nQsHEsrxB+KSzoQKT1Cln4Ar2qV7MD2zmxaCWIe9UhXNYI6RgcRAkL20fxnrkdsNfajDW5eQ+1Od lPnZi0IDO0zeCmk6kfsSat823IF3dEmCUGpx4RAvY/MR/hRa9HyhF1ctHHIDAwJZOB3EKPjZn5rh DS2LMasLfkyqSGowsnSSsGHxPk2WOqEqxwPxx+qacjwQf4oBAIUNXjralr4A7zYkNOiR/xJQpm8A dHCqk/UFf9vQeXbpz9hjpp0gvd4NCSpBVHqVAqcTWb7OYSgLqfs1aPFC70vdjGcpfayJPeP5VKuC jVwrKbR9J8YOezcyJsn8ykq9CdLXzwiTuKBDimRgxzcbErMhOJXfbM2SmnfsUGZ9+w0peCmzxkv2 FHfbsngZXgXwPovsFlkfPK2l8JdWkkmizxqqLCouJaW5mkh5ZammvFxTWilUVZPiYDhqMpt1Dkd5 hCdNpytC+Gv6w1unK4wmao+F8DOcNpw2Rg2nKwx/eDESplWVjVxNI19V6fcW6DiFt6q6OlqRx1kt ONDxVqvd6q2iRo+RJa5GbisptPtd+uZGd7jQqRqqv7W1fWFjjr6wvtTttypMd9LzF+T88Pla+meb zVdSFXCGojHvpF5LYUXezXnludH2Yn9jQ3uZpzRQlCNf9Z3vJD8Q9n29RPjvr76PARIO/mQi/EW2 GD7hAnKjGFeqPAUyjdpdoCtwOgrcngJeppNl5+cX6uxmpabA4lbz6t2i3j3FzRl5t9thopY83mgy HooTm07ukpkKHAJpiobs0aCR2KNGU8wRgkmW3XM2aDSRWCwMNTMaNcWQGU32mDEaNWw7efIkSxFP VSMHsAQCHoVcbrXY7FYPgFNDozSPs1uph+dzKiIOg96XLC/INjQ0JWfUTg/Q7zxM+xy+yrLzx+mj z0bUjmBhwZTITQu6uvPra1WRiGrNUmH61wcn95ZrIlwONwqXC9mIMS+HVyoXvvNqskqcYLNWl5RU 89W7xRJtbsnuonBuGV+2O1fMpYfiuSatn/fv1opazaG4ljfe6PFEbCXOGyOR2pLgZlnoTAVGc8YY YzlpCpJshwGDJY7xKuqh8fFHwlE2SmNlOReo8lTYYG3K5QprqvTyFbBOyzlvgVxhNNqiFdU49Pu9 3o2NJVlqux9nHvnZvNaVM7bv2vj2A4X3fadsysom/w35nYNbdjdPvOfmByKGQEcXP9zW5LVmReKj y2aN9BWqir+3fvv3e7jP797VNrvaLnAXvrqwStFy0/DwjY0Q79eOnRNMwL+brBENFoPO2mHRm+ab Vpt4k51AcRHDaAKhTOWGuNc4QcVzeXYdr9st2s15cl6+O0/Io3I5p6bmA5zJVKC+MTt0hqH3DBgg hj/SJAGDAYA4DM+DFmJBw/PIwApGrzRW0L5JGmxN1CiXewuIsdJUGK2wCaaFjq4FbVd8Z073PSt7 l050L5z3wvpk8vw2Kv/32ftktclPZl1Remvy7M+fT35yW2jJwuR7TiftpzPeoi0JM6NteNyFN4Fn F6IRdaLblcfn7XaJLiDVZdJpD8V1xXzxbh1v3uTzleVslksdBw7PBi9Fn4QxfhxjjFM5hRwU6g2g 041CVSUHTlZsKC+yqYGjEP33Zz4/1NvTJc7teflwrGhy39aVM6ud1/zmnnhDRGsrENv44famAuBn +qOfH/5ucmxWd6SoYK6QU79i55HFv6SyDcwlSSUaLUHfy8mtTxP92ElxkkrboVfn59sdHKfCm3iT iBaTfbeoLi9Qg2YLvIfiBQ7esVssKC87FC9X8ard5bzxgN5kctADHOfwuA/k54fVjs2BNNFKlCsh Kz1oiU7Z6FG58GJQYllHCFgMGV5MI0zweoyMMIErhj2v0VPRyNdEeYl5U2QtuBfo3QXFtYHk82+V Vnj08+bpCkKht2hNpKG0wG5ZaD6/IE3PshnJX0e6KvI0F/7TWS8mR+obsi/81FjcMjGe/M5ltMzk cgomKsCkhGwXpxOdQefW7dcldDIVr1NxnFKlsvF6Y74xZHzC+FOjTGW07RaJilp5VUmearcqnJOf l38onldSfCheouSVu0t4/QGjTudlwClV2Td702C5DCIQY1EGEEmIXXhx3tw0UAwvoiVFw/w3QWJh 8upSgKgW2IrL6iPJ372agoe+IFT+qs5dXZSMXwKJeF+p6cK7ufGJycF4W25yQ31HiRUS7FKeTsGB 8ex94Nkycr2YXeTz+yB9/VTF+/1aLleWy+fuFqnMrGfcWwzu1RPDVMOQ4TUDuNeg1Vp5626tYNVq lYYDRiNXttntDjk3KVPUH5NkmTGaYts0vzZFJflFILclQDCYRMI+ReBSbrV/g5urmOiCjLNiUhOq J3c23z7nwhjZReVH535/2UJX1xVTrjwwu+e+1euvModr6D2FhWaFzDq5yE9n05m/oS0/sGYnzw4u Du5Kfvaz55Mf33bFivrBqaW6SESbX96KwGqaHmQC6KGWzBPDQT2v3y0Gvfbg7nBYrrLyDrvjUFxp N/kilXxBhddbcCju5cnm0qysOn3J5lxA57ie9uSGgpIEjzLhjXEZ7VFHU2rySvHBWRC+D5NcBqMe 4zfRKw0Rs3VmvJxVuFOus/gCybk1pcYLb6qsxeXJ2WlE04OlAbuGKzUWTaCP1ZYavqqr89pM6khE V9A+nT6WnNvaWOjQXo71iMbmaWlLPkwXzBILDLjU296bHj+Xj/Fnk0LRJFMqlIfiCqvJbDoUN2Og Wmk+wpAcoTTCvrXj9IjUv8FM/w6x/n31P/aCvRe0ybH4rI0UiRZBxst2i4JRp9cdiut5QWbbrA6d ebEiBc7U1McgiGkuIM1841RB72vac4unvyvXGGig0mvj2x5fV9xf0La0X1iUGqo08gyuGe+3kdli LSnhS0Sbn+dJY4Tszgu78qJ8OBLGZO1x8BGdUeQbGhvQG5WFb+TbNEaby+NTBDfXhM7Y0a+0buLI KCkMz/Zo9mkm4STRVl2Df0wTYdTLKaikfzBdhLXxktT7dlA+nudvmjx1yFuq15YX0Sfdjc1NyQRd WddSX5Cc6CuwO/9S7C/1VX0bQXzqaBlcEY4Fcl1FPiESUXgb2pO3XPisrzVfFonwNpspWkhnNxaZ /wWBZHhCMABOeaRDDBCVQcVpeZXKTjSY7zTQfXaLGqfNbjsUt/Nq1QGl0k02G1KsfxnG0lJOknE+ iHjhchEvkTz9LpUH64o9eS7LYsv5TRkCOljqc2jnqK2++tmzk6suE18RrdndAm0CNISYo5zRUDVZ Ik6odIoqU4fTGfVpdAG+0Fd4KJ7lI5Fo5FC8yu7io7zTUekAs1ZW5svP2uxVvMlUm+2K8vkjQYZS CGx7lGkdwSgEl4ReEP0lGmgQ4opCDl3GuqYaL+KLYL7LmyXFjFKPPIsxgoSq+bFSg0puTK67Onkn 5hWp7e7McBfT+fRm2isrlEj1/CNpztEVtk+jm/fSqth5D/9ZQ/Lkd5N3fQtTnY/yLPIHeIx9BUaa AWujVSxMyXTB7jdkVVRWHIrn6Cp56wgv2HmlstqVU8m7R0ovDhz6NhtrFGN+sSLF6tRms0f9HGSw NBwmg41eCs5jw7X+E/HyDxZGsrNkSqXVV06Xlvns2k0X3qgsNRsVEKQQXuODjXG59YO1DXTFXb9u E5kSE9Fa3GLn14/wh2ZNDfQkrzz1yrcMkulibM76OeYsAzTNUtFOLLwFs7NZlcPn7FYJWZscjgLj JlnoL8DiXy7RGSNhWYEfA6k0wUpC3y2cnBpM4FJTSu/ScdztG164rWf7hcPH/nb9rrFk1vHvX3lf 98C+JYM3zQgYphymwlPvUPHwQ8lf/e7j5LP7uV8mTydP7qTa42/T/Jv7Hvg96xuzB2olngmSNtGX 4+bdu8WcHExIKZkqSVSmK5p5+42FhWX5knCtMEoav6QtShJWMnbYTClNGJerAFD1mYXnLQhUpdR6 pvkq6HezXOWRZGeGls59/GHH1icXrm5Yt/buyeXT1rQsrLgwob3Yrrl8Pjj+w6WHlpcL0yfcunbm 1e25UBgB3+TNsgrA14O4/koxplZbFDoFP1UxpFij4BWiXkfNvI64LBYf79stWswuZuGILkHt1hCL xWPP31RcHC3YZJdkwefGGEyzt7Kdp2HHZI8r8MyCS2lCpzNqEIZqzxMwpBo7UwZAbQE/B/09hS0D 9w1k8aLXFa6JlFpqpvrCk2+ZGOvqHJww8cuxFPpevNBxKfZU0UBTzKsvLmycHLdVLOlfpqXzaDyD zeTHyYe4Df+EzQw+/wF8hrBOaYlYleMikQjhI6A3MkFRqILyfiju8Sss5kNxywR+wm4LX5Kf7/L7 sHbgxpqaRl+Ebs6CLhhiCDYCEDBkJIWITRRpVhvHtWTVMj3wn5iKYVwy7ex2SR8E9wXKeS8P9Rnz ILPrCugRjc1fnhyfez/7+KO9extmVQ0GauvCyU/8cU9/UTQYiaxaO2vlnJrmrWsGuWnJ73c0exjn XaoXHjl+68lqpXPuggMd3UXKSNV1TYe7O3I13OMX/s3Zvmn2/BtbmIxZM3aO3wMaCZNbRH2I2Xqh shDaiUawMWWxHi02M8w0h9sx4hB0vMORoyksFHLKBF7YLZaZzYxbzYLjwBQ7tduL3Gf1+nDRWYWi ghwIpyYRsC9AFpormVGMeNKGPwOiRDqmGKYWXIAyEjbncSAdSVEsB0iYJ8SW0SOZB8AGyKXZxvim Jb5yxjWbKtdvvGZ767JfbunefeVCe/u8Sc1X1EdXLh+5bUrLNY8NP3Sa1vQviVx3zaQlg/V1q2/u WXNw0JCT/KJ/QSA83DpxQV+luOq2ect2zy6uoiZJ7gIwwg2gFTeZKZbpTUYoT0Zen0+z+Px8o8pJ nLwTdMNzB3idOt/Rkn/A7faoN0Naedgw2KRzJkgNPV+cSXEKxHB6oNG01mX2QDHmYShlCESoMqY8 Py1C3QJbMFxTs1mSAjVw15g1N4YaKoPmhbCMDsxcVGk7T9L8rzDYCxvrBWKKLcMSIkoGIU/fRr8j pFLMUUoSS2k2l5TxNism96CVj+z3+6PZm3WpPmKOwMzAdNuUgKIW2LBMHgHuaWcEVB1pJpTI81Jl drHF7PcuvWfRxh+srVCbCyP0APTW4q4l3e3LJ2Yz3e2OuqCB/vbKKZPqKjtLqq8/fBN31+Qatx00 yjTVC/XDWzs9kUV3Xc+tTSl1+sK4pL/aMIbfYAwecoM4Q+420h65W62j3QpWVUhVJasqpapKVOGc yg09QOUym6xuHmsmeQJr3izL1TtkhM9WuVw5Tr3e65EV6Q20W5YTOi1R22mgKa0apKEAhSAYpEHp R9nI4W4y00bmlstofV7K5k76dnkYPqePab5cq+JrWuiB4oqINzm8JfmEqygMCz2idJT64HI6/xpf bS4pysuqr4E2r/b3zfn6+8Ls2T0BNZbxUWIb+1IxhLH6yI3wZY69JoK4aLc1zHKTlMPb8poYU9Ee NNIetNEen8nKcyYNHBdKFZR7c46gI44ChYr3FVqteYSjJpPSYsaqoryAEiY6k1WSsGJ+N1QvqrpQ itiA2Y9C6Snn2SBTTjYz/GvmcW2XV1Av/4PkyUeTfzDl5Xk99PuNEZPhJdryOJV9GoxOoDvyCj2B 7OQ9dwgzv35MaIzPjDhho2rDQe9Qw/mPhVVf7+a+3jmhoZrBwBkc7P76JbAZxm8Fn23C+BvJFWJd UbnSQWtqQo15nghfHio/FHdXBQuzZSFqMKdUd2NMyLLJGnmlo4YvKso3N5gbwvn5YjgETJpgpEI2 w1K7OMCMLs8GjvOmGERyeoD2GkncptHKm1OmXFqZ5zOORjgxzBJc6Jlwid+7+w63O6uwhF7tm9Da +F6yOlQc8iY7y0tz8576abiwJHmLL1xaPeHT5J+Kir05JlCBwu/J6av7258rG0ts+UElQFLePz/5 aHLewMRIIThB6fXmxCtoefIXU6KeEpzX5Ie75tA19DWxrlAvl2gEEgl2/Qx4q2aJ5blEp1P4vH6f /1DcJ7M6eEkXsXFqk0um4B26XBlpkclKdbmbCSkrlYQR80EyYfQeZNG4kcMUQpxlMxdgItE0UC/R uzkFhLSVMy6g+Cr6XvLTispKzE/zXN5TLxR5giX0+uJGsTH5sTYHCktNuDwni2vg6NypcKtGNO25 HS3JLXTOxNn+wmJYL/qqwRVJf/InsfYSB86r7cH2OtDAPDhfv8L4bGSxWEUUBgVsE4XColZSJeXp blGpN0Humkwqm9Zi0fJaTMymA2azTaNRKw7I5Q6iDoG8JYEWRcHURDb9GlMzy7iTNS2AoZrAcOHg qPJUUU+BjlfAWWWlE+my1uaSAseC84u4HyT3BMoKvV7zAv6WOc6qocXJ3RHhVJarcnaczgqDbjky FXNmAjq6H2ulP3qa0LGPnmSiBcz6kahmNa6c5gpFiHCKcZW+o0ijCfCBe8U1mhFNQnNSIxCNQTNV c6dmv0am5TUaZ5iWC+V8+cOiYPMVHo77rG5z2LzfnDALYWScGYtQxECgtEMwW3DkzLLmWsvgweKt BqeBN9znNJgtFmXeKNX4+Qr2UhXEYUVFZcmoEkfMoaGEQ4PRQcoiOi0BiURhyMH7ujY4dy380ulp GRZDGlRr0/6doGTvBYM+ybPj91dVFvpSmoocgYpGTNZwVINOmDOEl8QHXKAgIu4x/az7Z3ava8RS UU/RzI7J8x1bhkZGWhZuqOfUlkBp8q/aX75c3h6Or268QxjomrCi/a5HspqXbqjt7b25IuRqunlL 8kBXQ2W+TRuhp7ily2ItzpYlFRL8w4D/l7K9WP1eToZEXyktlkET3yvKDLDbbIYsb5aX9+4Rs2zZ zsPxbJJDVVv8DIZZDDd+f9hQXp4zapY8ewwqIJqLAGDqbFNTSkcBMMAe9vQY4a3wFvgDigDmRshK 0BAGnVJV2NxtpXOF9rkLJ6y4f/rCn23t2tLR3sZn2QPRLyboPE2TwxtuWHtVbOoUH59PO1u8V779 8GNnrnYVNBiEpqHuqjyTqlL99es9s+srzM8//+IvvF0d5eCNZRhnL+jMQzaKcTcW13IJSmn+iHmi m5gMJreJV+WbKBjECcevv7jDpHfA4bVXdNjy4YbfI+YbDAa1yW02ezlIePUWl6SHsYkPWjxDM7lE kYeK9xbD9VWIzDh7ziJkcXruWiYxUw55SAdJMauBpx9gSCtmfNdmY0VLpH1lk6NuaGLbtWIsOnlg VvSZU2te3tq7kz/4evOkvMETozNuW1RbHW+pbSg2f332ng9vwPTE+AjjE4LAYwEs/uViufGIwaA/ HDdYo5aQI8SH2EAKivPzgVs2FoX8cFxBlFQ9arIU8F6GUEboXm9tKRtZmr7/CZdpMoaWAyI39HyI IV3EHwwyhbcmwJSezJDsDL2ItkAaSq58XkijUW4JVn9ar9U3zV1Wf+DYuheub1kZ03lqW0Mjt6xa U1pXW+fSXYLM6ya3Fjk1leoDQmtr0ZefHPhwjdWRPDp5nlhqOX3y5Cm9py4MPxVHlgLH9wDHTmD5 OrHFbbbleYy88V7R49HYyET3O87PnBxxGpxu5zknnLVOm2DjbXshKjQIXewRNThjNxGPybAlO9tr 2qqQIPG5KfaWMfZNW42hGBhey/AriX+YcWlbxXcJCGCZeJiizSw45tlC5IkfEVeM9Lz66xUv3rT4 9hkh/sKOqo3DvVuaV8hL+uJXXK850tod/O/P93xwg7j6u9tN678zu6GNzlh5a+fB+9k8PwXI/rPs QUROrxTdaoVScTiutBpMQLWN/jWoJ26D2+0+6X7NLcviEXE+KToKfB1uhNoK+cJ7c2GLcJ6D7iA3 6oD7+uRxA+3Rw6vzecWbDOeSX4ARK6Pdpp6z0Qomy9gEB0RfVLARrIGwEhBkjVYgmsoMLfg/rFFu 4WdZzuKy5BWlfqt6o99pN2YJqoZrRgen1Cw0R8s9ZX5X1mf8rAuPtca9VugvUrSGmxuFopwdLb9y +1BA89SEiMkvzu9eBppGuDfZzL8HfFaQZuy7+Zs4q8XTGwiolSFlNa/cc7Ka6qvzq0PVvKq6OqTv pb0iMVAr5JLekG8IGT4zjBlkXt5gCHVQPIInfxUr9M4OvmOP6MwJNfFNe0KGgFpb0F3IwFQMUBQW 5nlaWrrb3AYz7W7Ly+vjVEURoWTCVpkBzCGTWaOEzOhms4JGjyu6rdYZ0a0lEpGcDgJ+TEnA5ICw a4wpxlARUcGJ0xXw/Y1b+RenB4luGBFBTJyGxRZCNW3PSVoWoB5QSKFL+DUYE9mi0gwhSU/JoKth c0i1lDPJavdQidPS5q/cLM0h0hQCRxVc9Px7T6vyC196enp9d25r/NzyW2IrX9m++PC1zX09oWpx Wsek2OIdUzsm0gUXupYMRTvKrBUza+cvckajd9w9eFNcF+io2zONn6XQ5K9ofOyota7W5ze0rO6a d3evIza3vemKgLmrIja/oeTOOTM3Ty82Jl/btD0QH4j0r6+58fxZ/4zqwRnhwfqcqhInk1kUKw6I UACZVUdWiPU8gzFXhIyyjLDMYA7yRcVFh+OmYqubSqEXNjPV1hyO15IY1Y46HPXEOxpOk3I4HWu4 bBJifru0cZZS0VOTUB7zVsIAZnEkFn2UqDhloI23paYmeqUwefZAtGZmc7FFH5iQXB8osGe5pkws EvuCCktxMLmO0bsk2D6vx5Q0pcmdXdWzoje5bVaTF9EErcndGqfy0dvaczq6g8mb4nUBJ5S2VKyy LTNjMRk+HUD5iywOUnVCQy2xC07hcNxpzchyPbdwDU/1/Ds8p+fno+B5uoUzj3LqtGqCUmJpdSgY fP6M4QwJzV0792xaVmf4GMsf4LRPG6Vs4pWAQDefWBLw2LMER6TsLw2Gsmhygyz+3HNfnUXvW9rp k+LkkF1ZpbpQNbPVm8VkrSzZRq+R+mpHdCiiUSoRD71PVOZYLYfjtiNWdFb8Zm+VbpVK76BbOfvo JdLnzJtnGONIApZ1OPts04eX6FDStFllTsU3LvabXvPDY3V3jBQ0NpfY5JaSmo8bpP7+atfj1/j6 HcHY0CTuz5PjAYemSiXRWhNorR60JrJ4r2nsI6bKQRmUSgtzzjSgoaS8wW13yayFfLHIYUMep4Xv T+/MkYyow3FXyKrXHY7r9Y0Nh+ONRKQ6o9VZKCMlo9VpyFczCmQxEEkJYqNIuQXSemD2aXsUdiOG K5EioiE1iPSyv7RdjCCOgvmWpZUZkt8mwPiWsf43qXKl22N11teUh1RKXwl9onxpzZ+ou2JaODmS 7dQUlF1bkOt21TJEXl0RMCrS5MmVKVTBaLDeCfO2QI7VG2Ll28ntLU2QxrzRos+taNxflqM9JyE5 kpUTaK3mL6FQxrOAI/094GgjYdEqwMlxOA7JZD4ctxArlpOR0aw0KLJSymAKENIU4vu2UXyzh1/9 i3eDP+Tz+VewH+E9caZGCYSpWdRCclkI7JBnGcc8GJRlhGXKqNzhik7plVVXVR+OT82uss4/Mm/e 3MPxeXqqKgq2y1rlrXzr3iy5QVU2Ws8oAjMBK0UmkOrr+82jeg9tfQeaN2MznET5EWYAVDwLhkjH KNarnjwONwpKiZzYGl12XT/YEOTAwifBIGS8pFahAb4i6AqSsyilRqXiCyCNNF2k/Ah2Nr/aJI05 75uCSZC05EssSiha422pUOolrLJaV9/T0eRZdKNj0tzh2tbh1ny12V+WvJYJMpXZVVDuL2qbVnix TW31FJTnFndM8suzLD5fcoPf49AyyfBxA18g1Df4DHPmd3cEAtOuuyK5rbvObUc8NS3lZqxu8ecY 3N09lcm7Lz8zsCZeYtP42rtLk7fG6gusZqYBXCZcJD4FjoUQcFxPrhUbyhkKythMUMqyIMucOfXY L8LBGKHW4iNFRYHD8SJ9qUkfZup62FA9qlQ2lpZYRgvg7mFMjvLkkwYj7S4AFlLYwPzAEMAmhgwC JHyk5gdPekYYB+ilvAePVU1UkUJKOt4lhFJTgtLs8oUDgfY+vyQ+M9L04waNrmv23MrqGc0lVqXF H8qAqv2qzuJcY353Vzi5M0X0l4PjMWGS6HVW9qycntzW1ghUAT6Sns+/BZ0oCxZbl5hPoN/uEYlN kc1n71EYbAYN7bFtUbu14A11ng6U+BRadFt4Rrto5MGVTFVBfolKIkWB0mYIWzB1uRbBWV773dWn Rt76/aqXk9u3XNc6b0J285qOjTcZ/uvcwQ9Wf/mXQx+spV+9+ofmVbun3P3c7F+jm+hnZ7JX0ACP RVg9cLNYwoICMDlcxF/uh3m+R/TbqrOj+VE+uhfmiP0ItBxMG/qCLZH0XIYSRia4KBKpI45svlaa MkQVWvSMKqC2BlOhSZRsXRizR5gJlsJrxi+eUV9940E5iS8kmxNoZBzGBgyThU/ZZFWGlAG6RmUP hpNLC8scSkFrD5R90pClb+zomVh08Oiin27t2lDhaJge33jdh7XTpnry3mgWfQ7mkbMWt9fxgx0N RdkmVZXqMaEp5jf8918PnlnrpPOHlja7X3qebvdO7ixJwWgpYOQGLvPgZZ4t+vMksqaucmWJFgH4 vaLWZis0m6G47zEbHHq7weYcVUpwYbZaJBINbNGnbLXoGawDa0q7ay56HzKDpymKvsQssdlr7JL0 gP3GjJKMgSa4k0vDQbuqeu5V4sGjV7+6beJV9e1xlb2sMPm+o25y1U23rl5dMiE2IVuX7MVaQF9T Cx1o6Cz/+yeHPlyb624wfH37hDas0+Jfn7tkYv5rz8A2K6gLwTajTLfhyzDWAHxTeTanA94Eh5V5 aPxHfHo9NgorDUrOwitlI1o2G5sMtg44dLQyg0qpLA5Q02hemp/z2BTLYoNwvZwOkiCzV6BDY1pt 6pH0BkYBUBokHs2YJ0x+/hMb09W6mnlXttWF1jqqQ4UTW5xQr5NXXiLrbHxrT4n8T9WRkqnt4eSj s9vczBV7icyqVAOR8LvB7lRjbBGyT7SFspuyp2TzP82mJNuQ7QZfZvtzKaPmDpOtIwSnA5X5teu1 t2g5n7ZKy/FEa8Dix6naIa1MJdPmlluxwGiPaLWVI169p9yQfdDpLKmg2LmuNIwWFESVoymLg4WB JMVJkmYZowIuFwBj/lzAg+kcLIyIYNDcq5gBl8H0xagPfPFRZpum4mVQNTIxIm5syFbfXTN1vn/q 4iWrm6oXbJva9/CkBa7lcwvbqt1Ffctnr2oaeHxty/VzuTP1bTmTmsvrK4OlXQviU1bG85yW1+dM 13vry6JiVZm/Y0Fr70Yxyww4+fC1geeE45Bcs8SI3cBb3GbRH+owi1p9h9mw1w7nq15OtbxcIaoJ 1C31XxV6s0WlylPINKNY9xhjaH+LudxgmGbwHmvqufBWMAj1kQW84GaOWj1WaRERs7mlqKkfBquv otFr0dxOW5PPGEprS4vaC8ombo7fdOM9/A5lUdP82f+9ONk6fHVzjie/uq3x/se4IPrbCZ+KD19V KEWUsyD3SE6O63A8xwqr24uQ717RazOX0lJoPlRvG3XngW5T7kKttpwbhccSPhVoBUVMCSli0oqJ 3ShbByWtJriMTdPeFMSyJCkEfKQcY9Jxyq8iCSmMhK2C6qS5psKWOn/7TJ9cZ/YGaC5U4OoPG+T6 6Xu7Z6+vy/I18j9J8tdc11iSN6krQq+NpRZBXZjRE097Ugb7Ou64mV7X1+TDTgeM1Tz2d0GNseaT paKoCpuhVoVZPEhhYI4+pZRD0UJd5bAZ4ORHcOhwXJaFtT8yojfrgKWWvDy306FSedwgugb4wxkF Mn/5u6DOjL+8CbzJAkMEkZJMXOhyP3k6LvS9cr85S/dvr1gMZfV0faCkJDf5xPrk5zmeAFAS0Vjc LteEQFJOPww3ukpKWQTAM1G84OI+6YnlKNmXHbCOauxreSnG5CPPiQadQZo6kMGTB92QKXG5qFjc yIws00nzCsvgO5OuOIcoEmBgMbDcKOXSfQ16RJUsbpYbUznC/tRKTHo1YkmSU0bIcuQUyJR6X6HF kmvmqNFoRvhBmZuLSBIIQYofsRgSQHV5JCl6aSwJmiAAJQXS4HWEA+myuJL5EsBJgaW85Fc7z9nz QRA764q12ocove3thM5UVk3ngng9zuQ727hPLhi4P3VMyGXqVyDAYMjx8vNf0b/42/JKWLRBoc9t EC+4AT87ZPYvAL8asuhpUjL2D6ZOBbE5Swyj4iohOsEbNll9fIG3AFzgVagr+FA4BIdUWE90rhIB MbawymcyxXzjYSU4R8ZDpeMriOzMHKJBCkvoEjvInBLYUlPg4op1RBzMGUBg2rJzyput2QWFdKJ/ SuxXH0QmB5KrpuvMu/cZzb6i5DFPVU3Za78prSy10e1TrDau+aAr6rLnKSIRjTgxmTzd0q7HtF1p 9TtfPmXz2V1eRFe0hbEaytHC+uocmEjaCnt5DpuvKbEkuyQeKQePNGocRlvHh5r/0nAKETUWbnEr EEhQaEQoPprviUKOmxhs1kAJWykJJdWuVx5UKGxYoOMutqUIAOLs7Dg4YAVIrnIm2V6BEA/OhUCT sUl7XErXpMNL6XjqJejnFJyyZummmTVtA9rCgrxQtC2Y/Mjl8Qfo3pDflKU7dspoDtWl+Kj3hn2T s14sdttr1w1wn3fW5WFW01g92a66QFJD3y1qzQ1m+Ck17mmgg+mgAwt5SLRgjbSaw/Y5C6fi3aqs Dl7HweR7VyxGPUuGxS44o7foiNqg5py8WsZhNfsekdOw2UyjVx1UC2x+zwcFCVmMzbLUWWrecpBI LIdNDqzU8aANSUuVYpGwWOHMkDxoUhAK0pItdDdgtTDYh01xwXlzpcXCUiQKRrQUiZKiU/z080mu MPl5RV2lYxb39wt/oIrKSn+hkxYk/xjh6wr7JlJDxflfGLzdvRgsTwbGzsmuxxqODnydZQn5sbhQ MjCKOj2kbthT52nM0+TN4js755la3M3NjW2NfOPeNqw55+fx3DwEquY9LPI201R+6r2iSQgUbyks bPFoZg1jadDohM48T50woc9+rru7pW8U0cdmd0vL0sG0mzkdRmCzBKZ1e8xwxghHIjt68ZLQAqML 6DcgEeYoZGtPcR+TIZL1yDyOqWAkSMeXnjGw7CPlJqxO74MR4FO0j7MaW6hw6b90ZCJ1M5Uu80ND ZCpiigklX7Yf65AC/I1Lfrpu45PzG7at62wcOrqy9ZpZFbqcsinXdVWcWtzaHK6iuWq5SqXV6vWI MtpzXPmRzlh+Xk15ef2W+khnd3LlyJbg1OiE2dFo7oLB+PquWbumuOsPFru397ZPv++K3tEbW4ce 6p17x1RX/VCbp6GmLt5d0vrX1W07OisrwZm6stzcHMg1luXiFxNdOYFYY1t2PffH+IMzYtOD0eGW hpFPxNsGp2+sL68rbH+hoojxsSP5KW3Ft36yiFc0yY+dzBIZ7coVWdxRjUavSwEdK2xDwexPAcfU HhK2uLYyQKt04WVzqqPlFsVH7fH2dVe3NYR7sBmmK2XzfErX8dvwXCNpFP0G7HU2rjGOGBPGc0aZ cfxFhif0LVz6bfgUgoTiFysM5+CvwwtDcIB946VmtmVpyfiLf3zq8ldzj3z8MWiXw1dcCL0K7+fx zalKMZ9LEN7Au/mp/J28TM/zioQop5zsCblSJX+iCBLX0HMmWsE2I5xly+/xVgSoqqSXXXXq1Cl+ 28cfXxj+6KOUDLgSz64BzHhiF9V8YoSjT3CcTJB6T/AEdJn1sublj9gdlKykP+PquTm43iOaOMpz T4qEYq8AFWSUFNXBXsvsW8JrPVUerj4Zpq/Rnz2AcZzEA+5GHJuNo1zM5ljH4ezEeoyiOvIG33L5 EL6AKetoYjsqXsWjsABMGsHdzcORl07JZpyfxD/19d2sTxy+ZEF4G3jbh+9+TRaL3UqljfgTYhEL AHIe3mQbsUFY3WUT/E8U+0YIMWXfqFZDvIRYmE9izLdSYiite0rvZG5+vDe17SzjeE9vO2O+e8TF Ia5T287q1c6qSF00u6S7Ysp80/arHunZ8NBEfV55bGJV2OI9RfcXFFfEJjd0zVnY0LOiet68A3Xl HTdMK25raWuf3jhpYsx5AgOhZCL/XToHPjgd8YkGBeCq02kUbiUP6jXoJYywpYXpoORpdE6KIWB9 eIrpaas2q2jWQEOkXK6V7fVMdrcsWTa5fsLGWXnxNiCbJ8v453kqexx07IKuLopY4CfalFZFDs3K 0iiUGpfLaXXbnJrjvPO4MfT5H88YMu8zvJV571sVztMV2Y7T+BQI1sUyu4Lp4laL3XPZEaWvajSF fdNiNQFj0jRepe/zzxd25zYtXt5Z3X79QOu0yw7oG4wmOcDhOHefBIdcUiNmK+1uhY3k0txcl83u 0um0CqXWdNzFH9em+siwaHiL5Zhz36wAiFjnMrCR2Ntz2RGNajTe6dNjxV6Tkf71Yl22l3Vn0dLu 6qquOU2pzl08Yn2jpDHZy/8AfeNJrqjlKeci1M1nOCaa3XAajNfUhPdjuRD/gwvlD3Fvyvb+48eK Ntw7SF/hD3FTca9TzGK886x4CdukF5iBZ/hD55/ku+krW3HPk8ke7n3ZA/AllIl2NRSQe0U1JQhr 3ktcmjzrVpnMnc9I4wLbOTAei8L72fJfo8GEtYHWgsxEgA1jdhv7F+XeP/IfG6qrNvz2SHt1QzCc 5zWa8rw5Jb7ohHnJniWv08k0j+bQaW8u79XqikqnzLnvO2Nnki8s6gsVWx0SHILo1+A3+uVK9Yvm aWRbrdZUv85+o19mLIXAZ2I4zENV8JKn/mFNMqYd/PMG/8duyR5Y8nryWPK95AfJJy7rFp0w3i3A 64NkL/co8KNg8OKgnNwrcpTArgO84NYepVSllOAFRF0GLw8WuSBxjyZb6LPJLyg8IYq23i/n45nB ZC/iN+lnyqVnyinleO5e6pJxZJTnU888+0/PrMITqzz0L3imDs98NtnbK/8OFBJKJnMH+Vw800gm iB5OptTojHKtIJi01MgpZZxMoxOELF4rmMwCD7FqpNAApI2fWFLraALCcQAsK3xmr1kW8PlqZFju 77PL+Nzm5Fju1rwkXpmXfK+FcnlbcyltTr7P37f6qeQvaOyp1beMrnmKxpK/eGrNqITL3fyP6BKJ pvNFfMfQwOEnwBDcxPOZmYC9kWliEMN0SedyRPeSXvoH8Opu/nnukHSvArtarHJCDdCxqVKBMT7B C08oFCnYIBpEmpjLfC6TqniMhz2qT1yWzVmbljvxvDL6Bkt45q1ji+T3SLraPFh4i+dQKkxpwYLS +1rEFkEY4LkBaGQDWAokeMLGKbop/JQ9okmnixWXYnH2faViuJgvFY2WjtLwA2JxzMN7HogJpWVl jZVGc7cZ5s/WOXNmdnfnzoRLubKxIzd3yDdamZoH0D82H5igpcXglZAWxYWkNcxsOu05i7196Y2q qTXdmQ1euFI6f7kax9ZYsdEGMhpbyvNfY5fWAKXCt2wTpJDZyZlyaxRitjFVYyenwKQWBycmc+Ck jAI4MYWUU4+rESqy+vZObp4XCvSsuGP6hOHgZHG1WjU0cVX9xnPfeyP58++PJo/OvGOaQzw+9FXy x/s2fEQbn/l3mvVY16IfbizpjhX4lbLqRm9Ty4Swq7yqZPrcCUZ6iN64rvWG6dMO3bu2zeWq1ic1 pXWuq6/+5bU/pnTrM8lH330u+dUWR/agM+cArfzjD2jlJ5sXHXtn66Hk+dus5V1VDtpSWJkt1tqr Zlx/R8uMvoYNm2YAnzfBj3YW+GS+bbaHAb7tfdjDoMSmy31KQbPLYsnT7eJTGLiMKWUF0pp4KLhM ZEhr4k1Gad8o9i+U/vaN5msODP/urQ+T9Rs3b7ymfkV329yYw0D76OAJqn2iL/lvySPJh5N7uFeS P0r+iubTsj/R3Bt69/2B8d8xTIivok/Z0OjyTDZM5Eq5Sqm6Hzvf8O1Nnc2mkuNbnjt0uhwXExdn XsQy0ShbCUCaLm5aiDIWzOxxYw5oplErAjQqt3I/zPI0zuu5kLt6fgU0ZPf6WaX0zRo5ldVN8Fk1 XGenzFjQ2M4Hi3wtdT3UPnQEfboJfXoJfSoiC8WoOxcL+hwOmzLXxmfbHhBzBZVMNJg7ZEXKIr7o EaXTaVLJFHL3LpOpxFmkUjlud4bOREPMTAh9/lYFMx5CJMRmBOxBlSxQ7HFhK7fYElAWkILnDIv8 sAEVU3h1TcpViL0VqY31KQVHruCejdQXWg0zjOdfCt51y7pobY0jvHDSj5s3bnyj70fPWsu656x9 dmC/NqcslPx9eNnv94y0dCybG5p0dctrJ2PRxx6oGpi16IoNL0kfJaPkTtDByxhfmIyI8Sytz+/H pop9ol+w+fcVhfXZ1MhnAyF5ZbY83pkHn6tZKONp2QOCoFX6/SVhfCkxW7mrpCTbtMvjqXDdntoy LSlwDEVI0r5paXULmDU1XgyYaaRMMc0EDzB4s/T5gLRWYM3j08GCtEXOfBNetnCPlcDoI+tenrf2 yGD8+gUNa/urFr+2Z+Yvpm/wXr3w5tHEkcFtTw+uXztvfY5Q92xNdfuW2TNuGipXaar6rpm07sml AfebS+fdvvOuff3K/h0zV29Ysgz80INYmEc2B0MtIEOpXcohtktZr1QrZOocGXYLPICNiTJltgPX HIpnQwfUY5XarTluj1KQyQpdCmlBpx0LfH4Dt2lqyTyQisWq0hjZYnrpkJmLGEUV7GfMH9L2YwWi ztK+CmjnWGLipZyAbTQX3uQ677DWVXh03dpz0t6l5cm/0m1yQZ3cKO2YODCJv/r8Y8Zg5NUDqZ1K dOzLeX+ZcOFu0O29wOtvMAf4yd4fUqqVZRty2ToA0W/M6dBrc+Huf1DU5z6S+wQ84HxurlHmwxy6 T/SZjRDqj2ALBVYzYfw2I2+z2z367J0GA/XsUiqLuNvpRbnMPgs3KZHVO9h/NNtSOyAtxiFNrwbH lZ4UdQPXDAYS2bPtOKCKSLgm5Q9neE2xKLZfg+yjCo9R2jwhmYLegns35m0cGt3ecd20+ILaqVyg IM+knay/8LPK6xquPbFozZu7f1Dz5pKh/Y8s39kI64G7S2N3f5TstNmGj6+/5eQizKUcuRm+ZTVo 3IldxrPE0jyZXG5UqRAteFBUqZx+Jxbsik7BiE8jwJMl8zqhJ2bdFgyGvLssqaHCdwTsZcTg6TTP ZkgXPkWIHGuBnFPA1L+4akiSk4U1FAY9U/bSgR9Gv/wd+/76kFvd99j8tY9MXfT6/b97Z82r1HBv ciwye6pfK1fLR26etKTJdZ2sPLJ1jCSE+tqFxzfc/IurMI+rjtHqP48qL6ywlbg1WnNty09PVc6+ vuOeg8D5PWNfChxsOR2+8pHDc2GtVs6xrYlYVPlIFvRiTivT6QxZGm3o9AtAQfQi9p4msrGPagfQ yDz+krODaRfZhpcwMgpbswqLjvGBD7MH31z40W7Olewojnhs5pkWflDm++rNiHCNXp9THqdxZtOs Bu2NAd65gHcTGRaroYAYhQleLzYo7RO9dqUXokWJeOQ+UWm2B/ngPrvgui0QqNHm3WY2a4VdNTXN 5buw5xdd+NbQyyWCQ9K47CmhgchiyvoJZBZFMhrCZMB25mToLB17TB/qON7BrV235je3j760un64 i/uPta9vvvP5hSsvJHIaF3ZMX1vTfFXXjaOavOYlnb3XNLRsmNK1uMnFvZ5V+t1rrzk2PPC9dbNG phdkzX3vikfnTLt/xapHqHzC0u6y5k29g5vqbz3/RfPa3nDr1sGhnZ3lk7HQjiOLAJtPJFosJzPE YD5oUWXK0GIAH31gtGg2YeH1PpMg81KaZb3N6w2X3oZdXAwcSP8HSvRVMTa6qN9g8CajhRMUZja5 ZOYUya1JY7tOb7Km6bB+/dH1v/79o8nf//ywv62lyanSKWvWTp+0tDnvukDkhr+9kKLCwe9snJj8 Y/Lcl8m7f2ni9mQ5AzZldknZrT9fyMhwzwF8HhbrY++UP4UxYo8eYhzl+OL3TWJbPp9bSvAljj8R UQEa0SkUUDX+JCoEd6AlUMvX/kkMBN0VfMWf3GWlp6tCp7HHIFd/mteexvKZnGfyc5/Jy2uoZ5Lj zB8kQKRWMkkq7Li0AV2k3Lpw2X2Q0QrTtl9moSzWdzCaYJ611EwCs8FLzf/i9P33751229xZ6zvz DyZfmjqrd8qU6U2decKe87ffza9b960nOdmbv7nnhXmNqx+Y+7t36Y+eSxx48uSJvvup76tJsqe+ mvCtJyGqwMM3kFvx/VAV0ZCI6FDw3EmV/FmR8BoqqOT0GU6bxT0z7k5yQAEimF4uVGS/amAOGSN8 sTBvojCbuJG7k3fQtXfTqzghOUqv30mvS97CPmwNGryBVvJf8POABQWpEvPos268WHhWTMioXpYv 49S8jFcQQakSFBkzJ+VCYlL8j8x5ZcY+C8gE6w38+vM7+PXcGzt3Jod37pT6fwv6z778PlnUPiOn chn7rBcvypgnOk8GJxkvI1RICOcETi9QNZYpywWiUBL5+KucTDeYi/1dodpQbTaWc+OPvZJa4dTC Gy/kce9x/C666d7kG8k30noMGxd5vHaTcb6+/r+IS8lGSl44bOwYL2XJZuxaehzHKnat9MMaXcW+ ZIwQ++B/Vl44YPscI7j8N4B1d89S9pXj80QufEA2CiPkWtkkskHYh/okpPdxfCPZyN2HtI7kylSp dvkt5BrZVUh15FphJ9kolf8gG/l/kDXCs9jvEiKDwptYTTKf2IS7CL6zQExCD5nHf0SmCsMkDN/i MmEN/EN/Jku5lWQK/5+kSVhORC5GpnMeIhNgK3OlpEn+OJkuXIvUhOuvJp3CEFnKTyHT+TVkHvcU 8Qkr0KYkZnkFyeX/SOyoW/jHyDTZCBmgB4iDyyGdSEdQv5J7nKzkOslJfpjMoS/A54O1/EgT+U9J o0DwtXIdeRIpyJ0mHyAF+RVkMv0Q9qaP7FZYya3CKnIT0rF0eSfKHqR7kW5GugdpNdIiRR76uorc kEkA+Xr8O0fX0w+4Fu4VuFHfFPqEO4WXZfNkx+R18iPyfygGFe8qVyr/rupVPakuUR/R1Gu+r5Vr X8yqyzqiK9U9rLcYBMMuw3vGOuMfTTlmnflh8xeWrZavrEut5219tpftlfY3HXMcv3VOzhazV2Z/ P/vt7C9cBle9a7/rtZzCnKty7sw5kvP33Jbclbn35v4+96u8wnxt/sz8/VjkfY/7vOdmz98L6gpO eeu8vy1UF9YWrpMoZQD+UxlZhMQRA/boLgZxNeH/QMBWPoyJYlljip7kkIWkvWtK98DkYOvwlQuu Wjb8NHHT5JMqB+1yn6BfZSpfZir/yFT+O1P5e6ZyLlP5LFP5a6ZyNlP5NFP5JFP5U6byYabyQaby fqbyXqZyJlN5N1N5I1P5dabyeqbyq0zl1UzldKbySqayP1O5I1O5PVPZkalsz1S2ZSq3ZCqzM5XB TGUgU+nPVPoylamZSnemMilT6cpUqjOVcKYSylTKMpXSTEWVqSgyFZk4JmHuP6X8Cyn/XMrPSfln Un5Wyj+V8o+l/EMp/0DK35fyM1L+Ryl/W8p/K+VvSPlpKX9Fyl+W8pek/JSUvyjlz0v5c1J+Usp/ KuXPSPlxKT8q5U9I+UEpPyDl+6X8dim/Tcp3SflOKd8h5bdK+aiUb5XyLcjFxi73iHS0WcpvlPJN Ur5AyqdJ+VQp75DyFinXsXx+cwc+U0/JCMTanUj7kRJIJ5FeQ3oX6RySkoQE+HqQpiDNR1qNtBnp DqRHkJ5A+imSmuQLlbi6EldX4upKXF2JqytxdSUmul8JXvIO0mdI+E9GkOcjNSHNR3pE8Ipe2bn3 aOLCyQvcyQuvXXj3wrkLQqrgT469NvYu/qsPYU2zWvCh2yeRv4b0LhLWrYha4d1nzz3LSZm+2Sh4 8GAPkwlcP67WI38XicNr1exYUD5J9X6qb4b7UzqGi45s5uzStQ+SfO5BEkJqQpqCNB9JTt5B/hnS GPegOJ1/510E+d78DbLrb7C5rr/B+fqvUV9/LbIr1yBbuRrZilU214pVm6/KXneNxZpzxXJkS5Yh W7zU4lq8dBQbaq62Xdfq9GxEcjZHuLvI/UgcyUFeymrc/dw+7gGi5W7jbufuQLmD28ntwn+U4uLu JzuRMCTkjyD9GOl3SAJ3ENccJlncI7j3OygfxL0Pk6yxj7jbj1m8sadR2ccqzdnczdwmoDiI/2nj BsjQIHcjdx2+WRjkNqXL67hZUvu13BVSeQU365gs6D7BrTnmcsee4a7CeXb9KrQLrH3W8Ug0pmpu 5tYSJ9IRnEcjrlmGo7dR+wiJ57ZyGwHRIDeCkt2/GSXrx/XpciM3Uzq/gVsCOR7k1qNk569Jl1en yyXp69ahZNddnS5XczOPKYLFzVNxTMktLOfmcvO4+QDhNK6Xm45yMjeFmwpQarjJSNOImptLJqA+ gPp6pGtw/ACOn0L5v1CquWW4YwUAuhBPgucOX7Hr5RagXEbquYVIQ0hzkaYhTUaKc/US1Fo5IxAV 5MT0cSOO2agbOCOg1t5sRTsl7chfROK4CTivwPkYSgalmvT1HlyvYFCOHjPbYs02LpQ+UZ4uy1Ay NJamj4PpsgQ3yoITm1twTIkM+UEkDsONkklIi3C0DknA5G+QXt2Mkj2pCSXrel26vTZdVqfLqnTp TpeVKNl9kXQZTrcXp8sizoAh7GhehWMsGkT+NFeBIds5B+cEUjSclstCqeRUnFpCjhLI0QD4dvRW CeRogBwNkGMHcpRAjh3IUeK8F3f4gIxcPCkfZTaelIPSC0TkImUj2ZE0SEpST6dj1RNGhqhOqpxJ 5zCk0BnpchZKdv5t+iZkW5D+Nl1+SN9lI6Rn0uW79BPp+DOU7PpP6SeAtXgChUoNZjtJhWORSLoC poFn58lf5LtjuII/Vloa+xEsToDiWH6B92lWPX4Se+Uzjbm5mcacnPFGlyvTaMlO10Y05nRNVKlR Q7ThuDh1J2oUT2S1ZjUaCbbU5bMmVqJn5NjUGVLPyHGvl/WI/DA3LyZ+5HJJ3fxzoS828wRVimb6 h9/KghPemvQWJyY0WbGfnZRhbdRJseYRszkmPhgKxx7cR4MP7JMF9+0Wgt+9XwjefxcfFF8ojcTu 2s0Ht+++bzenWuhY+IuFvHthlh4PP/fkxHxf7JcnqFrMofftocGah+m9e7igY6+/JGbfSw17msTY /9pDf4L/RqYU80WQho+dFoInaOjYK6woO3aaR1HKGn9Cu2mXdE3Xsc2y4NP46lsf+Erf7KR9GG4f Yum30O0ScrahZEi+NV1up3dIN96OkrXfcXxUFmxq1tL9COC/Sl+RTv4aJdiQvk5fOSZnmFUcq6iI seIJ9AH7If6YJ6FVNP7ekR176WU++PIpISie8hQwKB4/ZbVL5YuAJjt+0ZbNStH707JIbOo0wGka 4P0hhvXB+zh4v6QkdvoVUNArLXHp+lcCAVb+8BV7duy5jylGrTr2tvRiMfqxzxd752MqPu/KjR0/ KgseBWLEkw0NsZNPCME3npAFn9gEcf22yRZ74Rnqvp0abmerc4/vrK6VHr0zEJS6UrETz951myx4 2w4heOsOWXAH4Pifn/HBLz6TBT8f4YLn9gvBzwAaEVv5Y+KneBt7zP5pvamybWKqrK2XHqfZD8S/ s5/ux53suntA/yjFN0cAn5s20+CN6NUmvOIs0m83082jvvztozS4DWkr3rIFqXg0Nto5yi8Zpe2j tHqU+kepq8bqqLZaq6ymSqs+atVW4IuGVnnYyoespNz65Vd695fhLzl/QFcU0JcEdaVBfcH/7u1+ YpqG4jiA921spHZbcZGIkAFxhJANnYGEC88wByTGehi4w0Y9oP4unjRZ8aaSKIoo6JVwkIOePPCm l2liNMYYNSAiF/8kBgQ8KAgaFauJ8dv9cYSYeNKXfN7re6/vdV3TLlm3X/2eGr9aWeWprlIlR4nD xnd6FG7wYY7vjje65A2Ky4kb5wg058IHhMtpp6qjAaYGmKJqKq4UzVKb3bBfk16pTkXCfWa1WWqW E3ZdPmYfkUbkYfWF5LrJFOYKB9QK5nOXFZe7S0s2u71Fm9wh84h52Rw1J82nprPFDJtjpjBnTIeU Zsr1kBm6xRSphSnh7UU/uMlX+RdezwO8jtfyGr6VV/NKXsHLeCn3cpXL3MntXOLRxhgTXk3SYohK ylDui4jGoJa2V3eKhqAm5KgeTzE2lECrsPXjfI6Jov60DYW3tUuPp9kWq7sPIZBxERBad99gIhj0 CbIC2ff6EqLBWrjkSyA2f0OHqPBHMn/PWZ8ljZ5ME8qkke1MBpPZhVRdbbsItB8Q9e3dbcF8a6aP JZGy6+dGBfNldmwmx5z52u+FfEOhzHVZRTbyimRYkxnWBo21syb/tA2Msn5qWkiFWmbG/F7lVpDy O5yt53r/OqYw/ZpxzBotykQLjt36FVKydRCjnRFha92vCcLjFSqjerco90fwrBDUmqI6wu5H8Hqs txIJpZHsQWaxGlISYsSnELE9lnIi0/X4rkPsp0TsO5jwDVbhK6zAMnyAJViE9/AWFmAe5uANzMIM TMMzmIJJeAITMA6jcBGGYAD64SycAR26IAFxiEEU9oIGe6AJdkAItkE9yFAMjvBh+kyf6COt0DIt 0SK9owWapzmapdf0kp7TNE3QOD2mR/SQHtB9ukd36Q7dphuUojG6SldolIZokC7QeRqgc9RHp+kU 9dJJOkHH6SB1UJR2U4Q8tP64/Js6zrz/kX4Brd/fagplbmRzdHJlYW0KZW5kb2JqCjI1MSAwIG9i agoxOTg4NAplbmRvYmoKMjUyIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50 IDk1MCAvQ2FwSGVpZ2h0IDY3MSAvRGVzY2VudCAtMjIyIC9GbGFncyA0Ci9Gb250QkJveCBbLTE0 NzUgLTI0NjMgMjg2NyAzMTE3XSAvRm9udE5hbWUgL0ZKT0xZTitDYW1icmlhIC9JdGFsaWNBbmds ZSAwCi9TdGVtViAwIC9NYXhXaWR0aCAyOTE5IC9YSGVpZ2h0IDQ3MSAvRm9udEZpbGUyIDI1MCAw IFIgPj4KZW5kb2JqCjI1MyAwIG9iagpbIDMyNCA1NTggMzM4IDQ4OCA0MTQgMzMyIDY2MiA0ODgg MzAzIDIyMCA1NzUgODMyIDQ5NCA0NDEgNTA0IDU2MyAyNzEgNTY4CjU1MiA1MzEgNjExIDY4MSA1 MDQgNTQ3IDU1NCA1NTQgNTU0IDYyMSA0MzAgNjg4IDUyNCA0ODMgNTU2IDI3OCA4MTUgNTU0IDIw NQo1NTQgMzUwIDM1MCA1NTQgMjA1IDU1MiA0OTYgNTU1IDI2NCA1OTMgMzA3IDU1NCA3NzQgNTU0 IDUzNyAzODIgMzgyIDM5MyA0OTAKNDU1IDkyMSA2NTMgNjIzIDYwNCA1NTQgNjg3IDM3NSAyNjYg Mzc1IDU1NCA1MzcgNjQ4IDU0NyAyMzcgNjUzIDU3MCA2MTEgNDIyCjU3MSAyMjEgMjg2IDg5MCA1 NTQgNTU0IDI2NCA2MjkgNTAwIDUzOCA0MjcgNTU0IDg4NSBdCmVuZG9iagoyNTQgMCBvYmoKPDwg L0xlbmd0aCAyNTUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2VzWrbQBSF 93qKWaaL4LGlsRMQhpAS8KI/1O0DyNI4CGpZyMrCb9/vnKRpyeKAj+7cO/Pd+fHicfd5N/RzWHyf zu0+z+HYD92UL+eXqc3hkJ/7oViuQte385vzt/bUjMWC5P31MufTbjieQ10XISx+kHKZp2u4eejO h/xJ375NXZ764Tnc/Hrc+8v+ZRx/51Me5hCL7TZ0+Ui5L834tTnlsHDq7a4j3s/XW7L+jfh5HXNg RWQsX5fUnrt8GZs2T83wnIs6xm399LQt8tB9CKX4mnE4vg1dLbe1FGN1vy3q1QqLYlxn2RKLYtxU shUWEU2yCYuIrmTXWCkuo+yGn4jKzr3DInKXit5jEXYt22ClyEfsgZ+IXE/UYhGDO0U7LMJuZDMW YUvZIxaxKpUq6YVEKUVLWCUGt7KwSjEmrbmEVSJ6JwurhD3KwipRSrwlrBJWvSphlZhXRCWsErke DGtpXqYjCqsUI2vDwiphPS+spXmTB8NamndjBFhL89JtcmGVmOiArWCVWIZKVbBKWE3Ewi0Gqzm0 xAJBjWWjLJahxtJ7K0aaj4VVIupcWCvzJs8La2Xe5FKwcqI0WNtdwSpRSr2qYJVYlfa3glViFwTI WiwWqZNDdy1KNbKwSgxWlH2zQFA0wSoxWKXon8VEEHEf/h78Mn24CMxcSySqq9S2KGtLK5LZOcNE 4ZbA0QYluCWszkmCW2JSLwnuZHZSiMItUdmD4U5mZ5uIwi5B53lhT95rDh5RuCVytYw17BI3ThvE xbLom+bl3FlEtSNcDgtA9Y3WWpRyLoBcas2ribiUFghaFffMAlAIXA6LwY7CynFSrg4Gk1tU9mBY OZlEOaVEYZUYbARYudRCcC6svDxEeZQYDKuE1ao4wjXrUSmtmVfHwuoEcjks5rUFkFdLlXUSOGgW 86o53NGaI6HKthBxX7Dcnf/PiZ5QPfXvT3P7Mk28yv4/8IOth7gf8vtfxngeVcD6AyvZi8YKZW5k c3RyZWFtCmVuZG9iagoyNTUgMCBvYmoKNzQ3CmVuZG9iago5IDAgb2JqCjw8IC9UeXBlIC9Gb250 IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0ZKT0xZTitDYW1icmlhIC9Gb250RGVzY3Jp cHRvcgoyNTIgMCBSIC9XaWR0aHMgMjUzIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAxMjAg L1RvVW5pY29kZSAyNTQgMCBSID4+CmVuZG9iagoyNTYgMCBvYmoKPDwgL0xlbmd0aCAyNTcgMCBS IC9MZW5ndGgxIDgzOTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVkLeFTVtV57 7zOPhDwmAUIexHPCMBPMJBIiEB6RnAlJfKRKgGhnUOsEkhYUZVoCKCogyhUHH7Fab62tRJRHBeXk DGLCo4x67We1llhbi9625mu1rRY+aavVi5Jz/70nvKzfvd+9Z7L2Wnvv9e+19tqPc/YOMSLKonUk yFx0Y3ucvDQDJT8HFS5a2WV8PuvJdyC/R+RZ8M34t27s9yx+kchrErlu+NbSW76ZU3HLSKLsXdBZ urizveOzNctKiXIKkZ+6GAX5a7yvId+K/PjFN3bd7J0uDeZ0IfEuXbaonabiRzm3Ie++sf3muGeZ thL5u5A3bmq/sfOpVTsfRf4p5APxZcu7nAvoN8hL/4Lx73TG/3bZ+wXIf0yU90uUMfzkk0VuENqQ Ja59NFbRdhqrBWkskYP+pGloifOerJOcf4gG4L2k4cemXfQbNoEZlGQnaAx9xorYJLqUNPoUEdtN J+l7NIra6BGWT+OpgK6kS5kGnRDdyx5zVjof0EX0XdriPM/WO0+j/gH6KX0GD36vMaqlK6B/JXXS B+J9ijo/QOzvphE0k+axAmqnt/D7BH48RA/TT9htzmewOorWo706ClPYecH5giroXq3bdSTjOXqQ 9jO3s8hZQufROErwkPOW8y4FKUpP0i74FGIp7RIqoxtoA32fFYmfQvoePUVDLItfK2a7DsHSpXQV 3USrKEFP06ssn7W6jriOO7c6f0Y0R9IE+LSEPmBT2OV8q5blzHLeoaupn15Bf+UvpV2tbXddPVTv /Mh5kUbT8yyTHWAvuGpc95+8w3nCeRYjEqRJiMgVsLOQ7qQX6Gf0N/o7X+uspUtoPiy/zEqZwYKI +Fu8iK/ha8SbdAF6ey28XUGbySKb9tF+OojY/CcN0vtsFCthl7GF7EH2d57FO/hh8ZjYI36lMe3H iLefAohRF22lvZjTr9Nh5kL71ayVXc+WsX9nP2KD3OJH+aeaV7tT+1w76QoODQ597lzhfEKFVExf o9W0FrF9kpK0h35Bv6a/0z/on8zHprHF7AlmsUF2lGfwcXwOj/NH+Fb+jLhCPChe0KZoDdoN2uva O65/c23ytHuGvtg29NDQM0NvOM87b2Du5KD9IDUjondgVmylQ/QmWn+bfkd/kPMH7c9kC9g3YGU5 28geZs+wl9kb7EP0ktRvHJ/JG2F1Gf8O4rSeP8QfhvXD+A3wd/jv+F/5J8Ilxomp4tviCWGJPjEg /qT5tKB2gTZJm6Mt0ByMTI3rYtd81w7XTteLruPuOneHO+7+i2e95y7vz09WnPz9EA0tHrKGkpi7 Xsyk1YjE47QF834PxuBVRPQX8HiQPsYoFLMyVg6/p7Nm1sIuZ19n17BOtp7dzb7Lvs8eY1vYs+gB +sA9iFaIh/l83s47+V38bn4f34PfPv4z/hY/wo/B8zHCL0JikrhULBBXi5vQhy6xRtyFyD4onhaH xZviz+Iv4hhGbYx2nrZCW609qm3X9mhvuL7muhG/La5DrpTrDdcXri/c3F3sHuue6L7evcP9B4/b M9XT6rnH8yvPP7xxNpZVwHMDc//0w4uwBs/jT/NR2lp2DMWlTKNc9DyEcZiPVfEPqhdDGJccWQ/f RvMiDXsgNjBTs4h4F9tPU9jLtNbNBXYjbZBs9ls+qL3EL6Jfsxgr0raLm1yv8jLaid2omx/g+1kD 7eF1/Cr+Q0HsfbaD3sd8v5keZjew5bSTHWMz2O2slq2lX/ECMZ/dRXXOFq6xDHYpO07wgO7QOugb p7vwlQKbTr+lD4Ye17K127A/9dEjGNFd9C77MZ1gLucodjeB3agdu8y9mO8bSO5612KdrcV6LMIO stR9mPYwN94Ete5Z2mo6Tv9FH7j2YUY1YDf989AS7XHtj06tU4UVhlVGO7DuFtPFWDHvY5YcRF7m rsFKz8ReUoNV3UoLqINux673oGM5P3TudG5xltFrwJ5glewE68GK6AOijl7B7wF6m23COrz4K7v3 vxYOdVCKPmSFLMBqsB6OuVa6ul1Pu/a4fuJ63T0J0b6LHsOM/gNmcyZ6sIjeoA/pU+bF2BRRJU2G v9Pge4SW8qg4SLNZMcWxZidgH28Y7slytLIe0fsh1vNBrI3j2CeuoZ/QEcbZGPRoEex70U4L4nwd LadtGME7WRIlHdi1K+iv6HcOm8a7YM9ES49g10rBp9/SnxBtR/lViX2hkV2Ftj6lr1MHLEylVtaL EdhL07GzNoqfI97jmY8a2Dj2FHAxrNAcKqXprj8yTpVDVzjT+BJxEO8YB+U9eHuV0EXs2/AiF/04 SaPZHJoyNA8+vMmEZrFfKi8e5Z3O3WLV0FJ6jX6MMTG1lZ5GIjPcZtbPuqhu5ozp02qnTL6wZlL1 xAuqKkMV508oDwbG+8eVGfp5pWNLiosKxxSMHjUyP8+Xm5OdNSIzw+txuzTBGVU2+ZtjhhWMWVrQ f8klVTLvb0dB+1kFMctAUfO5OpYhce2oOkfThOY3v6RppjXN05rMZ9RRXVWl0eQ3rNcb/UYfWzA3 Avm+Rn/UsI4p+XIldys5G3JZGQBGU+HiRsNiMaPJal65ONEUa6yqZL0jMmf7Z3dmVlVSb+YIiCMg WWP88V42ZhZTAh/TNKOXkzcbXbSK/Y1NVpEfUDQjAk3tHVbr3EhTY0lZWbSq0mKzF/kXWuRvsHJD SoVmKzOWe7blUWaMJRZ6Q5uM3spU4t4+Hy2MhbI6/B3t10Qs0Y42mqy8EOw2WmNWv1d4JovG82dH 7j67tkQkmgqXGFI5kbjbsFJzI2dhS8pkC9Eo2gCWB5pjiWaYvhcj1TLfgDW+IRqx2AaYNGRPZK/S /ev0N8mS2PWGleFv8C9OXB/D0BQnLJp3S5ldXGz2O4NU3GQk2iL+Mqu+xB9tbxzbO4oS825JFplG 0bk1VZW9vrx0YHtzcoeFrOyzhU4EPV2nJKUupZZ5pyPLpEf+Sy0TM2qRAU8ifvRpmkw6p1Fi0TQM AJ4oA8rqwIgssTJmxxK+GbIcXWSWK+DzG4lPCDPAf+zouSXtwyXugO8TkpVynpyeahZrPyVboZBV USGniGc2xhQ+zlL5KVWVK/v4VH/cZ4AhfNSK2LZHZ0xE+MvK5ABv6jNpITLWurmRdN6ghSU2mRND UYvHZA0GMF0z+kpZs+5UzWl4zI+ZvEd9LI+2vMHTf7m+gpFNi2dYrOB/qO5M17fM97fMXRAxmhKx 4Vnb0nZOLl0vA4q4oW5YskbOjogSjjIp8RKhajEpr1lwWgWZSJalBfDnlk5jdQhMSlXAjGbLF7sk nUYzy8qGl8y/Yvo83rNAfc5xiVLsDGy4F9aM0LCfaa+tmefkz/EuKyFa2rDj8Ja2BYlE5jl1zdjL Eolmv9GciCXa+5x1C/2Gz5/o59v59kS8CbtQekD7nH2bSqzme6PoymI2A9OWU0Ovn22c22uyjfMX RPp9OL1sbIvYnPHZsYZotAqfFvJw48IPb2oPNezhbMjt6eP15khyaUOCMj3aEKMir9s1xMUBFqQM fKAWUmHI98+6k3VX+D6uu/xkHdVD9n2BZFJ1WV5ZXgAJw0v/C0OkvjBd9DkZWorU1HDxB97yvhy/ LrfuE2+RF7aJXt6ed8kpftobRhlKX1ag0DNr6Aqa7aMTJ06sRi+k2tkPd6OIT1dF6vSnNDi+Ezje 8W6kPpqINyS5T/AX0VkOTUb5w+3Ikwi1trQ1fT0cCn9nSfvSqoZlSzsub5PNSU08Trk8I37FI+sF UW/bunC22EW7QTCG1AD1gASZYlfSk11j9oHnj1LcLgjV9DspscuecaEqr3q4Zt0BsROv8AtRvNO+ UhbvTJqNUn1n8sKZaT5xkuK2N13tGVWjh4sBmwjilDsszQF/ALQZdAjkhkM76V2QAxJih9hiN+to eCsayg2PElsRCBPpYZADEvB+K/qylT4aLtHg1ZPJjCxp/kmFKhFPApWL1AdaB9oNOgxy0TKkm0EO SEDC5z2Iiy3iCdun+8KZ4nFaC+LiB5TLGOlo/ftJn4rNo8nckTVm2Ce+R60gTpa4nFIgjmYfBOxB 4lBvsasmqRC2JDNzanzQ3wSnN8GRTTDZg5SpvAlJ6m9KjiyQzt9p5+Yp3K129eS0kPQV1rQiCjcT E53iJhzwdBwMbsLnky4WgZeCLxQdlK38NJO5vpp1sFcP9Xp8J5+P6rAowNenLhpFMb58ZHdW2Dlp OyvsCRU16PFsUahUckU2Pvx04RUeu0Y39gtTBX9jMmOE9G+j7Rtdc1BsEB4czHWxDlpj9NyDIhNj nKl60pbMyK7pDmeJNnSzDWHR4SNDlGVqiptsNBTOE01iLA6rurhBlOLgrItmcZ7i28UTOCLq4kfJ 4Fg9tV88pFDflY3C/Kz01JqVzM6pSYUzxCzUWuJ+DMD9ynh3MjgNn9lBMYGqQRwxXgtpLSSfSEBK YNQSGKkERioBpxKYfSTuQc090JkoVlNcrKJu0GbIclqNthFQuRhG2+Mn1PSLIlGIwPj2I5QMpcXJ jBzpWaGdP1KpFSazcmrqD4rlNAfE0eWu5JjCmmX7RYXqSmWysEQC4jam60Ec+9TQoKUCOSQHxVgE QgamVJxnj9atsI68nMg6Mf4qH5BB4m/yX8vhlidfxV8b5q8P81+kuZPiA+lFwX8p+WB4LH8fjV3H f0ebIXG+n79E1WjoHd4nR5+/zfupHvwI8h3g/eAXgu+zy17R+3hfEgy+P2ZnF8jO8pfs0MRhQQ8M C2NKhoX8gppwgL/IX8Dtj85/Az4e/AWewm2Nzg+BF4Kn8O3/CvhzfArugXScitP8P/gBOcX583wv TiE6T9o50gXL9ki223ZL9qxN6VzrRP0Af5bvxAWGzp+xg8Wo3JEMjtdz96M9hnuCLrtUzw9n8idY hH0MpR6cUcApn2+xa2Uj3fYBQ+/n3bzbLKw1A2aVuU1UB6qrqrcJI2BUGbXGNiPs4/djA9nMsX75 JqS1ZHDMHpAJ6ub32FqtFT6JPsl+cVqHtEdJMaRxJRFSn5Jk7XEl1fMNNAfE0cYa0FrQOtAdeE11 89WgW0G3gW5XJV2QVoBWYTeJAxEHIg5EXCHiQMSBiAMRVwhpOQ5EXCFiQMSAiAERU4gYEDEgYkDE FEL6GwMiphCtQLQC0QpEq0K0AtEKRCsQrQrRCkQrEK0KYQJhAmECYSqECYQJhAmEqRAmECYQpkJU A1ENRDUQ1QpRDUQ1ENVAVCtENRDVQFQrhAGEAYQBhKEQBhAGEAYQhkIYQBhAGArhA8IHhA8In0L4 gPAB4QPCpxA+IHxA+BRiEIhBIAaBGFSIQSAGgRgEYlAhBoEYBGKQr+oVA+GXARkAZACQAQUZAGQA kAFABhRkAJABQAaGuy4DISdMCtgUsClgUwqbAjYFbArYlMKmoJkCNqWwFhAWEBYQlkJYQFhAWEBY CmEBYQFhKUQPED1A9ADRoxA9QPQA0QNEj0L0ANEDRI9CdAPRDUQ3EN0K0Q1ENxDdQHQrRDcQ3UB0 K8T/eWj4HSzixbuWr2PnK76Wjiq+ho4ofjv1Kn4bbVP8Vlqv+GqqVXwVBRXHUCveRbqX2XptbrgA W8Ac0HWgZaDNoN2gQyCPkg5Dehfk8CnmOC3XM8ez2bPbc8jj2u0Z9PBc9xz3Zvdu9yG3a7d70M2N cAnPVvsothZ6ADhGa5F+BMJLBGm9kur5ZNidjH12Cn6T+WQz75jxUQU7XMEOVbDdFeyBChbO4Bcz Te10BtXic1dnETMrOEs/AqoNls/CznT/3qNjdDs4Ve9jB9LsfDOE7FFQL2gbaD2oFlQDqgIFQDqo NlgBWMQcN9zkAfByUBnIANVSAf6bQPl5XrOfZ7NtyZezKUPaKZ8A3H67vBqszy6fA/a8Xb5QD2ew vVQuv4rYc1hUO8F32/p7qH4mzXbZ+n7kdtj6ZLBr7fILwK62y1/Xw9nsStLxfwCdtQ3z+RhwmZ9n 61dBba6tnw8WssuDUrsChgKoPZ9F8P8YXcoKPT5tyW/rM6E9ztanS20vlcuBx31dlXLPBVnmRRIO fdTPIhozR+jH9If0o/D3rwgspsfbRp8GdjjQx64yM/UDVY9DOazb4Uypj/dD7zC3JH9O3xa4R38M bbHAXv1R/QL9/qo+L4rvg9/3KBO2vh7n2J3mSH2dXq13Vb2nL9cv09v1efq1AZTb+jX6AekmRVmE 79yrt6LBS9GLgK1fHIAvcLFZv0U39XJ9unFAxpemSdOYyVUHZASoJm29EvGtCMC6rV9Z28fyzArP cU+352pPg2emx+8Z5znPU+oZ5c33+rw53ixvptfrdXs1L/eSd1SfM2iG5BljlFsdV9yazGhK9uHM wDCPZYrzl5fTZWSNFC28ZX4Da7FSi6hloWH9c76/j2XOXWC5/A3Mym+hlrYGa1qopc/jzLNqQy2W p/XqSC9j90dRavGNfYzaIn3MkUUbSuR9TC+jDfeV9BNjRRvui0apsGBlfWF9/qy86c2NX5HEVGGs MXTmKTxbLLUeaZkfsZ4ujVo1UnBKoy3WHfK2pp/n8uymxn6eI1k00q/FeW7TPFmuxRujUHtPqWE2 50CNyiWDmreBDKmG/aRBqmGM0npBwKFXJhn0MrMpqPSCmdlKT2NSr/eI0dTYi7szqRMgOqJ0jgTo LB3MGGAbe4NIoOU3WERqMdzKKcfOVw3pOlSqkECF4btPNaQzZcyaeEYlMKwy5bTKFGVLpP1RzcgE zYyacEpn1ATonAnk/0/qbAix5KQVa15qwgVYzN/UCYpZm1YuLrTWLTSM3jUrZAXuoYKxhYsWS97e aa3wdzZaa/yNRu8khftS9UuyepK/sZdeamqL9L5kdjbak8xJTf72xmiyvi4SPsfWPadtReq+wlad bCwibdUr3JdshWV1vbQVlrbC0la9Wa9sNS2R87410uulhiguaRRP8hGZmMOxkrJoQ4EvPktO6P6Z ZYVrSvZphP9mjMDFVBauMrNBsqoqXBWWVVhnsipH3nIOVxWumVlWso/tGK7yoTjP30CnBoIkvsWa MrfFKsMliZwquIr86jFbLh9VXUhNSxrxh3yXoq7lXadalJyk5r8+XV/1rFixYnkXkhWh5UQtVsX8 FmsqbsF6PR6YijVGUXbBqTIhVFlvRkZTn5NCZQhOsC5pTkohFkIEzUxyk4f3uHs8XJ4iupLFpTXL DuK7YS0Ix2G+ysZVgqxalRwXwGkJKhOnpDmOqzJvF5fVwEKyFlDJA2lu5lVB6A50V3XX9gR6qnpq 3ajduw2F+jb5KrUnbhPUFVp+KhgQu6IINtyS9p6wx5Yqwz1SCIWioeVMxeuU/hmuypE9E1j0UT3L VfMy3irCSKWIoMtajEfa+gqZk09aUFjEWYFQCq10ThXJ5MyDHNF/A4xmS6QKZW5kc3RyZWFtCmVu ZG9iagoyNTcgMCBvYmoKNTUyNwplbmRvYmoKMjU4IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3Jp cHRvciAvQXNjZW50IDkwNSAvQ2FwSGVpZ2h0IDcyMiAvRGVzY2VudCAtMjEyIC9GbGFncyAzMgov Rm9udEJCb3ggWy02MjggLTM3NiAyMDAwIDEwMTFdIC9Gb250TmFtZSAvUEtURVdBK0FyaWFsLUJv bGRNVCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvTGVhZGluZyAzMyAvTWF4V2lkdGggMjAwMCAv WEhlaWdodCA1MjUgL0ZvbnRGaWxlMiAyNTYgMCBSID4+CmVuZG9iagoyNTkgMCBvYmoKWyAyNzgg XQplbmRvYmoKMzYgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNl Rm9udCAvUEtURVdBK0FyaWFsLUJvbGRNVCAvRm9udERlc2NyaXB0b3IKMjU4IDAgUiAvV2lkdGhz IDI1OSAwIFIgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMzIgL0VuY29kaW5nIC9NYWNSb21hbkVu Y29kaW5nCj4+CmVuZG9iagoyNjAgMCBvYmoKPDwgL0xlbmd0aCAyNjEgMCBSIC9MZW5ndGgxIDE4 MDU2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYV8C2BUxfX3zNx79+57726yz2x2 N9lkQ7KBQBIIgUhuIAEReRNMMJHwkqfyCCIqSFABiaioFR+1Ar4fRZYkYoi0xEr1L5Vi1dpqVajF Z0WxpVSFZL/fzAaE/vt9397MzJnHncc5Z86cOTM3hBJCrKSFSESfc82sZTRMH0TKm3Ddc1atjGxb 9vYqQugWQgwDr142/5q6x7+rIkTdT4jyh/lLbrj6lYbvg4TYthJSOG3BvFlzf/juxnRCyo/j/SEL kOC6xvooIcNQhuQsuGbl6lVO8xeI64gvW7J0zqz7nttcgHgC8WHXzFq9TP659X6AXyMeuXbWNfM+ CUyfTshwK48vW9q8kr7NziBeiPiMZSvmLZvSe/BLxG8nxJxEGsXDf1ZiIB0II6S2L0Uk/y+PIUUi MlFQXiVGYiJmYsHbtotK2i+KXRhxnI9ofZDzfMpPgEuAaQSYET+38D3ES3x9KX4SIBlKF/HDBZSn iV+O8bzk53DAV/Lz3oXJL3g+D9lXeKuzzxHyDNlFF5Jd5AD5DT2Jt3aTfRj7/6D2avIIWUN+RjZh dDOQsplMwaMg/WfUn+wgRWQnRr+THEbZK8jNpIt4qC/5JVlHNkjv4K0NwEM2qSKTyFJyJ708eR1p IEflW0kZuZxcS5bRlmRd8q7kvcknyJNkn/Q/yR7gLkDm4Dmc/Eb5c/JD0h9v3E8eIkfpvaYXiY5W WlDyF2QFeVhqlGlyfvJH9CCLXI8+yGQ8OUy7WRy1zyOfUx9dI41CLY8nE8mDKBUkjWQBeZh00cF0 DMtSGpLjk4eJB22sRq0PkTayF08n+RX5gFqVk8knkieJnxSSsRhPB/k97ZZ6e9b3VgJvCrCUT8qR s5T8mrxO3qJR+gpbqliVYkVXbky+C0oNAudcQZ7Gm5/Rf7Ob8ayTXpNHJ0cSO/ByD8c2+S35Kw3Q IjqRTmf5bCl7VFoBHirEu4PIXLIQ+H4QtX9M43Qvs7Ij0uPy8/IZQ2bvsaQdFImRn5NfkFeoDSON 0GZ6C32P/o2NYjPZz9kn0s/kZ+W31VkY9VXkGnIneZ78m7roUDqZXkkX0DV0E72HPkQP07foF6yK TWOL2bfSAmm59Ct5JJ6pcrN8q7JRucPwRW9d78HeP/T+O1mc3Egmgx/Wo/f3k0cxsn3kCHkfz1Hy CVWohdrxRGgWraU34bmZ3kkfo8/QZ2kHWnmLfkK/pP+g/6JnGMFjYBksi2XjibIV7Hr2M/YIO4Ln LfY1+0HyStlSXBosVUj10lL0apO0Fc+L0l/lgHxETgLPxco2ZbvyjPK88hvlpMGq3mIkxjfPPt5T 0PNxL+m9vXdbb1tvR/KvxA0aBoCFMKlA72fhWQR6bwPH7SbvUCtwF6AFdAS9HJiZSRfR5XQ1MHkb fZg+Kfr+At0PLP2Jfos+21hQ9HkAG8xGsol4rmLz2HK2ld3LOth77EdJlSySQ3JLBdIYqVGaJ62U bpC2SQnpTekj6RPptHQWT1I2y2E5W47JcXmMPFO+Tn5U/lz+XGlQfqd8ajAbrjFsNHQavlOHqCPU SepktVG9W92rvmtsAne+Sl4kL/XNeRHQY9J6qUZ6kdzFSmQ/+z37Pfh5JpkrjWfgVPYMvZ2tpR0s R1ltGM6G0wnkpBwDrl9j29lpNlwaT8fRqWQRG5Sq05AuPweoQn6VnJD3Y2y/R82rDVZ6M/vWYCVt lLByCMnfSgPluPQ78oF0lKryTvIX2Uy99AR7WpoELviVPEKpI1nSI+QFaTldS15kNZCuZ4xbwMcT 6HOQC9NoMf1eShKJTQAXlUl/I7eSxezP5ATm8e3kATpXnk/uIiV0DfmcPIVZka9caygwuOkbbKHc ytJoB2HysxhdOc2hkpJObqON0sOGb9n75DpyRDaTj6VfovdH2AvSePmkMoUuwAxYSzaS5cn15Aal Tn6bzicSnU5y5WOQbmukYjkL4TpIlQbItL2Y3V2QA1XSeKT4wDmXgy9qISEexvMg5IQMDlqIOX4F pNjvSYdhGusk8xU7hdQhRP5d7xQyI/kUeSg5n1ybvJf0hzzYlFyDGp8hn5K7yTN0Q+9NZBkJYeZ8 TC9XRrMjyuhkf9bK3mdT2baL6Qts51If+QrPC2Q0GaG8TFrlP5GppDK5JflHcHc/SNiHyGxyGTmO UX6DFi6VuklJ7wS2JzlaWobxHiWTk08nw9RMFiSXkIlkP3lSVcgsNa6Pqp1WpVeOuKRi+LDyoWWD S0uKBw0sGtC/MF6Q3y8vlpsTzc6KhEOZwYyA3+f1uNPTXE7NYbdZLWaTUTUossQoKayJjm6KJGJN CTkWvfTS/jwenYWEWRckNCUiSBp9cZlEhL83C1kXldRR8ur/KKmnSurnS1ItUkEq+hdGaqKRxOHq aKSTzphcB/jO6mh9JHFCwOMFvFXANsBZWXghUuNbUB1J0KZITWL0qgWtNU3V/QvpHot5VHTUPHP/ QrLHbAFoAZTwRpftod4RVADMWzNsDyNGG4aYCESraxL+KF5FNVJuzay5iUmT62qqM7Ky6vsXJuio OdHZCRIdmXDERREySjSTMIxKqKKZyMIERkPuiOwp7G7d0qmR2U1x69zo3FkNdQlpFuqoSTjjaLc6 4b3xuO+nKCp3jarbdGFuhtRa41sY4YVbWzdFEjsm113wbkYWr6G+HnXgXZY7uql1NJreAkqNmxpB a2xDfV2CbkCTET4SPqrU+OZFa3hK06JIwhQdGV3QuqgJpAm0JsiUG7LaAgF9X/IYCdREWqfVRbMS lRnR+lnVwT3ppHXKDe1+PeK/OKd/4R7NmULsHrujD7DaLgTmAempPAGJ4hwaN+U8ZinvUXRsQgdH zYmgJ3VRjGko9+YNJa1zhoIA+NVTvJWYC4osTJhGNbVqw3g6hkgTSq4WjbT+i4ADoie+vjhlVl+K IVf7F+GZnE/Os1qCzjoHJ+LxREEBZxF1FGiKPo4Q8cH9C1d1smh0mRZBAPSRScDtrPphRUB/VhYn 8B2dOpmNSKJlcl0qHiGzM9qIXhSvT7AmntN9Lsddy3NazuWcf70pCk7uEIqpO2GMnf9zaJ60mgXD EtTz/8iel8ofNzU6bvKMukhNa1Mf146bdlEslc8RCrwhrw9KpI2qkzIY0jjEMiSRC6ZsmHG+CCJ1 1oSciz+DYOq5naoRXClSaGR0Qmu6NOXXm7Oy+ubM/++lzuRJ/pYIfnqtbxiJYfG+jqa6nRh+Ufyi 7llbpXHTIHLYuGkzWlvNF+WB1VK9HNsXgOPJtLqsyKgEqcXMzMVfZ7J7KHf1GQkdKEPONMwikVyf 0Re9qGBG30v1+HHu7F84GjKztXV0NDK6tal1VmeyZXY0okVb97HfsN+0LquBtEsxTmey646MxOgt 9cDYAjoM04ORkXwaj5pW1zdyQRbO3SATX8QhkrmCqvB9iUpGdjB63KB2sof0NKLIxyViVuXjlPiN BuU4k/Zj4TdBDRxAfHHtdEVPxQTtVMX4ngpSCVg7C2/QwCxnljMXHsWydzYidZ/VFXKGRORuAgbs grcJurdEcnUfqyBmVjETSvE6KFfyDuTvkHc+yKtubDxBKk8MGlgyuMTddfjwYfST1CY/l51KN9FI Jq3dw/iYdHMgJCvpIZvNa+pMftHhcLBaDuh+mw2Qk1h5CvFYrfCtPI0UxePxw/AOo37eQsYew/+u 6RRqMvCaPuuw2QTwje63WAA5icZTiGa1cp+nna/ypzo7DBG/FgTrtbGI5dcQex44F5wjeUyfLRs2 sdsttzvesCsm1eJjNWmXuy/zj8qYltbgbvBPyVisLrbMSVviXuxvyriBXW9YZbnRscnwoLpNe8P3 AXvP8J7lL47A+YE3m/SsaOlAEyUmzcRMW8POZgJ20+1IjWALxMjW0Ot3CKTGTwCzy+MctXzotHE5 tjhD+Y/C1denaa4hJcUej8utMUM0Oy+WpnlKioc4tVg0WzXULn5nx6q2lSMXvbPz3Rvu2ffsmjXP Pnvzmssa2TtUppf8cmZ7b/KD3t7eV3c9+BL9Re8D357EvmHRNws3crofBQHPgHZmsluPSLrNWbpY XsfuZg8Z5V/K1EQMCpNMCrUyesgsem/mYyI0gnc7k8c6NA2k60x+pTsFQYOCoHZBUGBZ93NynaOJ oE/Aqug2R6lyDhMDFRrBXospfksXraAbwMATtONABpgNHMF/iKR4udJbTp3lHD+kMZ4VdRoM6uAh Q8pK2JmOqnemPfBJ0Ur5phFrwi+MOTSTj60COpyKsYXo6328ZHJqNl9amqHW1pk81eF0CuAb3aRp gELpSoizqJcXCIV4bihoR04IDAq/k72sW5nZ642ENSdjkbDTVV707mHuHyZFJ3hPK7l/EMpXRt80 4A1aXS4mGtRNDiegVDvHdIsrjdWG0nkar7sNVfOpYrGwWgBf6wKL/601Pkd4e7w10Zg+ZLgy3PCy csDwsvq68Y2gOtZab51mX2yda7/RdWPaZtd+16eBTzNOBqwHLC+lsQwtqGVqIc3wa2yMVTC/EaEJ 1AqEzJrRYDgUDKQHgwFjMCBRZgwEJVtI62RPtE90Umcn9b3IR0AEOhyUWc3N3neAbc7r9GW2HpYW jQ7Vrc4XK7GBXcrWMZl1sRwSpnfvSTH7KTB7vEI7BW6HXKo80dN43OnilIW3yT4gbl+rHUQEdBZT gM+AoaSRNq6or891Z8XKQPEhQwaXgvUNat4QPi/c6eAE/Mnq2TLmzX384W+feeimWx6h+9K+/8M7 py99+jePNYR27aqqmNN988FPr1583yOtaUfe/2pX3XP7n7h9Ft8xUTI9+ZnsAa/EaX0f6Sx+n875 2BcklDNr3IoIzY+abQ6rI2Q257tDQTmUH1TybVGb1eenxBWB8GG1ETXG6ciLx4q4SDtcxB/iKq+s 1E5oJ8AvJ17TXnOVawfjxdyBXfR+is1jq7FttMk1ziucqzKkKZ4l2qL0uZ7rbDekb7S1pm/OeNJm ViISJp1usVhtdlmlaJdywugYwMvYXOQTGx3cYbW6ZV8Xe4L42QI9D71U0E2bq3lmZGmERXyclyMt anNMSKcYJTEtxtDjUy/xnNjW/r5OOrTN/w7tokNhcOrWLT/Jq8JOem8fFeMnBB251DoVF4sCKAlC YnCaoGiKoJisEGKYr3R5fVqZh0stQTq17Dx4joqcjKoHPolmx6Z3hO9fvG73Y2tLLk93WZo7Ny5a uCW9I+urF1YfWnz13Fu29n7x3itJeqvvoU2JW9bsTH+UrV4755bbbou8+Pr8trkzHxkQ+tVd3b3/ +gy0ZbAaEFlTuiDjbDSmD3HVWRdYH7Y+a33DqlwuXW77mSy5wOfEapBUxWyRVGLFhD8kyemSJEs2 wqw2WZVeZi/DpMPoDt1MZBlFyCGz3MmufklRzHpmuNR8ThoC4IsTqwXwjVilzJ20TLepena0VG3J GqxudTDOUBZbeilhGoswCfFj4h0Ax/dyOrAX7Z10i8D115CAQhie4iKmQvtM4+t6JRb40xXOco7m 8vJNA+Iypo3D4QDCobTtI7bkx22ucsi5d3VLSbmU3b9ckjMzK3gV9SAHyujpVt1Sbm2ZVG7VY+XW 7CDC/uW8QLweasJgWuIscUedkpOybT23sV/c99prHb2D6cwnpb1nL3uydycm9v09i8F6fP3PUp6C nJ2emjv7CMX4bBwJNGg3h9zuoItLT4tDlkNBm50S1Yc1Q2gFAhDzjK/9fJ7wNRBs1HMQc4NPjXyX kL8O4Y8L3JDZmrkt7em0V63vWf+SYTSl+ewFAck0UBlo6YIskzA/tDSz25WWdsjuSLenpdsdNkwS PY13RLfvsDO73aG7aV+nXnLI9B0+gSDZ9AjvnnOmtlRbp92tyRqmiU9MEx8lPs3H0NnUNPFtjbj2 08HEQe8HUw1ts7/436ZL+OLp8tOEaQQBudwTA210lhc1QjAc32QcEFdARSKEn5B7dHkjqHHhxMFs SctyZ0mQe8SdrkIbiNX+yv3Qkls6dm25Yku/Z+9i7/e8NPG2e7qpceWdp/6nh7ZorXccfOzhtomV HvbdL3tXNfSe/sPr97Qdw9TA3BgP2rkh9zJJAZ3YJ/nCDhj/Z1KJZvQL6TZqs2FhzFCyQ+k2c4iS XA1ISOlxWsir8WXfK+SeFwQC3KfHHX73sPbbc7RsPKEdbOS07L/YT6tV3V3tr47McE2LLJbmqnON i1xzIyuN1wU3GDcG3zO+63GqET4H8lKzwlAbFUKPJ2WJDJVn5EWikSye4eS9nGRj6GcGfWcmJyUE n+lcnynEme4iL+Y2a4KUGiUatBaM4uRLXFfUthaauagL0XLdU+md6V3qXeeVvVBNDbVeD2/U28ly 2uMpVQ1z8QRfv4TcS+lrKWlX1MgVN75W8QnEJV49VWN5QkEzqHyZcvFlKppNnFoZYh6a/pM0NEhn 2n2FYxdPr6qdzar2z+/ouf6t2/7ae/wXm7/Y9VFP2cS7Jqx44rGbbnxOnmpfNHD8wBHffDinqfff b7eeuBlmvzX02Vee+c3Zjxqfq+989MHdu0FXCusowXr2NOz2y3T7QRuV8ceMsgnyjM/EgYzKJqut WZIYR8pEsVRLLOAwNpv+TiaC+jOZVIlgKV0HJdIPYSQEP7YVjcsrxp86MUE7zbUyDSjgq3i5U8gh YGB5Y9rgLLeBSAY1OsTlKpslvbil98S4IY590i3/3Cz/uGvL/b2u3jOdf9lFv6KvP8J3N1PBg37w oJdEyUBGUlzYYSUZoQFcTkIfY7UDBriyQgalX8hlC5msfJnFJuAURCWAuAO0FMIEQEqB4oDIdPiw Yp4UaqoAOLsC6GNgKcdt5fqWW9ToFgzs7mPg1G7kgi0JZFL8RDnUkr6dyUuiI2ITwjsCgHfkuNih cECk9bXP1WA0e1bP5gV5s5y9eIPc5yP9aXznJg3aokImpnoi9kZ8DpUN9tB8z1jP2Nhn1i8HKqaB MM2upWvklcbllhXW62w3eu8grXSLvNG43nKbdaPtTu+bztfSXNmYK23BSIAHkUgRD/pHsO4f00P5 ESsJ+YgV3dgxgP7Uk1DzARM1dbL5uhZvdugRaP4OShyagzk66T17i33NCYlKyG/LaXafU+gjbt3N 3FsHnd/anMLsB9dAT+hTE1zljUV8cHzh6pszfN5Aw1tOltfX01hscCmfIRfoAwQpaemec9qDQbpw 8tBFy5Z8dqD7q8XXbLqz9/T77/eevmf2xsULNmy+ev7tw8Zunbr+mV23rHtaysh/cNGOD47uuPqB /MKDt+9PEkq7736FTltw260z52y67Wxy/NaJT7Xc8twzXC7yNY3zZAhy8YXU7uElSxjLQK4Ti8Bp QWS+GogFHsBJvR+nqM8pSOoUu1Cnz1kYt/QLOexh+0S7ZLenk0mUCmXSpmF3QflqA7GqCIofjDcW g8UaTxQLxIDynBE1Lkc/+i1nOrGxvqATP62feoFYQJ2Ci/8vrV7c1n80hZZ+akgvHRa43KNHr/Rc Eb1aWuK5JjA/emNgbWhL4I7Qw55nA/sDX3k+i5yOpF3iedSzyyMNy59rYHl87Y2CmXxZEUOkX2ii fSZfaIN8ePSdSSmh3ME7Ee6i5cQCmey8eGndWsgldQcX1M7zvOTUncy5tU/2NqZ0Ts5KXPKeXz/P CV7SuJw2YrMs1MwRbHBpHpe3CAmYCRZvvnWOUbFxcAteWrbLs2bW1LWThtAhL1+z9yxVX7v7xE03 fvfYLz9gv3ty5eq2Z9es3Umnajdee/m6Py+z+qYvpsY/H6Xaw71/6/1H7+e97S8ckEp/vvfgI1u4 0GU4RSN0I85rub1mKHQJnCWrJmaokKUKapBhUYFuQ1gEuNhpFNYUzAouP7EnECQX0yENhhUJbh+M K1L94cNnn4aRheFElSj10GFVYqfz91K7A/tuKIv/6OgDvheMiJRTej1nRC4jDbWK8Iu0gdp84wJT k3a7tFV7Q3nN0K2d1CxGpR7HlZO0BZaE9k/rP23/tJtkq2yT7RKOBRRZxh7DaFBVK2AjzuVgjupM fq87xA4/olrTkcUkCLXvdUgzSNWIbE3HW6aQohhDBsnQyZbpJmK0fqkzylgXtWDCWXSXNULmqdKU STj+OypLW2Uqd1KqWyZZu9WjVmmrlVp5XHOoR1S2Tm1RmXqf470/wUwCbPnh8OcDxgJ+DVzgq6wI nKg8XqGdwN8mZUA8Dv1p0wCfCAVSoSFv0g4etB88uElJhRA54xKWqeMSIZhNO2SHZFS7sAEmye+5 FKqnK7jOxX9RWkKjUpaUliXF8gyqxEr+wOo+er7n5zvfp989NDo7WKJ0/Tia7u+tZjPotn3X33kH 16koztqJEgatTHTtHpeF87I5zV1q9Fk9Yu35Qs/ikBHIi6hGoNHIVEkymmTGTKpRliIGA6wjX4sF DcA/sFHAKqe4OJIR/7ce4MYtpTFioRHLJEuTZZmlxaJYjKYIN8lA70ZjnMkifbYZLqyEkea02GKg zI+6RVBRFlYyVIk9I8w0nJRmviKRRvPwem6YSuEB2w9uRQTqebxCbD8qKivArrDGlG+SB8Q3rT2Y kpH7uP79ktVZaozAI9BdBw2ENhTHdqPDqI8uB7t07x1dbtSLU2BxuZrtLwfbfrzXD7A4BfLUqAB1 S7RctafDpfH4qb1pADNTYCZANwe/3+NObVt4S+KHhtE09i/UWeKMUucjr0us6/WzvUrXmfXyuh9H yy1nWlK0aoCc/7vyDvQOt543R5ojN0srZTk3b7BUHhwljVUvz6wJV+eMzpsq1asNmVf025xmj/Jp x3Gbcw7IPQdgOU1lQXVNASgMtKcKpwAUTgEonAJQ+LQ+mhfqZ4vlsBwpL3eIozRanVtTNCMyPVqb u8SyyLbYfnX6PN8NlhttNzrWatflNOdulFotm22tjju1DTm35t5r2+bY5g71Gbr6Z8VcGbGAKZZP Y4TkB1xy8aAYLlMwYut/Q8bmDJaR67H1D+Xl0lzFA6Y6pafkRai/KRTySGJBimN9boTrCxoxnbzY 3aceqPK5OXabRckKZoYycIiIM0QDzc3JRpoBqnf/AGpktXcHaOAEbmaIRU9wsEYjdBIOY5bRrdQA iZ/Q0/rzJhU0jR5fZoqRfJrPd4d2O6sFcEq38ZryA8UYE425+NTgWQCAPswMAH1iCRsK8L1/0Jwr uRHxVOP442ADyAooq9Dbx8NiIQYG+0T8OPdO8RE58cdZGSCYFWuI4CDhwQ6bVhZi0Dq40SIvlpMn VBOum3i8agy6vcGd7vVgsyBMUNHsnFjDS7aZ/7N26XNTJzUM710yeeH8m//xs8d/2Kh0OXY9m9hZ PpS+X9dy48Yzv3i9958P0T9p1955xcjm6pr5Ue+seNnj85a+Mnfhm+vtd9y1/sqJJSWL+w1/cdV1 R5pX4mITlyt+3LdaBbnio3/RY/kk5sx3xXzlZIiz3DXEN5aMcY51jfHVkSucda4rfNqDxgcdrI8d SjQa8MfdpUqptVqpto5zT1OmWa90z1XmWhe7VyorrTe5HYrbKhHqwu0LBzNCYmNhwo9jiFO+vDxD D0myojCDajTCTGK1mmx2h8OKs2SX2+P1+aAAVrTjQk2Eh1aXk4f6DDfEElFgLaUknWITrRiNIbcv 3e32uawmU8jtAuhy4jQgojnTNc3pMlmNPrfigAZFGLqkSD5sMU0mo5GhTz6Xy+kkxoDXG9CqTHQy jI1W+G44nSh08t5IBAqW399J79jzTIoHAv7xPQFfT0/A3+ObUDOv+jNYHTU8KZ9DGCHF+PgYhYNI Gy9EGl9HINkuDsAYm+xYSOBVcE9AF3pYXBxYXJxYXNpcZq4s8kVlXCIXiQVIhJbAz5xIag2yI6Xd qis6N/NjZVrRmEVL0jzeIWUIXAjSsAZRvvxQ+mjvTa8fzQkMxR2Nr96eGA32/+zV3mtf7v1dnupN 731D6Tpb+cD9f8+RPu4J9H79zzs6pBcg6Bq3ROaNOfM4+IeRy5JfyEF5BG4alLH+eqHJZirw2wIF +baCgnLbEHdZxrCCsQWNtsaCRbaFBU0DW20b8x/2/DzwrM3dL7WvEltynOHwZeMp/3P99vpf7nfQ f6Tf2+6P+hmrPRTm81M6tFBDrQtz/Zz6MZjvMWp5POwN++KFBaXlcnnhWPnSwunG+vjVxoXxVdZN MMb9YPsh7iwrtVNZK8op9RZnpftm5i/NZ/nBInul/W77dnvSrmy377Z/C11anB/ZuZjgkhjAKd3N rfh2oX/bDXzDBfVTwt79ub2++2HPVrG+ndIDYqWryTMXByVL/ixtFjFwGUJysyDNvz4n1r9Orbk5 Mpc8yDgurPIATgEw8JQPdQtvLkc0hPhZsYTmdLIrdXuezm2qkdjA2O6YUo4VT8griPv39nLBFRvE 03RbCNup8u5ytqOclsPgf0qv4jV6c33ZRTkHDEcMLGyoNDADJhmrNYitqcHH+2MQW1buG2oNOCSA L7YbhkFDf1qxl0PYxbFkx7nkg4W271fRE//0Uy4Ej+P0IGWuFTlQRJeD+Tn/CzHPBSHPEPYnsjyX K9J8VwbTO3+gWnPhp+aNgHCELPS4oVB7ozFs+u0spVujkFQxd9+i3fvHNF86ePEH82lJze3rbshM +K59a/Ptz03STN7s/UHv7INLG4qvWbjgsVjmrbWjn98wYf2EdLstkJNrvrb/JfXLfcvvGKfPumzA 6pNnNlwylH7UL6j1G190adOVEy+5XvD06OQX0lHIRCc/e9SfMDPZlmsrtVXblMHpg4NXsGnmKelT g/PZXGWeaU56U7A7/K7yx7SP/J+mfZr+rffv/k8zj4WTYU84HA9UeCoC4wLLwlvD6gCWYxvgGcYG 28axGtvo9LHBK8zTbfNtnxo+9/xIT9k16pbsFs1BMoIW1UnMbjCTr4RvDh25mvaWk2rYuDQ5W5xy GMZ6VhsWJwlOF+dVbG4wSThRnQbODk5Y5EUqFD1OUqedswFKfSNYCsD3+khOZedKV84BaMVH1aQq h9VKdaIqqSFevSr4QsVpK2DBF6qYBqrgdtUfKp0khGGKCRqXjz/RkwK5D3sOjI89Fcc5W+A4phJG ZfAB5wBQnyzPGsxpD+KLI0gvFCpYrn7aiA+dd3DdH69b9O6tTduK2nsiv7xu1ZPP3LR658ZHt5x5 fDuVWidXMfuPo5nrzUOvvPbBmwe5HBoHORSCHHKDZlN1b5gE3VCMG5VGU61lnrRYWWqaZzFiOTku 9jRAwHF9CkdAZpD7ea73lR/TTwfkQa5h/kHBKtf4QFVwsgvns0FcMg7MCq42rHafZqd9Gi6xOmxe 7yRPk2eZR/IEHVu1HTD8aXJG0KySLvYcN1OLKS/UE1gFYQ3E+nF/WlC2eHXYzj8UCgaAlCEfwFeC KAC6dVNeQWkC5tFAGLH23FgpD/UqPq3DNOwp0XJUPaeg9BylIhdQCgMBpeyc3CqOTOF7+NA4pcou pFR8fM/xCRo0Ehjb8Buf2vbG432G44qe5RVibebkEoeifMauoF4+XWFnxL6XONPVLGFopFnCGmmQ ruoq/Gbfl73f0vQP/4h7nme/MLdtmLOl5wM22Tp0+uY1z9Lp3sc7YAGWcKmyX+/HvT9okd1dC+j9 G0cteErMOdyxphWYc3yfe1i/yjSEj2yiaatphylh6jYdNZ00qcQUNi0ztZi29yUdMyVN5jDOwnHP ECfKBulmirNl7IoNaq5C5O3yDjkhd8vHZEO3fFJmRI7IbyEmy2B/QSIAP+pePmGwx4QUlM28VTmd 4xB5fB0QQK9gGqSc1c0cs/IE4xhw/3nJCH5fgd0MN1tWprbdXOhx9K1YHhebb3D47R0dHfLfjxw5 45ZjZz7gutet8MrEmP+2VxEDhtbc3V42VJxkt5cOToUDB6XC7NzUCXeu21vqwGZwu3JUkSfCO6lI YWWZ0qIkFRk7ajOTcsWujdeEBapbd5cMLt1OaDc5iZkC/eYtcgz3Nc5hAcCPeibHAhFYIAILRGCB GDkKUCKFAgDJc/u6PlyQCfLFuODIwI5OoIOjgMf4Dzsn560dfHfLx74Jd/5jmK9R+jo/V0rZvIx8 MeRMCzvsn/XxFltprnxcPm76q/fTiPJH5XSEeY2RqMmXETFJUjQUNLiDIJVKDVHs3M1v5dKtuTty WS40OXvuVhwsy0I2+oRc5KffFiEb0zmpIQFwKs/J7WRCQlqFhBRLL/J+PC8n++QFbdStvtytGTRD VJdxvroMUR3i3+hOXl2G2ABnmHl1SO3lqz4g6BYinlrTMzpRn4ewkmgufYvQrWQHYWEYciaC//k7 KWrg8gloIs5BiFifiYd3FSXOCs4EcEpPF7chBFsSsXATf05uJ13dnsXJEp9wfpkWTIq5r12Q8tMi DpndI1TZ5SugzFZUgJVhiNdOYCfDpQEXBqNu0O1QzWPpVmcGddncGRQn2/H4+j4hwU/2xMm5V9hZ nVFnaWo3IyCs7Aa3c9PO4qcWrXogfPOhR59rjzaMWPazjrq5l68fJsfunzBzdl3X7r09eewXS2YO u/+JngdY2+rVkx6+p+f9Pn6RPgO/eOhaPU2RDGnsGa1T+5v0edpJ6XSaAXPzpF4BhrlBow9qb/mO +ZI+OWJMt6d7XEEFHOKxmW12qz3Hp3Oe8IkV1NKPw5Z0zhUwqXytOznCLWISWLI5MZF6KrWCWtI5 QRH/IUVQi5njHfHTsD5BJFj0kiGlSQvFn2UCFPRuPVA6pDThO+ljy3w7fAlft0/2wdrj9oi5eRoX RUBbzmi8DxxICaKLpuA5W8qPfG0H4ZlQNGXOUHijW3ehzZOYTOen9ASvuPOTmnDwMQtPcSNLnN8E uvAH0xa/xwU7IQ5Z+ojrMThNZqNZNUsGLQY9IoM6zK4+IheAyssJWEhQuU8/u4DEmx677qOmnZM0 c0fB4kubn5ZjD+yuWTa+eG1PM9t47TVV977Zsx9iHl3dgMX6NdDRSd7QhxelUU2mUblUHoWPCq6W V8oGk9NoMppsaU6TjUhGagny6U3Mpn5bjdSYHUmjaSzbmRJvuvafw79Aon2vOy+QaAZOTKDsgnnj ERg1CIwaBUYnuMYcvFioA3/HtcZTK6DGCEzhRCp1wkC0NzbZ1x7k+swK2niO87F95wos+HzDYyMW Vl551YiRI4dflR6SYzuXXzrs6bwxlU0ret5N4aESOuYe4GGg5NVvkrPTs4eZLjNV50zPnpe9xnSX 6bacp9KeL/yNZDN5Az7vwHGF73mVDFhnmVZMzb4GY4OpwdxgabA22BYZF5kWmRdZFlkX2TpiHXkO blLIyR+SM8Ncb5kbm9tvZXRlTkvOfeZHrPf2e6Dw/oFPmJ+1Pp73RL/22G9jHmzCUhI3+xwA41Iq JeccIMpwPIkyHBBlOCDKcCAT1jbdFSqfYczLtZrlQCTmli0DMgPYKenZ/kKO/rC/0j/RP9O/23/E b3D4w/6l/qN+Oey/28/8vwJ13OAMoT3pWHkYlCadMg1fhjBCNcq4NtWe7ilNaVV2ZymlAxoyl2Sy zKBbxeznmygs3fyeBJ+oHNDTOInl4ABLGBajHL+e5ist5tOmiC8IfiHH/UJR9os7g34YNw21/gh/ yy92P36hQfmxAWtTcwrw6ovB8rcKKKDPsD6wWgCpa4gC4HgA8JU4oysIiKayoM81FXcXs8rilmJW zDXBHCLa7LtaGElhGTd8OMA7wIHUHbdIjgN3DlmtQ3TPgWNqwFxSoIuA7LzB1A0GR/ZRQvnywWCp 6lP3oJL3SXp+gUyD0WrFhL7NWzy+HHrfT+vACch8XqjyxHJ+IClWcG7MwtLNb9/gr28DhyVAz+sf iirphTGn5tLSNMmQbYtkEFM/NYMq/eGF0hHNskczSDauEhnzzRm0X57JbIjLGSSsZXJ5EucWkpQn bKsF8fXr1wvzqhBR/MQF9vLzFxTyYnn4pqYUW8T/NJJ5Pd4QtoZiI1nZ5th805rVg3Pve+2hiVVD C+6ZuvZXM5wJa/PCNYs8nqKM2w48MH3ha2uPvE8vCS5eMa/6kqgvt3js+gljbugXjl9603zflIYp ZdFgZpo5p6RqTcOM7Vf8ksurnOQ/WIHyEM6R/7wPXwF2t0djpdBOoJMDaMEFLWq1malEPBpOas0G DzZtDi2bZFObK9dKk6qxxlTTpC7DmcNWVSZqRN2hJtRu9S0V926xA+DCHwC/giqAf4htPVL42YtI +V5wGlL4SgF1ni90Fs6iqpBdiH8hVBS1iy2CFW/InqsvlGEg5anjOMiAqf34KX5BhB+sw7ZX7iwp 0d7g6lk8nutNbcac0cElzjJxP0echDItcHnF7CWFt93W/uKLafF+oZ3btRHzHmNztlB1Se+dW3ru G1+Ia1BYfohkPdxROHvKTEfFv4wZRi7hyG+fdl56Lkz2JD+DlRFX+vANJC/PfwjVEb0TyCiN/Li7 t0Qbdj4nlU9I0IAk/k0RXJfcTGrhjsJVwE2HC8DxtPFws+DwXRqpRdl9yvRkj/I6eUSZThrUO/G9 YzO5DG403Dj6Orkd7lYDvjVCfBNkzgaZkEq8l4OGh+DhXyDtYHulJ+RpSrEhZFip/tr4Z5PB9KG5 zWq09bPf61iiXa695qx2NaTpaQfdD3rwlanofRCDkvCFooKJqOFrIXxdKtvw7ajE9W6UcPWN0YDv /Mjo0bXTJo2KV61YOGvJ+GmiBAol8/D92X/7BZEoYd3kX3q68WUi/75TfNmJ79cy0fdB6PkwfH05 hlyKbxwn4rvKyfjKcDq+QyJ7pjmqsiUv+RYuCSeRMPwiuIlwM+HuhtsOZyCOvpSlCNfBHYA7CWcg uuRtu7dE70RwhwjaFy0pFtFZqWhDo4i2X1GfCsdPToXVY1PFhqWKDSpNJQ8YmQrzClOhK7e4BZW3 m23F3VXYW5O34BhZBp+yg7gWRfG11Q7JTRJwTEJXRYouudpzYsXbD0gyoRKTKL6ODCe7JdpmcxZX mVmSfQu8h9k37EQqh51otzuLt1ddxj4hu+EOwEnsEzx/ZX8l69gxEEmDXwm3He4A3BG4b+EM7Bie o3g+Zh8TB/uIFMFVws2E2w53AO5bOJV9BF9jH3KSC5/DlXCMfQhfY3/BsP4C38E+APQB+yDZzd5p Kysv3ieAeFEfEM7tA7wZfYDLU9zJ3m77IT/cyf7WHomHd1QNZO+SBBz4DL4GF4GbBNcEtwzOAOg9 QO+RFritcDvgEnAGvPMe3nkP7xyCexPuPZxevUd0uElwRvZWG5rpZEfaYiPDVR58Svg6GDDMDjP+ KXCYvcleE+Hv2G9F+AbCENIPsdfaQmFSZUE+wTsaQg1hEfIV9kp7jiucrHKyA0BSGH4RXCXcRLiZ cHfDGdgBlt02N+xCJS+TQ5AuYdZGvhThU+QxI9EXhfXYKPBYhHuxYZcAgrc9sj3G9Ni2hxDlXuyu ewFxL3bbFkDci924HhD3YktWAeJebO4iQNyLzZgJiHuxidMAwetkj76Ukxcum7iYRqoc7Hpg6Xpg 6Xpg6Xoi40tVPOQHyJMw+3lbQQEw9rAezy8It3TRlv20ZQpteYy2zKMtN9OW9bSlgrZcRVvitCVI W0K0RactL+PSGCUtVO+4KFqu+2jLIdqyi7Y005YYbcmlLTm0JULL9E6W1TYWEwtBjQjaq/i8Ylnt l4wodqCPWcBoFtg6C9P+APwjcEkR01Eokp0q7A/xMLu9oDIVHzCseGnVpexVvPgqyPAqOQong0Cv go1eRSWvojoH/Eq4mXDdcN/CJeEMKJ2NcdwtfAf8IrhKuJlw6+C+hTOI7nyLrjCyFD7v4m7RsSL4 lXATeYy9iod/CpzFsvRMXDOPa5dKdwepI0QnhpIhVkY8HohGl9OIi+S2vf+2ff9vGzFVmdhd7G4I xjA+wE2Fd7f9kInbkw+2xV4OV7npAyQEa0mYlpMYzUU4lDSL+GASNPL0UhJkzyMsbgtOx2uOtlgh rpnY+Vt7wz8Ej4e/DHYygF8EXw7/KdIp07bwH5Hy/N7wu8HN4TeKOo1I2R/DxYO2cFdEFN0XHBre dUgUXY+Mh9vCN/Ngb3htcEx4cVBkzEtlXNWMmO4IT4nNCF+K+qqDs8N6M+rcG64MXhWuSJUazN/Z Gx6ILsRTYAE6mx8UjUZDosLask66QC9Ut6l1sO4OUYvVQjVLDauZaoaabnQZNaPdaDWajUajwSgb cWfZmM4PV+J8vUo34D8PwKgGhqa478x9DRKGisWKyzVqxBEQSaRJ49i4qSNxItU9h4ybHUmcnhrt pObJMxJKdCRNuMaRcdNGJobGx3WqySmJsvi4hDrpyro9lN5Vj9QEu72T4jupTprkSRsy+FeMuO9L nRvuzOBhvw131tcTn2dVpa/SNcJZPrr6v3hNIrGp+oJtLuwf53++eGZi27ipdYnnMusTxRxIZtaP S9zHP3Pch0/PT9ZU76Pf8aC+bp80gv6jZgpPl0ZU19eP66TTRTkSod+hHDgGAcoZQyTCy5GIMZQq 93CqXC7eR7kcHqCcyURyRblck0mUkykvt6c5p6Z6Tw48lPFGSLMo0+yNXFjmUC7K5MJDGU8LOSTK HPK08DKJEaKaYBBFQvBQhOJ7dlEkSAOiiOj5HlGkqK/I5vNFNouWpFRvRBnuoRrbsXNlbMdQ5jwa /3/AvJEwF7cPr5/TUINPRJuiNfPgmhJ3rFrgS7TMjkT2zKnnGfhSM9Y0e84CHs6al6iPzqtOzIlW R/YMF+/9R3YDzx4erd5DGmqm1e1p0OdVtw3Xh9dEZ1XXt4+ZVFp2UVubz7dVOum/tDWJV4abEJE9 Y8R7/9FWGc8ew9sq422V8bbG6GNEW0Tw+KS6PUYysh7XT0TYzixm8GtTRlb9SI+2bIRg3uFZvpsz uqCQPEMs+HTTio99bXCcr/tX9a/iWZhTPMvOvwPuy/LdPDwro4s+05elIdkZHUniK69rvo74ahZW p/6a8UPSyus4MVJ+nKf91x+K1OCT3urmlQTHwwU4MK7E8fAeVUVqUzU/Mh52Ls1iqcHOJpU4AInD eEFJOl+Qp1XwNJOpr+D/5gbRJySL7wVa2MvtVA/RlaS5XkqExk1jEAXTZgAN+B60C+oSXySa6zHA Zhqnzedq4+OI9+0HCYbcfM6tvK4P6sPDyr5QvMhfaT6HjnNVxTmWyP8BaYC9hwplbmRzdHJlYW0K ZW5kb2JqCjI2MSAwIG9iagoxMjgzNgplbmRvYmoKMjYyIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVz Y3JpcHRvciAvQXNjZW50IDkwNSAvQ2FwSGVpZ2h0IDcyMyAvRGVzY2VudCAtMjEyIC9GbGFncyAz MgovRm9udEJCb3ggWy02NjUgLTMyNSAyMDI4IDEwMDZdIC9Gb250TmFtZSAvRkZVVFBDK0FyaWFs TVQgL0l0YWxpY0FuZ2xlIDAgL1N0ZW1WCjAgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIwMDAgL1hI ZWlnaHQgNTI1IC9Gb250RmlsZTIgMjYwIDAgUiA+PgplbmRvYmoKMjYzIDAgb2JqClsgMjc4IDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDAgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2 IDU1NiA1NTYKNTU2IDI3OCAwIDAgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NzIyIDAgMCAwIDAgNjY3IDAgMCAwIDk0NAowIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCAwIDU1NiA1 NTYgMCAwIDAgMjIyIDAgMCAyMjIgODMzIDU1NiAwIDAgMCAzMzMgNTAwCjI3OCBdCmVuZG9iagox NyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9GRlVU UEMrQXJpYWxNVCAvRm9udERlc2NyaXB0b3IKMjYyIDAgUiAvV2lkdGhzIDI2MyAwIFIgL0ZpcnN0 Q2hhciAzMiAvTGFzdENoYXIgMTE2IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRv YmoKMjY0IDAgb2JqCjw8IC9MZW5ndGggMjY1IDAgUiAvTGVuZ3RoMSA0MzE2IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4AdVXfXiXZRW+n/e872/j0w2QgTjYTxiKgIAmypfA+GaQ40Mc SeUExgpxkw9zFUJxGZkuMm0a1yJdZoBki/xAA4KKFN0SlOvClRVIpulE8oPIbOs+9376R1f90Z/+ Xna/59znec5z3vOe5zwvCAA6Yz0MExavKKtCNkaTaeRfr8U3rS6YU3/Pesp/BqLd5VXLVpTlVS0B 7D5yNcuury6f9vLGNBAPpz65YmnZklPjlx+gvpr6yAoSWblty6nvoD6gYsXqmztsRjn1Q9Szr69c XIbzeCF+kXpqRdnNVdk9u3yF+jHqBTeUrVi6YdYb7wIJVRRWVa5a3XoMu6lfQH1g1cqlVdsGFuVR LwE63UEu8PJfZ6T4Rx9iWlCDd0IUOkfpaBbuCxHO4HjIjrJxOIwJu9DEe314NdRzxhq8jTUhstvR mzMidA2d4yLrSNuZ0AO/x9G4Bfsp0xbSWIcReNIO0t9RXv5bgHU2y66zOuTjFY5EXGE12B+2ho1o CU9hqtViLZ7jyLVYa02YSq/P2Rh67BweDlvIn+GFuIiP0jU6TA+bonxsIteCVmz3K4zHbbgO5fFB bEQlKsjvxK/wB/7ttAqu0hLGhS1hEGPzONNhE2qjU6GW/vJtps3FLjyIB6M7iTtxkCveFW2IEY/C k2FDiENXHCR2CydwGI/FCHdyxNz2eIlAS3w6rm+/qPXmWi2oxWNoppaOT7ZfuDdK+xj0I3+Af7xS PVKlYRdz0BSqo8LovrAIJ0I1muOTtKZRx2tV3JHyI3gklHBuc3QrNc/pWkl1qR5xR6trv2gdF81P mpJxST6aQz0z3pzkJ+lQE+60ujAKL4QaXxVbaanDUWtK7VcmN4XTzH99GB+KmMVqZrGa11rlcbtl Yyuupb9F2BsVet6i0+2ZC09FOTYznLQ0Ngc+ZXIj304NapIbURMdZrQ7PI/RpdgQ90CTjQkVqIya 0RvNWR7bs+idmosDWczTR9lrxulkBatvAdc7P9RGfGLWoz9zc8+8dW34KoZPyEolsUUBQwpyGqLC GUsaJswpLXh6YXrokP9QC3KyChpQ0tClumBXW1tJadwnWdiQnNtghdkNcWH/4//LeHzokOKS0oJd 4ZopkzNup1w7meS8Uq7Af05zuSmTh/JVIEJ5a21cnjzAjpGFvAkdYqRCdhLFGNb4UuMI5BxpPNI4 vHtuOrcwnZsuj/HBKuvzwSuttVldz7y9MjXIffge5d+ihS19P3vW2PdCbrazOPCj3Okf3T9cJXAn +3j/8Z7KbuXgVO37+99/JjX1I0u7ndHFTdwXTVLPAzuLRkThYsb9ZbaRCDmYgFwg67VO3+ITtEfS LeMnhe5ASfH8KVdPHDypcs3Kzy1dObSo8no2PH9u/Vqbvf/8l5/bDZjYFq0PC9l7LJSiA/Fq/BGd kPCeT21BuIq2JCxAX2ouW5jPnZtDbj73o4V5uIg4F39DF3Jzpc3B++Rmh1kYRG42llNz2UJxmIk7 yBWzB1DDPsRhZpiBheTcYsT15GaE6RhIzi1GnEDOGQvT8GniVM2fIpwsnIQfYxpnTOLOsDCp7RBn FCmOibKPF16RGXWFRo0RNxo/54xRGnu5mMuEI4WXsFcY34fHOwIXE4fjUuKwcCF6cL1hiuciLCE3 VGOHyNPgjH2wZvpYY4cbTbxAa58veaCsA0J/+RogzWULBZL7hb7MciK0cK64PsrkOZjHUb0VUS/x eXiaTE/JZ2MU5e6ydgu5jCgJ3WRx2UKO3klXtE5so9Y5dKItEVroqHEdhNnCWGjCKATF6mgsx7+g I2fytGQ1tXFEHqu2DTdTc9nwLxQTP/C5+Kfniuu7/I/2mby7dgZ/9xh5d81lw2m8J+60uPfwFrpy hHOGd+X1nYyPd/yN8BxkJaoODacyo09p7ls4ydpOxJlkw5s8n3LJvalZLhveYJ9dS+4NzXodf8Xd 1F7PaKxVMq+hjJxbjMhaJfMqfSSyGJG1SkZ5kcUkG054deBlzxuO4xjO4Zzj8n0Mf/IdJc4km3ah aacZXvIK5Vm+1XPNu+fod8JmPfmLXlE8z4cQj3gl4gVZn+fJNJEznlfeD4s7JPTnNPy2/f2zo7vH RuGzeMbfL/u/cy4bz1zWPavLmafwG99nvLvmsvG8/LXmOBpPdY/gl8rrfq2zD79AIefs0xyXDXsz se0Vt9f3K/awV+Vz3B6tt6fNM74789RuMTzBbwH2D9599Se8f5B53PuHLEb0d/I4z3f2D1mM6O/E GcOjmXUflQfPj+Fn/K5g/fPu8bts+KmwQfgTPcXD7b0DD+s9ercxnqEPKZ4dGrdD8TzEbx6Pxy1G 9Hi2Y5vicYtR83i2ZZ7MLSbZuNfPovxDVeMDqFdVPCDfPxA6Y7ifXrx278fl1L4vyxbh9xRbnXAz vuv9F5sVvcuGezXqHuF3HLn/75Z2F76td3iXas1l41dcF+I35a2GTzOP3mo02mXD7ZK/gT6Ub5P8 deFGfI1rJkLDBnHrhetwC7+cEn6HejS3cNQSas6ZZOOp55YvafQXhdXsJl73joYvqLpukmWNcLVw FVYqw6ukuWy4UXVUqfhvkLwcn1dPcTQs0+4p14ylwiXiF/M7q4QrLhbnsuEzkhcJr9GoTylT/iYM pfx/iHenUlxB7WrhAjKGqzBflqs002Vj7uYymkRomCNLibxdif68ElypaD8py2zhLGExZvrpzO7n NeqyYYYyNh2fUI+bLss04VR1BJ2SmISxHFskfqJ3f9agv/9Wxup5Hac3OjbzHGOVs9EaPUqokxGX YSS/kBPeff2RzN9Z1JwzyaYoDJdo5YvlZUTG5witMFwzh/npxw7hXWiomCEYrMrQ6Ul5kCrDOcOF Ge1C+RuU8ecjDBeIO18+dJqyu3hsAzKZHKC89s/M8ewav7N8ZlrjCjTf4/d+0U+dsq8s+ThXXL40 l42V7r7PEfZW3ffC2fSdoJfeQp4sPTNcT63tduN+8pnd0U27rLs0l431k6OazBXnsjGrPrqLsBO/ 1LwmOmbuHTLP0kGRe90ZvzkTnbyOxt7S/jSx8uuy8XvQPQYx7o9y6HVrTRj88frh4xXu/xNt/r8B atM19QplbmRzdHJlYW0KZW5kb2JqCjI2NSAwIG9iagoyMzIxCmVuZG9iagoyNjYgMCBvYmoKPDwg L1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgNzU0IC9DYXBIZWlnaHQgNTg3IC9EZXNjZW50 IC0yNDYgL0ZsYWdzIDMzCi9Gb250QkJveCBbLTY1NiAtNDAzIDc4NCAxMTE5XSAvRm9udE5hbWUg L1BLVEVXQStDb3VyaWVyLUJvbGQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDEyNiAvTWF4V2lkdGgg ODIzIC9TdGVtSCAxMDggL1hIZWlnaHQgNDU3IC9Gb250RmlsZTIgMjY0IDAgUiA+PgplbmRvYmoK MjY3IDAgb2JqClsgNjAwIF0KZW5kb2JqCjEzIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBl IC9UcnVlVHlwZSAvQmFzZUZvbnQgL1BLVEVXQStDb3VyaWVyLUJvbGQgL0ZvbnREZXNjcmlwdG9y CjI2NiAwIFIgL1dpZHRocyAyNjcgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDMyIC9FbmNv ZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKMjY4IDAgb2JqCjw8IC9MZW5ndGggMjY5 IDAgUiAvTGVuZ3RoMSAxODkwOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFvHl8 VNXdP37OvbOvd5bMksnMnT3JTCYTkskekpuVQEgIipggKWGLCCgJKApWCe7iAq11pU+l1q3qUyYT xAC1pq61tSWtrWsfoZX2UStCW7Stmszvfe5E1D7P7/d9vb7//O7knM9ZPmf7nPNZzjn3hlBCiIGM Ep5Iqy9eOUzeot1IeQXu2dVbL/UP/+2vSwmhewjRRIeGL7zYMW4VCdFOEKK84cKN24YOGJt8hJgl QiK/Xbd25Zp//WPTRYRU2lG+ah0SbAptPeILEQ+vu/jSKwa8qhrEhxHv27hp9cqh08tvR/xniJde vPKKYc1vFFcg/k/E/ZesvHjtOTv+9GNU5UI8Obxpy6Wcmt+MeCfiPcOb1w5vuKR+OeL3EGJrRhrF jz0GoiIHAf1k6WyKnPx/6XEox/8vZRVfSVOixf+3R000RItMHdHDNxCjjGgiZiIQixy2EhuxkzxQ 9XYiKhfKroD/DvEQkv0D3Am492YWZD9XbiChmfXZ47wNgw3nnFwDJoBcR8LkPXIXeYYMkF9wPGmn paSPKKiLuAlHa0kXFYiTKKmOFJEQ6SK9aHEB+RM1kv1kDvmAdpCdNEIWke+SIOkhDtJMvkX20XnZ 98lO8iq9iDyO0o9SiRSShbQze4wsJr3Zp9AGIfXkbnIfNREROToayr6DGraQG8lh8hrJkmXkHuU+ 1NJLziGXZJ8iy8mv6TJ6QbaAzCeXkKvJPeT75Glygt5EJxXK7CCpJKvIZqqmNlrEX5N9lNQo39A+ mX0+OwV6XQLcw+RDLq7oyH5EJPKegmbXYXZspAK/S8gDmPffUxet5FuJiaTQ1gD5JtnPF6GPneRm jO0wvZLu503ZBzGaarKa7CDH6RV0kgso31Cezm4nVowvhZ7uIg+Sn5LnyF9QWwddwl8805TtwWrS kDhpR0vXkRvIj0C5Z/F7npppgM5HzT+l79A/8Jfwf0bNj5CT5BPyT1pEL6JXc03cNcry6Z3ZJ0kU I5RQx3xyPtlInqBRKtELUPa73OXc1dwO/iD/e0WR4lS2JvscVlUSuNeQxzCuX5FXyeuYrw7aTV/j rubHlTdkr0R/k2QdRnEdeYgcIh9TJdVSA7VTP62g1RjZlXSS/oHzciGuj1/F71femt2WvY0EsFYG yFqUXE+uJdeTp8hR8kfyF3KS5qNkEiWbaC+9je6mz3NH+fP55fxdCklxl+JxxbOKz5UW5bMzv545 DqqzespIN34DZIhsB60n8HsOcoSnHupDTXPpAtS0gg7Rb9I99E76A/owPUhfolP0fXqK/otzcbdy 3+GOcC9wR7kp3svH+Db+fv4VRUDxluIz9cpp78wzM6ey+mw8W5Hdk/1u9u3sSXkWCrDim0grVtcG yK/ryB5yJ/kP0PwA+SX5HdbdMfl3gpzGHHxGVVhNbvQoSEO0kJZgdOfTPno53UXvoA/SF+kf6An6 OUc4AxfEL8ZVcQu45dw13Ifc57yOD/HN/BX83fxv+E8V25Tl+D2ufFJ5WnVCHdG88vne6XdmyMxF M3fN7M1WYi2qsPJs4LkUacGaW4BZXkNG8NtMtpLLQaPtoPh3sXL2kww5Qn4GaXsUv7fJ79HjE/Lv fczEGTJNZiiH+VRSDX65vpdhZlqxWgbpWsxt7nclvYbeTO/Bby/9Hv0+6Ptr+hv6Kj1G36UfY0yE S3DN3DyMqJe7gBvAbwW3mtvJ3cIdwO9X3Gvc29wfuU95gbfwIl/It/MX8jfxu/g0f4D/Lf87RVTR rOhUbFC8pPg1Rt6pnK9coVytvEX5feUPlM8qf648ocyq7lA9oJpQvafWqavUveol6pvVP1QfUf9e ndUUYj11o/fFs3KKgTvoBYokt4dmuQmM+yfcpfwvuO/Qx7+CQZS70IM1ZAU3wT/N/cc39/B/5J/g riFE0SZjzYUUe4X8mLyifFWRp3yPvMTlk48gD7/Dr+R+wt3LuWgVX6+4XvEKpM429PMH3DFOze0H xl8wGyvIedRN/qZYSk6B/keVu0DTDu4d+jj3IrcAK/kN8iB3hNxL9pG1tBq9W0OeJJ+Sb9FDvJ8e xLrbQabIh+T4l/1VJKdbuCaVi9uqqsMMHaKLsy9xxdm/gOv/QK8nb/OfYu0vpT00SR4m72LWf0dT VFTMKDzk15B8PrIXq/a/yTh48OeKMDjoY3KIT5FliuNYr8npl2falJfy19JPuGZMp1OW3IuYNIYM vgeyislRE9kPXocUkTn6L+SXNAh98qrqLXIf2U0O83kkwj/EjXJZ/mcKP/k2Oc4vRKtXQT4V0BRq uphAcyv82T/PPIga1pMaUkNX0WWkDTmdxJe9GD1/GLJIyi7P3qvsV8bJr+hCmkeegfRygYp3KbUz J4F5AHz4Numkt5DxmTVkEnrFRSO0HKvppHKrco/yMeUB5U+Uv1TNIVeAa/diFv9IzkBr+Olq0OID 8g+s9RZwTwn4pxm96IQO28j180+TVppPhiEDiyC3W0CDZZjJLajlGnIr+Okh6JBfkdNUoMvJT8gb 4Bwn+Hw12tegni5yHmZ9C3kY0vFaOo6UNcRHYuCzT6mJ1nCXoj0mZ++CnJ1En35P/gzJkZX7VULr aRtmbzX5B+NltFBFeukYdPJBUgtN2ca/Qv5EwtCuLZAvD6LcINaGiXhJrfJdypGSmZ5sDXcR/zR1 QBuasKqWQLPPpSPohRnjmCZ5dBGpnJmH2h6HLOtVPgTtG4dmyOPyFOcrz0O/34Im+xXZnO2j96nB AVLLeUukpsa5DfV1tTXVlamK8jllydJESTxWXFQYjYRDwYBf9HkLPPlul9ORZ7dZLYLZZDTodVqN WqVU8BwlJe2hjkF/OjqYVkRDnZ0JFg+tRMLKryQMpv1I6vg6TtrPyq1E1tcwJWAO/RumlMOUzmJS wd9AGhIl/vaQP/3LtpB/gi5b3IfwbW2hfn/6pBzulsN75LAR4UAABfztrnVt/jQd9LenO7au29U+ 2JYooWN6XWuoda0uUULGdHoE9QilnaHhMepspHKAc7bXjXFEY8QQ0/mhtva0O4SiqIaPtK9ck+5d 3Nfe5gkE+hMladq6OrQqTUItaXNcRiGtcjNpVWtaLTfjvyiN0ZBb/GMlk7tunRDIqsG4YU1ozcrl fWl+JepoT1viaLct7dx+wvVlFJVbW/tu/Gquh9/V7rrIz5B37brRn963uO8rZT0BVkN/P+pAWS7S MbirA03fipnqOteP1rjr+/vS9Ho06WcjYaPKjW9tqJ2lDK73p7WhltC6XesHMTX5u9LknG2BTH6+ dCh7nOS3+3ct6QsF0k2eUP/KtoIxO9l1zrZxt+R3fz0nUTImWHKEHTOZZwMG41cDa0H0XJ4cktFZ qOucs5SlrEeh+WkJK2q1Hz3pC2FMNcxbW0N2ra7BBODppyiVXoMZuSitbR3cJdSxdAyRppURIeTf 9THBCgid/PDrKStnU1QR4WPCMtk6ObvU0nTlF+F0PJ6OxdgSUbdiTtHHRjlemSjZOsHdHxoW/AAg H+kFbVf21yVB/kCATfAtExJZhUh6dHFfLu4nqzwZIiXj/WlukOVMfpGTdx7LGf0i52zxwRBW8gF5 T5KX1kTP/pkFh619XV2aOv4/stfm8rvODXUtXtbnb981OLtqu5Z8LZbLZwQF3ZA3G0rbWvt4D4c0 FuI8vJyLRbl82VkURPoMaUUEfyp5Ua+ZUGuwKuUU6u9IC4OdOb9fFwjM8sz/qdBE9jQrJYMvi80O I10Xn+1ortvp+q/Fv9Y9wy6+awlEDte1ZNmuXbqv5XVAmO3a1RHyd+wa3LVyIju6KuQXQrsOwZ4p 3DXcDjGUm9GJ7OFbPOmOW/sxlHW0DuuWIy1jIXrT4jGJ3nTusr5DAiH+m5b0ZTjKtQ629DN6ca1L +mb7KxOTrUkQF/qfowXQsgVKtkNUk5YDHH1OpZ7gNZKNKBXP8USnVjxHiVujUj7H8T+mzUQLZbiU uOLCJw3TDT3CmYbu6QbShLDwObw5ZQFLwBKBRwsU5HM/P/m5pCSfEb9iEm1h/0OUaeU6ZnXTMumO oKC3Ng0JW4XLQzcKN4QeMz4lqO8yjhs5Gg5xJBgKBXQmvVfnDLi8Tr2WajmNV+uw5HkdNKwjQceW kFnwh0hACHCBEBdIWAS7xSKEuFCAKzKZ7SaTmdtqoibddgsNQH0oHKGAxcQpqDNkDoaLCKGUnhAk wcw7HQ4dFIvZQR2H6TUkREulkF/nLosOR0ej+6JT0eNRMGbUH5WivUjZE01H1bsvdsV7RoSBM+78 7umTA8TV1CDg19SQL0wPgBKWWovVWUuZN2CtHai90VQa11wlPA/oYoGB5+OW2lr8uYhwkgqTOX/g qxG10NCgbgBNyQAdoHEaUKvy7E6HMy9QWVVVje2RIxepKK+uqkwVRgsLeZ5fMhOoLSj1rJ+ZO/8b 7fRPNvp+RyLYOD3sWeR3qLiC9T+fotdc1xKv9QiaSES/eq+i7rNHv1csKiMRh+Cz2rQtf6evziTA 4Yuzf1Cej/16mHoPEUd2dFyrSxVgXTKomoVGQKkfCYZ8rafK1p1/g+OW/N2emws0GywbrNss26w3 Wx5RPWp8yPmS8xcencpBoq2O5oJRx/XOGzzXFTylOOLTJaPrxMtVW41bPTfYDpvV1SaLNewlyzgv pRPULiEY+KHFalKu9/Km9XlauiJpoZb84SiNWiOXHKLlWIs9QmufpDXrRB2n63a7z3S/P+AZz4VO 9vcIA58MdJ8gTSebToLcH54BtU+eOUmEl+eUdZ27baxc07pNCjsKVEZD1BnRaNVaTuWJGh26CFEV wNO7TBGizVdGaDyOv3gsHt+5kw6MkIERFo1TSygaDQVVbHKsjoryquo8lSoUDHOVKWu4otwpJynP Lyw5fc+O385pWv78d0d/t3XzPx56c2b/U7+g/c/uvn+5259UKzfMxCae//bWuw8dnPndvcM3X3b5 hh/Rjoln6fLJxnCyAqyKOcEeRL0O5ytVdJG02ce4R++jWt+VPq6spr2qt+YR2LHKSEEVvZxcXnC5 9wZyY8GN3nu9j3o/8H7qNQzXHK/hRKtoE+1CWIgozVazzWzHBjiirVLp/F4uGMz3e63BYGmdNxoM 6v1eSzAk1nkjwVDS760MhiayN0mtxFvgxylVUYHHXlDgIVVVhCS8PrvX6yO0ylvAi7ByqyohfKIR b4HVoiGkusYj5NP8Rt1R/TE9p8+vmchOStoCX0ruEGKjkjbPkarxiUXJUpZnYXmlx0u5ydKpUq7U XV0zQZeMB+ZudU3Qkuvj8Z4zA5vjTPD0CPHN8U8GEBxocFustUkXRBF7mA/eqwX3aW4sjSvBeIAu ORB3sWmLx+eU0YGBzWwiyUic0kBeKKhms2ixOxwVFWAyxlfgLAu2MBbwnUNOc4D1kJbCnIcqA/wU HeaKShrCbrPe0VZbMt2QC0//0zV9Wmk8f2CmzJToKdJzyIxzMfor/upIningWvv5NetShRGEg64h /uRnccUrn7evcZY3RSJUTCX1F/DLLqwojLA5x2mZIgA+rKUJqdZVdn7x5QFeZaJaszquKnOZnfGE OS4UW5JBfzxcUhWril9YfHPxzbEfpiZih1O22rOsNF/KI8vMVWIVV/XDOZitZX6v6BepOEGvkDp8 y0i+kM/l/zCvOG7WRM16s7lAX2BWbDVvLd5rfkj/pP55sypebNYrQsrKOXyoMk+7CGcim+gOnLAo 6fkkKkS56AQVJJM1v17SG1P1Zo2o4TRIOiDOKXXXTdDasT7Gqme6T5wcwMR90n1y4MRAji0hI0fY dNXWEuHDgTMnB2ZZlIXl4JiKqTDJz+t5MxcpjsbX6y8yb9dvM99QfH38TvMT+iP6n+t/bjaCKfuZ vByBwLTl+FIWmUxSYhuhCAWjhTKzhiwVmNByyM1otLAUvFrFWFXmVf5ZfbH33euGLs/zSsnHPjr3 nJl/vCJtXlom5tdZI5GSz741fH3FuusOPXD+R0+2NCZv9OT7jGDehseOXjwvEUqWBpZctm7dDY99 nB+2FxVz5I13ty8uW7a4+YLR76144IRgaPbPzfHyAuhCA3jZT544RILZyXFXfirIVn+9YE35g1Kw NzgZVJQhwNH/Uqs/h0B0+b1CMKj1e83gy//Kz//c5xXV+UXEzwlmDRmGPpugMSmoMWtFLadtdAsu 6nf1uva4eJdfEKlf7BV3iHtEhXiYxoiL+9F44BJMifDJmYGRBgEOXHRmgGlzps9B9w+JMA0BlwuA XUYGZsUdaBj6H2wis0/IojSE/T1t0RVrna11iem6RH0436xfdXPj+c6ocuHMt3ZsClg/++DLxa9w 1C2+i25iNOHI8uzf+Xf453Ca28AtkPJUglCr8Au15VJDW+qWyjvUeyv5RkailV2VB2vp1eqHE080 PJV4MfFG4PXEG5V/Tmgr1e3qBbYFzvmVfc4hzZ1kb+VDOKw7qDFUqOlo472K+xLfnaMgjb2Nqx2D jZudd+Xtpw/VPUOPN+o0jt7GS+v5Tg2XZ83j6lkrzztrT9XT8goN9pzxkqJ4SSReUtxQ8XjFkQpe UTG3orviqorbKu6v+M+Kpyt+VfFfFScr9MMVtKLerglo1mou0yg4Tb1moWa75mbN/ZqHNT/TvKnR 6jUezbCGt1s1vMsYFeOosXgoWd/Jld9NBpJJziUVx1Nml+ha4drkut+13/WMS33M9aHrc8yhSzIJ KRcnqjm9uUQsSZY0lShK2opbzRExwkU+wBWDtkm7Q/uMVuEH4IhWwCqYoEckQWocbeSkxsFGrvHR PJrnYaMr6i1qynqoJ06qhWquulwphSKpTcrTSq5MKSl7lYNKhdI9t+Y8yNw51zO+HRiJd58cOTMS /+kAFssZyM4GmDqfMB5ustbGk8iHBXTmpHBSmD5zQjhpYVy9GbbPyGboXZm9hZc1QoOpoYEMxOnm HE8fMLi8Lo4MgG2hh8tr6gpCOoFXmCPeaCCij9ZGTT6Ljxj8Wh8Nhur4ah8RCow+qgvCq1HU4/YG opyiZVmmM90M7bx5ZIDA0ZE4RHs8HoE+joLFI4zb2TJlMiHPPpsKzmfCQV7P5dVOpryjhRZZnzPl zc1//Kbe9RO00ikVNcfyC6Lz65vO2/zKJdfvdZp0dmO+x1e+oa13mW5bfWHAnSjfdfdFizY8fvs3 1lcXe62uPDFeNKd9YUXntR0jLbG7Z+6UAkLEtaC1605aO29xVXVpCFckHIlnTyg8kAVOUkgXS2Zr h4Y4BSdHXW5LWHRO0I8kTyh6Ha/2RfV602azWdA7CRGCNCip863FmM1MVyUDUk393FRv8VQxV1Ys FfcWDxfvK04XTxari024rnGLbs4ds1glgZbB7u0VJoUpQSm4i3pGmBQYGMHm6RARIIrcgSYB1Y27 /DLMOMUmkLGfCYjapADlG5dRi3OorGWGKndkFvUTmMRMjggnmN0V502wZelAbo7zIwqjMhKOevIL 8jmVNuqPRBTBQuo1uH3EaBJ1CIdU0UKab/T5SEDjK/zaHMv2F+y90FXKYe2wf0f4Ls0jyoc1Tyk0 12iu13I7FDt0O8QdkbuUd4dVFKp9oJ9a2BSzCZenVh2ywFiOFlbOavXyKtl6DgXp/q23Dj42uP2V axdurd0bVOviFfQ6lW5hfcX8OVWFLUuVC6ent49M3XTvp9eWVa1VPLTYVuDhItMPzgzuCNXPr3vi +Ou9dTnZ3pM9wa+AHAuRv0oXf6yiYS3t1z7se4F7IfQG/YD+kVPrNLSEi9nPF4e0F4pbtVt1m313 256wPWGf4A7bD/oOh17wHY1YCM2zEd5UMIXzOI5M0eMU2xc7jgYDtjyX23UalvBfXFG9OtCp0Jux 1YlTNhXl7iYGJY/WkjJTuo+mUSJ/f+QUpIS5QCzgCsrVs3gMHiyKp6bUlAUlrcGUUrvDNbfLmjoO eQ8tLVvQ4KPuE5tldX1yRMD2BnuXgZFapradtcyWlmkNzovIHASNWs2onuMy7E1m+Q6cBq3LS2LL C5uOHB+68o1vPd5eU9+tVTmdYlkwtWR+ddecvr+6vrmN5r/4zLf2f3tZbVvPmia3u6L7/uv+Wh9n l3WgxCLQdwD0zSN+Win1qaxd9gH7Jvu6vLWubXZ1RPcIzsFftvya+zX/hvGNvL/z/zTqduSBW2x5 qaX8EL8peDm/I3gtf4PpA+N7edqYJuugGq02TjSCxq/hNQNKv4PQDscELTrgidrUygnqGzfotQ5G Ij3I65DcwZTjIsKoh6gZZhqC43pTikHJZakk+clgU3BF8FRQEfQXm6mIKSiXeQr4MvRZczBalmJx yQDSTwlUcAdmqQ/ig+bTAycY/eNxJn3jcWhn8NMZbLchagdOUOHlEZmpICS9EZfT7eRUBVbRR/Lt Dh/1WTw+6syDByGJzUosjo0LRCIEIw3kZiIn7wohHa2YLXXqi4nK4wems9pl7SsbVtUEF05sm9qw dPqx23/9USiSF0oF6unHhzee23q+Y+/OfTuf+YDmvf/A968QrRX9e0OYH4rTbcK3wGZN0Li0XEpS lU0Mc2YVUYsqQa2IxbH1LrYIRoPBCoaPC2ZDWFS/EKRhUfVCyOwRPU0efj9UU3n0mjyaMF1bAhTI Y11ScpqazEkxeSzJJ53OfOpihCtze1IuX3FQAgzuKU6+dSxBE68RUjxL9phhykzNr02BP14zGq3F BjZVqIhBKVlcnvIbpgwcVIyhzDBq2GPYZ1ARg2AYlINThtMGtQEbtLIkV5r8eeAwXUNV2HLGR7AJ GYEg7D4BGTdyYgSqUA79Wfgkfuan0Jfta9v+DGIzIdjA9ipNJ09CQ8YFqD+2r2dw1mdyUd7is11G NTYejVylJVRZUVnIrNKziiq3ycdOM8+ZV5FHj9n9S6ffbKq033QTffXAlZcvmJuaq1IYBKe3kNvF t09f/g1XhA+HqadsIXfzqvbknsnlNYmWqoC2wGLO05nLKvdfvorNVQduTWqge0rosUNElT2d0dfK m7BkV2VK2cFxvWwPplYqVQ5VVKWAiR0kJaJRCAolKut+0zMmzkOJLSyaJri3JUuwMCwGQ0FtWDSG QgVhMTDBvSWtDhWFxZJQiHpQlLiGFOpgIGAyGXUaEYc6MbtNCjQ32aT2eSmbNLfSJrXC1dYhUjYH XmERvHgCXjAMzyfCEyypozZqtlG/7aiNE2zUxswc62QpFUvTpVyydBjbRqmxkg1kHFXJELXJEBXK EDXJsKRUhpIJ0qGU5ARkrKiQrQ4TOna6kCYLJwuncA7HaquuS8kwOScH0SkZVesNpArdiZ6dOckJ 1sVsyxtTgfExHiwXGE1szZx9mELFCpEPjk42MaEqZ/FscdABWccG0KZV3xRg3dHaDU0mCZ4cszmM iGEhmyS3GZ5HaDIBKxOwM2UtP/1sadGBzVhdcYKTiqqcIoSpIx8ifbGRxeEFW3pfSYNyfK57tL3v quKiuTPRcrfVGvcULSwx2+pnovVuS2EjdOG7i1vX3Lhv5o4NlepwWB3IX0u/f2l9oLp9Rr/GHdSE wyq/YwN/cH1Kg20sZHYMXki5Ee+QFJC3JYdv1OJsMltw/V8gWgSrUKByhkUrTJ0DQWNYtLBAyBUW C47Qj6BGVRi9JVWV2q+iKolQQ4HKatFpGU0KkJqzdCW+2GAwG0UjZ4y5nBKqdzJy1FUyMO4PpWRo c8pQSibKUmkn3e2ksqnlvFLy9fo40Tfo2+dL+xRJX5NvNwKTvuM+lbdnEgYSpu4TzJ9MWDZxMHVn +bsJATwyseP0S46tsn2d0qBqtHnZBZK0bNkrpa0z6kafvbRFuVFOkKQLZuqnPaurFeEwF3Su5oII RsCfcdAtDP4UCAZrZVQbtNK0lZrZKzuCqBSwS1LpITpl2kGGQluBdhCpAgKSI4SSKqWO5HRQzKBn lNHnKMPAeCKVkiEoxKAUAonSerpbT4lewHnNlaJ1nzVt5ZPWJutu66T1uFVpZeXmpFIMHkyUpiwy gdgS/xqFZOH3BWFAORhc/7bIxr8kw8LPtp4dPP+zVWzwsi7Bu1eqy6DrO7geSZzHUatVlHS+ao3Z RhpIh2gD83SoaFW1OyzCeHr9QDARFosQkOzB5rDYEAqaw6ItFJIKaTAsFk5wbzwVkuppdVisR1iK hVrCYkcopA4mqgJqqvA1lA8pfEM6nUJNOlQN9UWFdpuuU4LS7mS0Oc8XTJHOfZ3pzslORSdUkMls Fs2cOZbvhuhyMzl1v/sZ91E3L7l3w9p+PxCMlSaQlZCzEs8kjiZ4KbE7wSXeJ+ZqERuvWEszqznf G0wNNh9v5vY1p5snm/kkvKlmvtk9r3OCO3c8wAQLO/iC/JClCsx1WAPTDbNwoKGHKRykgejsYXqn G1uxk7PH0JAs0P34wzMrX2TDIZyc4/HqjUpVWbQgOkdZ6qMqtVef76MGY1JV7qMegy9nPmCHJW+y 2AaLzF+yTbKKfo3WD/NcKWoDhcQf0Kgpk2SQNDt3wkAPD3Ye7+RUhrAhZZA6X9MrFykXaXq0i/ST ncoabpFqkeFTlYLpvZHN/bKo68SicnhlQo8LeU04ZP7nOISdDCECoa9PM1EoQ4sxlw4ox836XBxQ jguz5QBZfExfy/aJsw9MoX40nCeLQ+f/WSgyfTy7c4Sg/Lcl/HL3tT3Ltgd67+hduSVR2DjjrfVY 7XFvvC9hcTbPFBQmzPakpyiQrESeT5ad/CNXLmldsnRZb//Nd83s3JiCrFQWelbSb1/VFmhqmtGt xQYJQiA05xz67R1SOE/smtGtblLJEnUjJ8gSNae3q8EXcU7B9PZ7T+prtSqaYGuppquyN0GV0NkR Ff8m9xr/u3w+T1UJbc6/Ro95OKvZhCuYuGgSAkJ8v/kZM97OKbCHRXNOh0eht0NBHXS6rMNxofiW lBeCZo/jRsbvN5tNOveQkleoPRN0xfgUO3bKPiktdVXSbdipqXSyVs/LszO1bsfaN+NlLvtRO2dn Kt4O9W5n6t0uVVbBg1a2M96wM0VvZzreznS8nel4wU7tTLGbxUQ6wSUTw2AbaHU2RqbVZYhKZIh6 ZAhtLkPUJkPUxaBkhnZPFJjxih9UUWFhlKXJ6j1Kk9FJ3PHwLImpdxlCvcsoWm84FXWXfKnWZa3O rni+UOsQemdkrsotLpktWT7T62fiI1DrDXAyYzCMr+p2PxrEgvazvjDdbma6XY4x3W6WrV2m281M t5uB9TXdDqNxM7PksR1nB9izq1k+yPiKJmf7rv+xZp/rvG7hBVfYBSzJwkqnYI3nL11QWDlTOLs8 t/XMW9tV+8DMdzbKqj3iXk33bWkIXDmjv6gGuh6K/YtlCGIuwF7sKaxDIwnQJZLrpXxaaKDW8zWm qJEStTOq1mr0Xkkh0xtiVCFFccCloIp8XCewcwsZzMuBJhmM185NsVQpjJ3pZGgKd4EhKTQYYkGc Ut2PGz6zVbRyVmlKT2XVhXpliKoZPIitlN7N7itGDxRW1uB0g51fgfgDud3srA32CaRl90kmL+VJ ksVhG8UBDRcRfX4fp7Lb8mycShX1FOQXuAt4ldloLcQovT7q0Fp9xKX2FlKLwVRIfbzJR206p48U KJ2FsqSR74Zi8Rg7roAwnFNEa/GC5Xxhm0E5rNph2CEMu0dVuw27hVH3z7gXRd0O9bBx2LzDtVs9 ahw173ZpsJ/GYTbOXGFQYA+gxtkFu1JyBlXy8RW20ex2AnKpMEpntv/m4rXbX3/1xPtHK+Y7TfrO 0oSv0GiPRvL5565+b9dLNzxAi557mcbndb/78w0D8xa4g3NX0MBjO7x4ZZftAbqwX7sEc1hMCyWd Pqqv1dsNQo6kYEiQ9L/HPWIqDtIyrQ84mhEr5ajXl0s2CzKUCu2OlBCnd+n3xDm924gDCC/eUyoW vYJPKFbRPIfTSYIPiD7ZWHG+KHplYyUUFouZseIN6crNkq8BK76gusl8IRMypFjl8+rMA0R3mK7A 28ArntqjnlIfV/PqCXpY0pNis1N0cs5YiB2eYz0xMF6Wks/Sxz3+3Jk6buZSk0E6HKQkKOANybdi PefJZ16MXZkeHThzZuDkSQHXhLLmbMBWG39xNTu3kg+uYD7ncJHKdtM5dvvieEM++1bl5TlhRuf0 A7sjyp0yvTxwa3NNa3NpZY9aZ/TmF+f5qdqQrJlRz41rdNEy/pHffmtFe1PrgjaFyhFsWnnZ6zW1 gseNrZuydjun7HUU4O4Rc7Q4e4L7LeaonHtMWq4vyxOaFIKx2C54ixUqu8P+YuTF6JvCB8K/BHWx EInVCFWxG/V3hu4M/1D/g9CE/kBIj9sGo6Y4zzBP32VQSXrJwFnLRbKXEyllcodKuE68nwlz2o7b /73WJBJSyb/HXaJ7r0fMz2eMBZQ9uMqboBskn3uv4+9WqzIaV1t9UavemjMwJWteil5gxQ7l+AGt XXUeC0g6rZ07L3dRj1okvd6cysWCbMci1YF/RWzP880pmkwtSq1IbUrtSO1PqVJWjZ9VwnzuvNyN koTCuVAwv7iIdQqlzUWUBeXzqyJ3BWN5xvE4M8FlEwA7r3xS44cY1TA0J4poJHugSdOQF4LniCCK sbG1ANsABy4jn2xmR19fFA34QSF5KFrUEfgGyiM2OY4qZIhaZIiKGMycrSvefyLOzlUlN5WKXCBy gQWe4IFncsIzOnKN9uNch/XR5/OZm3wT2T+OG+w5CAwWzwBd7pyMd4gooXKtwFX6gKj0AUtp/wJF wCU3bL3cNfeHbOySOSnpLE1J3JLDw1jYMBlSDou1HEmga2D1qfEcPC5poXoiCWwwkfqqpEUgkoBe ikxk/zqOY17AE0/h2NdQgOPiL62rfoITKXbGNDAAnvnKJZxi9gRWPgoM8Wfv39jh4Oz9G7s9575j Ds69trm4zu6n0YGe25e2Dvv0AUdACCb+o6NsbsO6exMtd962cJ7HYnW4+J/O/PT2ddVhj7v4pVuW 9tzVG9OX097rrquPlXXMW19zzuqN+yNmMw6lKIlm/87dpZjGm5n3SKbd+t0GTvb0BuKeoAcxPwq7 nc+7lqMqv75ML+l5/WbtWpOe4yeoSfIq9QcN+R6qUBCzUlRyypjNkbfNbrdJoL6NLSkB9nvSNmmb svE2dz6TLuzKBKKlG+/IMHsAJkCPgEtPREnT9IkBdsfGzIIzuGljx6d4w5paKvJy92rsHkK+q2QH Qexlj4l33jFHheY63+KD/VdadNuvHmtRTM88tnr6mcVJ72rH5Oq5wbvov0L9z8MEo6QJ9wlz+EdI kH77EAmjdw/DIgxPhTmtwWOIGeYbFLWG+wp+WDBRoDil/kjDBdmNbYB52FXasKe0KY6paVZN2XYy FMrtoHzsaCekxF7SvVar1+lJMAgCqIgqNru19KmYgaeCxaeCkadiRp6K2XcqZtqpmGmnYpaeitl3 KvkMR0XNKupXHVVxRCWoOGxhj0i6MLMbw7DzwozDUIkMUY8MYd8xmInlslGznIwqGZTcMPMmw1QM p8NcMjwc5sJ2ETdeMTMTNOOoWIaw8mQIK49BVMaAZIOxd9pEk6ZJ05SJN7lDs2bfrODPneZ89QTn 385zoEZOnj3PYVaFvGFil9GYX6gNxhSbz+6C5duIKNtZFFYGYKLlNLoc5V/Bscu1rTecu+jKWGEj vcpW7Al7i2oKG/lHpsPsvOWq3vkrr3mAbmF7gemda+p8tvxF9MzsWQveziBKbrfx1X+8ssLc8LHG jXcw8LzwiKXzLBSyx/EmyUasFS1c7gFUB2bayfkC+ezmT4/hZa0vcmYRiENVSws4xJQvEQFusfo2 UqzYQtYrl5IFCkKWIxznbyM9cIu4x0gL4h1cLYnBxVWPkYUsDrwFyO/ivWQxcKJIa0KVVXirxYDv Qqb4Hys6lM+qHlMv08S0RJfSTel7Db83+bHN/q3lUssHVtx0yj1zkL/B/tyNYxD2ZlkS30oRTSf3 PFEizjCss/1X4U1m0td//qJzOuJLLrp47ZaetZefs+nilZf0npto2bRxTfcSdj4lP9kAvv343x4H Enm8KhPF1yJVeH+7Dd+/dODd7vmwnRbim6NevMl+Dt7RXoo3rPsIGVvin1AYxg2mcgYzNmf5hEI/ XuQXzc2CwkpG4Thiht8EtwKOl31KJIU1c0WFNAGwOQcuyYH1ObCkQvox0BeQiuykwjrudJUz3HGd oXyUQY2WxS2ZZRVSs1ZhQXcYnoWcm4OZXlaLJdPNarGQebnU8bb2XKmWXHLjLHJdhdgcBpofToIb htsPdxpOhd5bSBJuD1wWTiHHGN4OuN1w++COw+HwDm1qKszNHoWAHEEeu0BEhJJwPBlUsFWYln2z QgOqaMgiuPth/ikUugzZKB5CJfx4ezvrKT8eL5Vhpqi4XM7I5BeUP423wu/Fx08iMGnG4ZFzSKal ZTZQVZMLjMcS5ceadViGp+A4BWxKvJIvlxovKi0//QzilJ/BgRllqfzn44IdrfHT42ZbudQs8P8i vXAcSfNjZBKOI5v4j8kOOA7o+zOJOawhfv+4zlQuAP8U8cONwvFkH3wqxyWEGP6pcZuDVf/fGbNF LncsU5bKBcYFV3lvs53/PfrzMv8bnIOK+IzkNzCoRf4lQC/gi/zPsPVi/Xxw3CyUj6K9HwD9B/w2 vC0m8g/x20k54KP81Xhnn6G9mTHl2nkzUxQrb9bxj/DflFG28CP4ZEHkN/IbMuWi/wj/IHoq8R+O a/Wsfx9mhLzyp/n3+Q341E/kTwDLKZqf5i8hSTg2kolxrbF8T7OBn8AwJ0AWEX2k5H7Zl/jfZFAR 2vshP4rPA0T+KL8TF3gi/xh/TSZPnDzC/0Nu7xNWC9p7ACuGgXGjqXyyWcs/gNw0/zdQHFyP1s6M R2vKSXOUv5WUwXEg6rsIvYuQwH+E0EeYpo8wNR9haj5CLz7CoiX8SeScBE6Sf4cM82+TPXD3I6xA ldsyoCCbum2ZcFH5If4q/pughHAEtKNIvXpca2I9+2bGapPRvskYvOlp/nWyCI4Dsd5gHLnpCH+7 PJQ94y4PK/DbjNYA0l2ZmwvUtJ3NwdP8KH+NTImdMgXSP0GUEjN/rVw4O26wlO/A7C9BdBP83XBT cKfgYIbAT8KtgOPRcu+4yVxuPsIvkwvPz5gqxKf5Tgy9U6ZWZyYvKPd53mxAYc7gzYWfgFfMuKYj pFxhUqgySXHxEb4L62cR35NZI6LvizOol9GkZ7ymrrzsCI9vCFksI4ZyyRmbWw50ZLS5ddU6rrOw nrTJiPGMxiTnx2dZko+N253lYrPA18mjrYBP+GpMXzWmphp8UiFPRvm4YMXqX8OXyyMqJ4MI7YNL wykwx+VAL8ccl+NTIJZi5qsw3CqSheMxt1XkNBzELD+HNMHthnsG7jicUk4dRAgKhC9DC4Pw98Bx qDGJuABfghuEG4XbBzcJdxpOTY7yCbSTAHYZ/FG4NNwxOAXmqgT9KEGelfeTaShfkezg7pXq6A6y g+7AB5J4R0G5Q9hh0UiVkZJyaT3zSplXBK96UDusHdXyZVpJ26vlBa1fyzEbRV1XwWwUq6qu4q3u D7o/7eat1XtUe9Tc0WYDtZBjcKfgeHIUH/IcgzuFt/Fu5I82Hms81cgf7T7WfaqbP/rOsXdOvcMf TRxLnMJBdLenrrz6i9f4FCJN4rvCRVSxgt/E7+B38wqRT/JNWAuKQf2wflTPM7u4V88Ler+e26Pf p0/rJ/VTemVaNamaUh1XnVYpe1WDqmHVqGqPap9KJaqT6ia1pFKcbm7l3gZR98FPw3FkFP4eOSTA p2QS/pQcZ6mYDvjDclyC3yuHQvDLWAguhLreAt4o/D1wYD45HoJfxuJwMPu5N4EzDH8PHMe9KRUE y8JSmBPC/jCHV5tPh+lU+HiYS4cnw9xkcx33BvD3wU/DsV6+gZIsFIJfxkJwIfT2dRnvdeAxxh+F v0cO7YP/72mDSBuWcyX4vXIoBL+MhbjXM6Fqc7OT24saV8C/H+4YHE+S8JvgNskxET7l9sKXuPvG C0ug8Ln7MlHISIBgDvhyoEAG4+788hXNZu4+VHkfqrwPVbKYCNfEYtlJ7t5MG8O9NzM3B+oqjjVX Q4uyrtxL9sPhZQv498uhJPwmOcRyIKrOxtMIHZdzhuHvk0OsHKsFegD+F2V57j787kWKmduO1O2S niMOZl7hXWEr3n7JXGQVJ7gDmSIBYDwHMgw02zgetDfKF4JG+iM5fL/sf0f2z5d9s6QPGf8VMr4Q Mj4SMjbr8EFkGIVOy/77sr9eMoWN74WNL4aNPwgbHwgbj9B3ca1tpAEpP2j8U9D4X0HjU0HjY0Hj HUHj8qBxcdC4MMiqwquWxMh5mU+/IfsFktNv/Nxv/IPf+Au/8Wd+4/f9xn6/sc4PdPo3kgLid2X/ btmvfCplFFNGb8p4mINkohdkzER7hOPoBcTI6zKxRnGC18qAC2S6I6BAQaa7GcCT6T4HID/TvRnA lum+Q2zWcmY6BmNF5Ex0TMOgIRPbiWx9DmgysW8gpszEavGW70wmFgL4LDPkBfg0M+QD+CQzlAL4 mIEf07+TIQ7V0L9mhr6H6ukHpIhVS/+bRLnHAScy3U3AfirXOj1AGmkEyfiEiPWCPpGJoXP00Uys COCRTCwM8HAO/CATExH7fmaoFOB7maE7AP4jM3QC4L5M0UbW3L2kSK7nHuwJWH1bMt0eZI9kullF w5nuJMCmTHclwIZM4y8BLso0nmBFL6RjFCubDmGrwXq6MjMUQ/aK2YEMkCI5ezmplGuel+lmJOlg lTQbafvsQNrwGS1ruIWOybVImVgZ0BozsSjA3BzlGjJDccRqMkUgNa3OFH0PlKuabaCYzc+PaRjd YBWFMrHHgSRmhooBfJmhdgAPK4k+22ZbtZJGuVOWTIxhCZmYX/wJ1ZMhucs6EqX3HRSnUe9njRN0 aUb8VJrQ0Iz4jyKAg+KH3avEv3RPwOIVPwAnP35QPAbUdxoRlPTi72MnxLeHguLPY8CQPOLLsVLx ueg2caLoiDje7RPH0LH00Cpx/5Bcw4+iKJYRH8X9KY4DxX1DC8V7YnHxbrzZjT58G8g3sjZQ0fWx beI10Z3iZViIl3bfLG6JecXhom+I64tYQ07xotg54joM5EKUWTt0obgydoc4WCn3+BuxX4rnsmBG 7BqSRzS/Uc7oHDpH7EAPkNHEMtCDeqzLchQtrTzCaARLpXX8l+J51T/moIXpKNxmqVT9tPpq9Sp8 tN0CfVOojqgDap/arrHibS6TxqDRaTQalUaBl9Hxvw84OzuPxJ06JXaVvMPFHSQi2IbAF7ANpBBY zMenURrcbpC0je/ius5tSVfHuybU2XPSNfGutKb3gr4xSm/vp13pydWka5U//cm5oQmqW7wsrQy1 4H6+i3QtaXEBOc3dNEHJkr4JmmUlrvewzygP4Q2okutv8zDYcf1t/f3EsbXJ1WRttNR2tP0v3qCc ONjW3sbOAGef2e8Yzsa86bu6zu1LP+btT5ezQNbb35UuZp9aHuI2cuvb2w5xGxjo7ztE13Eb289h 6XRdWz/Q6mU00shtABrpZgBo3HLSyNCQvvwraHQMyW1jjfAY0iI6xpDANItkpGVyXbT1q0j8LbRV Rmrlb5GRvpdrMIZ+oEGJAdSFE4mY3GBMuVFGczG0sWgUzQ3B6+8bK48CYSxaLmcv/jK7KJf9n7ns /2TZE5R+mV8p5x+CDGcYhyDSioDzBS3//4BrW/4vWqXjc7de0teOT2QHQ+1r4QbTt2xd50qPrvL7 xy7ZyjL8aT46uGr1OgZXrk1vDa1tS18SavOPzZXL/Vt2H8ueG2obI33tS/rG+qS1bZm50tz20Mq2 /vGenTUjX2vr5rNt1ez8X9raySqrYW31yOX+ra0Rlt3D2hphbY2wtnqkHrmtrnNaaFdv35iGtLDX AWQ4zul14JZBT6C/xSEMN8qsUx9wXe05rCD0UaLHl6sGfOtshGNclWhONLMssDTLMrHPoGezXFfX BzyH6aOzWQKSLaEWcqmr/aI2/G3Bc+mll+HBnGzZkpsYlsfS4+1yPhAuRQg+HmAizBwSvsy/lLA6 Zp94PIdLtsRb+8a6u/GxdBt7936c2d3xfpyVxYEpt0XQJkYtG/oO2dDXqxwVv+v+U/fH3fykbOFP wbo/Llv4k7Dup+COw8L38ZONU43HG/nJ7qnu48B9Z+qd4+/wk4mpxPEEXz3bA9ZUP0VXv/xdFt9y GUuOU3m08rgRQ8ql8S0gAfxZMiCGjEvhGJVYHguyonFUJ2fGc6NASi4gl9xyKSKsgJwqJ7EyrNRl rHqW/T+e2VSI4P8HL8y8UwplbmRzdHJlYW0KZW5kb2JqCjI2OSAwIG9iagoxMzcwMgplbmRvYmoK MjcwIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDg5MSAvQ2FwSGVpZ2h0 IDY3MCAvRGVzY2VudCAtMjE2IC9GbGFncyAzMgovRm9udEJCb3ggWy01NTggLTMwNyAyMDAwIDEw MjZdIC9Gb250TmFtZSAvWFlXT1JGK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQgL0l0YWxpY0FuZ2xl CjAgL1N0ZW1WIDAgL0xlYWRpbmcgNDIgL01heFdpZHRoIDIwMDAgL1hIZWlnaHQgNDY0IC9Gb250 RmlsZTIgMjY4IDAgUiA+PgplbmRvYmoKMjcxIDAgb2JqClsgMjUwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIKMCA3MjIg MCAwIDAgMCAwIDAgMCAwIDAgOTQ0IDAgMCAwIDAgMCA1NTYgNjY3IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDUwMAo1NTYgNDQ0IDAgNDQ0IDMzMyAwIDU1NiAyNzggMCAwIDI3OCA4MzMgNTU2IDUw MCAwIDAgNDQ0IDM4OSAzMzMgNTU2IF0KZW5kb2JqCjE2IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9T dWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1hZV09SRitUaW1lc05ld1JvbWFuUFMtQm9sZE1U Ci9Gb250RGVzY3JpcHRvciAyNzAgMCBSIC9XaWR0aHMgMjcxIDAgUiAvRmlyc3RDaGFyIDMyIC9M YXN0Q2hhciAxMTcgL0VuY29kaW5nCi9NYWNSb21hbkVuY29kaW5nID4+CmVuZG9iagoyNzIgMCBv YmoKPDwgL0xlbmd0aCAyNzMgMCBSIC9MZW5ndGgxIDEyNTcyIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Aa16C3gb1ZnoOTOjl/UavWVLliWPJD9kW4plx4/I9kSSHTtOgu04QYrzkGM5 cUKAhCSUEJKY4BCipAuEhgbYpaW7xWzapWPa0rDfAqGbBrpL7oXLY2lvoeHR7RboNqWFTYHI9z9H kuOY9+6VdP455z//ef3vGQ3CCCE1GkcsCo1cPbwVHUZ/Asw/QYmOXL/DveS93nMIESKma8PWjVc/ 90q6HiG2GyHNwo1bdm2Q7XzpuwjpjyBU8tDY6HD6j+uv2oBQdQMMmD8GCH2H4klob4G2d+zqHTes u1P+KLTvgPbqLdeODC/e0X8rtN+Fdujq4Ru2ci1MDKGAE9rua4avHh1L/e9XoB2Btm/rdaNbX+i7 DWgDaYRkPwEcpluDzSA5mg9tD7LCSVTIhLTIjDhkQTqgYJABGaFHDXQKpERFSI94JIMxSJYBCiRb Ae0AhYirh3r+w57L1afPT/8NQtPnCZrA7ECuXqDLXeV7EM+2TZ9nYNT0t4HCcHn/p7eUgCaFI917 0GvoGVJB3wCZjMH1OEikDaXQNor9LPD+Z3V8Nh634/m4FnvR36JDOIQ92I5AisDSdlyPK9HDMyP3 op3oOXQ/+mt0J9qOxkAX3kPn0H7oX4+umaEi+4vCF6FV9Di0A+twHfoz6M7ADN2lyovoWVjNCP3P obXoBrQM3Y32ol+hN4Akhd6GNWY+uIZUKczAPr4Nja9DAU2Cz3po30pxEkrD6gidQNehxbRvBsif QEpmB8jnZpDLOfQydOxEK1B7gQC34mrsQg8B399CL6K7GQ79Cn+ITsEa57EOMI/Cic/h19AqVg67 vBudR9fDvn+VfSX7KtEFMZlet3bN6qFVycSKwYGlS3oX93Qv6orHogvFjva2yILWluam+Y0N4fp5 oWBdbU2guqqywu/zCuUed5mr1OkoKbbbrBazyWjg9TqtRl2kUirkMo5lMKrBdskeS3RulopjKUkj xAXeLWmWnV8alJDR4REM7nAwWZunkmQBCZl6JXNfYgqJzUlJHphLskxiffx7Hhi81OHulDgf/ITF w2mpciDhEfiXHTP9SZhWKoklPB6HxPjg1wNd8Fs87E5LfB/goYNieiTUlyDl5PQbzYBEzZ4kwIGE 5Co0k2S23FFmbfIxMKhTc7a5DGf4KU1xLC4h8xTSvCEhCyE734wkFJEqA7ARHmp0NhSUsPk9CZsk bFkKR7p8CTLsXPOn8KAzvVnoTG8CjqZTl3h6PsdRjzvjzgwkDGGHx0M33Ss905+YUhfFhNhoEZwC UQSaKlIDRk0QIJatU1jTjmmF0XS2TjFIqQX2Gcl2O0nZLImHU1AR4sA36DFd6jk5ferI7C4Ew3JE CMhoDdM1JXlMUuQ24d4kicMSOuyeqjmVOXKSR+tTAU1aSA+vTkjsMGxqCrG+zrFBydnbtwpQsAko qTE3EXecAiI8d+eYOwNtQpsCKMRh6OX49NhoiqgJTglx6FPFEgc9pxySEa6dkiEgaWG49sa3HGym 077JTZqZzEG39O3+xOxeD6EBJbDX1rgznQKsBpN1bo4SiQVnxEa1sSdNhSMeHnZL4+s3A8/gN3yk oP+eDC9pPvCAdEA+MJJYB2EwKenUZnKUzTCSg4s7c3iUHvUIPRroq7tzc5wUMhC0H62A0asSnWNC J/AzvyAwBMazvrljPR6pOEAGZjKdZIvDadg94Qz8igN0G7kG2IQjgGE/MUkcpBc0SGUAK4rD8WQe lSeAHg7kIImpeDJJDpUTgKTwHZTVCe4MmV7hk8wB3nMa+k7V1vQOJDrjRDuBkokl2n5vd/we6r19 M2hsB5pM8PeESaRnudDbn9OCMcIfAlKDOQMGruUlD6R5ejrrWbvjbG6F1YkuoSuVyXQJ7q5MKjN8 cnp8veDmhcyURpPZ2plyU/PHgP/Hww6p60hS4lNjuJVKiCwPh2N9XQO9kql/iIiqyz02DBj4dQie ZofHMEMDXuTTu/M2B9oPNkBsLsO/C6fXgHdyuLuIqzkJHsIh8c3EZGFDKxJgEyOwRGeaArCV5TC5 g1gNm/R1blqeZ5bDA0tS5SE+sD+PhUk8HmJPh0+KaD00pPH+RK7tRusdjyAxGAA5pkjPqUKPZQXp GS/0zAxPCSA3ey+sT/Xjs/QbfPuMbmcMgtHdQhw77A5+PWnp1CCc8UKzpASOUdGbYgnWwRASqDEO ltSKAhAeIpItQAcSnoDHzPCC+zlB4gOSLJY45Ygk3bwBnCUGmm4gJJrKPyf8HBM/isy8hCMSthI8 Ar8K3AO/b2uGzhlFcndmUnkFnH0sICXU6bEZU8ptHmyXnA1Ozwtguo4cGwxGgZzwWaLwhcDg6yJ2 BSKhjFqclHQk3km6dymA/TpiCTd4IrDcflpxd7rHiLAldypOXULSQfoL6JPT51Jx4gIToINA4sir OCh6jrWXq2JtzZdV9HFQ9JuPJMdaYU9iNZzA3QjLEqbHBhN5c6NyokYAa/WQo1zeP8PFAg04NjBn jxQq+bkdFLXETq06Z7szxCCEQTjNjABmL0b7CupBdiJ1QfzP+QC6M2kRbdOzk+7uOd09hW5wH3sc NwIdBLLolIBv658S8W3LVyUeg+zYfdtg4hEGM7FUNDnlhb7EY27IgSiWIViCJCRu0kC9GGZ7hFFS esdjIkLjtJejCNoeOYkRxeWIAIfRyEkmh+MLdAzguBxOpDiIJ7DFTvsYuLeEAEJPS2Jf4qbkWCaV JMxG1pwCgmYL7UhihPYpzMg1UpEwGpXUQpTgOwi+I4eXE7xCiIL6g3G4T4KpZ1ICmD844ARy4CRR YaLljM99cnoaPOhZ8LweSe5bDQUcrCqQdEsy32KgW0RKCtCLpPGRYbIPoqYwVuHrGUlKypkJgaRH UsEMqvwMQNFFx0B4JoNGQFmHBVoFNBjHeFJKBsiiiU1kR2435EPdQqsk9+c2KfOThYLJjFGop+FE 7pOKfAdhBKyxmDpCinFAExYj8Qh+Cg3sfEQAqpGUGyTAoZHloIycn/yKiNwAMwpRnfNDUIVSBIZM OxE5FutTa4skVR1MCD9SV9fBhPBTJIEp5PC0dTBPAGvzkhp25J/FyvwA4A509ZC9wO8gbJ6QPkWm 6T+JBoQbJEw5SpdSQLek9fUMQ7KQG68GjAB5X24wzKX0ERSZ43QOqyAn19CEdvDk9KSwixhJ4VNb I0hoMEEUEzkghxRRMjMXIQ2B41TOxWopOpNRaj99QI5fSu3Mlczi7twUr4WlgL1PALhVNogqUQ0K oQY0LJrMZl25XK5DNYFASGe3hxrEINiF6AihMB9mwqXqSrh/DpjM9eaAmg3X1s4PhYNnjS1Bo63l bBC+LQSg4JqzJa+WEPxZQ0vw1f9laDGEoTEvhBsb2pmmdraxwS+U6xiF0Dh/frjexVjM0NCxFovN IjRig8dACtMkt1Z7bX6HfmG7O+QtVqUih2JdI+1OvTdS4/ZbFMY78McX5ezwx834t1arr7qxojgY bhF6B8zeetd+V11puKvK397WVeupqah0yq954IHsW9y9H23g/uvD78Ox4YPRxunz3ELZKHKhU2CU sRUJmvyLjTpLN9xJ9jEphlWxjNMpY2VHRSdn4KHDoNdjHas3m9Ws+qjZxGC9yPNu5R475JZLX4eD lpx98Szq+H0A2fnTcKPWEugoWTqrNS9E5Dx9Xqz50quIZhOyXz7L5a15oSQ2CH5gK2PgjeH6+fOb wga5XCj3Mo0NRm+43sotvM0+Nnj/d75xe8/qJvOhax5d/1z2L3vuwq6nR/9ONj/72rarss9nX86+ k31z3vpk9vkS+904+B+/wAsfthI+pUBXFsMzizpsKvBJO31KXKLSdGuVvAgXnrcoLazlqKis8yiP hkKIwcC5ujoFqzhaJ9bVPhivY10ej5W1HvWInvIH4x4tr9dbGewSy8pCSuveCsq+esq/l6ny1KNg AJXY+TzzOmY3gK/A32CesWeCAf5MgDKWbCvyP9kWzDp7oS+xKmF9HSMIhjzfC412rinMehpB3w0N dUxFIyce8tSJS385UVPv0W/bpisPBid+IYT8gsNlPGT6uMoXsMhlloBftiL703Wxiqy7uLUtu7m1 reTi2yqrv6a7I3tXtMhW1RFi1wbFyuIi8gAkL5sKkE0Aq3OyEQeQAEmYIAmc4NL7y/xB/5N+TsX6 /QFXgHUdFQOBUiWy99lT9q12wNstllK29KhFtJgfjFtYuUqpejCuFPw+H7KLNlutC+3VzRIOsWsi GgMK2+dyx0DEl5PXmSDIiD+zBqQixv9/bIgI5kuvmfSZXazNMov7nk8REoPlvK1KuPjvBdazT1MR PTUeDHvU27Zpyuvrxj9qbCq3GGTRqMpeJYbYNTne50TElsbbs0s6Op05OTBXgxycaEVeDhab+TKW Ah91rlKDEbcQTzHDQjgUYZJ+LvXMeSnBp5zIAj6TwZzGVll68U+FIzDaqgqz8iMh4i8xKaJ5hVkX aq+yF0Wj6mJvazNiqD3fD3t1oWr0jfxuK5xu1g1ezmlWmKvZ6qNm8DoPxs2sTKlQPhhX2Pd6vTVl aK92RhUunSBvpQYjgpMR+ZPzuD5/vk+Ic/ZocljmcvHVwyMr4tEqGomZQQgBZ6dgcBHcfVySH9N5 8ePrzz003L4yfX1LyzUru/wfRps8VmWBD3nD+fE/HTg9ym1ruWnT2O4GBmQ3OH2efQHiwDz0ao4b P1L7fLU2uKURI+Clbai4rzhVDLGg2GwmtiKauRCJBSH9PIgF82prWZY9WmsqtturPOM8H6oaVyjC SAwBr2ggpHHhdYiGnxcYjBAngXGXliYB4sstLdZ+QYDIzZ00Wa0F7lXUQRwm8ddqo5YBgd9itlpt JBwTPvsrDK8W79y2YG1L3YahZXuT82787fHkd8YOmRYkYi2rGmo3j+7+euy6X96+4dVh3P+1nZXJ WPvQQF3F4OgNvbu/nzTZs69dsaam8orm1hX9DeLuO1O7fzxss2LysB70LwJxl2fPQ+4RRh/k9W+p uoqtul8U1X1qZqsaq9Wc3lJm2Wdhi1iLw8Gz/HHRwVf6J+OVCIfZIAryQcbMcUE2eDdnRVhdybkn wuFGpVm01BxQUi19seQs8Uiv28I0HoNDMtjCxL9fFkyBYs22gta2/fd3IcI28hN/8UpJXwXlsr+x wevLabNcDhlROwsSsVoMOffFUqFQkTHf1Q/cd+XKfQvh8bm/OlpXF5uvfXz1jV9bG9x1Z7dcay6t zB6x33csHqkbCN0i6+vu2Npz199b160ZrXInr3i0qqZUI96xL3tjtFuwaIui+BVuy1j7wnkDdTSG DIH+/w3Iw4Wuz0vDxavH1SbWdFxU84jjnKzzGGflRT3C2G2/RUHZC4wLv1wyo9K5lAQC9rPE/C2f nGAWgyA1mk2exDbKjYJGWmguowNVpArL9i1d/5Mtv3hrz9vf7H8gekYfafbFwq6a9X2tGzFak1o+ /ae/+8Num/mPa1f6hu7ZufOBK+tBx8iZ/gJnKkZu9LP8qVrdJtZ9XNxqwnpTmekK0zoTZ2VNpiK2 CKz6uFjEo2KsZotZFvKUYyJrLUbGiZKScrdpQj7j9v54ph51lMwkdPQYOd8FUl9T0KPgV1ypoDm5 nPFTJ036ZvPIaiNfD+VPE8R2oVyuYH+94Zn9v3tn12t3DR1a7/abzPjirXjf/iU3Lnqc6+5bOqR6 dMuq6Y++886u6t7Gjv7l1//4ey3duPeeu//6Lvgny5sVuVLgF9gKugJX5TmWFN3LKoqUQWUT23Rc ZJXKII9RfT3QLxLr9cE2tu24GOT5Zax+Wdmy4DLWxi4TdcbuZSJv72K7jtudPWZZrFQjiKVCNWbq 2WokO9Da2t8wUV1QoT+egdsH/vTpEv4sfAupM/jNAPDzkqnOsAQs2h5sIXwmXAefSaPnwv/ZPkW7 c0YCX23pJK5QgMGaSWiiHjQMBpxzoXWQfM9v8oOJQz5OLu0McbcebCZemN4FyWcsnPoAoZwr/R7n 9L1wdqSjvjjSdGHywV1v3Lft5P5F3Qur/RULG5b1xXZ+a3V4mQ9vurhm0ZLOnkU9ixd5vb49B/fe Yu8Sv9/DrjKpncPxh39krG1wuQ37D111b7+5cfWillS5a1lLcCBWWXN7as2BwYoiefbJvbuv27n7 5u0fn3BGA92dg0vKQ27inzFqhXz/oOw4WoC+nteDygqDjq2uqp6M81WWBS4HC1+wEL65aTLejFqx csJiaVvgniAhb+nrJI1/HXVAephziJDBQLIYhvzNRqVV+rmzwaBPH5jENGDNuMfGdobm1qD7cuIy OZoycATHVjT6wgb83NDtvdfc0MRqLH5H1hEUtNqyeZX+5U2sXG0sd2atrnKTjmOLzP5qbNnDru6P 9R/flb2rZmldqRmSJ3X14nVYlr62zRXsr8ve1NzmKbEaAa8wFVd0iqxmZX+Tx6yM6i7+DPxNDwS2 Ntm1YBkO9JM811pYhmVHRD1zBcNMw50i8yTza6hwKsTwDMOzjOGEXq+bjOv1xZyDm4w7sJExTiiV pc5ClniaPz2TKMIN5dLfkLR67Zpt14EHIm429FVXmJV3fWK6JIaMmc0zlTIwx1P8fPY/N8/zaVXF gXJs2pNnnl127fvvf/iCtrp7HX5+XsRrUsSVF1sKTCroERMCPbKh/jxHLBbzZNyCbJhTyBWTcTma 0GqL7YXTFo7aQc+mn0tbyIhJdxKsyDpH3vhZjS9cEKrKQoWKPeu6A9pPyozuD2QmPwc+L4n+Lb8/ UelVe1nvMRL2cJwVOZEVj4kcnzxx5ZUrJ+NX6m0l8xp6ZEvCxb29SybjvYYJl7JmotnV3OwaSqLO ib6c/oMBtASD/Ov1fD5LDpPMg6g1iJBED2IJM7ZBBBn8igvn5fgF80JgzZkMvUBul08sLlmOjiO4 XLJNrYnLW1OeuzkLI8qA/0UzdHTJ4vVxy+ix/r5N8bKcVblqy7Wa8qC/pKbWbVLIeMGX9dYJGpnG 4vA5ff1Nam9t1hPyaWWmihA27mUT7Iouf8+CtUuqExOr59iaZtU20cl7yqsbFmT/Md5dU0ruWap7 UlgTHWquLtHVDQSze9b2BtTRKFW7+xbDM+aiuJL4LJAldwxk2YLuycsyYGNa2JLiksk4LrZUnPD5 vJNxn77SoKvVsbpjYi0fnpDLF7gqK0wTLio2Q5imizS851xWXmCXPJf7i+a8zOPNGQ7/uOUZ/5lM VthIkCgIijuWddR5tXKtzel1+geaNb5gtvQSL/Wa9rUbWwa2xEqpKKLqQM86rF401FpRrAkuD2b3 rVv8CVbdwTZ1+IKr9q/MHs25OZKPQ67EhYF3esgAh/LcsyOa/iGrClz9cVHFa26x2938LVwhcIOD p2kQjcxEhfm5I2ZCap4kKSufCYMkRNJACO6GPA+Uy5kFd710w+KJn1z13gc3vpH90bpU46KAcd2a +ICf3/jmD249Pd42/cHD71zH6F98Yf6G25P/9tLK79N7iewAtxH2LsDd2+P5vTcQ78IqJkW5w3LC ZDKyxknRpA/Zaktq2dpjYgnvqWArjosea+kt1dVhi9XLogk1PZctH7ounSynCCTfmGW8NIpVftlV LufDZ02YlBU8GrU5GsEUOfPN5RMVhlmJg9yCn+WrGrK6oI9n1eYKP7bs1mtWHrvikUc2PXd848iK 5OrhK1fXrpj/w952ryYa1ZW3LWGvWhSpdpiVceWd7PKejz78h9/tLMHtu3c+9cOnT9WtaASXmLMj ltiRH/1znpvNBqxGSl7JqFglJzJqo7pczRo4Dh6AEtfoP+H1CpNxr95abC+ejNuVokJR6YfMuXTG F0JKVXDtl7iIIJLB3cJZuOSTuLqvttCcUEa1cc6cef8Ht7gkQ4bnJcDCXNSY5df+Vdtz76q22I8N TXXWxlqTXFddnzVdsjK2n125RJt9t7XdMS/c0JB9at2SgGquA8LIB/cbDPdLeP5zPM+3GpNqMq4w wfNiDas3LRJ5vVPU8N1Op52FL7m/MBrhL1CzTmnO31+cCRvC/OmWYOEGAx5sEtPJsYjGRM8Xzjmj bPzc0YUbCAO5zWwKWzwWD2EHub1sYpnEHX3H7trTBrdIsj/g0uyblnqfs2ae44betgf+lgl2FlXG tvR/uCfbtm1LuKjEntMVEfxGBt5cq0W3589cYag1IlQ7GUd6Vhl0nihRl7pYhQeM8RgxN6d5Qq0O MhO+GScShvuNQjwMLv0NOOAO8piPPgoRSz93thlXS27qLx+aNMHRXOBJ4VFR7ukrbdssMqGpcOMN eK5CxAc05fP8voEWucFbhW+VGSuD2fO7VJo1Rxdv3tcMqY7J42TPXXwptaWjtG55EO/vWVTp0EQv xpd0VTuKYqo72JXxK+7Zha9pjngckB1SGzJle7lOypen8nyJ2H2VrMVvdJTXyOB2YTJu1bsQr1eA aijAnLBWXapmcjbFOcCCLEjPsy6Xpbwy6LAAs8L8mXr4I8UW5ukd99kAsZ41ubvFYDhMeGYjuQDx w7Vffi2RcxAufs50SZmOoU/d8ooiYPIs22MhTyZsJhN9FEfaOlbBLFu4/cBI78Kt2grB37a0uSX7 kdNT5cJ/CtaU3PEtszlUgw+UCmU1/to7vztg+k1QqN5+HfOHKxaUyeHhqtcbWprtxftCPUJ1kyIa U5VUL4d/aejroAjpumK/WaePvI/UEOvh87NJA/xDk7+asqL8HGSZGN7GZAgWPjBOcW+2BV44Lfr4 QjZddILOlOvLQZssjp7A/wxZw91oI/ctlOI2oRTzLFx/B8WBBrluFGFPoSGuA0oV8nJnUCszgXqY r6FWRRnq4V6E8lfQ9zTQTQH+XeSDugj0JlhiP9oP/+y+xTzEZNlbuXaZXLZVrlToFA8p65X7VWNF 8qK0WqN+SFOueVg7SHdnQ7fB/3IpeFuUQTwKolF4+/XbuAruKAgXMLxXSq6QspL5lyzq6euJBmLD V6+/btNwbfTaLWnoegy5setHKjte7D6JSwsVZ6FiK1SshYqxUDEUKvpCRVuoFBUqqkJFWajICxVZ ocKJ03T5jyj8kMK3KXyLwjcpfJ3C1yh8hcIXKDxL4bMU/pzCZyg8Q+FpCn9K4SkKH6dwisIfUHiE wsMUZig8ROGtFB6gcILCWyjcT+HNFI5TuI/CvRTuobCfwj4KeyjsJvDX56w254svAdh9k9Wx+6bi 5/8P1K8XU1+Dy9VbAWy5FsBV11gdV12z77qSHTvNFufGzQA2bAIwOmZ2jI4d2FZSvN16Y6zYswuK 4mnb08xv/wMHdvwQ257AFS+nntj6xPgT3D33MgHxXrzuLnznUSZAnkvz7zhKW1Qj9pGnR1j3iFbf QpA1i8p8LfyJ0b0t9x8Xyuzf9Fe3fPM4DnQfx3cfYwL8sQ6x5RfHsFpySBMSu1CLFVgGShPA8vyV y19lYk8GBQ5DOQQlc0AeuHkfDuzZKwvsnSgvu+0ADhyEMnFAFrgFiqPJYp9vsTRajA0Wfdiiqbeo 5lnkIQsbtKA6y0nsFsdj7R5/ha6yQq+vxpUXpgMX/qL/4L90f35fF/ogdIE5fwFXB3Q1AX25oPMK eleZzl2m1/MGjapIrZErlBqWk2kQZjRyNl2m1vfqGTU8moizG1Q72IOq76EHVf9Xr1IjyEf0C9AC VZIdUl3P7tDfh+5T3aN/TPVLpHsMnpqWi0a9A5dq7YoSrYW3aY2cWVu2UIc9xKwA8lCCUDqgfAvK k9gj+uU1kepIZcQf8UbKI+6IK+KI2COWiDGij6gi8ggbQZG+8CCWjL2odzAqmTBcl0elcKD3JOse kOoDvZKqbygxhfFfJQErMbfB2yeDEncb/LE+CO81rhpKnMTFpPsA/C2MMZJ6Uwe+noS/6KQ0eYlr vDQp1ZPKHaVJeC+tvl9yCNHA3M/2HRSzfcfO2T3bpT93Shc6Nw1LF+C1yQ/grcMLnSnpAyG+nVBt l6o7pZrOYakSkH4hPntkAF/WCmxHsEBuDXLZvj2wfcd2UpPsUgec93LqQGBKRQ7eNxCFF4FW90pp eB3P0TeUkkqEKLxbCq35fUPwmlZ0CsGLQ1PwGs/glBzA0FBiYSm8Gp3GpVCcUGxQrFCMUAxQ9FC0 UIqgqKAoocihyKBw4tL0R+kP02+n30q/mX49/Vr6lfQL6bPpZ9M/Tz+TPpM+nf5p+lT68fRU+gfp I+nD6Uz6UPrW9IH0RPqW9P70zenx9L703vSedH+6L92T7k7PPdSXaoPk/hsf9P8AXm1e0gplbmRz dHJlYW0KZW5kb2JqCjI3MyAwIG9iago3Njc5CmVuZG9iagoyNzQgMCBvYmoKPDwgL1R5cGUgL0Zv bnREZXNjcmlwdG9yIC9Bc2NlbnQgOTUwIC9DYXBIZWlnaHQgNjcxIC9EZXNjZW50IC0yMjIgL0Zs YWdzIDQKL0ZvbnRCQm94IFstMzc5IC0yMTkgMTMzMyA5NTBdIC9Gb250TmFtZSAvTEdJUElCK0Nh bWJyaWEtQm9sZCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvTWF4V2lkdGggMTM4MCAvWEhlaWdo dCA0ODggL0ZvbnRGaWxlMiAyNzIgMCBSID4+CmVuZG9iagoyNzUgMCBvYmoKWyA1NzggNDY5IDQ2 MSAzMTQgMzY1IDU1MSA1OTcgMzA4IDIyMCA1NzMgNTY5IDU5NyA1MzEgNTIwIDU5NyA1MTMgNTM1 IDUzMQo4OTAgNjA0IDM1MCA2MTQgXQplbmRvYmoKMjc2IDAgb2JqCjw8IC9MZW5ndGggMjc3IDAg UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkstqwzAQRff+Ci3TRbBs5dGAMZSU gBd9ULcfYEvjIKhlISsL/33vKGkKXVzjo9EdzWiUH5vnxtko8vcw6ZaiGKwzgebpEjSJns7WZUUp jNXxRmlNj53PcpjbZY40Nm6YRFVlQuQfsMwxLGL1ZKaeHnjtLRgK1p3F6uvYppX24v03jeSikFld C0MD0r10/rUbSeTJum4M4jYua7j+dnwungQqgqO4lqQnQ7PvNIXOnSmrpKyr06nOyJl/oeJwdfTD bWtZ1BVLys22zqqyBEJS7hSjAkJS7kvGDRBC9MC4BUKIbhh3QAipdox7IIRoyvwIhODVHD0AWRJf YIdfCN50bg/UafPAUQOEkCptJuCQontEFbplSbllr0I3LBxUMKIbFpDLUOhGXVswjCifhXM5s0L5 LKSS6fp+74lvkid+n5C+hIDhpGeR5sbzsI7uL8dPnu8/6QcqKKl5CmVuZHN0cmVhbQplbmRvYmoK Mjc3IDAgb2JqCjM0OAplbmRvYmoKMTIgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1Ry dWVUeXBlIC9CYXNlRm9udCAvTEdJUElCK0NhbWJyaWEtQm9sZCAvRm9udERlc2NyaXB0b3IKMjc0 IDAgUiAvV2lkdGhzIDI3NSAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgNTQgL1RvVW5pY29k ZSAyNzYgMCBSID4+CmVuZG9iagoyNzggMCBvYmoKPDwgL0xlbmd0aCAyNzkgMCBSIC9MZW5ndGgx IDkwNTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvVkLeFPHlT5z75UsWa8r2bJl y+ArhB3qa2JjE7CxGmRs8XIe5hEiJXWQwSY24RkgJSENDsSFFbTFCyZtv/2+pN3Ndvv6uJYbIpOk uNmEpm3SmrR5tEkpS+km3dQfhCQNbbG0/1zJxhBC6bftXunMmZlz5sx5jqQRMSKyUheJFFy5tnUD radzmHkJMLjyvs3K3rvi3yRie4kMNas23L12S66cJDI+T2SrvnvN/asU/9t2opzzoG/taG9tO/eb tb8kKtiA9TM6MGE9I/Zi/B8YT+5Yu3lrWYtUiTGXP3nN+pWthoXGZzA+i3Hu2tatGwyq3UdUKGGs rGtd2+53+cownoxx2Yb1mzaTnW3EuBnj6Rvubd/wbL3nPowfITK9gTmGF3+sZKTvASt0W2ZGn77m RvgYp/ixmb99gls1/jFAy6yxCZNRpQL48UXyj82N60gLOZUo9Wu9fVtv3yRKbkm9g4jMRI979f/0 mLCaw+WK/s1Cv0fLoOlNqW9h5QC1oD8v9a+fLIXNo3NsOrOyG+gVVkcfsikIZSm9iHBym0cAyBJm oZ9kZAzQ7+kb9OInS+QU9u/j6aweUgfoGDL8o/Hzev+7aDlcfB6+2L1K73Himc6fr6WROFVwiTE6 Sv3USyfSc2PtAHY+QD10hJnpPVYiqLSHPcNy6DQdp220R3hK/Dyh2qDlx58TkLYbq8ce9in6iHVR Pb1Ot9I06mde1k4vMTv2eBeWvkXv0g46yorGfJZZyePLH4mk76YzKj3+B7Tb4OsXaOW1S2ZTmMg8 n8SPyihBfWQq8aIdaX4p4+0UagL5pteH3qtL05EP65ADM7FHEctDrpmYSOfpD/D+68iKAdpHj9BW Hk+d73rwKfCpzCQm0J/g1bP0ffrqKBerh1RVz/JXU99iJXQdxi+M7nR1bFjF/T5azyaCHscv1pzh 1Uydpyv8g1FZyff03mE6TH+mk3SGfspkOoyT+SPs+xzybS+ivhcabqMV9D5jSRKfg13NeF3lMRQZ uCWXPtvoAKzn1bIeupxgL2OnKz0HkI+X5bixmb16WSUR/QB1/DjkjX++M36Q6R8Qt9IHtPASymnY c1x4ivagbnbQOp22XnpcGsAuZelXMLh4wfxA3azampkzbpheXTWtsuL6qeVq2aemXFdaMtk/yacU T5xQ5C0s8OTnuXNzXE7ZYbdZLdlmU5bRIIkCo3Lm0TwN4dBqraAhqln9jX5Z0ay3nL25QiOX1+d3 KtUVkakZLs2gapTTpOU2h/soWBPRjOrlLLdoYol8zofFN3uVkCaV4O1f2NqmTVkc9vnl17xj9AjE aoUNYZ/PqwkleC8ACe+FrUqbJjdjHgR9ZoFGzWEOidSpGkxSjS+CdnFYmzg6jHBpaVPGKYnTJDV4 mZq3sJjcZy1oaNQot4+spzRyc7azNaRRQJuiQhEZPV0aVWgs95zGcjTmvhkmXboFX3ay5go+CLWt 9ofaOuHRtuhFn55Ne9SnxJTY4rCz2uvz6Uo3aS8uCvdZshv8De3ZsIL0CerLtmDGwicQlg19zHoj 0zuCNTSrTyCTDe5zcXVDHFZrwT1RdPyN8BsoORcpidTg3vEkwrI0E4FN7zF9T83YoGWllVA6tWCr RnuUvvLB2N6ETCuiqrXN39b6mbAmtkKpPhJLQh1LtaKm5jswBSUA0Q6Fh7tRb3jwlFCHEsOY80bR +hux9NL5to72KE8TFvU3gmZuCO/yDXo1F3BIc6qaDcttD5z2irGQp1Phw1hsl6I9vig8nurjPEgC z9RyJRbyYzcIC62ewyNWMRY2PRsXtOnBCe5pVbSuFavhM7xb947mvy8ma9Y/+hAdxAcreXVwB3No i67mpqzGSglIie1p103dq5uGfFVCqxs58IXIfroNq+8Ihzr8IfgzsyEcgvViyeVrfT6tQOULY7EQ V7G1Ddpzz+BdoOpqpAeoCa/KoE+DFlyqI1qqxwA7BlsbI5mpDAMoEuKgBaONkQg3Kh0ALatkl+F6 vxLj4rNKtFxV9j0P2uDU8qbF4VAjz05wCg3hTw97vMPoNzWPTTMPeGIVw9xJnLLE37QonQUd3D+8 iS5NFzC8lok8WDP8utSXPd6XsXauf240FpvrV+bGorHWRKprhV+R/bE+qzW2IRRV9MpnmD+yx6vN 3RvR5GgHm4Ug83ybu7hJy1l0Jw/PXKWjFTN4z/b7arw+J0SneXByXJmcqTNkPPKe11lM/gMstuJE 8ipz+fGSwKng1eQaXqbQ5LYw6mAltgi16Q3qYwmEe3mliJGSUOeSjIO8PmypJww/9xZlZiHE5+M1 tCcRpBUYaF2LwumxQiu8cQpWqIhdlFMGRynu2zila5QytjzqR6w8Tdhfz4lPymmc52P5HHP6XUot P8yhHd4L2rTBpbDxfI1mgsf0cOc0hEWvwFnQE7wi72Wr+EgIaPmqvpD7BKdkTPYrQ35NVjVDQ3jQ G4goshMHJBtLhoxEnqbykP9HjB+ilCtrLKCxPF5WhEMVbsShn18D4thCJRSLZrJvvH1g5dxtHWN1 lLYChcuNhBtkP+rWm/aH0+Xnpr7Es330U6FkLi8qxEb32MKIZucfdpr9D3oD47wNYQXHEMp2kd5R QkoHj7qmRBv18yDi5fTR6UTqZLSRn39hJBpYvJn8RpbDbZmayLihaWl4tLc4/DnvA5GpCVpS3pQg Mz5JGftiJMFS3QlqnDBAZhKX3wXy0nJFCXU2YkMMbivHRJkPvWXlyE2e+mF/hH+SLGiLKTz522CW jkFoj0UqkK9LwjgvCXWoBSPesW57JDILcm7ncrAE7LEIJKzOSADWpypGwBQub8JJVdocxmHb1YhE b+QlDHMHUVWD3GJuSGRMU2j8uU5PRuc7oHOkDPQ701KQq10QEYnFuMwlYT/SPBbzxmBHZpxgdPlE MDORIL4EhocSrKsZa4H8+veDkN/n556PNGKrz8Dvo6dUglqu7uG7xvTGyuXQ9i7dw9G/k4dbr8XD K67JwyvHNL3Ew23QeSX3cPuVPawJpVfx8XiXBtMuDV7BpasucendV3dpx5ii0KoT6nXoLl39d3Lp Pdfi0jXX5NK1Y5pe4tJ10Hktd+n6K7v0H5G0Gy7x8Mare/jeMb2h5CZoe6/u4c1/Jw9vuRYP33dN Hv7smKaXeHgrdP4s9/D9/38efmCch4nwqwe/pfHCzV8W4RBeoibIVIHDGGCSE0RDAD5GX3wLfWAJ WAQ2vEVH9EuiZVgkyUdIwE0W7wty5TSf0+csQcPAcSEodl3oMtBfKCh1gauTiPXgly/fc2rQIx0y ONghchkPGYyCQTjEgiYzO1RVqbJCj3zz8KA8KA/T7OHZw9MqqyGVATrZlOQb/Ndp8g1xEm9hBqOW 1JuGqGGY3LQjePudIssS2W1ZzJzFmNPpFGyOCQ7B6nHlz8+TWIGRtdtZu4ttzdqdJVCP7GbunB4h J7vHYusxSRaSdxqC2/mtoUyVNESSWaT8PMMaQWUe+djyu1paCqGa/DzNHnltGNAC5VhLSwu1tKhA eEqMPoWcMvmq8t34+SmgW1010xB9Pfla8kByNfsK23buTPK9p/4nyZzv/+pEXZR9la1n97H9te8t T76ePJP8IPkL/YeuQMtSb0szpZVQxU2PBic7bazetsh23PZftvdshm6J9UpPSEKhkRk9rrz586Tb JUHEd5NgIUxdKLIHspn1UYeTHXX+zCk4nfZc+rKM30FBxZEzX7Z/WcjL7TXJssPFzKJrp8XqhOEW mLoqbSrMHHlBHobFgzwGI6+pw05XbUXLRt3gjSq1qBtb8Cox+mHudNjocvpcvqqZzCf7J0kzf/5s cjj5HPOfee/EyO0TWV3v0yNLWOzJRMmNrIbZU2xmcij5VPJYiP0Lv+Rj/NYrKw+2euk7wew8MxON OUbBbEmkhoJtZuv8dyznLUKd1CS9Kb0rSZvNj5gPmEXeCHY3uU3Og9mi56BBZg4T5dq7baK3m4Jk Yw5i2aKbcm3tdbnd7uB2N3O4Z7uPusXH3UxzM3KDXDTB3c2TDqZuvLdlo557+qiFd0eQhDCcZs8e rh4arp49NMgDvnEj7L+rhbUgMd0zqqvy8mdUKwXM55zun5SFPNXRACvacfbBx11f/RWbmjy9o/uh 5OmdOx+SFv7snQfWvZP83oXfC4f/c3BknnD4+R+MzMv4QDqgx7t1gLJSbwSzYbngcDkE0cEdYcnN ny+ILlGQJQT6neAEjB2iTbc7m7K7zYIMs13mDsFJ7YKariNuAFUMQv+qKhU2qstbYIE6qrj7orZT en63/1vJNx78wg6u45GvXTgvHH36hyM3o8bSufgCdLNQHn0mOMtuYnaJ/ZPtKzaBuZndwew5LNvG RIuVWSy48GF2g7PXKFt7Kc++05y7Uwx6zJ1CvojsypT3WG1zx7e0LOclxB9Dunr0tqTKOb3UP8no zs0TPp9MJY+zaczIsti05E+T51O77tuy6/MFuNPLYtlsevKl5PnkueRPB9iu/qGhJ/tfgdrIq5tS bwtnDCWUQ7cGq7JN1Jvj7BXy7AaLodfksDmMksVhknIc3VFpUBJwmkmKtEHahysmTTopmSQk/Mgx HESD8jH5GAoBPV758svTKnnmFzD/DdU3lLir3X5nLspcOLP608nt27axKe+++0TpDcZi1iHMGRiY 9ObAyO9+jL9K+LHLaOdNXd+8Z7kj8CHzmriW9MI3nPPH8E2pN7PycJoxfA/m/PwBznomibs8XPA2 f1RnOzlGSdOJzEZMCbhlZ3+mTkM/tUgaLct6jgZwwzdgKKJl4o10E5hn4bUK9+zz2Y8Fj7BZeEaX ZKa1iPGtOJeZfvBtw41kzFaNkzqtsUvH+KOBPES3NC9c1tSg3rRlZWdb67x7W9e1tU+ds35NG6Rn /jlJ1RAfffwxY0qkCVRK83EzuYgW0+0J2oiPjrsBLYAlav0kulXIwX7L0a4HbAd8CfAYAB9Ygotk gAKoBGgAg+ACLY+8Oi5IDbK3glvMltrfnMzLL/rFq2i2PZjn3fZgwfFX0L/vs2jWbkCzZj2ae9bl eZevW79u+zqR7mH3rNt+b+HmLbnuortXo1nViaa9I9e7vmN7x5c6RGqX25V2rf1ku2GwnbV3dG8s LNiU90BDge9+gCAMCAeF3ifripMpQU0woR8oiK/0h7Oza8/2Zqn1dqFOmEV1VCwoQjG8qQqlbAQe UVODwoS401n7rDBBKMpMFMUrKmsHQCmKFxRmOg4ZLEVjawrjOTk6pTBus4NSAAqXmsdG4kY1u76S vYZafJW9gsio7BcZ/PMMPp7BQxn8MvuhzvdSBv8kg38MDB3ZjzL4xQw+xn4Yl1RLvZm9gHhZMOsF CKkh9nx8Ri30eg2dYl+mk5uf7vSb7bWOZ9jDVAwQmBo/KMJXn4r3cHRdf4+Ju6yk35xdC+zvt1h1 HMc4wbzxXl9xgvniPcVAnjSSDsO1n+Bx/oFX99+unNod+03q7l5J7dnPVPoi+2JvttrTK6r7ewX1 y71VxY89yoYOnjx49qB4sJepwd4Cb22wF85OCOviDxvUhLAmftSg8mCs6Ecwu54W5hPDyNtfeh30 A87L03HcatMD4o4rkzKdfE/tgOAV3HERlgn58TyMsTQ3braCkMsuxPUsudAPNWHyhThSd4CdYI/G J/owPhHPLaitz2bPsaN6dH6QwYPsKBZSfRn7NckAgRS0lXqvi30fcX+a4TsZ4nYkgwcy+KkMPpzB T2ZwPI1TJ1kibrVDh37Why0sT7M+GDvEtNGoaqNR1eKZqGpxRPVZtpPtICcVowJ3cAnPsA7WSVWI dH58uxHhLYt3czQlvlsCKo0/wtHk/odhxxE2CSpP6gcDjC6IF0zkXkLHo7sLHbsTGVAclHf6ikcu wJd/gWP/0oWsSQ32n3e7a3WMz2oec+t5m632jx+K6oddJp3h/apqneH9yZN1Bsv7eYW1lX3BvuY+ fJZiQZ/TUxs8PbWiVj7NuKR44USdcUZcdtZqhwzqoW6DKv+2+bf7fivu7UaSniooqFVOzT712KlD p46eOnnK+LntmH3I4ah9KLNn16w6fc+uzN5dZeXpsVcX3d/lT+uS25Xrqe3qFtR93ZL6MKRsh3yu lHfXnObaXd3Z6k6+YXdJSW2wu7gYDYqh/n5BFCTBQFb2ETvP/gT8AfuQ/RH/fhcL/NwuZh/RbEAz QBQc7EN8K7AJZqyxABvZecEE7KCAYAYYASIFwBtgHwAew382X4PM/ewA6wXex3rYPwN/G/i7+Gb1 BOjfAP466P8G/G2seQLwdb4WsB+wD1CDf3Tt0KWOBdinsb6CVbJpwOVsKrseeB7wAqyvB70B+EbQ +Te3eVhbD7gRUAeoAJQH9we8M92eGW73DW7XdLej2m2tcpunuY2VbrHCTde7S6+zT7nOUabay1XH JL99st8xsdiuFDscstNqzrZYjVkmqygZrMQEK4mu4mLxVvGomBKlYsdsR7ND9LIJNk9Woc0t59tc Uq6tPFAWmBIoDUwOTAoogYkBb8ATcAdcAUfAHDAGxAAFmquZ5mqipqVztBwGvGSOVq02JURlsVal Nmnm5jvTt1uY1YTd+CxYqkm7EwKQq+GOO8PIdH751e0dQPKT1hTt/kIE/2zM0dhuzY/bHqAgbp6U 3bh3XRruE9gc3PBrM3Hjxrki6gStjd+Adk2IaFW8s29CBJe6sxZpXv8c9UrPpk3jZ/umlIa0slCr Vh6KNo4n/PW+LohdgQ8b6Hug2Xw5+ZLNLw42bboiJ2F5Wt+PkUf3uCiD816+Hb5rNoS9EQ4q/j7Q gggPtMr4YJwrEux1/p9Fgr2RRr9Mo1+l0Ztp9BZHukqb+8w8uDcuntOkmXADb2q+Uyv0Y/AiBjMw sPrn/C8icr5vCmVuZHN0cmVhbQplbmRvYmoKMjc5IDAgb2JqCjUxNTkKZW5kb2JqCjI4MCAwIG9i ago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5NjcgL0NhcEhlaWdodCA3MzIgL0Rl c2NlbnQgLTIxMSAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstMTA4NiAtNDQwIDE3MzQgMTE2OV0gL0Zv bnROYW1lIC9OUEpWS0MrTHVjaWRhR3JhbmRlLUJvbGQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDE1 MCAvTWF4V2lkdGggMTc1MCAvU3RlbUggMTAwIC9YSGVpZ2h0IDU0MiAvRm9udEZpbGUyIDI3OCAw IFIgPj4KZW5kb2JqCjI4MSAwIG9iagpbIDMzMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI0NyAwIDAgMCAwIDAgMCAwCjAgNzEyIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU4 NgowIDAgMCAwIDAgMCAwIDk3MCA2NTcgNjM5IDAgMCAwIDAgNDA1IF0KZW5kb2JqCjIwIDAgb2Jq Cjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL05QSlZLQytMdWNp ZGFHcmFuZGUtQm9sZCAvRm9udERlc2NyaXB0b3IKMjgwIDAgUiAvV2lkdGhzIDI4MSAwIFIgL0Zp cnN0Q2hhciAzMiAvTGFzdENoYXIgMTE2IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+Pgpl bmRvYmoKMSAwIG9iago8PCAvVGl0bGUgKGRyYWZ0LWlldGYtZWNyaXQtcGhvbmViY3AtMDYgU0Fi KSAvQXV0aG9yIChTdGVpbmFyIEFuZHJlc2VuKSAvU3ViamVjdAooKSAvQUFQTDpLZXl3b3JkcyBb ICgpIF0gL0tleXdvcmRzICgpIC9DcmVhdG9yIChNaWNyb3NvZnQgV29yZCkgL1Byb2R1Y2VyCihN YWMgT1MgWCAxMC41LjYgUXVhcnR6IFBERkNvbnRleHQpIC9DcmVhdGlvbkRhdGUgKEQ6MjAwOTAx MjkwNzU0NDhaMDAnMDAnKQovTW9kRGF0ZSAoRDoyMDA5MDEyOTA3NTQ0OFowMCcwMCcpID4+CmVu ZG9iagp4cmVmCjAgMjgyCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDMzMzA1NyAwMDAwMCBuIAow MDAwMDA2NDY2IDAwMDAwIG4gCjAwMDAxOTYyNTYgMDAwMDAgbiAKMDAwMDAwMDAyMiAwMDAwMCBu IAowMDAwMDA2NDQ2IDAwMDAwIG4gCjAwMDAwMDY1NzYgMDAwMDAgbiAKMDAwMDAwNzY5MyAwMDAw MCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAyODExNTkgMDAwMDAgbiAKMDAwMDIyNzA4MiAw MDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAzMjY5NzMgMDAwMDAgbiAKMDAwMDMwMzcy MSAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAyNTk1NDQgMDAwMDAgbiAKMDAwMDMx ODIwNSAwMDAwMCBuIAowMDAwMzAwODQ1IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAw MDIzMjcwNiAwMDAwMCBuIAowMDAwMzMyODcyIDAwMDAwIG4gCjAwMDAwMDY3NzggMDAwMDAgbiAK MDAwMDAwNzY3MyAwMDAwMCBuIAowMDAwMDEyMTIxIDAwMDAwIG4gCjAwMDAwMDc3MjkgMDAwMDAg biAKMDAwMDAxMjEwMCAwMDAwMCBuIAowMDAwMDEyMjM0IDAwMDAwIG4gCjAwMDAyMTkyMTkgMDAw MDAgbiAKMDAwMDAxNTU1NiAwMDAwMCBuIAowMDAwMDEyMzczIDAwMDAwIG4gCjAwMDAwMTU1MzUg MDAwMDAgbiAKMDAwMDAxNTY2OSAwMDAwMCBuIAowMDAwMDI1OTgxIDAwMDAwIG4gCjAwMDAwMTU3 OTUgMDAwMDAgbiAKMDAwMDAyNTk1OSAwMDAwMCBuIAowMDAwMDI2MDk0IDAwMDAwIG4gCjAwMDAy ODcyMzIgMDAwMDAgbiAKMDAwMDAzMTgzMSAwMDAwMCBuIAowMDAwMDI2MjcyIDAwMDAwIG4gCjAw MDAwMzE4MTAgMDAwMDAgbiAKMDAwMDAzMTk0NCAwMDAwMCBuIAowMDAwMDM3NDcwIDAwMDAwIG4g CjAwMDAwMzIxMjIgMDAwMDAgbiAKMDAwMDAzNzQ0OSAwMDAwMCBuIAowMDAwMDM3NTgzIDAwMDAw IG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDIxMzI5MiAwMDAwMCBuIAowMDAwMjM3ODc3IDAw MDAwIG4gCjAwMDAwNDM4NDAgMDAwMDAgbiAKMDAwMDAzNzc4OSAwMDAwMCBuIAowMDAwMDQzODE5 IDAwMDAwIG4gCjAwMDAwNDM5NTMgMDAwMDAgbiAKMDAwMDA0NzU5NyAwMDAwMCBuIAowMDAwMDQ0 MTQ2IDAwMDAwIG4gCjAwMDAwNDc1NzYgMDAwMDAgbiAKMDAwMDA0NzcxMCAwMDAwMCBuIAowMDAw MjQzMTk5IDAwMDAwIG4gCjAwMDAwNTQ4MjIgMDAwMDAgbiAKMDAwMDE5NjM4MCAwMDAwMCBuIAow MDAwMDQ3OTA0IDAwMDAwIG4gCjAwMDAwNTQ4MDEgMDAwMDAgbiAKMDAwMDA1NDkzNiAwMDAwMCBu IAowMDAwMDYwMzAzIDAwMDAwIG4gCjAwMDAwNTUxMDIgMDAwMDAgbiAKMDAwMDA2MDI4MiAwMDAw MCBuIAowMDAwMDYwNDE3IDAwMDAwIG4gCjAwMDAwNjQyOTEgMDAwMDAgbiAKMDAwMDA2MDU1NSAw MDAwMCBuIAowMDAwMDY0MjcwIDAwMDAwIG4gCjAwMDAwNjQ0MDUgMDAwMDAgbiAKMDAwMDA2ODA2 MyAwMDAwMCBuIAowMDAwMDY0NTMyIDAwMDAwIG4gCjAwMDAwNjgwNDIgMDAwMDAgbiAKMDAwMDA2 ODE3NyAwMDAwMCBuIAowMDAwMDcyNDUyIDAwMDAwIG4gCjAwMDAwNjgzMDQgMDAwMDAgbiAKMDAw MDA3MjQzMSAwMDAwMCBuIAowMDAwMDcyNTY2IDAwMDAwIG4gCjAwMDAwNzY5MDcgMDAwMDAgbiAK MDAwMDA3MjczMSAwMDAwMCBuIAowMDAwMDc2ODg2IDAwMDAwIG4gCjAwMDAwNzcwMjEgMDAwMDAg biAKMDAwMDA4MjA0NyAwMDAwMCBuIAowMDAwMDc3MTg2IDAwMDAwIG4gCjAwMDAwODIwMjYgMDAw MDAgbiAKMDAwMDA4MjE2MSAwMDAwMCBuIAowMDAwMDg3MDEwIDAwMDAwIG4gCjAwMDAwODIzNTQg MDAwMDAgbiAKMDAwMDA4Njk4OSAwMDAwMCBuIAowMDAwMDg3MTI0IDAwMDAwIG4gCjAwMDAwOTIy MzEgMDAwMDAgbiAKMDAwMDE5NjUwNiAwMDAwMCBuIAowMDAwMDg3MjY0IDAwMDAwIG4gCjAwMDAw OTIyMTAgMDAwMDAgbiAKMDAwMDA5MjM0NSAwMDAwMCBuIAowMDAwMDk1Njg1IDAwMDAwIG4gCjAw MDAwOTI1MzcgMDAwMDAgbiAKMDAwMDA5NTY2NCAwMDAwMCBuIAowMDAwMDk1Nzk5IDAwMDAwIG4g CjAwMDAxMDAyODEgMDAwMDAgbiAKMDAwMDA5NTk1MiAwMDAwMCBuIAowMDAwMTAwMjU5IDAwMDAw IG4gCjAwMDAxMDAzOTcgMDAwMDAgbiAKMDAwMDEwNzEwOCAwMDAwMCBuIAowMDAwMTAwNTYzIDAw MDAwIG4gCjAwMDAxMDcwODYgMDAwMDAgbiAKMDAwMDEwNzIyNSAwMDAwMCBuIAowMDAwMTE0NDc5 IDAwMDAwIG4gCjAwMDAxMDc0MDQgMDAwMDAgbiAKMDAwMDExNDQ1NyAwMDAwMCBuIAowMDAwMTE0 NTk2IDAwMDAwIG4gCjAwMDAxMTc5NTggMDAwMDAgbiAKMDAwMDExNDgwMyAwMDAwMCBuIAowMDAw MTE3OTM2IDAwMDAwIG4gCjAwMDAxMTgwNzUgMDAwMDAgbiAKMDAwMDEyMTEzMiAwMDAwMCBuIAow MDAwMTE4MTc1IDAwMDAwIG4gCjAwMDAxMjExMTAgMDAwMDAgbiAKMDAwMDEyMTI0OSAwMDAwMCBu IAowMDAwMTI1Mjc5IDAwMDAwIG4gCjAwMDAxMjEzNDkgMDAwMDAgbiAKMDAwMDEyNTI1NyAwMDAw MCBuIAowMDAwMTI1Mzk2IDAwMDAwIG4gCjAwMDAxMjg2MDEgMDAwMDAgbiAKMDAwMDE5NjYzNyAw MDAwMCBuIAowMDAwMTI1NTI0IDAwMDAwIG4gCjAwMDAxMjg1NzkgMDAwMDAgbiAKMDAwMDEyODcx OSAwMDAwMCBuIAowMDAwMTMxNjYzIDAwMDAwIG4gCjAwMDAxMjg4NDYgMDAwMDAgbiAKMDAwMDEz MTY0MSAwMDAwMCBuIAowMDAwMTMxNzgxIDAwMDAwIG4gCjAwMDAxMzUxODYgMDAwMDAgbiAKMDAw MDEzMTg4MSAwMDAwMCBuIAowMDAwMTM1MTY0IDAwMDAwIG4gCjAwMDAxMzUzMDQgMDAwMDAgbiAK MDAwMDEzODY1NiAwMDAwMCBuIAowMDAwMTM1NDA0IDAwMDAwIG4gCjAwMDAxMzg2MzQgMDAwMDAg biAKMDAwMDEzODc3NCAwMDAwMCBuIAowMDAwMTQyMDA4IDAwMDAwIG4gCjAwMDAxMzg4NzQgMDAw MDAgbiAKMDAwMDE0MTk4NiAwMDAwMCBuIAowMDAwMTQyMTI2IDAwMDAwIG4gCjAwMDAxNDUxODEg MDAwMDAgbiAKMDAwMDE0MjIyNiAwMDAwMCBuIAowMDAwMTQ1MTU5IDAwMDAwIG4gCjAwMDAxNDUy OTkgMDAwMDAgbiAKMDAwMDE0OTgxNiAwMDAwMCBuIAowMDAwMTQ1Mzk5IDAwMDAwIG4gCjAwMDAx NDk3OTQgMDAwMDAgbiAKMDAwMDE0OTkzNCAwMDAwMCBuIAowMDAwMTUyOTAwIDAwMDAwIG4gCjAw MDAxNTAwNDcgMDAwMDAgbiAKMDAwMDE1Mjg3OCAwMDAwMCBuIAowMDAwMTUzMDE4IDAwMDAwIG4g CjAwMDAxNTYzMTAgMDAwMDAgbiAKMDAwMDE5Njc3MiAwMDAwMCBuIAowMDAwMTUzMTMxIDAwMDAw IG4gCjAwMDAxNTYyODggMDAwMDAgbiAKMDAwMDE1NjQyOCAwMDAwMCBuIAowMDAwMTU5NzYwIDAw MDAwIG4gCjAwMDAxNTY1MjggMDAwMDAgbiAKMDAwMDE1OTczOCAwMDAwMCBuIAowMDAwMTU5ODc4 IDAwMDAwIG4gCjAwMDAxNjI3NzkgMDAwMDAgbiAKMDAwMDE1OTk5MiAwMDAwMCBuIAowMDAwMTYy NzU3IDAwMDAwIG4gCjAwMDAxNjI4OTcgMDAwMDAgbiAKMDAwMDE2NTkzOSAwMDAwMCBuIAowMDAw MTYyOTk3IDAwMDAwIG4gCjAwMDAxNjU5MTcgMDAwMDAgbiAKMDAwMDE2NjA1NyAwMDAwMCBuIAow MDAwMTcwMTI2IDAwMDAwIG4gCjAwMDAxNjYxNTcgMDAwMDAgbiAKMDAwMDE3MDEwNCAwMDAwMCBu IAowMDAwMTcwMjQ0IDAwMDAwIG4gCjAwMDAxNzM0MDggMDAwMDAgbiAKMDAwMDE3MDM1NyAwMDAw MCBuIAowMDAwMTczMzg2IDAwMDAwIG4gCjAwMDAxNzM1MjYgMDAwMDAgbiAKMDAwMDE3NjU5MyAw MDAwMCBuIAowMDAwMTczNjUzIDAwMDAwIG4gCjAwMDAxNzY1NzEgMDAwMDAgbiAKMDAwMDE3Njcx MSAwMDAwMCBuIAowMDAwMTc5NTY0IDAwMDAwIG4gCjAwMDAxNzY4NTIgMDAwMDAgbiAKMDAwMDE3 OTU0MiAwMDAwMCBuIAowMDAwMTc5NjgyIDAwMDAwIG4gCjAwMDAxODMwODggMDAwMDAgbiAKMDAw MDE5NjkwNyAwMDAwMCBuIAowMDAwMTc5NzgyIDAwMDAwIG4gCjAwMDAxODMwNjYgMDAwMDAgbiAK MDAwMDE4MzIwNiAwMDAwMCBuIAowMDAwMTg2MTQxIDAwMDAwIG4gCjAwMDAxODMzMjAgMDAwMDAg biAKMDAwMDE4NjExOSAwMDAwMCBuIAowMDAwMTg2MjU5IDAwMDAwIG4gCjAwMDAxODk1NTUgMDAw MDAgbiAKMDAwMDE4NjM1OSAwMDAwMCBuIAowMDAwMTg5NTMzIDAwMDAwIG4gCjAwMDAxODk2NzMg MDAwMDAgbiAKMDAwMDE5MjI2MSAwMDAwMCBuIAowMDAwMTg5NzczIDAwMDAwIG4gCjAwMDAxOTIy MzkgMDAwMDAgbiAKMDAwMDE5MjM3OSAwMDAwMCBuIAowMDAwMTk1MTg3IDAwMDAwIG4gCjAwMDAx OTI0OTIgMDAwMDAgbiAKMDAwMDE5NTE2NSAwMDAwMCBuIAowMDAwMTk1MzA1IDAwMDAwIG4gCjAw MDAxOTYwMjUgMDAwMDAgbiAKMDAwMDE5NTQzMSAwMDAwMCBuIAowMDAwMTk2MDA0IDAwMDAwIG4g CjAwMDAxOTYxNDMgMDAwMDAgbiAKMDAwMDE5NzAyNiAwMDAwMCBuIAowMDAwMTk3MTU2IDAwMDAw IG4gCjAwMDAxOTcyMDkgMDAwMDAgbiAKMDAwMDIxMjE3NyAwMDAwMCBuIAowMDAwMjEyMjAwIDAw MDAwIG4gCjAwMDAyMTI0MzcgMDAwMDAgbiAKMDAwMDIxMjY2NiAwMDAwMCBuIAowMDAwMjEzMjcx IDAwMDAwIG4gCjAwMDAyMTM0NjggMDAwMDAgbiAKMDAwMDIxODkyNSAwMDAwMCBuIAowMDAwMjE4 OTQ3IDAwMDAwIG4gCjAwMDAyMTkxOTQgMDAwMDAgbiAKMDAwMDIxOTQwMyAwMDAwMCBuIAowMDAw MjI2NTgxIDAwMDAwIG4gCjAwMDAyMjY2MDMgMDAwMDAgbiAKMDAwMDIyNjgzNyAwMDAwMCBuIAow MDAwMjI3MjU3IDAwMDAwIG4gCjAwMDAyMzIwOTcgMDAwMDAgbiAKMDAwMDIzMjExOSAwMDAwMCBu IAowMDAwMjMyMzYxIDAwMDAwIG4gCjAwMDAyMzIzODQgMDAwMDAgbiAKMDAwMDIzMjY4NSAwMDAw MCBuIAowMDAwMjMyODc2IDAwMDAwIG4gCjAwMDAyMzc1ODAgMDAwMDAgbiAKMDAwMDIzNzYwMiAw MDAwMCBuIAowMDAwMjM3ODUyIDAwMDAwIG4gCjAwMDAyMzgwNjIgMDAwMDAgbiAKMDAwMDI0Mjky MiAwMDAwMCBuIAowMDAwMjQyOTQ0IDAwMDAwIG4gCjAwMDAyNDMxNzQgMDAwMDAgbiAKMDAwMDI0 MzM4MiAwMDAwMCBuIAowMDAwMjU4Mzk2IDAwMDAwIG4gCjAwMDAyNTg0MTkgMDAwMDAgbiAKMDAw MDI1ODY0NyAwMDAwMCBuIAowMDAwMjU4ODg4IDAwMDAwIG4gCjAwMDAyNTk1MjMgMDAwMDAgbiAK MDAwMDI1OTcxNCAwMDAwMCBuIAowMDAwMjc5NjkxIDAwMDAwIG4gCjAwMDAyNzk3MTQgMDAwMDAg biAKMDAwMDI3OTk0MCAwMDAwMCBuIAowMDAwMjgwMzEzIDAwMDAwIG4gCjAwMDAyODExMzggMDAw MDAgbiAKMDAwMDI4MTMyNCAwMDAwMCBuIAowMDAwMjg2OTQzIDAwMDAwIG4gCjAwMDAyODY5NjUg MDAwMDAgbiAKMDAwMDI4NzIwNyAwMDAwMCBuIAowMDAwMjg3NDExIDAwMDAwIG4gCjAwMDAzMDAz NDAgMDAwMDAgbiAKMDAwMDMwMDM2MyAwMDAwMCBuIAowMDAwMzAwNjAwIDAwMDAwIG4gCjAwMDAz MDEwMjAgMDAwMDAgbiAKMDAwMDMwMzQzMyAwMDAwMCBuIAowMDAwMzAzNDU1IDAwMDAwIG4gCjAw MDAzMDM2OTYgMDAwMDAgbiAKMDAwMDMwMzkwMCAwMDAwMCBuIAowMDAwMzE3Njk1IDAwMDAwIG4g CjAwMDAzMTc3MTggMDAwMDAgbiAKMDAwMDMxNzk3MCAwMDAwMCBuIAowMDAwMzE4Mzk1IDAwMDAw IG4gCjAwMDAzMjYxNjcgMDAwMDAgbiAKMDAwMDMyNjE4OSAwMDAwMCBuIAowMDAwMzI2NDE3IDAw MDAwIG4gCjAwMDAzMjY1MjYgMDAwMDAgbiAKMDAwMDMyNjk1MiAwMDAwMCBuIAowMDAwMzI3MTQz IDAwMDAwIG4gCjAwMDAzMzIzOTQgMDAwMDAgbiAKMDAwMDMzMjQxNiAwMDAwMCBuIAowMDAwMzMy NjY1IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMjgyIC9Sb290IDIxNSAwIFIgL0luZm8gMSAw IFIgL0lEIFsgPGEzMWExOTViYmE3OWYwNDY5M2ZlYjY2MDU5MzExNDBhPgo8YTMxYTE5NWJiYTc5 ZjA0NjkzZmViNjYwNTkzMTE0MGE+IF0gPj4Kc3RhcnR4cmVmCjMzMzM0MQolJUVPRgo= ------_=_NextPart_001_01C98525.B16F76B8 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://www.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C98525.B16F76B8-- From ecrit-bounces@ietf.org Mon Feb 2 03:05:49 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E4A28C17A; Mon, 2 Feb 2009 03:05:49 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300AB3A68A6 for ; Mon, 2 Feb 2009 03:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjNANaqIzaVL for ; Mon, 2 Feb 2009 03:05:47 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id E45133A6A1C for ; Mon, 2 Feb 2009 03:05:46 -0800 (PST) Received: from Upstairs.home (pool-98-109-204-63.nwrknj.fios.verizon.net [98.109.204.63]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n12B5OfJ008776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Feb 2009 06:05:24 -0500 (EST) Message-Id: <80886C44-0F4E-40D7-AFC8-E9504900E987@cs.columbia.edu> From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Feb 2009 06:05:24 -0500 References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "'Rosen, Brian'" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, not disagreeing, but email has also become a favorite tool for automated event notifications, in the absence of other widely-deployed and interoperable mechanisms. In limited scenarios, such as automated alarms, this may be more robust than alternatives (such as IM and SMS). Compared to SMS, the sender (if it directly submits the email, rather than through a queueing sendmail) gets a good indication that the email has reached the destination domain. One could imagine special-purpose setups, such as an alarm monitoring company or a chemical plant with automated sensors, where authentication is not a big deal (since the alarm company/chemical company can easily cryptographically sign the email via S/MIME and the number of such companies is modest on a local level and their identities are known). In other words, I have a hard time picturing the local police chief telling their citizenry to send email when the house is on fire, but specialized arrangements may make sense, given the widely deployed infrastructure. Henning On Jan 31, 2009, at 7:31 AM, Hannes Tschofenig wrote: > Hi Brian, > > we have already everything in place that would allow emergency email > to > work. > > Here are the building blocks: > > * LoST > * mails can obviously carry location as location is just another > MIME type > * mechanisms to obtain location > > LoST allows different elements to be returned. In the examples > we > spoke about SIP related URIs (including tel URIs) and XMPP URIs. > Obviously > one can also put a mailto: URI in there. > > So, if the end point uses LoST to obtain the mailto: URI then it > could send > the emergency email there. > > One important question is: Would email provider be interested in > deploying > this? I suspect "no". Hence, it is better not to mark the mail as an > emergency email in the same way as we did the marking with the > Service URN > in SIP. Instead, the theme would be to mark it for those you care > and if > there is someone who does not care then it still gets routed to the > right > place (rather than dropped on the floor). The fear that a user could > do > fraud by marking emails as emergency emails is not really an issue > for email > at all. > > It might be possible to operate dedicated email providers only > responsible > for handling emergency email routing as many email clients allow > multiple > accounts to be maintained quite transparently. > > The next important question is whether the PSAP operator really want > this. > We all know that email does not really have a strong notion of > security. > Even though there is DKIM standardized it isn't widely used. As > such, there > is essentially no cryptographic identity with email the PSAP > operators get > and email operators will not deploy new security security mechanisms > for > this purpose either since the email operators will not like the > emergency > email concept as it adds new obligations for them and no (monetary) > benefit. > PSAPs might receive a lot of fake emergency mails and it might make > them > difficult to figure out which onces are real. > > The final aspect is on location suitable for dispatch: While our > protocols > would support ways to fetch location by the PSAP operator from the > access > provider using, for example, the location by reference concept we so > far > know that (despite initial indications of interest) operators rather > prefer > a model where they do not send anything to the end host. Even though > the > location aspect is independent of the actual application service > (voice, IM, > email, etc.) most operators would not see it that way. Hence, they > would > only hand out location to the PSAP if the regulator forces them (and > sometimes not even then). This is more an procedural aspect than a > technical > one. > > Did you think about an opt-in variant or not? > > Ciao > Hannes > > PS: I see James already writing an RPH extension for email :-) > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Rosen, Brian >> Sent: 31 January, 2009 01:21 >> To: ecrit@ietf.org >> Subject: [Ecrit] Does it make sense to email to urn:service:sos? >> >> The subject of emailing an emergency request comes up from >> time to time. >> So far, we've dismissed the idea primarily because email is >> not a real time protocol. >> >> In the U.S., we have started working towards supporting SMS >> for emergency use. The objection raised is "SMS is not a real >> time protocol". >> >> My response to the SMS issue is "although it's certainly true >> that it isn't a real time protocol, and messages can be >> delayed by minutes, hours, or even days, people use it as if >> it was real time, and deal with the reality that it isn't. >> Many users have an expectation that they should be able to >> text to the emergency service". >> >> Is that not true, perhaps to somewhat less degree, for email? >> Users are indeed less likely to treat email as real time, but >> in fact they often use it as if it was. >> >> Let us consider what it would take to allow email for emergency >> services: >> 1. We would need a way to convey location in SMTP 2. We would >> need a way to mark an emergency email 3. We would need a way >> to route an emergency email It goes without saying that a PSAP >> could send a reply email to the originator. >> >> 2 and 3 could clearly be virtually identical to what we use for >> calls: >> "dial string" translation to urn:service:sos, LoST routing to >> a URI, regular email routing to that URI. 1 would require a >> new feature in SMTP. I'm not sure there is any analog to the >> "recognize the local dial string, translate to the service >> urn, retarget to the PSAP URI", but it does seem like a >> straightforward thing for an email server to do. >> >> Does this make any sense? Is there a good reason NOT to do it? >> >> Brian >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 03:11:48 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4954D3A6A4D; Mon, 2 Feb 2009 03:11:48 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1793A6A4D for ; Mon, 2 Feb 2009 03:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.601 X-Spam-Level: X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekuYOFkEiU8j for ; Mon, 2 Feb 2009 03:11:45 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C6C013A69E3 for ; Mon, 2 Feb 2009 03:11:44 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n12BBE3L008119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Feb 2009 12:11:14 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n12BBDlL020521; Mon, 2 Feb 2009 12:11:13 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 12:11:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 13:11:59 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FFF249@FIESEXC015.nsn-intra.net> In-Reply-To: <80886C44-0F4E-40D7-AFC8-E9504900E987@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Does it make sense to email to urn:service:sos? Thread-Index: AcmFJjIhfIqo5ONISxuK8mXl5alNigAALAWw References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <80886C44-0F4E-40D7-AFC8-E9504900E987@cs.columbia.edu> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 02 Feb 2009 11:11:13.0667 (UTC) FILETIME=[F5D92530:01C98526] Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with you, Henning. In his short mail Brian left a couple of things unanswered including the scenarios where he envisions emergency email to be used. Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Henning Schulzrinne >Sent: 02 February, 2009 13:05 >To: Hannes Tschofenig >Cc: 'Rosen, Brian'; ecrit@ietf.org >Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > >Hannes, > >not disagreeing, but email has also become a favorite tool for >automated event notifications, in the absence of other >widely-deployed and interoperable mechanisms. In limited >scenarios, such as automated alarms, this may be more robust >than alternatives (such as IM and SMS). > >Compared to SMS, the sender (if it directly submits the email, >rather than through a queueing sendmail) gets a good >indication that the email has reached the destination domain. > >One could imagine special-purpose setups, such as an alarm >monitoring company or a chemical plant with automated sensors, >where authentication is not a big deal (since the alarm >company/chemical company can easily cryptographically sign the >email via S/MIME and the number of such companies is modest on >a local level and their identities are known). > >In other words, I have a hard time picturing the local police >chief telling their citizenry to send email when the house is >on fire, but specialized arrangements may make sense, given >the widely deployed infrastructure. > >Henning > >On Jan 31, 2009, at 7:31 AM, Hannes Tschofenig wrote: > >> Hi Brian, >> >> we have already everything in place that would allow emergency email >> to work. >> >> Here are the building blocks: >> >> * LoST >> * mails can obviously carry location as location is just >another MIME >> type >> * mechanisms to obtain location >> >> LoST allows different elements to be returned. In the examples >> we spoke about SIP related URIs (including tel URIs) and XMPP URIs. >> Obviously >> one can also put a mailto: URI in there. >> >> So, if the end point uses LoST to obtain the mailto: URI >then it could >> send the emergency email there. >> >> One important question is: Would email provider be interested in >> deploying this? I suspect "no". Hence, it is better not to mark the >> mail as an emergency email in the same way as we did the >marking with >> the Service URN in SIP. Instead, the theme would be to mark it for >> those you care and if there is someone who does not care >then it still >> gets routed to the right place (rather than dropped on the >floor). The >> fear that a user could do fraud by marking emails as >emergency emails >> is not really an issue for email at all. >> >> It might be possible to operate dedicated email providers only >> responsible for handling emergency email routing as many >email clients >> allow multiple accounts to be maintained quite transparently. >> >> The next important question is whether the PSAP operator really want >> this. >> We all know that email does not really have a strong notion of >> security. >> Even though there is DKIM standardized it isn't widely used. >As such, >> there is essentially no cryptographic identity with email the PSAP >> operators get and email operators will not deploy new security >> security mechanisms for this purpose either since the email >operators >> will not like the emergency email concept as it adds new obligations >> for them and no (monetary) benefit. >> PSAPs might receive a lot of fake emergency mails and it might make >> them difficult to figure out which onces are real. >> >> The final aspect is on location suitable for dispatch: While our >> protocols would support ways to fetch location by the PSAP operator >> from the access provider using, for example, the location by >reference >> concept we so far know that (despite initial indications of >interest) >> operators rather prefer a model where they do not send >anything to the >> end host. Even though the location aspect is independent of >the actual >> application service (voice, IM, email, etc.) most operators >would not >> see it that way. Hence, they would only hand out location to >the PSAP >> if the regulator forces them (and sometimes not even then). This is >> more an procedural aspect than a technical one. >> >> Did you think about an opt-in variant or not? >> >> Ciao >> Hannes >> >> PS: I see James already writing an RPH extension for email :-) >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Rosen, Brian >>> Sent: 31 January, 2009 01:21 >>> To: ecrit@ietf.org >>> Subject: [Ecrit] Does it make sense to email to urn:service:sos? >>> >>> The subject of emailing an emergency request comes up from time to >>> time. >>> So far, we've dismissed the idea primarily because email is not a >>> real time protocol. >>> >>> In the U.S., we have started working towards supporting SMS for >>> emergency use. The objection raised is "SMS is not a real time >>> protocol". >>> >>> My response to the SMS issue is "although it's certainly >true that it >>> isn't a real time protocol, and messages can be delayed by minutes, >>> hours, or even days, people use it as if it was real time, and deal >>> with the reality that it isn't. >>> Many users have an expectation that they should be able to text to >>> the emergency service". >>> >>> Is that not true, perhaps to somewhat less degree, for email? >>> Users are indeed less likely to treat email as real time, >but in fact >>> they often use it as if it was. >>> >>> Let us consider what it would take to allow email for emergency >>> services: >>> 1. We would need a way to convey location in SMTP 2. We >would need a >>> way to mark an emergency email 3. We would need a way to route an >>> emergency email It goes without saying that a PSAP could >send a reply >>> email to the originator. >>> >>> 2 and 3 could clearly be virtually identical to what we use for >>> calls: >>> "dial string" translation to urn:service:sos, LoST routing >to a URI, >>> regular email routing to that URI. 1 would require a new >feature in >>> SMTP. I'm not sure there is any analog to the "recognize the local >>> dial string, translate to the service urn, retarget to the >PSAP URI", >>> but it does seem like a straightforward thing for an email >server to >>> do. >>> >>> Does this make any sense? Is there a good reason NOT to do it? >>> >>> Brian >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 06:52:28 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A1328C1F0; Mon, 2 Feb 2009 06:52:28 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39873A6B20 for ; Mon, 2 Feb 2009 06:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-og6au2X7tx for ; Mon, 2 Feb 2009 06:52:22 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 22FA53A6A1A for ; Mon, 2 Feb 2009 06:52:22 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LU09R-0007Ub-Bj; Mon, 02 Feb 2009 08:51:53 -0600 From: "Brian Rosen" To: "'James M. Polk'" , "'Hannes Tschofenig'" , References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> In-Reply-To: Date: Mon, 2 Feb 2009 09:51:56 -0500 Message-ID: <054601c98545$ccd81280$66883780$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmD+MlZrjw/FHkCS3igv1SwjjujYgBS6pzQ Content-Language: en-us 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: Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org See inline > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of James M. Polk > Sent: Saturday, January 31, 2009 6:10 PM > To: Hannes Tschofenig; 'Rosen, Brian'; ecrit@ietf.org > Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > SWIW > > - email has no guarantee of delivery Neither does SMS. Really, "guarantee of delivery" could mean many things, some of which apply to sip > - no guarantee of delivery to the right endpoint Neither does SMS, nor SIP. What is "right"? The one you intended? > - no guarantee of delivery to the an endpoint application that won't > filter said message into the wrong directory/folder Definitely true of sip (think spit filtering). Somewhat more true than SMS which typically is not filtered into directories > - had a HIGH likelihood of SPAM on the recepient's end Increasingly true of SMS, but this is true, sadly > - SPAM could in general become the biggest issue wrt actually having > someone at the PSAP have to "look" at each and every message because > no one can build in the proper automated filters to cover all > possible misspellings of a legitimate email message No doubt about it. Not clear that is reason enough to kill the idea, but it's certainly an issue. On the other hand, that would argue that no improvement to email other than spam related improvements should be accepted. > - every email application will have to be revved to incorporate > location into some kind of user identifying indication this is for > sos (maybe this is merely having the "urn:service:sos" in the To: > header). Many (most) users do not upgrade their mailers too often > (like their home routers)... so this upgrade path will be an issue, > because it likely cannot be universally expected by the network to be > in place. Yes. Also true of every other system (SMS, SIP, legacy wireline/wireless networks, ...) > - MTAs don't have the ability to understand where "I am" to insert > location, given the number of users that either > > -- use a generic application on any computer to access their > email, or Each email client has to be upgraded, but if that happened, it works. The MTA doesn't know where the user is unless the user tells them. Same as SIP. > -- have a VPN This is exactly the same problem as a SIP softclient, with the same answer. > > for example, I use the same laptop with an out of date email > application (Eudora -- that's not supported anymore, and even if it > was -- which version do I have?). I'm connecting via a VPN today from > a suburb of Fort Worth through Cisco's Richardson facility (which is > a suburb of Dallas) through Cisco San Jose (California). Last wee I > was in Barcelona, Spain. I used the same VPN server in Richardson to > get to the Cisco San Jose campus. The only thing that changed was my > origination point, one that cannot be tied to an IP address, because > any VPN that I use going through Richardson - which gives my laptop > one from its own address range. If you were using an outdated version of X-lite to make phone calls, you would have all of these problems, exactly the same way. > > To make matters worse, I have access to 16 other VPN connection > points other than Richardson (in case I cannot get through via > Richardson). Some times these are accessed automatically, sometimes > I purposely connect to another Cisco site than Richardson directly. > > How does Cisco understand where I am connecting from? The access network tells your PC, your PC tells the client, the client tells the server. > > I'm mostly focused on location URIs being inserted by a server in the > network thinking it knows where I am (i.e., what we (use to?) call a > "sighter" function). I think the client adds location. The client queries via LoST. The MTA is transparent. Just like a SIP server. The server may be able to help an un-upgraded client, just like some SIP servers could, but it wouldn't always work, and VPNs are examples of things that wouldn't work. > > > At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: > >Hi Brian, > > > >we have already everything in place that would allow emergency email > to > >work. > > > >Here are the building blocks: > > > >* LoST > >* mails can obviously carry location as location is just another MIME > type > >* mechanisms to obtain location > > > >LoST allows different elements to be returned. In the examples > we > >spoke about SIP related URIs (including tel URIs) and XMPP URIs. > Obviously > >one can also put a mailto: URI in there. > > > >So, if the end point uses LoST to obtain the mailto: URI then it could > send > >the emergency email there. > > > >One important question is: Would email provider be interested in > deploying > >this? I suspect "no". Hence, it is better not to mark the mail as an > >emergency email in the same way as we did the marking with the Service > URN > >in SIP. Instead, the theme would be to mark it for those you care and > if > >there is someone who does not care then it still gets routed to the > right > >place (rather than dropped on the floor). The fear that a user could > do > >fraud by marking emails as emergency emails is not really an issue for > email > >at all. > > > >It might be possible to operate dedicated email providers only > responsible > >for handling emergency email routing as many email clients allow > multiple > >accounts to be maintained quite transparently. > > > >The next important question is whether the PSAP operator really want > this. > >We all know that email does not really have a strong notion of > security. > >Even though there is DKIM standardized it isn't widely used. As such, > there > >is essentially no cryptographic identity with email the PSAP operators > get > >and email operators will not deploy new security security mechanisms > for > >this purpose either since the email operators will not like the > emergency > >email concept as it adds new obligations for them and no (monetary) > benefit. > >PSAPs might receive a lot of fake emergency mails and it might make > them > >difficult to figure out which onces are real. > > > >The final aspect is on location suitable for dispatch: While our > protocols > >would support ways to fetch location by the PSAP operator from the > access > >provider using, for example, the location by reference concept we so > far > >know that (despite initial indications of interest) operators rather > prefer > >a model where they do not send anything to the end host. Even though > the > >location aspect is independent of the actual application service > (voice, IM, > >email, etc.) most operators would not see it that way. Hence, they > would > >only hand out location to the PSAP if the regulator forces them (and > >sometimes not even then). This is more an procedural aspect than a > technical > >one. > > > >Did you think about an opt-in variant or not? > > > >Ciao > >Hannes > > > >PS: I see James already writing an RPH extension for email :-) > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > >On Behalf Of Rosen, Brian > > >Sent: 31 January, 2009 01:21 > > >To: ecrit@ietf.org > > >Subject: [Ecrit] Does it make sense to email to urn:service:sos? > > > > > >The subject of emailing an emergency request comes up from > > >time to time. > > >So far, we've dismissed the idea primarily because email is > > >not a real time protocol. > > > > > >In the U.S., we have started working towards supporting SMS > > >for emergency use. The objection raised is "SMS is not a real > > >time protocol". > > > > > >My response to the SMS issue is "although it's certainly true > > >that it isn't a real time protocol, and messages can be > > >delayed by minutes, hours, or even days, people use it as if > > >it was real time, and deal with the reality that it isn't. > > >Many users have an expectation that they should be able to > > >text to the emergency service". > > > > > >Is that not true, perhaps to somewhat less degree, for email? > > >Users are indeed less likely to treat email as real time, but > > >in fact they often use it as if it was. > > > > > >Let us consider what it would take to allow email for emergency > > >services: > > >1. We would need a way to convey location in SMTP 2. We would > > >need a way to mark an emergency email 3. We would need a way > > >to route an emergency email It goes without saying that a PSAP > > >could send a reply email to the originator. > > > > > >2 and 3 could clearly be virtually identical to what we use for > calls: > > >"dial string" translation to urn:service:sos, LoST routing to > > >a URI, regular email routing to that URI. 1 would require a > > >new feature in SMTP. I'm not sure there is any analog to the > > >"recognize the local dial string, translate to the service > > >urn, retarget to the PSAP URI", but it does seem like a > > >straightforward thing for an email server to do. > > > > > >Does this make any sense? Is there a good reason NOT to do it? > > > > > >Brian > > > > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 06:56:14 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FD83A6B12; Mon, 2 Feb 2009 06:56:14 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821883A6B12 for ; Mon, 2 Feb 2009 06:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IC2i2HaY9bz for ; Mon, 2 Feb 2009 06:56:11 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 337E83A6A0C for ; Mon, 2 Feb 2009 06:56:11 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LU0DA-0007tT-Db; Mon, 02 Feb 2009 08:55:44 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <80886C44-0F4E-40D7-AFC8-E9504900E987@cs.columbia.edu> <3D3C75174CB95F42AD6BCC56E5555B45FFF249@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFF249@FIESEXC015.nsn-intra.net> Date: Mon, 2 Feb 2009 09:55:49 -0500 Message-ID: <054801c98546$56a5ef50$03f1cdf0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmFJjIhfIqo5ONISxuK8mXl5alNigAALAWwAAdUWzA= Content-Language: en-us 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: Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You can invent scenarios where it makes more sense to use email that other scenarios, but you can't stop people from using it in any scenario they want to (that is, the emergency system can't filter email based on the scenario). Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Monday, February 02, 2009 6:12 AM > To: ext Henning Schulzrinne; Hannes Tschofenig > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > I agree with you, Henning. In his short mail Brian left a couple of > things unanswered including the scenarios where he envisions emergency > email to be used. > > Hannes > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of ext Henning Schulzrinne > >Sent: 02 February, 2009 13:05 > >To: Hannes Tschofenig > >Cc: 'Rosen, Brian'; ecrit@ietf.org > >Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > > >Hannes, > > > >not disagreeing, but email has also become a favorite tool for > >automated event notifications, in the absence of other > >widely-deployed and interoperable mechanisms. In limited > >scenarios, such as automated alarms, this may be more robust > >than alternatives (such as IM and SMS). > > > >Compared to SMS, the sender (if it directly submits the email, > >rather than through a queueing sendmail) gets a good > >indication that the email has reached the destination domain. > > > >One could imagine special-purpose setups, such as an alarm > >monitoring company or a chemical plant with automated sensors, > >where authentication is not a big deal (since the alarm > >company/chemical company can easily cryptographically sign the > >email via S/MIME and the number of such companies is modest on > >a local level and their identities are known). > > > >In other words, I have a hard time picturing the local police > >chief telling their citizenry to send email when the house is > >on fire, but specialized arrangements may make sense, given > >the widely deployed infrastructure. > > > >Henning > > > >On Jan 31, 2009, at 7:31 AM, Hannes Tschofenig wrote: > > > >> Hi Brian, > >> > >> we have already everything in place that would allow emergency email > >> to work. > >> > >> Here are the building blocks: > >> > >> * LoST > >> * mails can obviously carry location as location is just > >another MIME > >> type > >> * mechanisms to obtain location > >> > >> LoST allows different elements to be returned. In the examples > >> we spoke about SIP related URIs (including tel URIs) and XMPP URIs. > >> Obviously > >> one can also put a mailto: URI in there. > >> > >> So, if the end point uses LoST to obtain the mailto: URI > >then it could > >> send the emergency email there. > >> > >> One important question is: Would email provider be interested in > >> deploying this? I suspect "no". Hence, it is better not to mark the > >> mail as an emergency email in the same way as we did the > >marking with > >> the Service URN in SIP. Instead, the theme would be to mark it for > >> those you care and if there is someone who does not care > >then it still > >> gets routed to the right place (rather than dropped on the > >floor). The > >> fear that a user could do fraud by marking emails as > >emergency emails > >> is not really an issue for email at all. > >> > >> It might be possible to operate dedicated email providers only > >> responsible for handling emergency email routing as many > >email clients > >> allow multiple accounts to be maintained quite transparently. > >> > >> The next important question is whether the PSAP operator really want > >> this. > >> We all know that email does not really have a strong notion of > >> security. > >> Even though there is DKIM standardized it isn't widely used. > >As such, > >> there is essentially no cryptographic identity with email the PSAP > >> operators get and email operators will not deploy new security > >> security mechanisms for this purpose either since the email > >operators > >> will not like the emergency email concept as it adds new obligations > >> for them and no (monetary) benefit. > >> PSAPs might receive a lot of fake emergency mails and it might make > >> them difficult to figure out which onces are real. > >> > >> The final aspect is on location suitable for dispatch: While our > >> protocols would support ways to fetch location by the PSAP operator > >> from the access provider using, for example, the location by > >reference > >> concept we so far know that (despite initial indications of > >interest) > >> operators rather prefer a model where they do not send > >anything to the > >> end host. Even though the location aspect is independent of > >the actual > >> application service (voice, IM, email, etc.) most operators > >would not > >> see it that way. Hence, they would only hand out location to > >the PSAP > >> if the regulator forces them (and sometimes not even then). This is > >> more an procedural aspect than a technical one. > >> > >> Did you think about an opt-in variant or not? > >> > >> Ciao > >> Hannes > >> > >> PS: I see James already writing an RPH extension for email :-) > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of Rosen, Brian > >>> Sent: 31 January, 2009 01:21 > >>> To: ecrit@ietf.org > >>> Subject: [Ecrit] Does it make sense to email to urn:service:sos? > >>> > >>> The subject of emailing an emergency request comes up from time to > >>> time. > >>> So far, we've dismissed the idea primarily because email is not a > >>> real time protocol. > >>> > >>> In the U.S., we have started working towards supporting SMS for > >>> emergency use. The objection raised is "SMS is not a real time > >>> protocol". > >>> > >>> My response to the SMS issue is "although it's certainly > >true that it > >>> isn't a real time protocol, and messages can be delayed by minutes, > >>> hours, or even days, people use it as if it was real time, and deal > >>> with the reality that it isn't. > >>> Many users have an expectation that they should be able to text to > >>> the emergency service". > >>> > >>> Is that not true, perhaps to somewhat less degree, for email? > >>> Users are indeed less likely to treat email as real time, > >but in fact > >>> they often use it as if it was. > >>> > >>> Let us consider what it would take to allow email for emergency > >>> services: > >>> 1. We would need a way to convey location in SMTP 2. We > >would need a > >>> way to mark an emergency email 3. We would need a way to route an > >>> emergency email It goes without saying that a PSAP could > >send a reply > >>> email to the originator. > >>> > >>> 2 and 3 could clearly be virtually identical to what we use for > >>> calls: > >>> "dial string" translation to urn:service:sos, LoST routing > >to a URI, > >>> regular email routing to that URI. 1 would require a new > >feature in > >>> SMTP. I'm not sure there is any analog to the "recognize the local > >>> dial string, translate to the service urn, retarget to the > >PSAP URI", > >>> but it does seem like a straightforward thing for an email > >server to > >>> do. > >>> > >>> Does this make any sense? Is there a good reason NOT to do it? > >>> > >>> Brian > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 06:56:18 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A52D28C22F; Mon, 2 Feb 2009 06:56:18 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD42A3A6A0C for ; Mon, 2 Feb 2009 06:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdGrriht90nO for ; Mon, 2 Feb 2009 06:56:15 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D56A728C22F for ; Mon, 2 Feb 2009 06:56:14 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LU0D7-0007tT-UC; Mon, 02 Feb 2009 08:55:42 -0600 From: "Brian Rosen" To: "'ken carlberg'" , "'Hannes Tschofenig'" References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> In-Reply-To: <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> Date: Mon, 2 Feb 2009 09:55:41 -0500 Message-ID: <054701c98546$55725150$0056f3f0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmEa/TJ93UCP3AJSLac302t4TzzvAA2drSQ Content-Language: en-us 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: Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is no priority for emergency calls in the PSTN today. I would not expect any tomorrow, although I'd like to allow it (RPH). I would not expect any priority for emergency SMS. I would not expect any priority for emergency email. I am not sure what the right thing to do with marking is. The easiest thing is to recognize the "dial string" and translate that to the "PSAP URI" using LoST. That would be a mailto, and would get the email to the right place. What should the "dial string" for email be? I'm not sure. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ken carlberg > Sent: Sunday, February 01, 2009 7:52 AM > To: Hannes Tschofenig > Cc: 'Rosen, Brian'; ecrit@ietf.org > Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > Gentleman, > > This note probably goes a bit beyond what Brian first brought up, but > there are other things to keep in mind... > > The fact that email runs over TCP and its adaptive algorithms helps > diminish enthusiasm in augmenting email. But as Brian indirectly > points out, its the buffer consumption at intermediate servers (ie, > MTAs) where the bottleneck occurs. And keep in mind that large > companies will generally have several MTAs needed to simply exit their > stub domain. In my old company of 40k+ employees, we would receive > email messages from admins every November asking that we don't send > the dancing Santa video during December to decrease the chances of the > outgoing MTA getting clogged. > > And while I also agree with a number of points brought up by James, > its important to note that this is under the context of SMTP. X.400 > has extensions that distinguish the importance of email in order to > get past the MTA bottleneck problem. Now, before folks say that X.400 > is really a blip in the overall installed based of email systems, I'll > agree with you. Its deployment is mostly confined to organizations > that must have prioritization of email -- eg, DoD, MoD, NATO. And > NATO is of particular importance on this example because while it is a > restricted federation from the perspective of the rest of the > Internet, it still represents a collection of separate administrative > domains, thereby escaping the counter argument that its purely a > walled garden. (Note that the collection tier-1 ISPs is also a type > of restricted federation in terms of participants). But the point is > that X.400 has a market because it does something that is not > standardized with SMTP during emergencies, or importantly, event- > driven spikes of traffic load. > > So, if we go back to Brian's original point of "we want to mark > emergency mail", I think a couple of questions to ask is in what form > and to what degree of versatility do you want this marking? And is > the form to be binary (eg, SoS in the URL), or is it to be something > more along the lines of rfc-4412 and an additional header in the SMTP > message? > > For your reading entertainment purposes only, you can look at an > expired (and somewhat incomplete) draft-rfc on the subject at > http://ftp.iasi.roedu.net/Docs/internet-drafts/draft-schmeing-smtp- > priorities-05.txt > > cheers, > > -ken > > > On Feb 1, 2009, at 5:07 AM, Hannes Tschofenig wrote: > > > Hi James, > > > > I agree with many of your statements. > > > > I also agree with the installed base that does not support this > > functionality. This almost sounds like the VoIP emergency story to > me. > > > > I also agree with the location aspect. Also like in VoIP. > > > > Ciao > > Hannes > > > >> SWIW > >> > >> - email has no guarantee of delivery > >> - no guarantee of delivery to the right endpoint > >> - no guarantee of delivery to the an endpoint application that > >> won't filter said message into the wrong directory/folder > >> - had a HIGH likelihood of SPAM on the recepient's end > >> - SPAM could in general become the biggest issue wrt actually > >> having someone at the PSAP have to "look" at each and every > >> message because no one can build in the proper automated > >> filters to cover all possible misspellings of a legitimate > >> email message > >> - every email application will have to be revved to > >> incorporate location into some kind of user identifying > >> indication this is for sos (maybe this is merely having the > >> "urn:service:sos" in the To: > >> header). Many (most) users do not upgrade their mailers too > >> often (like their home routers)... so this upgrade path will > >> be an issue, because it likely cannot be universally expected > >> by the network to be in place. > >> - MTAs don't have the ability to understand where "I am" to > >> insert location, given the number of users that either > >> > >> -- use a generic application on any computer to > >> access their email, or > >> -- have a VPN > >> > >> for example, I use the same laptop with an out of date email > >> application (Eudora -- that's not supported anymore, and even > >> if it was -- which version do I have?). I'm connecting via a > >> VPN today from a suburb of Fort Worth through Cisco's > >> Richardson facility (which is a suburb of Dallas) through > >> Cisco San Jose (California). Last wee I was in Barcelona, > >> Spain. I used the same VPN server in Richardson to get to the > >> Cisco San Jose campus. The only thing that changed was my > >> origination point, one that cannot be tied to an IP address, > >> because any VPN that I use going through Richardson - which > >> gives my laptop one from its own address range. > >> > >> To make matters worse, I have access to 16 other VPN > >> connection points other than Richardson (in case I cannot get > >> through via Richardson). Some times these are accessed > >> automatically, sometimes I purposely connect to another Cisco > >> site than Richardson directly. > >> > >> How does Cisco understand where I am connecting from? > >> > >> I'm mostly focused on location URIs being inserted by a server > >> in the network thinking it knows where I am (i.e., what we > >> (use to?) call a "sighter" function). > >> > >> > >> At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: > >>> Hi Brian, > >>> > >>> we have already everything in place that would allow > >> emergency email to > >>> work. > >>> > >>> Here are the building blocks: > >>> > >>> * LoST > >>> * mails can obviously carry location as location is just another > >>> MIME > >>> type > >>> * mechanisms to obtain location > >>> > >>> LoST allows different elements to be returned. In the > >> examples we > >>> spoke about SIP related URIs (including tel URIs) and XMPP URIs. > >>> Obviously one can also put a mailto: URI in there. > >>> > >>> So, if the end point uses LoST to obtain the mailto: URI then > >> it could > >>> send the emergency email there. > >>> > >>> One important question is: Would email provider be interested in > >>> deploying this? I suspect "no". Hence, it is better not to mark the > >>> mail as an emergency email in the same way as we did the marking > >>> with > >>> the Service URN in SIP. Instead, the theme would be to mark it for > >>> those you care and if there is someone who does not care then > >> it still > >>> gets routed to the right place (rather than dropped on the > >> floor). The > >>> fear that a user could do fraud by marking emails as emergency > >>> emails > >>> is not really an issue for email at all. > >>> > >>> It might be possible to operate dedicated email providers only > >>> responsible for handling emergency email routing as many > >> email clients > >>> allow multiple accounts to be maintained quite transparently. > >>> > >>> The next important question is whether the PSAP operator > >> really want this. > >>> We all know that email does not really have a strong notion > >> of security. > >>> Even though there is DKIM standardized it isn't widely used. As > >>> such, > >>> there is essentially no cryptographic identity with email the PSAP > >>> operators get and email operators will not deploy new > >> security security > >>> mechanisms for this purpose either since the email operators will > >>> not > >>> like the emergency email concept as it adds new obligations > >> for them and no (monetary) benefit. > >>> PSAPs might receive a lot of fake emergency mails and it might make > >>> them difficult to figure out which onces are real. > >>> > >>> The final aspect is on location suitable for dispatch: While our > >>> protocols would support ways to fetch location by the PSAP operator > >>> from the access provider using, for example, the location by > >> reference > >>> concept we so far know that (despite initial indications of > >>> interest) > >>> operators rather prefer a model where they do not send > >> anything to the > >>> end host. Even though the location aspect is independent of > >> the actual > >>> application service (voice, IM, email, etc.) most operators would > >>> not > >>> see it that way. Hence, they would only hand out location to the > >>> PSAP > >>> if the regulator forces them (and sometimes not even then). This is > >>> more an procedural aspect than a technical one. > >>> > >>> Did you think about an opt-in variant or not? > >>> > >>> Ciao > >>> Hannes > >>> > >>> PS: I see James already writing an RPH extension for email :-) > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>> Behalf Of Rosen, Brian > >>>> Sent: 31 January, 2009 01:21 > >>>> To: ecrit@ietf.org > >>>> Subject: [Ecrit] Does it make sense to email to urn:service:sos? > >>>> > >>>> The subject of emailing an emergency request comes up from time to > >>>> time. > >>>> So far, we've dismissed the idea primarily because email is not a > >>>> real time protocol. > >>>> > >>>> In the U.S., we have started working towards supporting SMS for > >>>> emergency use. The objection raised is "SMS is not a real time > >>>> protocol". > >>>> > >>>> My response to the SMS issue is "although it's certainly > >> true that it > >>>> isn't a real time protocol, and messages can be delayed by > minutes, > >>>> hours, or even days, people use it as if it was real time, and > deal > >>>> with the reality that it isn't. > >>>> Many users have an expectation that they should be able to text to > >>>> the emergency service". > >>>> > >>>> Is that not true, perhaps to somewhat less degree, for email? > >>>> Users are indeed less likely to treat email as real time, > >> but in fact > >>>> they often use it as if it was. > >>>> > >>>> Let us consider what it would take to allow email for emergency > >>>> services: > >>>> 1. We would need a way to convey location in SMTP 2. We > >> would need a > >>>> way to mark an emergency email 3. We would need a way to route an > >>>> emergency email It goes without saying that a PSAP could > >> send a reply > >>>> email to the originator. > >>>> > >>>> 2 and 3 could clearly be virtually identical to what we use > >> for calls: > >>>> "dial string" translation to urn:service:sos, LoST routing > >> to a URI, > >>>> regular email routing to that URI. 1 would require a new > >> feature in > >>>> SMTP. I'm not sure there is any analog to the "recognize the > local > >>>> dial string, translate to the service urn, retarget to the > >> PSAP URI", > >>>> but it does seem like a straightforward thing for an email > >> server to > >>>> do. > >>>> > >>>> Does this make any sense? Is there a good reason NOT to do it? > >>>> > >>>> Brian > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 07:03:46 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5F328C242; Mon, 2 Feb 2009 07:03:46 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2FC28C240 for ; Mon, 2 Feb 2009 07:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg4Hz0VZ-i0C for ; Mon, 2 Feb 2009 07:03:44 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 702DB28C242 for ; Mon, 2 Feb 2009 07:03:42 -0800 (PST) Received: (qmail invoked by alias); 02 Feb 2009 15:03:23 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 02 Feb 2009 16:03:23 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+NX9lolmyNy6JuY1aUnE1CZY3hm+/9GysWcWntTo Bc55TSlgIYDrzz From: "Hannes Tschofenig" To: "'Brian Rosen'" , "'ken carlberg'" References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> <054701c98546$55725150$0056f3f0$@net> Date: Mon, 2 Feb 2009 17:04:02 +0200 Message-ID: <006501c98547$80a48e50$e846a20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <054701c98546$55725150$0056f3f0$@net> Thread-Index: AcmEa/TJ93UCP3AJSLac302t4TzzvAA2drSQAAA9qoA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: "'Rosen, Brian'" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, >There is no priority for emergency calls in the PSTN today. I >would not expect any tomorrow, although I'd like to allow it (RPH). > >I would not expect any priority for emergency SMS. > >I would not expect any priority for emergency email. Thanks for saying that. > >I am not sure what the right thing to do with marking is. The >easiest thing is to recognize the "dial string" and translate >that to the "PSAP URI" using LoST. That would be a mailto, >and would get the email to the right place. > >What should the "dial string" for email be? I'm not sure. I believe it could be anything since there is no user expectation about it yet. I could imagine that a button on the UI would do it. This relates to the question of the usage scenario: Henning mentioned one where there isn't a user. Hence, the problem does not come up in the first place. When you think about users that opt-in for a usage of emergency mail then they could be told how to use it. The additional advantage of the opt-in solution is that you could deal much better with security. Ciao Hannes > >Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of ken carlberg >> Sent: Sunday, February 01, 2009 7:52 AM >> To: Hannes Tschofenig >> Cc: 'Rosen, Brian'; ecrit@ietf.org >> Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? >> >> Gentleman, >> >> This note probably goes a bit beyond what Brian first >brought up, but >> there are other things to keep in mind... >> >> The fact that email runs over TCP and its adaptive algorithms helps >> diminish enthusiasm in augmenting email. But as Brian indirectly >> points out, its the buffer consumption at intermediate servers (ie, >> MTAs) where the bottleneck occurs. And keep in mind that large >> companies will generally have several MTAs needed to simply >exit their >> stub domain. In my old company of 40k+ employees, we would receive >> email messages from admins every November asking that we don't send >> the dancing Santa video during December to decrease the >chances of the >> outgoing MTA getting clogged. >> >> And while I also agree with a number of points brought up by James, >> its important to note that this is under the context of SMTP. X.400 >> has extensions that distinguish the importance of email in order to >> get past the MTA bottleneck problem. Now, before folks say >that X.400 >> is really a blip in the overall installed based of email >systems, I'll >> agree with you. Its deployment is mostly confined to organizations >> that must have prioritization of email -- eg, DoD, MoD, NATO. And >> NATO is of particular importance on this example because >while it is a >> restricted federation from the perspective of the rest of the >> Internet, it still represents a collection of separate >administrative >> domains, thereby escaping the counter argument that its purely a >> walled garden. (Note that the collection tier-1 ISPs is also a type >> of restricted federation in terms of participants). But the >point is >> that X.400 has a market because it does something that is not >> standardized with SMTP during emergencies, or importantly, event- >> driven spikes of traffic load. >> >> So, if we go back to Brian's original point of "we want to mark >> emergency mail", I think a couple of questions to ask is in >what form >> and to what degree of versatility do you want this marking? And is >> the form to be binary (eg, SoS in the URL), or is it to be something >> more along the lines of rfc-4412 and an additional header in >the SMTP >> message? >> >> For your reading entertainment purposes only, you can look at an >> expired (and somewhat incomplete) draft-rfc on the subject at >> http://ftp.iasi.roedu.net/Docs/internet-drafts/draft-schmeing-smtp- >> priorities-05.txt >> >> cheers, >> >> -ken >> >> >> On Feb 1, 2009, at 5:07 AM, Hannes Tschofenig wrote: >> >> > Hi James, >> > >> > I agree with many of your statements. >> > >> > I also agree with the installed base that does not support this >> > functionality. This almost sounds like the VoIP emergency story to >> me. >> > >> > I also agree with the location aspect. Also like in VoIP. >> > >> > Ciao >> > Hannes >> > >> >> SWIW >> >> >> >> - email has no guarantee of delivery >> >> - no guarantee of delivery to the right endpoint >> >> - no guarantee of delivery to the an endpoint application that >> >> won't filter said message into the wrong directory/folder >> >> - had a HIGH likelihood of SPAM on the recepient's end >> >> - SPAM could in general become the biggest issue wrt actually >> >> having someone at the PSAP have to "look" at each and >every message >> >> because no one can build in the proper automated filters to cover >> >> all possible misspellings of a legitimate email message >> >> - every email application will have to be revved to incorporate >> >> location into some kind of user identifying indication >this is for >> >> sos (maybe this is merely having the "urn:service:sos" in the To: >> >> header). Many (most) users do not upgrade their mailers >too often >> >> (like their home routers)... so this upgrade path will be >an issue, >> >> because it likely cannot be universally expected by the >network to >> >> be in place. >> >> - MTAs don't have the ability to understand where "I am" >to insert >> >> location, given the number of users that either >> >> >> >> -- use a generic application on any computer to >access their >> >> email, or >> >> -- have a VPN >> >> >> >> for example, I use the same laptop with an out of date email >> >> application (Eudora -- that's not supported anymore, and >even if it >> >> was -- which version do I have?). I'm connecting via a VPN today >> >> from a suburb of Fort Worth through Cisco's Richardson facility >> >> (which is a suburb of Dallas) through Cisco San Jose >(California). >> >> Last wee I was in Barcelona, Spain. I used the same VPN >server in >> >> Richardson to get to the Cisco San Jose campus. The only thing >> >> that changed was my origination point, one that cannot be tied to >> >> an IP address, because any VPN that I use going through >Richardson >> >> - which gives my laptop one from its own address range. >> >> >> >> To make matters worse, I have access to 16 other VPN connection >> >> points other than Richardson (in case I cannot get through via >> >> Richardson). Some times these are accessed automatically, >> >> sometimes I purposely connect to another Cisco site than >Richardson >> >> directly. >> >> >> >> How does Cisco understand where I am connecting from? >> >> >> >> I'm mostly focused on location URIs being inserted by a server in >> >> the network thinking it knows where I am (i.e., what we (use to?) >> >> call a "sighter" function). >> >> >> >> >> >> At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: >> >>> Hi Brian, >> >>> >> >>> we have already everything in place that would allow >> >> emergency email to >> >>> work. >> >>> >> >>> Here are the building blocks: >> >>> >> >>> * LoST >> >>> * mails can obviously carry location as location is just another >> >>> MIME type >> >>> * mechanisms to obtain location >> >>> >> >>> LoST allows different elements to be returned. In the >> >> examples we >> >>> spoke about SIP related URIs (including tel URIs) and XMPP URIs. >> >>> Obviously one can also put a mailto: URI in there. >> >>> >> >>> So, if the end point uses LoST to obtain the mailto: URI then >> >> it could >> >>> send the emergency email there. >> >>> >> >>> One important question is: Would email provider be interested in >> >>> deploying this? I suspect "no". Hence, it is better not to mark >> >>> the mail as an emergency email in the same way as we did the >> >>> marking with the Service URN in SIP. Instead, the theme would be >> >>> to mark it for those you care and if there is someone >who does not >> >>> care then >> >> it still >> >>> gets routed to the right place (rather than dropped on the >> >> floor). The >> >>> fear that a user could do fraud by marking emails as emergency >> >>> emails is not really an issue for email at all. >> >>> >> >>> It might be possible to operate dedicated email providers only >> >>> responsible for handling emergency email routing as many >> >> email clients >> >>> allow multiple accounts to be maintained quite transparently. >> >>> >> >>> The next important question is whether the PSAP operator >> >> really want this. >> >>> We all know that email does not really have a strong notion >> >> of security. >> >>> Even though there is DKIM standardized it isn't widely used. As >> >>> such, there is essentially no cryptographic identity with email >> >>> the PSAP operators get and email operators will not deploy new >> >> security security >> >>> mechanisms for this purpose either since the email >operators will >> >>> not like the emergency email concept as it adds new obligations >> >> for them and no (monetary) benefit. >> >>> PSAPs might receive a lot of fake emergency mails and it might >> >>> make them difficult to figure out which onces are real. >> >>> >> >>> The final aspect is on location suitable for dispatch: While our >> >>> protocols would support ways to fetch location by the PSAP >> >>> operator from the access provider using, for example, >the location >> >>> by >> >> reference >> >>> concept we so far know that (despite initial indications of >> >>> interest) >> >>> operators rather prefer a model where they do not send >> >> anything to the >> >>> end host. Even though the location aspect is independent of >> >> the actual >> >>> application service (voice, IM, email, etc.) most >operators would >> >>> not see it that way. Hence, they would only hand out location to >> >>> the PSAP if the regulator forces them (and sometimes not even >> >>> then). This is more an procedural aspect than a technical one. >> >>> >> >>> Did you think about an opt-in variant or not? >> >>> >> >>> Ciao >> >>> Hannes >> >>> >> >>> PS: I see James already writing an RPH extension for email :-) >> >>> >> >>>> -----Original Message----- >> >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >>>> Behalf Of Rosen, Brian >> >>>> Sent: 31 January, 2009 01:21 >> >>>> To: ecrit@ietf.org >> >>>> Subject: [Ecrit] Does it make sense to email to urn:service:sos? >> >>>> >> >>>> The subject of emailing an emergency request comes up from time >> >>>> to time. >> >>>> So far, we've dismissed the idea primarily because >email is not a >> >>>> real time protocol. >> >>>> >> >>>> In the U.S., we have started working towards supporting SMS for >> >>>> emergency use. The objection raised is "SMS is not a real time >> >>>> protocol". >> >>>> >> >>>> My response to the SMS issue is "although it's certainly >> >> true that it >> >>>> isn't a real time protocol, and messages can be delayed by >> minutes, >> >>>> hours, or even days, people use it as if it was real time, and >> deal >> >>>> with the reality that it isn't. >> >>>> Many users have an expectation that they should be able to text >> >>>> to the emergency service". >> >>>> >> >>>> Is that not true, perhaps to somewhat less degree, for email? >> >>>> Users are indeed less likely to treat email as real time, >> >> but in fact >> >>>> they often use it as if it was. >> >>>> >> >>>> Let us consider what it would take to allow email for emergency >> >>>> services: >> >>>> 1. We would need a way to convey location in SMTP 2. We >> >> would need a >> >>>> way to mark an emergency email 3. We would need a way >to route an >> >>>> emergency email It goes without saying that a PSAP could >> >> send a reply >> >>>> email to the originator. >> >>>> >> >>>> 2 and 3 could clearly be virtually identical to what we use >> >> for calls: >> >>>> "dial string" translation to urn:service:sos, LoST routing >> >> to a URI, >> >>>> regular email routing to that URI. 1 would require a new >> >> feature in >> >>>> SMTP. I'm not sure there is any analog to the "recognize the >> local >> >>>> dial string, translate to the service urn, retarget to the >> >> PSAP URI", >> >>>> but it does seem like a straightforward thing for an email >> >> server to >> >>>> do. >> >>>> >> >>>> Does this make any sense? Is there a good reason NOT to do it? >> >>>> >> >>>> Brian >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Ecrit mailing list >> >>>> Ecrit@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/ecrit >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 07:13:33 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F493A69A0; Mon, 2 Feb 2009 07:13:33 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705F23A69A0 for ; Mon, 2 Feb 2009 07:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9emll9TgvDf for ; Mon, 2 Feb 2009 07:13:30 -0800 (PST) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 364863A682C for ; Mon, 2 Feb 2009 07:13:26 -0800 (PST) Received: from c-69-255-80-200.hsd1.md.comcast.net ([69.255.80.200]:57831 helo=[192.168.1.120]) by portland.eukhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LU0Tq-00031t-Dq; Mon, 02 Feb 2009 15:12:58 +0000 Message-Id: From: ken carlberg To: "Brian Rosen" In-Reply-To: <054701c98546$55725150$0056f3f0$@net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Feb 2009 10:12:59 -0500 References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> <054701c98546$55725150$0056f3f0$@net> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Feb 2, 2009, at 9:55 AM, Brian Rosen wrote: > There is no priority for emergency calls in the PSTN today. I would > not > expect any tomorrow, although I'd like to allow it (RPH). within in the U.S. and 911-type service, couldn't agree more. However, my understanding is that Japan does mark and prioritize 911- type calls. > I would not expect any priority for emergency SMS. > > I would not expect any priority for emergency email. i would agree as well in the general case and the bulk of the installed base, as per Hannes' earlier comment on the topic. my feeling is that we'll see some proprietary work for internal deployments in large companies sometime in the near term. -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 07:18:00 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3173A6A0C; Mon, 2 Feb 2009 07:18:00 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CD63A693C for ; Mon, 2 Feb 2009 07:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbl-H-BPgBJc for ; Mon, 2 Feb 2009 07:17:58 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E840F3A6882 for ; Mon, 2 Feb 2009 07:17:57 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LU0YE-0001qv-Dj; Mon, 02 Feb 2009 09:17:31 -0600 From: "Brian Rosen" To: "'ken carlberg'" References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> <054701c98546$55725150$0056f3f0$@net> In-Reply-To: Date: Mon, 2 Feb 2009 10:17:33 -0500 Message-ID: <055501c98549$618f7c30$24ae7490$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmFSL9GaPoUcj9sQ1qtGJdtl/edqgAAJB+A Content-Language: en-us 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: Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I stand corrected about some jurisdictions having priority for emergency voice calls. Brian > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] > Sent: Monday, February 02, 2009 10:13 AM > To: Brian Rosen > Cc: 'Hannes Tschofenig'; Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > > On Feb 2, 2009, at 9:55 AM, Brian Rosen wrote: > > > There is no priority for emergency calls in the PSTN today. I would > > not > > expect any tomorrow, although I'd like to allow it (RPH). > > within in the U.S. and 911-type service, couldn't agree more. > However, my understanding is that Japan does mark and prioritize 911- > type calls. > > > I would not expect any priority for emergency SMS. > > > > I would not expect any priority for emergency email. > > i would agree as well in the general case and the bulk of the > installed base, as per Hannes' earlier comment on the topic. my > feeling is that we'll see some proprietary work for internal > deployments in large companies sometime in the near term. > > -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 07:52:08 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBA03A68F8; Mon, 2 Feb 2009 07:52:08 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6483A698A for ; Mon, 2 Feb 2009 07:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rKqovAnWVtp for ; Mon, 2 Feb 2009 07:52:04 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 40ADA3A6828 for ; Mon, 2 Feb 2009 07:52:02 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n12FpMgo017803 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Feb 2009 16:51:29 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 2 Feb 2009 16:51:22 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'ken carlberg'" , "'Hannes Tschofenig'" Date: Mon, 2 Feb 2009 16:51:20 +0100 Thread-Topic: [Ecrit] Does it make sense to email to urn:service:sos? Thread-Index: AcmEa/TJ93UCP3AJSLac302t4TzzvAA2drSQAAH5mDA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67495C189@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <046401c98454$e5f1acf0$0201a8c0@nsnintra.net> <304623D1-D056-4F93-834F-73A8BC7089A2@g11.org.uk> <054701c98546$55725150$0056f3f0$@net> In-Reply-To: <054701c98546$55725150$0056f3f0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org To be clear to everyone reading this, "priority" in this case means special handling as a distinct class of traffic, and not necessarily handling at the expense of other traffic. As has already been indicated, there are countries that do this. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, February 02, 2009 2:56 PM > To: 'ken carlberg'; 'Hannes Tschofenig' > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > There is no priority for emergency calls in the PSTN today. > I would not expect any tomorrow, although I'd like to allow > it (RPH). > > I would not expect any priority for emergency SMS. > > I would not expect any priority for emergency email. > > > I am not sure what the right thing to do with marking is. > The easiest thing is to recognize the "dial string" and > translate that to the "PSAP URI" using LoST. That would be a > mailto, and would get the email to the right place. > > What should the "dial string" for email be? I'm not sure. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of ken carlberg > > Sent: Sunday, February 01, 2009 7:52 AM > > To: Hannes Tschofenig > > Cc: 'Rosen, Brian'; ecrit@ietf.org > > Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > > > Gentleman, > > > > This note probably goes a bit beyond what Brian first > brought up, but > > there are other things to keep in mind... > > > > The fact that email runs over TCP and its adaptive algorithms helps > > diminish enthusiasm in augmenting email. But as Brian indirectly > > points out, its the buffer consumption at intermediate servers (ie, > > MTAs) where the bottleneck occurs. And keep in mind that large > > companies will generally have several MTAs needed to simply > exit their > > stub domain. In my old company of 40k+ employees, we would receive > > email messages from admins every November asking that we don't send > > the dancing Santa video during December to decrease the > chances of the > > outgoing MTA getting clogged. > > > > And while I also agree with a number of points brought up by James, > > its important to note that this is under the context of > SMTP. X.400 > > has extensions that distinguish the importance of email in order to > > get past the MTA bottleneck problem. Now, before folks say > that X.400 > > is really a blip in the overall installed based of email > systems, I'll > > agree with you. Its deployment is mostly confined to organizations > > that must have prioritization of email -- eg, DoD, MoD, NATO. And > > NATO is of particular importance on this example because > while it is a > > restricted federation from the perspective of the rest of the > > Internet, it still represents a collection of separate > administrative > > domains, thereby escaping the counter argument that its purely a > > walled garden. (Note that the collection tier-1 ISPs is > also a type > > of restricted federation in terms of participants). But > the point is > > that X.400 has a market because it does something that is not > > standardized with SMTP during emergencies, or importantly, event- > > driven spikes of traffic load. > > > > So, if we go back to Brian's original point of "we want to mark > > emergency mail", I think a couple of questions to ask is in > what form > > and to what degree of versatility do you want this marking? And is > > the form to be binary (eg, SoS in the URL), or is it to be > something > > more along the lines of rfc-4412 and an additional header > in the SMTP > > message? > > > > For your reading entertainment purposes only, you can look at an > > expired (and somewhat incomplete) draft-rfc on the subject at > > http://ftp.iasi.roedu.net/Docs/internet-drafts/draft-schmeing-smtp- > > priorities-05.txt > > > > cheers, > > > > -ken > > > > > > On Feb 1, 2009, at 5:07 AM, Hannes Tschofenig wrote: > > > > > Hi James, > > > > > > I agree with many of your statements. > > > > > > I also agree with the installed base that does not support this > > > functionality. This almost sounds like the VoIP emergency story to > > me. > > > > > > I also agree with the location aspect. Also like in VoIP. > > > > > > Ciao > > > Hannes > > > > > >> SWIW > > >> > > >> - email has no guarantee of delivery > > >> - no guarantee of delivery to the right endpoint > > >> - no guarantee of delivery to the an endpoint application that > > >> won't filter said message into the wrong directory/folder > > >> - had a HIGH likelihood of SPAM on the recepient's end > > >> - SPAM could in general become the biggest issue wrt actually > > >> having someone at the PSAP have to "look" at each and > every message > > >> because no one can build in the proper automated filters > to cover > > >> all possible misspellings of a legitimate email message > > >> - every email application will have to be revved to incorporate > > >> location into some kind of user identifying indication > this is for > > >> sos (maybe this is merely having the "urn:service:sos" in the To: > > >> header). Many (most) users do not upgrade their mailers > too often > > >> (like their home routers)... so this upgrade path will > be an issue, > > >> because it likely cannot be universally expected by the > network to > > >> be in place. > > >> - MTAs don't have the ability to understand where "I am" > to insert > > >> location, given the number of users that either > > >> > > >> -- use a generic application on any computer to > access their > > >> email, or > > >> -- have a VPN > > >> > > >> for example, I use the same laptop with an out of date email > > >> application (Eudora -- that's not supported anymore, and > even if it > > >> was -- which version do I have?). I'm connecting via a VPN today > > >> from a suburb of Fort Worth through Cisco's Richardson facility > > >> (which is a suburb of Dallas) through Cisco San Jose > (California). > > >> Last wee I was in Barcelona, Spain. I used the same VPN > server in > > >> Richardson to get to the Cisco San Jose campus. The only thing > > >> that changed was my origination point, one that cannot > be tied to > > >> an IP address, because any VPN that I use going through > Richardson > > >> - which gives my laptop one from its own address range. > > >> > > >> To make matters worse, I have access to 16 other VPN connection > > >> points other than Richardson (in case I cannot get through via > > >> Richardson). Some times these are accessed automatically, > > >> sometimes I purposely connect to another Cisco site than > Richardson > > >> directly. > > >> > > >> How does Cisco understand where I am connecting from? > > >> > > >> I'm mostly focused on location URIs being inserted by a > server in > > >> the network thinking it knows where I am (i.e., what we > (use to?) > > >> call a "sighter" function). > > >> > > >> > > >> At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: > > >>> Hi Brian, > > >>> > > >>> we have already everything in place that would allow > > >> emergency email to > > >>> work. > > >>> > > >>> Here are the building blocks: > > >>> > > >>> * LoST > > >>> * mails can obviously carry location as location is > just another > > >>> MIME type > > >>> * mechanisms to obtain location > > >>> > > >>> LoST allows different elements to be returned. In the > > >> examples we > > >>> spoke about SIP related URIs (including tel URIs) and XMPP URIs. > > >>> Obviously one can also put a mailto: URI in there. > > >>> > > >>> So, if the end point uses LoST to obtain the mailto: URI then > > >> it could > > >>> send the emergency email there. > > >>> > > >>> One important question is: Would email provider be > interested in > > >>> deploying this? I suspect "no". Hence, it is better not to mark > > >>> the mail as an emergency email in the same way as we did the > > >>> marking with the Service URN in SIP. Instead, the theme > would be > > >>> to mark it for those you care and if there is someone > who does not > > >>> care then > > >> it still > > >>> gets routed to the right place (rather than dropped on the > > >> floor). The > > >>> fear that a user could do fraud by marking emails as emergency > > >>> emails is not really an issue for email at all. > > >>> > > >>> It might be possible to operate dedicated email providers only > > >>> responsible for handling emergency email routing as many > > >> email clients > > >>> allow multiple accounts to be maintained quite transparently. > > >>> > > >>> The next important question is whether the PSAP operator > > >> really want this. > > >>> We all know that email does not really have a strong notion > > >> of security. > > >>> Even though there is DKIM standardized it isn't widely used. As > > >>> such, there is essentially no cryptographic identity with email > > >>> the PSAP operators get and email operators will not deploy new > > >> security security > > >>> mechanisms for this purpose either since the email > operators will > > >>> not like the emergency email concept as it adds new obligations > > >> for them and no (monetary) benefit. > > >>> PSAPs might receive a lot of fake emergency mails and it might > > >>> make them difficult to figure out which onces are real. > > >>> > > >>> The final aspect is on location suitable for dispatch: > While our > > >>> protocols would support ways to fetch location by the PSAP > > >>> operator from the access provider using, for example, > the location > > >>> by > > >> reference > > >>> concept we so far know that (despite initial indications of > > >>> interest) > > >>> operators rather prefer a model where they do not send > > >> anything to the > > >>> end host. Even though the location aspect is independent of > > >> the actual > > >>> application service (voice, IM, email, etc.) most > operators would > > >>> not see it that way. Hence, they would only hand out > location to > > >>> the PSAP if the regulator forces them (and sometimes not even > > >>> then). This is more an procedural aspect than a technical one. > > >>> > > >>> Did you think about an opt-in variant or not? > > >>> > > >>> Ciao > > >>> Hannes > > >>> > > >>> PS: I see James already writing an RPH extension for email :-) > > >>> > > >>>> -----Original Message----- > > >>>> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > > >>>> Behalf Of Rosen, Brian > > >>>> Sent: 31 January, 2009 01:21 > > >>>> To: ecrit@ietf.org > > >>>> Subject: [Ecrit] Does it make sense to email to > urn:service:sos? > > >>>> > > >>>> The subject of emailing an emergency request comes up > from time > > >>>> to time. > > >>>> So far, we've dismissed the idea primarily because > email is not a > > >>>> real time protocol. > > >>>> > > >>>> In the U.S., we have started working towards > supporting SMS for > > >>>> emergency use. The objection raised is "SMS is not a > real time > > >>>> protocol". > > >>>> > > >>>> My response to the SMS issue is "although it's certainly > > >> true that it > > >>>> isn't a real time protocol, and messages can be delayed by > > minutes, > > >>>> hours, or even days, people use it as if it was real time, and > > deal > > >>>> with the reality that it isn't. > > >>>> Many users have an expectation that they should be > able to text > > >>>> to the emergency service". > > >>>> > > >>>> Is that not true, perhaps to somewhat less degree, for email? > > >>>> Users are indeed less likely to treat email as real time, > > >> but in fact > > >>>> they often use it as if it was. > > >>>> > > >>>> Let us consider what it would take to allow email for emergency > > >>>> services: > > >>>> 1. We would need a way to convey location in SMTP 2. We > > >> would need a > > >>>> way to mark an emergency email 3. We would need a way > to route an > > >>>> emergency email It goes without saying that a PSAP could > > >> send a reply > > >>>> email to the originator. > > >>>> > > >>>> 2 and 3 could clearly be virtually identical to what we use > > >> for calls: > > >>>> "dial string" translation to urn:service:sos, LoST routing > > >> to a URI, > > >>>> regular email routing to that URI. 1 would require a new > > >> feature in > > >>>> SMTP. I'm not sure there is any analog to the "recognize the > > local > > >>>> dial string, translate to the service urn, retarget to the > > >> PSAP URI", > > >>>> but it does seem like a straightforward thing for an email > > >> server to > > >>>> do. > > >>>> > > >>>> Does this make any sense? Is there a good reason NOT to do it? > > >>>> > > >>>> Brian > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Ecrit mailing list > > >>>> Ecrit@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/ecrit > > >>>> > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ecrit > > >> > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 08:08:39 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BCB3A6B88; Mon, 2 Feb 2009 08:08:39 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176793A6B88 for ; Mon, 2 Feb 2009 08:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgIJFykRhwtK for ; Mon, 2 Feb 2009 08:08:36 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 7A3B628C1A6 for ; Mon, 2 Feb 2009 08:08:35 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n12G87Rg024257 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Feb 2009 17:08:07 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 2 Feb 2009 17:08:07 +0100 From: "DRAGE, Keith (Keith)" To: Henning Schulzrinne , Hannes Tschofenig Date: Mon, 2 Feb 2009 17:08:06 +0100 Thread-Topic: [Ecrit] Does it make sense to email to urn:service:sos? Thread-Index: AcmFJj8ziPmurbn6RSW5KxvB82JkQgAKZ/HQ Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67495C195@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> <80886C44-0F4E-40D7-AFC8-E9504900E987@cs.columbia.edu> In-Reply-To: <80886C44-0F4E-40D7-AFC8-E9504900E987@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "'Rosen, Brian'" , "ecrit@ietf.org" Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My question would be: "Do such alarms fall into the definition of emergency calls?" Certainly in the UK they do not go near a PSAP. Mostly nowadays they go to some private contractor or security firm who sends one of their own people to investigate before the police are summoned. Some burglar alarms do still end up in the local police station, but do not form part of the normal emergency response handling. So, if part of the definition of emergency service is that it is a public service, then I would guess it would be difficult to call these an emergency service. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Monday, February 02, 2009 11:05 AM > To: Hannes Tschofenig > Cc: 'Rosen, Brian'; ecrit@ietf.org > Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? > > Hannes, > > not disagreeing, but email has also become a favorite tool > for automated event notifications, in the absence of other > widely-deployed and interoperable mechanisms. In limited > scenarios, such as automated alarms, this may be more robust > than alternatives (such as IM and SMS). > > Compared to SMS, the sender (if it directly submits the > email, rather than through a queueing sendmail) gets a good > indication that the email has reached the destination domain. > > One could imagine special-purpose setups, such as an alarm > monitoring company or a chemical plant with automated > sensors, where authentication is not a big deal (since the > alarm company/chemical company can easily cryptographically > sign the email via S/MIME and the number of such companies is > modest on a local level and their identities are known). > > In other words, I have a hard time picturing the local police > chief telling their citizenry to send email when the house is > on fire, but specialized arrangements may make sense, given > the widely deployed infrastructure. > > Henning > > On Jan 31, 2009, at 7:31 AM, Hannes Tschofenig wrote: > > > Hi Brian, > > > > we have already everything in place that would allow > emergency email > > to work. > > > > Here are the building blocks: > > > > * LoST > > * mails can obviously carry location as location is just > another MIME > > type > > * mechanisms to obtain location > > > > LoST allows different elements to be returned. In the > examples > > we spoke about SIP related URIs (including tel URIs) and XMPP URIs. > > Obviously > > one can also put a mailto: URI in there. > > > > So, if the end point uses LoST to obtain the mailto: URI > then it could > > send the emergency email there. > > > > One important question is: Would email provider be interested in > > deploying this? I suspect "no". Hence, it is better not to mark the > > mail as an emergency email in the same way as we did the > marking with > > the Service URN in SIP. Instead, the theme would be to mark it for > > those you care and if there is someone who does not care > then it still > > gets routed to the right place (rather than dropped on the > floor). The > > fear that a user could do fraud by marking emails as > emergency emails > > is not really an issue for email at all. > > > > It might be possible to operate dedicated email providers only > > responsible for handling emergency email routing as many > email clients > > allow multiple accounts to be maintained quite transparently. > > > > The next important question is whether the PSAP operator > really want > > this. > > We all know that email does not really have a strong notion of > > security. > > Even though there is DKIM standardized it isn't widely > used. As such, > > there is essentially no cryptographic identity with email the PSAP > > operators get and email operators will not deploy new security > > security mechanisms for this purpose either since the email > operators > > will not like the emergency email concept as it adds new > obligations > > for them and no (monetary) benefit. > > PSAPs might receive a lot of fake emergency mails and it might make > > them difficult to figure out which onces are real. > > > > The final aspect is on location suitable for dispatch: While our > > protocols would support ways to fetch location by the PSAP operator > > from the access provider using, for example, the location > by reference > > concept we so far know that (despite initial indications of > interest) > > operators rather prefer a model where they do not send > anything to the > > end host. Even though the location aspect is independent of > the actual > > application service (voice, IM, email, etc.) most operators > would not > > see it that way. Hence, they would only hand out location > to the PSAP > > if the regulator forces them (and sometimes not even then). This is > > more an procedural aspect than a technical one. > > > > Did you think about an opt-in variant or not? > > > > Ciao > > Hannes > > > > PS: I see James already writing an RPH extension for email :-) > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of Rosen, Brian > >> Sent: 31 January, 2009 01:21 > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Does it make sense to email to urn:service:sos? > >> > >> The subject of emailing an emergency request comes up from time to > >> time. > >> So far, we've dismissed the idea primarily because email is not a > >> real time protocol. > >> > >> In the U.S., we have started working towards supporting SMS for > >> emergency use. The objection raised is "SMS is not a real time > >> protocol". > >> > >> My response to the SMS issue is "although it's certainly > true that it > >> isn't a real time protocol, and messages can be delayed by > minutes, > >> hours, or even days, people use it as if it was real time, > and deal > >> with the reality that it isn't. > >> Many users have an expectation that they should be able to text to > >> the emergency service". > >> > >> Is that not true, perhaps to somewhat less degree, for email? > >> Users are indeed less likely to treat email as real time, > but in fact > >> they often use it as if it was. > >> > >> Let us consider what it would take to allow email for emergency > >> services: > >> 1. We would need a way to convey location in SMTP 2. We > would need a > >> way to mark an emergency email 3. We would need a way to route an > >> emergency email It goes without saying that a PSAP could > send a reply > >> email to the originator. > >> > >> 2 and 3 could clearly be virtually identical to what we use for > >> calls: > >> "dial string" translation to urn:service:sos, LoST routing > to a URI, > >> regular email routing to that URI. 1 would require a new > feature in > >> SMTP. I'm not sure there is any analog to the "recognize > the local > >> dial string, translate to the service urn, retarget to the > PSAP URI", > >> but it does seem like a straightforward thing for an email > server to > >> do. > >> > >> Does this make any sense? Is there a good reason NOT to do it? > >> > >> Brian > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 08:35:57 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5383A6BB5; Mon, 2 Feb 2009 08:35:57 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8B128C154 for ; Mon, 2 Feb 2009 08:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkww1n4oY+LF for ; Mon, 2 Feb 2009 08:35:55 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id BDBDD3A68EC for ; Mon, 2 Feb 2009 08:35:55 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LU1lc-0007BR-4x; Mon, 02 Feb 2009 10:35:25 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <3D3C75174CB95F42AD6BCC56E5555B45FFF227@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFF227@FIESEXC015.nsn-intra.net> Date: Mon, 2 Feb 2009 11:35:24 -0500 Message-ID: <058f01c98554$4436a9f0$cca3fdd0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmFJcsVTmxjy0HdTnSv5Rj8gvNhdQALecHQ Content-Language: en-us 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: Cc: 'Nils Weidstam' , 'Steinar Hidle Andresen' Subject: Re: [Ecrit] Comments to Phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have looked at these. It is my opinion that no change to -phonebcp is warranted based on them. If/when we re-open -framework, I might improve some wording to clear up some confusion that they seem to have, although it is not clear to me that they are reading -framework when they are looking to understand what -phonebcp is saying. I will respond privately to Nils and Steiner to explain their confusion. Comments on "this may be hard to do", I'm not sure I can respond to other than "if you have a better way, please suggest it, although we have been discussing alternatives for a couple of years now, and these are the best options we came up with". Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Monday, February 02, 2009 6:03 AM > To: ecrit@ietf.org > Cc: Nils Weidstam; Steinar Hidle Andresen > Subject: [Ecrit] Comments to Phone BCP > > FYI, > > Let me forward the comments from Nils and Steinar. > > Ciao > Ha <> nnes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 12:07:35 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC1A3A696D; Mon, 2 Feb 2009 12:07:35 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319ED3A696D; Mon, 2 Feb 2009 12:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wrZORyLBqgH; Mon, 2 Feb 2009 12:07:33 -0800 (PST) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by core3.amsl.com (Postfix) with ESMTP id 2EEAE3A68C5; Mon, 2 Feb 2009 12:07:33 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-170.messagelabs.com!1233605231!11703744!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 20798 invoked from network); 2 Feb 2009 20:07:12 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-170.messagelabs.com with AES256-SHA encrypted SMTP; 2 Feb 2009 20:07:12 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n12K7BDa003918; Mon, 2 Feb 2009 15:07:11 -0500 In-Reply-To: <054601c98545$ccd81280$66883780$@net> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Mon, 2 Feb 2009 15:06:59 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/02/2009 03:09:36 PM, Serialize complete at 02/02/2009 03:09:36 PM Cc: ecrit@ietf.org, ecrit-bounces@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1456050629==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1456050629== Content-Type: multipart/alternative; boundary="=_alternative 006E7D4485257551_=" This is a multipart message in MIME format. --=_alternative 006E7D4485257551_= Content-Type: text/plain; charset="US-ASCII" However, current PSTN emergency calls suffer from both "Emergency butt calls", and people making "Emergency" calls as a way of testing/demonstrating that an unsubscribed handset is functional (apparently a big problem in European "flea market" scenarios). Quite analogous to spam. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ecrit-bounces@ietf.org wrote on 02/02/2009 09:51:56 AM: > > > - had a HIGH likelihood of SPAM on the recepient's end > Increasingly true of SMS, but this is true, sadly > > > - SPAM could in general become the biggest issue wrt actually having > > someone at the PSAP have to "look" at each and every message because > > no one can build in the proper automated filters to cover all > > possible misspellings of a legitimate email message > No doubt about it. Not clear that is reason enough to kill the idea, but > it's certainly an issue. On the other hand, that would argue that no > improvement to email other than spam related improvements should be > accepted. --=_alternative 006E7D4485257551_= Content-Type: text/html; charset="US-ASCII"
However, current PSTN emergency calls suffer from both "Emergency butt calls", and people making "Emergency" calls as a way of testing/demonstrating that an unsubscribed handset is functional (apparently a big problem in European "flea market" scenarios).

Quite analogous to spam.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

ecrit-bounces@ietf.org wrote on 02/02/2009 09:51:56 AM:

>
> > - had a HIGH likelihood of SPAM on the recepient's end
> Increasingly true of SMS, but this is true, sadly
>
> > - SPAM could in general become the biggest issue wrt actually having
> > someone at the PSAP have to "look" at each and every message because
> > no one can build in the proper automated filters to cover all
> > possible misspellings of a legitimate email message
> No doubt about it.  Not clear that is reason enough to kill the idea, but
> it's certainly an issue.  On the other hand, that would argue that no
> improvement to email other than spam related improvements should be
> accepted.
 --=_alternative 006E7D4485257551_=-- --===============1456050629== 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://www.ietf.org/mailman/listinfo/ecrit --===============1456050629==-- From ecrit-bounces@ietf.org Mon Feb 2 14:37:25 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B373A6B04; Mon, 2 Feb 2009 14:37:25 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0223A6B04 for ; Mon, 2 Feb 2009 14:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4Iq8LwcwVce for ; Mon, 2 Feb 2009 14:37:23 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E89693A67B5 for ; Mon, 2 Feb 2009 14:37:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,367,1231113600"; d="scan'208";a="132434928" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2009 22:37:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n12Mb4Sb029754; Mon, 2 Feb 2009 14:37:04 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n12Mb4jF020980; Mon, 2 Feb 2009 22:37:04 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, 2 Feb 2009 14:37:03 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.16.25]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 14:37:03 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Feb 2009 16:37:02 -0600 To: "Hannes Tschofenig" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <046501c98455$a2dd0490$0201a8c0@nsnintra.net> References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> <046501c98455$a2dd0490$0201a8c0@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 02 Feb 2009 22:37:03.0441 (UTC) FILETIME=[C5065C10:01C98586] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3827; t=1233614224; x=1234478224; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Update |Sender:=20; bh=DMbDUlrq0i9iNuZmX3v7bOJHxzECtMLv7RCDxQM9nzE=; b=FBQXe4ZkI66TVFFFq48IzOR33xCkAEhckG10bUHRzDKsM/mzeiFpJesYF8 hixfE6imLZsmT3GaX1mrHT2DtdlY/n8NsEuTb3jNpJlNxFnXzhxl31ib3Jav Z9uNxwYvZw/jmE634uO1rACBWRzozQeBztqZI6abfEnWnU72sYj0E=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ok -- so Richard pointed out where I'm brain dead today about the timezone issue (I'm still obviously not recovered from flying to Barcelona last week) -- I apologize. That said -- as a point of process, is this an official IETF (virtual) interim? The only reason why I ask is that it isn't a month away from the next meeting (which starts on Mar 22nd), nor is it more than 1 month from it's announcement (which should have occurred on Jan 26th)... I don't believe either occurred on time according to IETF rules. just wondering... James At 04:12 AM 2/1/2009, Hannes Tschofenig wrote: >Hmmm. I hope that the Doodle guys got the timezone implemented right. Have >not used it before. > >I have obviously used my timezone (Europe/Helsinki): Thu 26, 9:00 PM >According to http://www.timeanddate.com/ this should translate to 2PM EST. > >It's also fine to have the meeting at 1pm EST but I wonder what others have >read on the page. > >Ciao >Hannes > > > >-----Original Message----- > >From: James M. Polk [mailto:jmpolk@cisco.com] > >Sent: 01 February, 2009 01:13 > >To: Hannes Tschofenig; 'ext Hannes Tschofenig'; 'ECRIT' > >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update > > > >At 03:59 PM 1/31/2009, Hannes Tschofenig wrote: > >>Hi all, > >> > >>Based on the received feedback I have picked one of the > >preferred dates: > >> > >> >>> 26th February, 2:00 PM EST <<< > > > >err... hate to point this one out, but no day at 2pm EST was an option. > > > >The options were 8am and 1pm (both EST) > > > >Please clarify this > > > > > >>Ciao > >>Hannes > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >Behalf Of ext Hannes Tschofenig > >> >Sent: 25 January, 2009 10:46 > >> >To: 'Hannes Tschofenig'; 'ECRIT' > >> >Subject: [Ecrit] ECRIT Virtual Interim Meeting: Update > >> >Importance: High > >> > > >> >Brian quickly spotted a conflict with the NENA TDC. Here is another > >> >try: > >> >http://www.doodle.com/4z4q2fr9mukxn876 > >> > > >> >Ciao > >> >Hannes > >> > > >> >>-----Original Message----- > >> >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf > >> >>Of Hannes Tschofenig > >> >>Sent: 24 January, 2009 10:49 > >> >>To: ECRIT > >> >>Subject: [Ecrit] ECRIT Virtual Interim Meeting > >> >> > >> >>Hi all, > >> >> > >> >>to make some progress in ECRIT we would like to make a > >proposal for > >> >>a virtual interim meeting. The concept of virtual interim meetings > >> >>is floating around in the IETF recently and we thought it is a > >> >pretty good > >> >>idea. Virtual interim meeting means that we are going to have a > >> >>phone conference call for about ~2 hours to chat about > >working group items. > >> >> > >> >>So, unless there are strong objections we suggest that ECRIT > >> >holds such > >> >>a meeting on the 18th February 2009, 10am EST for 2 hours. > >> >> > >> >>Proposed agenda: Discuss status and open issues of ECRIT > >> >working group > >> >>items > >> >> > >> >>We will send an update within the next week on the > >technicalities of > >> >>the call. > >> >> > >> >>Document authors, please resubmit your drafts by the 11th February. > >> >> > >> >>Ciao > >> >>Hannes & Marc > >> >> > >> >>_______________________________________________ > >> >>Ecrit mailing list > >> >>Ecrit@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org > >> >https://www.ietf.org/mailman/listinfo/ecrit > >> > > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 14:50:22 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD723A6B04; Mon, 2 Feb 2009 14:50:22 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3243A68C0 for ; Mon, 2 Feb 2009 14:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o91u90xCBJAk for ; Mon, 2 Feb 2009 14:50:19 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6C5903A6B04 for ; Mon, 2 Feb 2009 14:50:18 -0800 (PST) Received: (qmail invoked by alias); 02 Feb 2009 22:49:59 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp022) with SMTP; 02 Feb 2009 23:49:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18WFmITok4Wgo5r2i005BBHgHcKOYIx0nA18/9yBY Ca9vZH9LrRDagA From: "Hannes Tschofenig" To: "'ext James M. Polk'" , "Hannes Tschofenig" , "'ECRIT'" References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net><013501c97ec9$5cc04300$0201a8c0@nsnintra.net><045801c983ef$3c4643b0$0201a8c0@nsnintra.net><046501c98455$a2dd0490$0201a8c0@nsnintra.net> Date: Tue, 3 Feb 2009 00:50:52 +0200 Message-ID: <009d01c98588$b39c4820$e846a20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmFhskEqzPjR7n1TYWGlCb4hXHoPwAAaEVg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, >That said -- as a point of process, is this an official IETF >(virtual) interim? > >The only reason why I ask is that it isn't a month away from >the next meeting (which starts on Mar 22nd), nor is it more >than 1 month from it's announcement (which should have >occurred on Jan 26th)... I don't believe either occurred on >time according to IETF rules. The rules have changed. The announcement period for a "virtual interim meeting" (=phone conference) as I understood is 2 weeks. Previously phone conferences were treated like regular interim meeting. That was obviously a pretty old-fashioned way of working and that has been revised. Ciao Hannes > >just wondering... > >James > >At 04:12 AM 2/1/2009, Hannes Tschofenig wrote: >>Hmmm. I hope that the Doodle guys got the timezone implemented right. >>Have not used it before. >> >>I have obviously used my timezone (Europe/Helsinki): Thu 26, 9:00 PM >>According to http://www.timeanddate.com/ this should >translate to 2PM EST. >> >>It's also fine to have the meeting at 1pm EST but I wonder >what others >>have read on the page. >> >>Ciao >>Hannes >> >> >> >-----Original Message----- >> >From: James M. Polk [mailto:jmpolk@cisco.com] >> >Sent: 01 February, 2009 01:13 >> >To: Hannes Tschofenig; 'ext Hannes Tschofenig'; 'ECRIT' >> >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update >> > >> >At 03:59 PM 1/31/2009, Hannes Tschofenig wrote: >> >>Hi all, >> >> >> >>Based on the received feedback I have picked one of the >> >preferred dates: >> >> >> >> >>> 26th February, 2:00 PM EST <<< >> > >> >err... hate to point this one out, but no day at 2pm EST >was an option. >> > >> >The options were 8am and 1pm (both EST) >> > >> >Please clarify this >> > >> > >> >>Ciao >> >>Hannes >> >> >> >> >-----Original Message----- >> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >> >Behalf Of ext Hannes Tschofenig >> >> >Sent: 25 January, 2009 10:46 >> >> >To: 'Hannes Tschofenig'; 'ECRIT' >> >> >Subject: [Ecrit] ECRIT Virtual Interim Meeting: Update >> >> >Importance: High >> >> > >> >> >Brian quickly spotted a conflict with the NENA TDC. Here is >> >> >another >> >> >try: >> >> >http://www.doodle.com/4z4q2fr9mukxn876 >> >> > >> >> >Ciao >> >> >Hannes >> >> > >> >> >>-----Original Message----- >> >> >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >> >On Behalf >> >> >>Of Hannes Tschofenig >> >> >>Sent: 24 January, 2009 10:49 >> >> >>To: ECRIT >> >> >>Subject: [Ecrit] ECRIT Virtual Interim Meeting >> >> >> >> >> >>Hi all, >> >> >> >> >> >>to make some progress in ECRIT we would like to make a >> >proposal for >> >> >>a virtual interim meeting. The concept of virtual interim >> >> >>meetings is floating around in the IETF recently and we thought >> >> >>it is a >> >> >pretty good >> >> >>idea. Virtual interim meeting means that we are going to have a >> >> >>phone conference call for about ~2 hours to chat about >> >working group items. >> >> >> >> >> >>So, unless there are strong objections we suggest that ECRIT >> >> >holds such >> >> >>a meeting on the 18th February 2009, 10am EST for 2 hours. >> >> >> >> >> >>Proposed agenda: Discuss status and open issues of ECRIT >> >> >working group >> >> >>items >> >> >> >> >> >>We will send an update within the next week on the >> >technicalities of >> >> >>the call. >> >> >> >> >> >>Document authors, please resubmit your drafts by the >11th February. >> >> >> >> >> >>Ciao >> >> >>Hannes & Marc >> >> >> >> >> >>_______________________________________________ >> >> >>Ecrit mailing list >> >> >>Ecrit@ietf.org >> >> >>https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> >> > >> >> >_______________________________________________ >> >> >Ecrit mailing list >> >> >Ecrit@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/ecrit >> >> > >> >> >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www.ietf.org/mailman/listinfo/ecrit >> > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 2 16:22:55 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABD43A6AB6; Mon, 2 Feb 2009 16:22:55 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969423A6AB6 for ; Mon, 2 Feb 2009 16:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spVs0PHetW0t for ; Mon, 2 Feb 2009 16:22:52 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6076C3A69C1 for ; Mon, 2 Feb 2009 16:22:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,368,1231113600"; d="scan'208";a="132448281" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Feb 2009 00:22:33 +0000 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 n130MXb6012355; Mon, 2 Feb 2009 16:22:33 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n130MXsl028949; Tue, 3 Feb 2009 00:22:33 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, 2 Feb 2009 16:22:33 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.16.25]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 16:22:32 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Feb 2009 18:22:31 -0600 To: "Hannes Tschofenig" , "Hannes Tschofenig" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <009d01c98588$b39c4820$e846a20a@nsnintra.net> References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> <046501c98455$a2dd0490$0201a8c0@nsnintra.net> <009d01c98588$b39c4820$e846a20a@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 03 Feb 2009 00:22:32.0963 (UTC) FILETIME=[81B6C530:01C98595] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4862; t=1233620553; x=1234484553; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Update |Sender:=20; bh=tcWaMR5lj6BqoCQgPVEXZLPkqGz3fV+gGGP6l0UjQZg=; b=KWKlr8rhOC2E7/NitNOM0Ox1Edms/3jy/mjVtDdZn+x6BbVe4uCUzXOAoU ukhntG1KDZdm3Z/KythZAhChRzYcrX2cbeP4hdhVSWbBpcJ2swe9P7cWNAE3 FSpoR73JHE; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:50 PM 2/2/2009, Hannes Tschofenig wrote: >Hi James, > > >That said -- as a point of process, is this an official IETF > >(virtual) interim? > > > >The only reason why I ask is that it isn't a month away from > >the next meeting (which starts on Mar 22nd), nor is it more > >than 1 month from it's announcement (which should have > >occurred on Jan 26th)... I don't believe either occurred on > >time according to IETF rules. > > >The rules have changed. The announcement period for a "virtual interim >meeting" (=phone conference) as I understood is 2 weeks. thanks for the update -- I was unaware of the official change in process (hand-slap). >Previously phone conferences were treated like regular interim meeting. That >was obviously a pretty old-fashioned way of working I'm not sure I agree - given that this was primarily built into the process to give enough folks the time to review all the written material associated with any given meeting... >and that has been revised. > >Ciao >Hannes > > > > >just wondering... > > > >James > > > >At 04:12 AM 2/1/2009, Hannes Tschofenig wrote: > >>Hmmm. I hope that the Doodle guys got the timezone implemented right. > >>Have not used it before. > >> > >>I have obviously used my timezone (Europe/Helsinki): Thu 26, 9:00 PM > >>According to http://www.timeanddate.com/ this should > >translate to 2PM EST. > >> > >>It's also fine to have the meeting at 1pm EST but I wonder > >what others > >>have read on the page. > >> > >>Ciao > >>Hannes > >> > >> > >> >-----Original Message----- > >> >From: James M. Polk [mailto:jmpolk@cisco.com] > >> >Sent: 01 February, 2009 01:13 > >> >To: Hannes Tschofenig; 'ext Hannes Tschofenig'; 'ECRIT' > >> >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update > >> > > >> >At 03:59 PM 1/31/2009, Hannes Tschofenig wrote: > >> >>Hi all, > >> >> > >> >>Based on the received feedback I have picked one of the > >> >preferred dates: > >> >> > >> >> >>> 26th February, 2:00 PM EST <<< > >> > > >> >err... hate to point this one out, but no day at 2pm EST > >was an option. > >> > > >> >The options were 8am and 1pm (both EST) > >> > > >> >Please clarify this > >> > > >> > > >> >>Ciao > >> >>Hannes > >> >> > >> >> >-----Original Message----- > >> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >> >Behalf Of ext Hannes Tschofenig > >> >> >Sent: 25 January, 2009 10:46 > >> >> >To: 'Hannes Tschofenig'; 'ECRIT' > >> >> >Subject: [Ecrit] ECRIT Virtual Interim Meeting: Update > >> >> >Importance: High > >> >> > > >> >> >Brian quickly spotted a conflict with the NENA TDC. Here is > >> >> >another > >> >> >try: > >> >> >http://www.doodle.com/4z4q2fr9mukxn876 > >> >> > > >> >> >Ciao > >> >> >Hannes > >> >> > > >> >> >>-----Original Message----- > >> >> >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> >On Behalf > >> >> >>Of Hannes Tschofenig > >> >> >>Sent: 24 January, 2009 10:49 > >> >> >>To: ECRIT > >> >> >>Subject: [Ecrit] ECRIT Virtual Interim Meeting > >> >> >> > >> >> >>Hi all, > >> >> >> > >> >> >>to make some progress in ECRIT we would like to make a > >> >proposal for > >> >> >>a virtual interim meeting. The concept of virtual interim > >> >> >>meetings is floating around in the IETF recently and we thought > >> >> >>it is a > >> >> >pretty good > >> >> >>idea. Virtual interim meeting means that we are going to have a > >> >> >>phone conference call for about ~2 hours to chat about > >> >working group items. > >> >> >> > >> >> >>So, unless there are strong objections we suggest that ECRIT > >> >> >holds such > >> >> >>a meeting on the 18th February 2009, 10am EST for 2 hours. > >> >> >> > >> >> >>Proposed agenda: Discuss status and open issues of ECRIT > >> >> >working group > >> >> >>items > >> >> >> > >> >> >>We will send an update within the next week on the > >> >technicalities of > >> >> >>the call. > >> >> >> > >> >> >>Document authors, please resubmit your drafts by the > >11th February. > >> >> >> > >> >> >>Ciao > >> >> >>Hannes & Marc > >> >> >> > >> >> >>_______________________________________________ > >> >> >>Ecrit mailing list > >> >> >>Ecrit@ietf.org > >> >> >>https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> > >> >> > > >> >> >_______________________________________________ > >> >> >Ecrit mailing list > >> >> >Ecrit@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/ecrit > >> >> > > >> >> > >> >>_______________________________________________ > >> >>Ecrit mailing list > >> >>Ecrit@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 3 00:29:59 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E523A69D8; Tue, 3 Feb 2009 00:29:59 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A503A6A63 for ; Tue, 3 Feb 2009 00:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 153fAxgfAT9a for ; Tue, 3 Feb 2009 00:29:57 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 23E1D3A6824 for ; Tue, 3 Feb 2009 00:29:56 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n138TWwo006980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Feb 2009 09:29:32 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n138TLjZ010033; Tue, 3 Feb 2009 09:29:31 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 09:29:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 10:29:14 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FFF908@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Update Thread-Index: AcmFlYdGbhW6o66hQMWFEyvNj2Q9FgAPbFdA References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net><013501c97ec9$5cc04300$0201a8c0@nsnintra.net><045801c983ef$3c4643b0$0201a8c0@nsnintra.net><046501c98455$a2dd0490$0201a8c0@nsnintra.net><009d01c98588$b39c4820$e846a20a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "Hannes Tschofenig" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 03 Feb 2009 08:29:29.0015 (UTC) FILETIME=[87D68470:01C985D9] Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, >>The rules have changed. The announcement period for a >"virtual interim >>meeting" (=phone conference) as I understood is 2 weeks. > >thanks for the update -- I was unaware of the official change >in process (hand-slap). Don't worry. > >>Previously phone conferences were treated like regular >interim meeting. >>That was obviously a pretty old-fashioned way of working > >I'm not sure I agree - given that this was primarily built >into the process to give enough folks the time to review all >the written material associated with any given meeting... Maybe. In KEYPROV I am using weekly conference calls with the draft authors (and everyone from the WG is allowed to participate) to the check the editing progress for a while now and it certainly has helped us to make some progress. Folks tend to get distracted so quickly and sometimes it requires some additional mechanisms to keep them right on track. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 3 01:55:55 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D25F3A6923; Tue, 3 Feb 2009 01:55:55 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C09E3A6923 for ; Tue, 3 Feb 2009 01:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PciyVPSU6PcY for ; Tue, 3 Feb 2009 01:55:53 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 92BFF3A68D2 for ; Tue, 3 Feb 2009 01:55:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,371,1231131600"; d="scan'208";a="160121805" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 03 Feb 2009 04:55:33 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Feb 2009 04:55:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 10:55:10 +0100 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFF908@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Update thread-index: AcmFlYdGbhW6o66hQMWFEyvNj2Q9FgAPbFdAAASF+OA= References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net><013501c97ec9$5cc04300$0201a8c0@nsnintra.net><045801c983ef$3c4643b0$0201a8c0@nsnintra.net><046501c98455$a2dd0490$0201a8c0@nsnintra.net><009d01c98588$b39c4820$e846a20a@nsnintra.net> <3D3C75174CB95F42AD6BCC56E5555B45FFF908@FIESEXC015.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext James M. Polk" , "Hannes Tschofenig" , "Hannes Tschofenig" , "ECRIT" Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, February 03, 2009 10:29 AM > To: ext James M. Polk; Hannes Tschofenig; Hannes Tschofenig; ECRIT > Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Update > > Hi James, > > > >>The rules have changed. The announcement period for a > >"virtual interim > >>meeting" (=phone conference) as I understood is 2 weeks. > > > >thanks for the update -- I was unaware of the official change in > >process (hand-slap). > > Don't worry. > For reference - the 'new rules' can be read at http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt Dan _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 3 04:07:58 2009 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6EB28C163; Tue, 3 Feb 2009 04:07:58 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27A23A69BA for ; Tue, 3 Feb 2009 04:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5UbQxfSlORy for ; Tue, 3 Feb 2009 04:07:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9411928C190 for ; Tue, 3 Feb 2009 04:07:37 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n13C7GFm012360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Feb 2009 13:07:16 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n13C7Gu1011350; Tue, 3 Feb 2009 13:07:16 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 13:07:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 14:07:15 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FFFC06@FIESEXC015.nsn-intra.net> In-Reply-To: <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Virtual Interim Meeting: Agenda Thread-Index: Acl+AGcDaTZN0lrqSDa8KqbwOQ/NCAAyLM5QAUk+ynAAgHJ/QA== References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net><013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 03 Feb 2009 12:07:15.0612 (UTC) FILETIME=[F422FDC0:01C985F7] Subject: [Ecrit] ECRIT Virtual Interim Meeting: Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is the agenda proposal for the meeting: * draft-ietf-ecrit-phonebcp and draft-ietf-ecrit-framework Only if there are substantial comments received during WGLC that require a discussion. Brian will do the job. * draft-ietf-ecrit-lost-sync Recently Roger and Richard provided their document reviews. We discuss their reviews. Henning or Hannes will be the discussion lead. * draft-ietf-ecrit-local-emergency-rph-namespace This document received a lot of feedback. We should start our discussion with the where the marking should happen along the e2e chain. James is going to lead this discussion. * draft-barnes-ecrit-rough-loc Richard will lead us through this document and tell us what the necessary steps are to complete it. * draft-patel-ecrit-sos-parameter Milan will tell us what the open issues with this document are. * draft-rosen-ecrit-premature-disconnect-rqmts Brian will inform us about the recent draft update and we will chat whether this version can be picked up as a WG item. * RFC5031bis and draft-forte-ecrit-lost-extensions Henning or Andrea will brief us about the plans to update the Service URN RFC and how to then deal with the extensions that have been proposed to the group. * draft-wolf-ecrit-lost-servicelistboundary Karl Heinz wanted to give a presentation about this draft at the last IETF meeting but we ran out of time. Let's try it again. * draft-schulzrinne-ecrit-unauthenticated-access Finally, we should chat about how we should proceed with the unauthenticated emergency calls document. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From sedge@qualcomm.com Thu Feb 26 20:30:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2E23A6B45 for ; Thu, 26 Feb 2009 20:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cWxq0CBinxK for ; Thu, 26 Feb 2009 20:30:21 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CA2F63A6936 for ; Thu, 26 Feb 2009 20:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1235709044; x=1267245044; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20R ichard=20Barnes=20|CC:=20Brian=20Rosen =20,=20"'ECRIT'"=20 |Date:=20Thu,=2026=20Feb=202009=2020:30:14=20-0800 |Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework=20D raft|Thread-Topic:=20[Ecrit]=20Comments=20on=20Framework =20Draft|Thread-Index:=20AcmXuikRk+dIr3f0R02FPhxVSe0AlwA1 eIWg|Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC53749 E36@NASANEXMB04.na.qualcomm.com>|References:=20<1288E74A7 3964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.c om>=0D=0A=09<0a8d01c991ff$fd063420$f7129c60$@net>=0D=0A =20<1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04. na.qualcomm.com>=0D=0A=20<49A5FEAE.6000605@bbn.com> |In-Reply-To:=20<49A5FEAE.6000605@bbn.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5537"=3B=20a=3D"15826368"; bh=J/pLpV7gsMRptk9sizv17fnJqjK8Kv9fCGyerVN4pw8=; b=VBmDDTNGyTILTFN9rNxbCC0XMpY3nACISz/XFGnOAtEyyhcggOL5G51U 3a+juMn97uf0aaybeTvR6ylIROB0wPNzJ9lRjrZ0C5uIiY5oPG+wLROig Kux79WH3tQByb3TJQavziHF3KusHTVf5cmO/I1A6y0Gzt/tzZesotSLOp Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5537"; a="15826368" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2009 20:30:43 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1R4UhNP024276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Feb 2009 20:30:43 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1R4UfvV011057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Feb 2009 20:30:42 -0800 (PST) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Thu, 26 Feb 2009 20:30:17 -0800 From: "Edge, Stephen" To: Richard Barnes Date: Thu, 26 Feb 2009 20:30:14 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmXuikRk+dIr3f0R02FPhxVSe0AlwA1eIWg Message-ID: <1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <49A5FEAE.6000605@bbn.com> In-Reply-To: <49A5FEAE.6000605@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 04:30:23 -0000 Hi Richard Thanks for the comments. Your statement below that "SIP emergency calling w= orks if all parties behave as specified in these (IETF Ecrit) documents" to= some degree highlights the problems we are raising. The documents do conta= in a number of implicit and explicit restrictions - like IP capable PSAPs, = global IP access (no islands of circuit mode access for example), universal= support of this solution by all access providers and VSPs (not much good i= f some opt for another solution) and end system oriented location and routi= ng capability - which together make them unsuitable (we believe) for cellul= ar wireless networks. If these restrictions and assumptions were all made e= xplicit upfront, it would to a large degree (and possibly completely) addre= ss our concerns. =20 You are right in assuming another set of specifications for the 3GPP and 3G= PP2 solution. The applicability of this solution is explicitly defined in T= S 23.167 (or more exactly in an already agreed CR in contribution S2-090752= which will become part of 23.167 in a few more weeks) to cover the followi= ng access types: GPRS (UTRAN WCDMA), I-WLAN, Fixed Broadband, CDMA2000 HRPD= , EPS UTRAN (WCDMA) and EPS E-UTRAN (LTE). So there is a restriction and ar= bitrary internet access is not covered (yet) as I have stated before. Kind Regards Stephen -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Wednesday, February 25, 2009 6:30 PM To: Edge, Stephen Cc: Brian Rosen; 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft Hi Stephen, I'm a little confused by the scope of what you're asking. The framework=20 and phonebcp documents exist in order to describe the ECRIT solution:=20 They say, in effect, "SIP emergency calling works if all parties behave=20 as specified in these documents." As I understand what you're saying (and I'm by no means an expert in=20 3GPP), 3GPP specifies that one or more elements of this system behave=20 differently. This simply means that 3GPP networks aren't complying with=20 these specs. Just like there's no disclaimer in RFC 791 (IPv4) that=20 says "this doesn't work on X.25 networks", it's not clear to me that an=20 analogous disclaimer is called for here. I presume there are similar documents describing how emergency calling=20 works in 3GPP networks. Do they include notes saying that the 3GPP=20 solution doesn't work in the broader Internet? --Richard Edge, Stephen wrote: > Brian >=20 > First of all apologies for the likely lateness of this reply - I actually= wrote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems unl= ikely that my VPN, Outlook server and WiFi access capability will cooperate= together to get it sent until I return to the office mid-next week. >=20 > Anyhow thanks for your comments. There have actually been a number of con= ference calls between IETF and 3GPP participants over the last couple of ye= ars at which common features like support of IP emergency calls were discus= sed and these could have been good forum for participants on either side to= have raised the kinds of issues you elaborate on below. Given that seems n= ot so far to have happened, it could still be possible in future such calls= . >=20 > But the issues we are raising are not directly to do with further alignin= g the 2 solutions or with the lack of this in the past. We are simply point= ing out that the solutions are currently different and that from a cellular= wireless perspective, the Ecrit solution is not seen as suitable in all re= spects (for support of IP emergency calls originating from such access type= s). That is not just our point of view. 3GPP2 sent a liaison to Ecrit some = months ago pointing out the same issues. >=20 > So we are proposing that the Ecrit framework and phoneBCP spec.s include = a statement acknowledging this - e.g. by referencing the alternative 3GPP/3= GPP2 solution and indicating the IP access types for which the Ecrit soluti= on will work without limitation (or equivalently the access types where lim= itations are not ruled out). >=20 > We are not proposing further modification and extension of the Ecrit solu= tion - just pointing out that this would be needed (as with the 3GPP/3GPP2 = solution) to fully cover all types of access. >=20 > Kind Regards=20 >=20 > Stephen > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, February 18, 2009 8:07 PM > To: Edge, Stephen; 'ECRIT' > Subject: RE: [Ecrit] Comments on Framework Draft >=20 > I have bit my tongue on this one for a long time. >=20 > Stephen, with respect, please go talk to 3GPP management and ask them wh= y > there has been no participation in the ecrit effort despite multiple YEAR= S > of begging them to get involved. To put it frankly, 3GPP is quite willin= g > to bully IETF into doing its work on its schedule, but cannot be bothered= to > get work done it knows it will eventually have to do when the IETF asks i= t > to do so. >=20 > 3GPP understands the mess that is being created by not participating. Th= ey > know full well that when they finally get around to dealing with PS > terminated emergency calls, that there will be a lot of resistance to > changing fully specified and implemented standards to more closely align > with 3GPP standards. I expect you will have several interworking functio= ns > to define and build. >=20 > So, politely, please go away, we're finishing work we dearly wanted you a= ll > to be involved with for years, but you refused to do anything. It's too > late for this rev. >=20 > Now, having said that, there are quite a few people who have participated= in > the IETF work who are IMS aware and I believe that despite your fears, > everything you need is in the specs. The mechanisms we have defined prov= ide > the ability for the network to insert location, recognize and mark emerge= ncy > calls, and route on behalf of endpoints. An E-CSCF could quite > straightforwardly provide a SIP call towards an ecrit compatible PSAP. T= he > only not-quite-nice interwork would be from SUPL to HELD (or SIP), but it= 's > pretty easy to do that. I'll also note that we have tried to get OMA and > IETF to cooperate on location protocols, but we have been spectacularly > unsuccessful at that effort also. >=20 > Brian >=20 > =20 >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Thursday, February 05, 2009 2:50 AM >> To: 'ECRIT' >> Subject: [Ecrit] Comments on Framework Draft >> >> All >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> description of how terminals and networks should support emergency >> calls made over IP capable facilities to IP capable PSAPs. It appears >> intended to cover all types of access network - including fixed line, >> WiFi and cellular (e.g. examples involving each can be found throughout >> the draft). >> >> When we evaluated this with respect to support of wireless cellular >> access and WiFi access associated with a cellular operator (e.g. WLAN >> or Femto cells integrated into a cellular network), we found that >> certain portions of the draft exhibited one or more of the following >> characteristics: >> >> (A) Inconsistent with already standardized wireless solutions >> >> (B) Inconsistent with essential wireless requirements and >> conventions >> >> (C) Already part of wireless standards or potentially part of >> future standards >> >> (A) refers to all portions of the draft framework that differ from the >> requirements and procedures currently standardized for wireless >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of >> solution and could be resolved through support of both solutions by >> terminals (with each solution being used according to the type of >> access network and VSP) or could be resolved by supporting only one >> solution and accessing only the types of network supporting that >> solution. To acknowledge this category, the framework document could >> reference the applicable wireless standards and point out that these >> are valid alternatives for wireless cellular based access. >> >> (B) refers to portions of the draft that would be unsuitable for >> wireless networks even if no alternative solution existed together with >> other portions missing from the draft that would be needed to fully >> support wireless networks. Examples of the former include: (a) emphasis >> on endpoint derivation of location, performance of Lost query and >> receipt of local dial strings; (b) restriction of LCPs to protocols >> that require terminal initiation (not allowing for network initiation >> as far as we can tell) and that include two LCPs (DHCP and LLDP) that >> are not applicable to (not defined for) cellular access; and (c) the >> requirement that a terminal or at least a LIS will update the PSAP >> whenever location changes. (a) is impractical due to network and >> terminal loading consequences and failure to support non-IP capable >> PSAPs; (b) makes location verification and updated location provision >> to PSAPs difficult or impossible; while (c) is also incompatible with >> support of existing non-IP capable PSAPs besides increasing terminal >> load and possibly interfering with optimum maintenance of the RF >> connection (e.g. if a terminal has to tune away from the serving base >> station or WLAN periodically to make location measurements). Examples >> of the latter include (d) absence of support for access to non-IP >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in the >> US); (e) no support for handover from the IP to the circuit domain when >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; and >> (f) no allowance for limited access modes wherein a terminal may access >> a network only to place an emergency call with ensuing restrictions on >> (for example) location acquisition, PSAP callback and caller >> verification and identification to the PSAP. To resolve this category >> either significant changes to the framework document could be made or a >> disclaimer/applicability statement could be added stating that support >> of cellular wireless networks and their associated WLAN and Femto >> access points is not covered. >> >> Category (C) comprises concepts and capabilities in the draft that are >> either already part of the standardized solution for wireless networks >> or that might be added at a later time. Examples of the former include >> LoST, SIP location conveyance, general use of SIP, location for routing >> versus for dispatch, cellular positioning methods. Examples of the >> latter include use of location references and dereferencing and >> possible interworking between the current wireless network solutions >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The >> presence of this category could be acknowledged by following the >> disclaimer for (B) with a statement that certain portions of the >> solution are expected to be incorporated into wireless networks now >> and/or in the future. >> >> We hope that these comments will be seen to be a useful addition to >> this review in the sense of enabling a more precise scoping for the >> framework document and we are willing to assist in providing wording >> for any disclaimer/applicability statement that the Ecrit working group >> may now deem fit to include. >> >> Kind Regards >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm >> 3GPP2 TSG-X and TSG-C participant) >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From sedge@qualcomm.com Thu Feb 26 21:38:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C183A6964 for ; Thu, 26 Feb 2009 21:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxvmDDvIJRag for ; Thu, 26 Feb 2009 21:38:09 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id BBB993A68F2 for ; Thu, 26 Feb 2009 21:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1235713112; x=1267249112; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20Brian=20Rosen=0D=0A=09,=20ECRIT=20|Date:=20Thu, =2026=20Feb=202009=2021:38:22=20-0800|Subject:=20RE:=20[E crit]=20Comments=20on=20Framework=20Draft|Thread-Topic: =20[Ecrit]=20Comments=20on=20Framework=20Draft |Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZB fMABQDsYoAA26fDA|Message-ID:=20<1288E74A73964940B132A0B9E A8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com>|References: =20<1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04. na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net>=0D =0A=20<1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB 04.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5537"=3B=20a=3D"15844025"; bh=6rjZVOGxlV5O9KZd5zDOhyUonb+V6gLl4SkttJUb1WA=; b=gvBhRKQtxTh0U5ONx2NpRTgV+QSbpEv9qdwHNEnaQ2CIOfbtszlM1VZV /jvHsqWM9dOU3P357b5WYrybb4i78Ivja7mK2gpmeU4Yp55K3fPAuFJvm UDhdatZrZ5xak1XgAcg1KLjvwKVQjtfMdMKs0v23ZbE0kdG9cnSrgKg6i 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5537"; a="15844025" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2009 21:38:31 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1R5cVxS029900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Feb 2009 21:38:31 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1R5cOv6024739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Feb 2009 21:38:31 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Thu, 26 Feb 2009 21:38:24 -0800 From: "Edge, Stephen" To: "Winterbottom, James" , Brian Rosen , ECRIT Date: Thu, 26 Feb 2009 21:38:22 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26fDA Message-ID: <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 05:38:16 -0000 Hi James Thanks for these further comments and for this oft repeated example - namel= y use of a 3GPP or 3GPP2 IP access network to reach a non-3GPP/3GPP2 VSP. T= his is always being thrown up as a reason that the 3GPP/3GPP2 solution cann= ot even fully address its own calling scenarios. It is however incomplete f= or the following reasons. First of all, I doubt that in this example either the Ecrit or 3GPP/3GPP2 s= olution would actually be possible now since neither are fully defined or f= ully implemented yet. Perhaps the VSP would provide some rudimentary E911 c= apability though probably not to the right PSAP. So the example is more hyp= othetical for future implementation in which case either solution might be = considered. Maybe you are aware that CDMA EvDO providers will be obligated by the FCC i= n the US to provide E911 capability assuming they are using licensed spectr= um. So in this example, and in a few more years when the 3GPP/3GPP2 solutio= n has been fully defined and implemented, the device in question would be a= ble to access the CDMA EvDO network, assuming it recognized the dialed emer= gency number and supported the 3GPP/3GPP2 solution, and make an IP based E9= 11 call directly via the serving EvDO network and not via its normal VSP. I= f it did not recognize the dialed emergency number or chose to use the norm= al VSP anyway but still supported the 3GPP/3GPP2 solution, then the VSP (e.= g. based on receiving some access network related information from the devi= ce in the SIP INVITE such as an EvDO cell ID and possibly based on subscrip= tion information if needed to imply 3GPP/3GPP2 capability for the device) c= ould send an error response back to the device (a SIP 380 response with an = emergency indication) that would cause the device to redirect the call to t= he EvDO serving network. If the device did not support the 3GPP/3GPP2 solut= ion, this would not work - but it seems unreasonable to treat non-support o= f a solution as a weakness since almost every solution is susceptible to th= is. The above would not prevent the VSP from employing the Ecrit solution for o= ther types of access not supporting the 3GPP/3GPP2 solution and the increme= ntal cost to the VSP of supporting the 3GPP/3GPP2 solution (by means of the= 380 response) ought to be small. The one case I have omitted but which I assume you may specifically have in= mind is where the device only supports IP data access and acts as a router= on behalf of another end device (e.g. a laptop). In that case, I think bot= h solutions would be severely handicapped. The Ecrit solution would have a = hard time obtaining location (unless the end device already had an accurate= location fix which it included in the SIP INVITE) and in routing to a PSTN= capable PSAP (particularly one in another country). The 3GPP/3GPP2 solutio= n - assuming the VSP supported it - might find location easier (e.g. if the= router or end device supported SUPL since that would allow location for di= spatch subsequent to call routing), but would find PSTN PSAP routing just a= s hard. The parts of the Ecrit solution that appear unsuitable for cellular network= s I have already elaborated on - e.g. endpoint oriented location and routin= g, no explicit cellular location capability, no explicit support for PSAPs = accessed over the PSTN (the NENA i2 solution is not a global standard and s= eems impractical where a PSAP is very remote from the VSP), no consideratio= n for handover to or from circuit mode access (which will remain the norm f= or many years) or even to/from other IP access networks. Kind Regards Stephen -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, February 25, 2009 8:48 PM To: Edge, Stephen; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, It is a pity that you were not in the NENA location WG meeting in Orlando l= ast week, as we had a very pertinent example put forward. The example was a guy with a CDMA EVDO capable device, he is able to establ= ish a VPN connection back into his corporate network and then make VoIP cal= ls. The gentleman in question claims that he does this regularly. If he wer= e to make an emergency call would it be following the ECRIT or 3GPP2 call f= lows? The answer is that the call flow follows the ECRIT flow but the access is C= DMA EVDO, clearly 3GPP2, and clearly cellular! Ipso facto ECRIT on cellular= works! I don't believe that anybody that understands the ECRIT architecture and ha= s a notion of what products are being sold and used today can seriously sug= gest that the ECRIT architecture doesn't work for a cellular network. The f= act that home routers with 3G Internet connections are being sold is an ind= icator that the 3G service is just another access to the Internet and that = VoIP over 3G is being used and that ECRIT over 3G is quite possible. Perhaps it would be pertinent at this time to ask precisely which bits of t= he ECRIT architecture you feel are unworkable in a 3GPP/2 network? Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of E= dge, Stephen Sent: Thursday, 26 February 2009 1:11 PM To: Brian Rosen; 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft Brian First of all apologies for the likely lateness of this reply - I actually w= rote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems unlik= ely that my VPN, Outlook server and WiFi access capability will cooperate t= ogether to get it sent until I return to the office mid-next week. Anyhow thanks for your comments. There have actually been a number of confe= rence calls between IETF and 3GPP participants over the last couple of year= s at which common features like support of IP emergency calls were discusse= d and these could have been good forum for participants on either side to h= ave raised the kinds of issues you elaborate on below. Given that seems not= so far to have happened, it could still be possible in future such calls. But the issues we are raising are not directly to do with further aligning = the 2 solutions or with the lack of this in the past. We are simply pointin= g out that the solutions are currently different and that from a cellular w= ireless perspective, the Ecrit solution is not seen as suitable in all resp= ects (for support of IP emergency calls originating from such access types)= . That is not just our point of view. 3GPP2 sent a liaison to Ecrit some mo= nths ago pointing out the same issues. So we are proposing that the Ecrit framework and phoneBCP spec.s include a = statement acknowledging this - e.g. by referencing the alternative 3GPP/3GP= P2 solution and indicating the IP access types for which the Ecrit solution= will work without limitation (or equivalently the access types where limit= ations are not ruled out). We are not proposing further modification and extension of the Ecrit soluti= on - just pointing out that this would be needed (as with the 3GPP/3GPP2 so= lution) to fully cover all types of access. Kind Regards Stephen -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, February 18, 2009 8:07 PM To: Edge, Stephen; 'ECRIT' Subject: RE: [Ecrit] Comments on Framework Draft I have bit my tongue on this one for a long time. Stephen, with respect, please go talk to 3GPP management and ask them why there has been no participation in the ecrit effort despite multiple YEARS of begging them to get involved. To put it frankly, 3GPP is quite willing to bully IETF into doing its work on its schedule, but cannot be bothered t= o get work done it knows it will eventually have to do when the IETF asks it to do so. 3GPP understands the mess that is being created by not participating. They know full well that when they finally get around to dealing with PS terminated emergency calls, that there will be a lot of resistance to changing fully specified and implemented standards to more closely align with 3GPP standards. I expect you will have several interworking functions to define and build. So, politely, please go away, we're finishing work we dearly wanted you all to be involved with for years, but you refused to do anything. It's too late for this rev. Now, having said that, there are quite a few people who have participated i= n the IETF work who are IMS aware and I believe that despite your fears, everything you need is in the specs. The mechanisms we have defined provid= e the ability for the network to insert location, recognize and mark emergenc= y calls, and route on behalf of endpoints. An E-CSCF could quite straightforwardly provide a SIP call towards an ecrit compatible PSAP. The only not-quite-nice interwork would be from SUPL to HELD (or SIP), but it's pretty easy to do that. I'll also note that we have tried to get OMA and IETF to cooperate on location protocols, but we have been spectacularly unsuccessful at that effort also. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Edge, Stephen > Sent: Thursday, February 05, 2009 2:50 AM > To: 'ECRIT' > Subject: [Ecrit] Comments on Framework Draft > > All > > draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative > description of how terminals and networks should support emergency > calls made over IP capable facilities to IP capable PSAPs. It appears > intended to cover all types of access network - including fixed line, > WiFi and cellular (e.g. examples involving each can be found throughout > the draft). > > When we evaluated this with respect to support of wireless cellular > access and WiFi access associated with a cellular operator (e.g. WLAN > or Femto cells integrated into a cellular network), we found that > certain portions of the draft exhibited one or more of the following > characteristics: > > (A) Inconsistent with already standardized wireless solutions > > (B) Inconsistent with essential wireless requirements and > conventions > > (C) Already part of wireless standards or potentially part of > future standards > > (A) refers to all portions of the draft framework that differ from the > requirements and procedures currently standardized for wireless > emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of > solution and could be resolved through support of both solutions by > terminals (with each solution being used according to the type of > access network and VSP) or could be resolved by supporting only one > solution and accessing only the types of network supporting that > solution. To acknowledge this category, the framework document could > reference the applicable wireless standards and point out that these > are valid alternatives for wireless cellular based access. > > (B) refers to portions of the draft that would be unsuitable for > wireless networks even if no alternative solution existed together with > other portions missing from the draft that would be needed to fully > support wireless networks. Examples of the former include: (a) emphasis > on endpoint derivation of location, performance of Lost query and > receipt of local dial strings; (b) restriction of LCPs to protocols > that require terminal initiation (not allowing for network initiation > as far as we can tell) and that include two LCPs (DHCP and LLDP) that > are not applicable to (not defined for) cellular access; and (c) the > requirement that a terminal or at least a LIS will update the PSAP > whenever location changes. (a) is impractical due to network and > terminal loading consequences and failure to support non-IP capable > PSAPs; (b) makes location verification and updated location provision > to PSAPs difficult or impossible; while (c) is also incompatible with > support of existing non-IP capable PSAPs besides increasing terminal > load and possibly interfering with optimum maintenance of the RF > connection (e.g. if a terminal has to tune away from the serving base > station or WLAN periodically to make location measurements). Examples > of the latter include (d) absence of support for access to non-IP > capable PSAPs as already mentioned (e.g. to support E911 phase 2 in the > US); (e) no support for handover from the IP to the circuit domain when > a terminal loses (e.g. moves out of) RF coverage in the IP domain; and > (f) no allowance for limited access modes wherein a terminal may access > a network only to place an emergency call with ensuing restrictions on > (for example) location acquisition, PSAP callback and caller > verification and identification to the PSAP. To resolve this category > either significant changes to the framework document could be made or a > disclaimer/applicability statement could be added stating that support > of cellular wireless networks and their associated WLAN and Femto > access points is not covered. > > Category (C) comprises concepts and capabilities in the draft that are > either already part of the standardized solution for wireless networks > or that might be added at a later time. Examples of the former include > LoST, SIP location conveyance, general use of SIP, location for routing > versus for dispatch, cellular positioning methods. Examples of the > latter include use of location references and dereferencing and > possible interworking between the current wireless network solutions > (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The > presence of this category could be acknowledged by following the > disclaimer for (B) with a statement that certain portions of the > solution are expected to be incorporated into wireless networks now > and/or in the future. > > We hope that these comments will be seen to be a useful addition to > this review in the sense of enabling a more precise scoping for the > framework document and we are willing to assist in providing wording > for any disclaimer/applicability statement that the Ecrit working group > may now deem fit to include. > > Kind Regards > > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm > 3GPP2 TSG-X and TSG-C participant) > > PS this being sent on 2/4/09 at 11:50pm PST > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] From Martin.Thomson@andrew.com Thu Feb 26 21:44:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF823A68F2 for ; Thu, 26 Feb 2009 21:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkEb4uu4NfA1 for ; Thu, 26 Feb 2009 21:44:19 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id F2C033A688E for ; Thu, 26 Feb 2009 21:44:18 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_27_00_04_15 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); Fri, 27 Feb 2009 00:04:15 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 23:44:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 26 Feb 2009 23:44:37 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmXuikRk+dIr3f0R02FPhxVSe0AlwA1eIWgAAJKN/A= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com> From: "Thomson, Martin" To: "Edge, Stephen" , "Richard Barnes" X-OriginalArrivalTime: 27 Feb 2009 05:44:39.0801 (UTC) FILETIME=[7B523690:01C9989E] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 05:44:21 -0000 VGhlcmUncyBiZW5lZml0IGluIGtub3dpbmcgdGhlIGxpbWl0YXRpb25zIG9mIGEgZnJhbWV3b3Jr LCBhbmQgZXZlcnkgYXJjaGl0ZWN0dXJlIG1ha2VzIGNlcnRhaW4gYXNzdW1wdGlvbnMuICBMZXQn cyBleGFtaW5lIHRoZW0gdGhvdWdoLi4uDQoNClRoZSBJRVRGIG1pZ2h0IG9jY2FzaW9uYWxseSBt YWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHN0YW5kYXJkcyBpdCBkZXZlbG9wcyBhcmUgZm9y IEludGVybmV0IGRldmljZXMuICBUaGF0IGFzc3VtcHRpb24gcHJvYmFibHkgbmVlZCBub3QgYmUg c3RhdGVkIGV4cGxpY2l0bHkuDQoNClRoZSBFQ1JJVCBhcmNoaXRlY3R1cmUgcmVsaWVzIG9uIGlt cGxlbWVudGF0aW9ucyBvZiB0aGUgcHJvdG9jb2xzIHRoYXQgaXQgcmVmZXJlbmNlcy4gIFRoYXQg aXMgbm90IGV4dHJhb3JkaW5hcnkuICBBIHJlbGlhbmNlIG9uIGltcGxlbWVudGF0aW9uIG9mIHRo ZXNlIHByb3RvY29scyBieSBlbmRwb2ludHMsIHJvdXRpbmcgaW50ZXJtZWRpYXJpZXMgYW5kIFBT QVBzIHNob3VsZCBub3QgbmVlZCB0byBiZSBleHBsYWluZWQuDQoNClNvIHRoZSBhc3N1bXB0aW9u cyBhcmU6DQogLSB0aGUgSW50ZXJuZXQNCiAtIHNvbHV0aW9ucyBhcmUgaW1wbGVtZW50ZWQgYW5k IGRlcGxveWVkDQogLSB0aGUgZW5kIGRldmljZSBpcyBhIGtleSBjb21wb25lbnQNCg0KT25seSB0 aGF0IGxhc3QgZWxlbWVudCBpcyBwYXJ0aWN1bGFybHkgbm92ZWwgLi4uIG9yIG5vdCB0aGF0IG11 Y2ggcmVhbGx5LiAgICBJdCdzIGEgZGVzaWduIGNob2ljZS4gIFVubGVzcyB5b3Ugd2VyZSB0aGlu a2luZyBvZiB0cnVua2luZyB0aGUgdm9pY2UgZWxzZXdoZXJlLg0KDQpPZiBjb3Vyc2UsIHlvdSdy ZSBzdWdnZXN0aW5nIHRoYXQgdGhlIGRlc2lnbiBjaG9pY2Ugd2FzIG1hZGUgaW4gaWdub3JhbmNl IG9mIGFsbCB0aGUgY29uc3RyYWludHMuICBZb3UncmUgc3VnZ2VzdGluZyB0aGF0IC0gYXMgYSBy ZXN1bHQgLSB0aGUgY2hvaWNlIGlzIGZsYXdlZCBhbmQgdGhlIHNvbHV0aW9uIGlzIG5vdCBnb2lu ZyB0byB3b3JrIGZvciBjZWxsdWxhciBzZXJ2aWNlcy4gIFdlIGRpc2FncmVlLiAgVGhlIHNvbHV0 aW9uIGlzIGEgYmFzaXMgZm9yIGVtZXJnZW5jeSBjYWxsaW5nIGluIF9hbnlfIElQIG5ldHdvcmsu DQoNCkNoZWVycywNCk1hcnRpbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZg0KPiBPZiBFZGdlLCBTdGVwaGVuDQo+IFNlbnQ6IEZyaWRheSwgMjcgRmVi cnVhcnkgMjAwOSAzOjMwIFBNDQo+IFRvOiBSaWNoYXJkIEJhcm5lcw0KPiBDYzogJ0VDUklUJw0K PiBTdWJqZWN0OiBSZTogW0Vjcml0XSBDb21tZW50cyBvbiBGcmFtZXdvcmsgRHJhZnQNCj4gDQo+ IEhpIFJpY2hhcmQNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBZb3VyIHN0YXRlbWVu dCBiZWxvdyB0aGF0ICJTSVAgZW1lcmdlbmN5DQo+IGNhbGxpbmcgd29ya3MgaWYgYWxsIHBhcnRp ZXMgYmVoYXZlIGFzIHNwZWNpZmllZCBpbiB0aGVzZSAoSUVURiBFY3JpdCkNCj4gZG9jdW1lbnRz IiB0byBzb21lIGRlZ3JlZSBoaWdobGlnaHRzIHRoZSBwcm9ibGVtcyB3ZSBhcmUgcmFpc2luZy4g VGhlDQo+IGRvY3VtZW50cyBkbyBjb250YWluIGEgbnVtYmVyIG9mIGltcGxpY2l0IGFuZCBleHBs aWNpdCByZXN0cmljdGlvbnMgLQ0KPiBsaWtlIElQIGNhcGFibGUgUFNBUHMsIGdsb2JhbCBJUCBh Y2Nlc3MgKG5vIGlzbGFuZHMgb2YgY2lyY3VpdCBtb2RlDQo+IGFjY2VzcyBmb3IgZXhhbXBsZSks IHVuaXZlcnNhbCBzdXBwb3J0IG9mIHRoaXMgc29sdXRpb24gYnkgYWxsIGFjY2Vzcw0KPiBwcm92 aWRlcnMgYW5kIFZTUHMgKG5vdCBtdWNoIGdvb2QgaWYgc29tZSBvcHQgZm9yIGFub3RoZXIgc29s dXRpb24pIGFuZA0KPiBlbmQgc3lzdGVtIG9yaWVudGVkIGxvY2F0aW9uIGFuZCByb3V0aW5nIGNh cGFiaWxpdHkgLSB3aGljaCB0b2dldGhlcg0KPiBtYWtlIHRoZW0gdW5zdWl0YWJsZSAod2UgYmVs aWV2ZSkgZm9yIGNlbGx1bGFyIHdpcmVsZXNzIG5ldHdvcmtzLiBJZg0KPiB0aGVzZSByZXN0cmlj dGlvbnMgYW5kIGFzc3VtcHRpb25zIHdlcmUgYWxsIG1hZGUgZXhwbGljaXQgdXBmcm9udCwgaXQN Cj4gd291bGQgdG8gYSBsYXJnZSBkZWdyZWUgKGFuZCBwb3NzaWJseSBjb21wbGV0ZWx5KSBhZGRy ZXNzIG91ciBjb25jZXJucy4NCj4gDQo+IFlvdSBhcmUgcmlnaHQgaW4gYXNzdW1pbmcgYW5vdGhl ciBzZXQgb2Ygc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSAzR1BQDQo+IGFuZCAzR1BQMiBzb2x1dGlv bi4gVGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhpcyBzb2x1dGlvbiBpcyBleHBsaWNpdGx5DQo+IGRl ZmluZWQgaW4gVFMgMjMuMTY3IChvciBtb3JlIGV4YWN0bHkgaW4gYW4gYWxyZWFkeSBhZ3JlZWQg Q1IgaW4NCj4gY29udHJpYnV0aW9uIFMyLTA5MDc1MiB3aGljaCB3aWxsIGJlY29tZSBwYXJ0IG9m IDIzLjE2NyBpbiBhIGZldyBtb3JlDQo+IHdlZWtzKSB0byBjb3ZlciB0aGUgZm9sbG93aW5nIGFj Y2VzcyB0eXBlczogR1BSUyAoVVRSQU4gV0NETUEpLCBJLVdMQU4sDQo+IEZpeGVkIEJyb2FkYmFu ZCwgQ0RNQTIwMDAgSFJQRCwgRVBTIFVUUkFOIChXQ0RNQSkgYW5kIEVQUyBFLVVUUkFODQo+IChM VEUpLiBTbyB0aGVyZSBpcyBhIHJlc3RyaWN0aW9uIGFuZCBhcmJpdHJhcnkgaW50ZXJuZXQgYWNj ZXNzIGlzIG5vdA0KPiBjb3ZlcmVkICh5ZXQpIGFzIEkgaGF2ZSBzdGF0ZWQgYmVmb3JlLg0KPiAN Cj4gS2luZCBSZWdhcmRzDQo+IA0KPiBTdGVwaGVuDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmJhcm5lc0BiYm4uY29tXQ0KPiBT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDA5IDY6MzAgUE0NCj4gVG86IEVkZ2UsIFN0 ZXBoZW4NCj4gQ2M6IEJyaWFuIFJvc2VuOyAnRUNSSVQnDQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRd IENvbW1lbnRzIG9uIEZyYW1ld29yayBEcmFmdA0KPiANCj4gSGkgU3RlcGhlbiwNCj4gDQo+IEkn bSBhIGxpdHRsZSBjb25mdXNlZCBieSB0aGUgc2NvcGUgb2Ygd2hhdCB5b3UncmUgYXNraW5nLiAg VGhlDQo+IGZyYW1ld29yaw0KPiBhbmQgcGhvbmViY3AgZG9jdW1lbnRzIGV4aXN0IGluIG9yZGVy IHRvIGRlc2NyaWJlIHRoZSBFQ1JJVCBzb2x1dGlvbjoNCj4gVGhleSBzYXksIGluIGVmZmVjdCwg IlNJUCBlbWVyZ2VuY3kgY2FsbGluZyB3b3JrcyBpZiBhbGwgcGFydGllcyBiZWhhdmUNCj4gYXMg c3BlY2lmaWVkIGluIHRoZXNlIGRvY3VtZW50cy4iDQo+IA0KPiBBcyBJIHVuZGVyc3RhbmQgd2hh dCB5b3UncmUgc2F5aW5nIChhbmQgSSdtIGJ5IG5vIG1lYW5zIGFuIGV4cGVydCBpbg0KPiAzR1BQ KSwgM0dQUCBzcGVjaWZpZXMgdGhhdCBvbmUgb3IgbW9yZSBlbGVtZW50cyBvZiB0aGlzIHN5c3Rl bSBiZWhhdmUNCj4gZGlmZmVyZW50bHkuICBUaGlzIHNpbXBseSBtZWFucyB0aGF0IDNHUFAgbmV0 d29ya3MgYXJlbid0IGNvbXBseWluZw0KPiB3aXRoDQo+IHRoZXNlIHNwZWNzLiAgSnVzdCBsaWtl IHRoZXJlJ3Mgbm8gZGlzY2xhaW1lciBpbiBSRkMgNzkxIChJUHY0KSB0aGF0DQo+IHNheXMgInRo aXMgZG9lc24ndCB3b3JrIG9uIFguMjUgbmV0d29ya3MiLCBpdCdzIG5vdCBjbGVhciB0byBtZSB0 aGF0IGFuDQo+IGFuYWxvZ291cyBkaXNjbGFpbWVyIGlzIGNhbGxlZCBmb3IgaGVyZS4NCj4gDQo+ IEkgcHJlc3VtZSB0aGVyZSBhcmUgc2ltaWxhciBkb2N1bWVudHMgZGVzY3JpYmluZyBob3cgZW1l cmdlbmN5IGNhbGxpbmcNCj4gd29ya3MgaW4gM0dQUCBuZXR3b3Jrcy4gIERvIHRoZXkgaW5jbHVk ZSBub3RlcyBzYXlpbmcgdGhhdCB0aGUgM0dQUA0KPiBzb2x1dGlvbiBkb2Vzbid0IHdvcmsgaW4g dGhlIGJyb2FkZXIgSW50ZXJuZXQ/DQo+IA0KPiAtLVJpY2hhcmQNCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiBFZGdlLCBTdGVwaGVuIHdyb3RlOg0KPiA+IEJyaWFuDQo+ID4NCj4gPiBGaXJzdCBvZiBh bGwgYXBvbG9naWVzIGZvciB0aGUgbGlrZWx5IGxhdGVuZXNzIG9mIHRoaXMgcmVwbHkgLSBJDQo+ IGFjdHVhbGx5IHdyb3RlIGl0IG9uIDE5IEZlYnJ1YXJ5IGluIGEgM0dQUCBTQTIgbWVldGluZyBp biBCdWRhcGVzdCBidXQNCj4gaXQgc2VlbXMgdW5saWtlbHkgdGhhdCBteSBWUE4sIE91dGxvb2sg c2VydmVyIGFuZCBXaUZpIGFjY2Vzcw0KPiBjYXBhYmlsaXR5IHdpbGwgY29vcGVyYXRlIHRvZ2V0 aGVyIHRvIGdldCBpdCBzZW50IHVudGlsIEkgcmV0dXJuIHRvIHRoZQ0KPiBvZmZpY2UgbWlkLW5l eHQgd2Vlay4NCj4gPg0KPiA+IEFueWhvdyB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFRoZXJl IGhhdmUgYWN0dWFsbHkgYmVlbiBhIG51bWJlciBvZg0KPiBjb25mZXJlbmNlIGNhbGxzIGJldHdl ZW4gSUVURiBhbmQgM0dQUCBwYXJ0aWNpcGFudHMgb3ZlciB0aGUgbGFzdA0KPiBjb3VwbGUgb2Yg eWVhcnMgYXQgd2hpY2ggY29tbW9uIGZlYXR1cmVzIGxpa2Ugc3VwcG9ydCBvZiBJUCBlbWVyZ2Vu Y3kNCj4gY2FsbHMgd2VyZSBkaXNjdXNzZWQgYW5kIHRoZXNlIGNvdWxkIGhhdmUgYmVlbiBnb29k IGZvcnVtIGZvcg0KPiBwYXJ0aWNpcGFudHMgb24gZWl0aGVyIHNpZGUgdG8gaGF2ZSByYWlzZWQg dGhlIGtpbmRzIG9mIGlzc3VlcyB5b3UNCj4gZWxhYm9yYXRlIG9uIGJlbG93LiBHaXZlbiB0aGF0 IHNlZW1zIG5vdCBzbyBmYXIgdG8gaGF2ZSBoYXBwZW5lZCwgaXQNCj4gY291bGQgc3RpbGwgYmUg cG9zc2libGUgaW4gZnV0dXJlIHN1Y2ggY2FsbHMuDQo+ID4NCj4gPiBCdXQgdGhlIGlzc3VlcyB3 ZSBhcmUgcmFpc2luZyBhcmUgbm90IGRpcmVjdGx5IHRvIGRvIHdpdGggZnVydGhlcg0KPiBhbGln bmluZyB0aGUgMiBzb2x1dGlvbnMgb3Igd2l0aCB0aGUgbGFjayBvZiB0aGlzIGluIHRoZSBwYXN0 LiBXZSBhcmUNCj4gc2ltcGx5IHBvaW50aW5nIG91dCB0aGF0IHRoZSBzb2x1dGlvbnMgYXJlIGN1 cnJlbnRseSBkaWZmZXJlbnQgYW5kIHRoYXQNCj4gZnJvbSBhIGNlbGx1bGFyIHdpcmVsZXNzIHBl cnNwZWN0aXZlLCB0aGUgRWNyaXQgc29sdXRpb24gaXMgbm90IHNlZW4gYXMNCj4gc3VpdGFibGUg aW4gYWxsIHJlc3BlY3RzIChmb3Igc3VwcG9ydCBvZiBJUCBlbWVyZ2VuY3kgY2FsbHMgb3JpZ2lu YXRpbmcNCj4gZnJvbSBzdWNoIGFjY2VzcyB0eXBlcykuIFRoYXQgaXMgbm90IGp1c3Qgb3VyIHBv aW50IG9mIHZpZXcuIDNHUFAyIHNlbnQNCj4gYSBsaWFpc29uIHRvIEVjcml0IHNvbWUgbW9udGhz IGFnbyBwb2ludGluZyBvdXQgdGhlIHNhbWUgaXNzdWVzLg0KPiA+DQo+ID4gU28gd2UgYXJlIHBy b3Bvc2luZyB0aGF0IHRoZSBFY3JpdCBmcmFtZXdvcmsgYW5kIHBob25lQkNQIHNwZWMucw0KPiBp bmNsdWRlIGEgc3RhdGVtZW50IGFja25vd2xlZGdpbmcgdGhpcyAtIGUuZy4gYnkgcmVmZXJlbmNp bmcgdGhlDQo+IGFsdGVybmF0aXZlIDNHUFAvM0dQUDIgc29sdXRpb24gYW5kIGluZGljYXRpbmcg dGhlIElQIGFjY2VzcyB0eXBlcyBmb3INCj4gd2hpY2ggdGhlIEVjcml0IHNvbHV0aW9uIHdpbGwg d29yayB3aXRob3V0IGxpbWl0YXRpb24gKG9yIGVxdWl2YWxlbnRseQ0KPiB0aGUgYWNjZXNzIHR5 cGVzIHdoZXJlIGxpbWl0YXRpb25zIGFyZSBub3QgcnVsZWQgb3V0KS4NCj4gPg0KPiA+IFdlIGFy ZSBub3QgcHJvcG9zaW5nIGZ1cnRoZXIgbW9kaWZpY2F0aW9uIGFuZCBleHRlbnNpb24gb2YgdGhl IEVjcml0DQo+IHNvbHV0aW9uIC0ganVzdCBwb2ludGluZyBvdXQgdGhhdCB0aGlzIHdvdWxkIGJl IG5lZWRlZCAoYXMgd2l0aCB0aGUNCj4gM0dQUC8zR1BQMiBzb2x1dGlvbikgdG8gZnVsbHkgY292 ZXIgYWxsIHR5cGVzIG9mIGFjY2Vzcy4NCj4gPg0KPiA+IEtpbmQgUmVnYXJkcw0KPiA+DQo+ID4g U3RlcGhlbg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQnJpYW4g Um9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gPiBTZW50OiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDE4LCAyMDA5IDg6MDcgUE0NCj4gPiBUbzogRWRnZSwgU3RlcGhlbjsgJ0VDUklUJw0K PiA+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIENvbW1lbnRzIG9uIEZyYW1ld29yayBEcmFmdA0KPiA+ DQo+ID4gSSBoYXZlIGJpdCBteSB0b25ndWUgb24gdGhpcyBvbmUgZm9yIGEgbG9uZyB0aW1lLg0K PiA+DQo+ID4gU3RlcGhlbiwgd2l0aCByZXNwZWN0LCBwbGVhc2UgZ28gdGFsayB0byAzR1BQIG1h bmFnZW1lbnQgYW5kIGFzayB0aGVtDQo+IHdoeQ0KPiA+IHRoZXJlIGhhcyBiZWVuIG5vIHBhcnRp Y2lwYXRpb24gaW4gdGhlIGVjcml0IGVmZm9ydCBkZXNwaXRlIG11bHRpcGxlDQo+IFlFQVJTDQo+ ID4gb2YgYmVnZ2luZyB0aGVtIHRvIGdldCBpbnZvbHZlZC4gIFRvIHB1dCBpdCBmcmFua2x5LCAz R1BQIGlzIHF1aXRlDQo+IHdpbGxpbmcNCj4gPiB0byBidWxseSBJRVRGIGludG8gZG9pbmcgaXRz IHdvcmsgb24gaXRzIHNjaGVkdWxlLCBidXQgY2Fubm90IGJlDQo+IGJvdGhlcmVkIHRvDQo+ID4g Z2V0IHdvcmsgZG9uZSBpdCBrbm93cyBpdCB3aWxsIGV2ZW50dWFsbHkgaGF2ZSB0byBkbyB3aGVu IHRoZSBJRVRGDQo+IGFza3MgaXQNCj4gPiB0byBkbyBzby4NCj4gPg0KPiA+IDNHUFAgdW5kZXJz dGFuZHMgdGhlIG1lc3MgdGhhdCBpcyBiZWluZyBjcmVhdGVkIGJ5IG5vdCBwYXJ0aWNpcGF0aW5n Lg0KPiBUaGV5DQo+ID4ga25vdyBmdWxsIHdlbGwgdGhhdCB3aGVuIHRoZXkgZmluYWxseSBnZXQg YXJvdW5kIHRvIGRlYWxpbmcgd2l0aCBQUw0KPiA+IHRlcm1pbmF0ZWQgZW1lcmdlbmN5IGNhbGxz LCB0aGF0IHRoZXJlIHdpbGwgYmUgYSBsb3Qgb2YgcmVzaXN0YW5jZSB0bw0KPiA+IGNoYW5naW5n IGZ1bGx5IHNwZWNpZmllZCBhbmQgaW1wbGVtZW50ZWQgc3RhbmRhcmRzIHRvIG1vcmUgY2xvc2Vs eQ0KPiBhbGlnbg0KPiA+IHdpdGggM0dQUCBzdGFuZGFyZHMuICBJIGV4cGVjdCB5b3Ugd2lsbCBo YXZlIHNldmVyYWwgaW50ZXJ3b3JraW5nDQo+IGZ1bmN0aW9ucw0KPiA+IHRvIGRlZmluZSBhbmQg YnVpbGQuDQo+ID4NCj4gPiBTbywgcG9saXRlbHksIHBsZWFzZSBnbyBhd2F5LCB3ZSdyZSBmaW5p c2hpbmcgd29yayB3ZSBkZWFybHkgd2FudGVkDQo+IHlvdSBhbGwNCj4gPiB0byBiZSBpbnZvbHZl ZCB3aXRoIGZvciB5ZWFycywgYnV0IHlvdSByZWZ1c2VkIHRvIGRvIGFueXRoaW5nLiAgSXQncw0K PiB0b28NCj4gPiBsYXRlIGZvciB0aGlzIHJldi4NCj4gPg0KPiA+IE5vdywgaGF2aW5nIHNhaWQg dGhhdCwgdGhlcmUgYXJlIHF1aXRlIGEgZmV3IHBlb3BsZSB3aG8gaGF2ZQ0KPiBwYXJ0aWNpcGF0 ZWQgaW4NCj4gPiB0aGUgSUVURiB3b3JrIHdobyBhcmUgSU1TIGF3YXJlIGFuZCBJIGJlbGlldmUg dGhhdCBkZXNwaXRlIHlvdXINCj4gZmVhcnMsDQo+ID4gZXZlcnl0aGluZyB5b3UgbmVlZCBpcyBp biB0aGUgc3BlY3MuICBUaGUgbWVjaGFuaXNtcyB3ZSBoYXZlIGRlZmluZWQNCj4gcHJvdmlkZQ0K PiA+IHRoZSBhYmlsaXR5IGZvciB0aGUgbmV0d29yayB0byBpbnNlcnQgbG9jYXRpb24sIHJlY29n bml6ZSBhbmQgbWFyaw0KPiBlbWVyZ2VuY3kNCj4gPiBjYWxscywgYW5kIHJvdXRlIG9uIGJlaGFs ZiBvZiBlbmRwb2ludHMuICBBbiBFLUNTQ0YgY291bGQgcXVpdGUNCj4gPiBzdHJhaWdodGZvcndh cmRseSBwcm92aWRlIGEgU0lQIGNhbGwgdG93YXJkcyBhbiBlY3JpdCBjb21wYXRpYmxlDQo+IFBT QVAuICBUaGUNCj4gPiBvbmx5IG5vdC1xdWl0ZS1uaWNlIGludGVyd29yayB3b3VsZCBiZSBmcm9t IFNVUEwgdG8gSEVMRCAob3IgU0lQKSwNCj4gYnV0IGl0J3MNCj4gPiBwcmV0dHkgZWFzeSB0byBk byB0aGF0LiAgSSdsbCBhbHNvIG5vdGUgdGhhdCB3ZSBoYXZlIHRyaWVkIHRvIGdldCBPTUENCj4g YW5kDQo+ID4gSUVURiB0byBjb29wZXJhdGUgb24gbG9jYXRpb24gcHJvdG9jb2xzLCBidXQgd2Ug aGF2ZSBiZWVuDQo+IHNwZWN0YWN1bGFybHkNCj4gPiB1bnN1Y2Nlc3NmdWwgYXQgdGhhdCBlZmZv cnQgYWxzby4NCj4gPg0KPiA+IEJyaWFuDQo+ID4NCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPj4gT2YgRWRnZSwgU3Rl cGhlbg0KPiA+PiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDUsIDIwMDkgMjo1MCBBTQ0KPiA+ PiBUbzogJ0VDUklUJw0KPiA+PiBTdWJqZWN0OiBbRWNyaXRdIENvbW1lbnRzIG9uIEZyYW1ld29y ayBEcmFmdA0KPiA+Pg0KPiA+PiBBbGwNCj4gPj4NCj4gPj4gZHJhZnQtaWV0Zi1lY3JpdC1mcmFt ZXdvcmstMDcgaXMgKGFzIHdlIHNlZSBpdCkgYSBtb3N0bHkgaW5mb3JtYXRpdmUNCj4gPj4gZGVz Y3JpcHRpb24gb2YgaG93IHRlcm1pbmFscyBhbmQgbmV0d29ya3Mgc2hvdWxkIHN1cHBvcnQgZW1l cmdlbmN5DQo+ID4+IGNhbGxzIG1hZGUgb3ZlciBJUCBjYXBhYmxlIGZhY2lsaXRpZXMgdG8gSVAg Y2FwYWJsZSBQU0FQcy4gSXQNCj4gYXBwZWFycw0KPiA+PiBpbnRlbmRlZCB0byBjb3ZlciBhbGwg dHlwZXMgb2YgYWNjZXNzIG5ldHdvcmsgLSBpbmNsdWRpbmcgZml4ZWQNCj4gbGluZSwNCj4gPj4g V2lGaSBhbmQgY2VsbHVsYXIgKGUuZy4gZXhhbXBsZXMgaW52b2x2aW5nIGVhY2ggY2FuIGJlIGZv dW5kDQo+IHRocm91Z2hvdXQNCj4gPj4gdGhlIGRyYWZ0KS4NCj4gPj4NCj4gPj4gV2hlbiB3ZSBl dmFsdWF0ZWQgdGhpcyB3aXRoIHJlc3BlY3QgdG8gc3VwcG9ydCBvZiB3aXJlbGVzcyBjZWxsdWxh cg0KPiA+PiBhY2Nlc3MgYW5kIFdpRmkgYWNjZXNzIGFzc29jaWF0ZWQgd2l0aCBhIGNlbGx1bGFy IG9wZXJhdG9yIChlLmcuDQo+IFdMQU4NCj4gPj4gb3IgRmVtdG8gY2VsbHMgaW50ZWdyYXRlZCBp bnRvIGEgY2VsbHVsYXIgbmV0d29yayksIHdlIGZvdW5kIHRoYXQNCj4gPj4gY2VydGFpbiBwb3J0 aW9ucyBvZiB0aGUgZHJhZnQgZXhoaWJpdGVkIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcN Cj4gPj4gY2hhcmFjdGVyaXN0aWNzOg0KPiA+Pg0KPiA+PiAgICAgKEEpIEluY29uc2lzdGVudCB3 aXRoIGFscmVhZHkgc3RhbmRhcmRpemVkIHdpcmVsZXNzIHNvbHV0aW9ucw0KPiA+Pg0KPiA+PiAg ICAgKEIpIEluY29uc2lzdGVudCB3aXRoIGVzc2VudGlhbCB3aXJlbGVzcyByZXF1aXJlbWVudHMg YW5kDQo+ID4+IGNvbnZlbnRpb25zDQo+ID4+DQo+ID4+ICAgICAoQykgQWxyZWFkeSBwYXJ0IG9m IHdpcmVsZXNzIHN0YW5kYXJkcyBvciBwb3RlbnRpYWxseSBwYXJ0IG9mDQo+ID4+IGZ1dHVyZSBz dGFuZGFyZHMNCj4gPj4NCj4gPj4gKEEpIHJlZmVycyB0byBhbGwgcG9ydGlvbnMgb2YgdGhlIGRy YWZ0IGZyYW1ld29yayB0aGF0IGRpZmZlciBmcm9tDQo+IHRoZQ0KPiA+PiByZXF1aXJlbWVudHMg YW5kIHByb2NlZHVyZXMgY3VycmVudGx5IHN0YW5kYXJkaXplZCBmb3Igd2lyZWxlc3MNCj4gPj4g ZW1lcmdlbmN5IGFjY2VzcyBieSAzR1BQLCAzR1BQMiBhbmQgT01BLiBUaGlzIGlzIGEgcGxhaW4g ZGlmZmVyZW5jZQ0KPiBvZg0KPiA+PiBzb2x1dGlvbiBhbmQgY291bGQgYmUgcmVzb2x2ZWQgdGhy b3VnaCBzdXBwb3J0IG9mIGJvdGggc29sdXRpb25zIGJ5DQo+ID4+IHRlcm1pbmFscyAod2l0aCBl YWNoIHNvbHV0aW9uIGJlaW5nIHVzZWQgYWNjb3JkaW5nIHRvIHRoZSB0eXBlIG9mDQo+ID4+IGFj Y2VzcyBuZXR3b3JrIGFuZCBWU1ApIG9yIGNvdWxkIGJlIHJlc29sdmVkIGJ5IHN1cHBvcnRpbmcg b25seSBvbmUNCj4gPj4gc29sdXRpb24gYW5kIGFjY2Vzc2luZyBvbmx5IHRoZSB0eXBlcyBvZiBu ZXR3b3JrIHN1cHBvcnRpbmcgdGhhdA0KPiA+PiBzb2x1dGlvbi4gVG8gYWNrbm93bGVkZ2UgdGhp cyBjYXRlZ29yeSwgdGhlIGZyYW1ld29yayBkb2N1bWVudCBjb3VsZA0KPiA+PiByZWZlcmVuY2Ug dGhlIGFwcGxpY2FibGUgd2lyZWxlc3Mgc3RhbmRhcmRzIGFuZCBwb2ludCBvdXQgdGhhdCB0aGVz ZQ0KPiA+PiBhcmUgdmFsaWQgYWx0ZXJuYXRpdmVzIGZvciB3aXJlbGVzcyBjZWxsdWxhciBiYXNl ZCBhY2Nlc3MuDQo+ID4+DQo+ID4+IChCKSByZWZlcnMgdG8gcG9ydGlvbnMgb2YgdGhlIGRyYWZ0 IHRoYXQgd291bGQgYmUgdW5zdWl0YWJsZSBmb3INCj4gPj4gd2lyZWxlc3MgbmV0d29ya3MgZXZl biBpZiBubyBhbHRlcm5hdGl2ZSBzb2x1dGlvbiBleGlzdGVkIHRvZ2V0aGVyDQo+IHdpdGgNCj4g Pj4gb3RoZXIgcG9ydGlvbnMgbWlzc2luZyBmcm9tIHRoZSBkcmFmdCB0aGF0IHdvdWxkIGJlIG5l ZWRlZCB0byBmdWxseQ0KPiA+PiBzdXBwb3J0IHdpcmVsZXNzIG5ldHdvcmtzLiBFeGFtcGxlcyBv ZiB0aGUgZm9ybWVyIGluY2x1ZGU6IChhKQ0KPiBlbXBoYXNpcw0KPiA+PiBvbiBlbmRwb2ludCBk ZXJpdmF0aW9uIG9mIGxvY2F0aW9uLCBwZXJmb3JtYW5jZSBvZiBMb3N0IHF1ZXJ5IGFuZA0KPiA+ PiByZWNlaXB0IG9mIGxvY2FsIGRpYWwgc3RyaW5nczsgKGIpIHJlc3RyaWN0aW9uIG9mIExDUHMg dG8gcHJvdG9jb2xzDQo+ID4+IHRoYXQgcmVxdWlyZSB0ZXJtaW5hbCBpbml0aWF0aW9uIChub3Qg YWxsb3dpbmcgZm9yIG5ldHdvcmsNCj4gaW5pdGlhdGlvbg0KPiA+PiBhcyBmYXIgYXMgd2UgY2Fu IHRlbGwpIGFuZCB0aGF0IGluY2x1ZGUgdHdvIExDUHMgKERIQ1AgYW5kIExMRFApDQo+IHRoYXQN Cj4gPj4gYXJlIG5vdCBhcHBsaWNhYmxlIHRvIChub3QgZGVmaW5lZCBmb3IpIGNlbGx1bGFyIGFj Y2VzczsgYW5kIChjKSB0aGUNCj4gPj4gcmVxdWlyZW1lbnQgdGhhdCBhIHRlcm1pbmFsIG9yIGF0 IGxlYXN0IGEgTElTIHdpbGwgdXBkYXRlIHRoZSBQU0FQDQo+ID4+IHdoZW5ldmVyIGxvY2F0aW9u IGNoYW5nZXMuIChhKSBpcyBpbXByYWN0aWNhbCBkdWUgdG8gbmV0d29yayBhbmQNCj4gPj4gdGVy bWluYWwgbG9hZGluZyBjb25zZXF1ZW5jZXMgYW5kIGZhaWx1cmUgdG8gc3VwcG9ydCBub24tSVAg Y2FwYWJsZQ0KPiA+PiBQU0FQczsgKGIpIG1ha2VzIGxvY2F0aW9uIHZlcmlmaWNhdGlvbiBhbmQg dXBkYXRlZCBsb2NhdGlvbg0KPiBwcm92aXNpb24NCj4gPj4gdG8gUFNBUHMgZGlmZmljdWx0IG9y IGltcG9zc2libGU7IHdoaWxlIChjKSBpcyBhbHNvIGluY29tcGF0aWJsZQ0KPiB3aXRoDQo+ID4+ IHN1cHBvcnQgb2YgZXhpc3Rpbmcgbm9uLUlQIGNhcGFibGUgUFNBUHMgYmVzaWRlcyBpbmNyZWFz aW5nIHRlcm1pbmFsDQo+ID4+IGxvYWQgYW5kIHBvc3NpYmx5IGludGVyZmVyaW5nIHdpdGggb3B0 aW11bSBtYWludGVuYW5jZSBvZiB0aGUgUkYNCj4gPj4gY29ubmVjdGlvbiAoZS5nLiBpZiBhIHRl cm1pbmFsIGhhcyB0byB0dW5lIGF3YXkgZnJvbSB0aGUgc2VydmluZw0KPiBiYXNlDQo+ID4+IHN0 YXRpb24gb3IgV0xBTiBwZXJpb2RpY2FsbHkgdG8gbWFrZSBsb2NhdGlvbiBtZWFzdXJlbWVudHMp Lg0KPiBFeGFtcGxlcw0KPiA+PiBvZiB0aGUgbGF0dGVyIGluY2x1ZGUgKGQpIGFic2VuY2Ugb2Yg c3VwcG9ydCBmb3IgYWNjZXNzIHRvIG5vbi1JUA0KPiA+PiBjYXBhYmxlIFBTQVBzIGFzIGFscmVh ZHkgbWVudGlvbmVkIChlLmcuIHRvIHN1cHBvcnQgRTkxMSBwaGFzZSAyIGluDQo+IHRoZQ0KPiA+ PiBVUyk7IChlKSBubyBzdXBwb3J0IGZvciBoYW5kb3ZlciBmcm9tIHRoZSBJUCB0byB0aGUgY2ly Y3VpdCBkb21haW4NCj4gd2hlbg0KPiA+PiBhIHRlcm1pbmFsIGxvc2VzIChlLmcuIG1vdmVzIG91 dCBvZikgUkYgY292ZXJhZ2UgaW4gdGhlIElQIGRvbWFpbjsNCj4gYW5kDQo+ID4+IChmKSBubyBh bGxvd2FuY2UgZm9yIGxpbWl0ZWQgYWNjZXNzIG1vZGVzIHdoZXJlaW4gYSB0ZXJtaW5hbCBtYXkN Cj4gYWNjZXNzDQo+ID4+IGEgbmV0d29yayBvbmx5IHRvIHBsYWNlIGFuIGVtZXJnZW5jeSBjYWxs IHdpdGggZW5zdWluZyByZXN0cmljdGlvbnMNCj4gb24NCj4gPj4gKGZvciBleGFtcGxlKSBsb2Nh dGlvbiBhY3F1aXNpdGlvbiwgUFNBUCBjYWxsYmFjayBhbmQgY2FsbGVyDQo+ID4+IHZlcmlmaWNh dGlvbiBhbmQgaWRlbnRpZmljYXRpb24gdG8gdGhlIFBTQVAuIFRvIHJlc29sdmUgdGhpcw0KPiBj YXRlZ29yeQ0KPiA+PiBlaXRoZXIgc2lnbmlmaWNhbnQgY2hhbmdlcyB0byB0aGUgZnJhbWV3b3Jr IGRvY3VtZW50IGNvdWxkIGJlIG1hZGUNCj4gb3IgYQ0KPiA+PiBkaXNjbGFpbWVyL2FwcGxpY2Fi aWxpdHkgc3RhdGVtZW50IGNvdWxkIGJlIGFkZGVkIHN0YXRpbmcgdGhhdA0KPiBzdXBwb3J0DQo+ ID4+IG9mIGNlbGx1bGFyIHdpcmVsZXNzIG5ldHdvcmtzIGFuZCB0aGVpciBhc3NvY2lhdGVkIFdM QU4gYW5kIEZlbXRvDQo+ID4+IGFjY2VzcyBwb2ludHMgaXMgbm90IGNvdmVyZWQuDQo+ID4+DQo+ ID4+IENhdGVnb3J5IChDKSBjb21wcmlzZXMgY29uY2VwdHMgYW5kIGNhcGFiaWxpdGllcyBpbiB0 aGUgZHJhZnQgdGhhdA0KPiBhcmUNCj4gPj4gZWl0aGVyIGFscmVhZHkgcGFydCBvZiB0aGUgc3Rh bmRhcmRpemVkIHNvbHV0aW9uIGZvciB3aXJlbGVzcw0KPiBuZXR3b3Jrcw0KPiA+PiBvciB0aGF0 IG1pZ2h0IGJlIGFkZGVkIGF0IGEgbGF0ZXIgdGltZS4gRXhhbXBsZXMgb2YgdGhlIGZvcm1lcg0K PiBpbmNsdWRlDQo+ID4+IExvU1QsIFNJUCBsb2NhdGlvbiBjb252ZXlhbmNlLCBnZW5lcmFsIHVz ZSBvZiBTSVAsIGxvY2F0aW9uIGZvcg0KPiByb3V0aW5nDQo+ID4+IHZlcnN1cyBmb3IgZGlzcGF0 Y2gsIGNlbGx1bGFyIHBvc2l0aW9uaW5nIG1ldGhvZHMuIEV4YW1wbGVzIG9mIHRoZQ0KPiA+PiBs YXR0ZXIgaW5jbHVkZSB1c2Ugb2YgbG9jYXRpb24gcmVmZXJlbmNlcyBhbmQgZGVyZWZlcmVuY2lu ZyBhbmQNCj4gPj4gcG9zc2libGUgaW50ZXJ3b3JraW5nIGJldHdlZW4gdGhlIGN1cnJlbnQgd2ly ZWxlc3MgbmV0d29yayBzb2x1dGlvbnMNCj4gPj4gKGluIDNHUFAsIDNHUFAyIGFuZCBPTUEpIGFu ZCB0aGUgc29sdXRpb24gZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQuDQo+IFRoZQ0KPiA+PiBwcmVz ZW5jZSBvZiB0aGlzIGNhdGVnb3J5IGNvdWxkIGJlIGFja25vd2xlZGdlZCBieSBmb2xsb3dpbmcg dGhlDQo+ID4+IGRpc2NsYWltZXIgZm9yIChCKSB3aXRoIGEgc3RhdGVtZW50IHRoYXQgY2VydGFp biBwb3J0aW9ucyBvZiB0aGUNCj4gPj4gc29sdXRpb24gYXJlIGV4cGVjdGVkIHRvIGJlIGluY29y cG9yYXRlZCBpbnRvIHdpcmVsZXNzIG5ldHdvcmtzIG5vdw0KPiA+PiBhbmQvb3IgaW4gdGhlIGZ1 dHVyZS4NCj4gPj4NCj4gPj4gV2UgaG9wZSB0aGF0IHRoZXNlIGNvbW1lbnRzIHdpbGwgYmUgc2Vl biB0byBiZSBhIHVzZWZ1bCBhZGRpdGlvbiB0bw0KPiA+PiB0aGlzIHJldmlldyBpbiB0aGUgc2Vu c2Ugb2YgZW5hYmxpbmcgYSBtb3JlIHByZWNpc2Ugc2NvcGluZyBmb3IgdGhlDQo+ID4+IGZyYW1l d29yayBkb2N1bWVudCBhbmQgd2UgYXJlIHdpbGxpbmcgdG8gYXNzaXN0IGluIHByb3ZpZGluZyB3 b3JkaW5nDQo+ID4+IGZvciBhbnkgZGlzY2xhaW1lci9hcHBsaWNhYmlsaXR5IHN0YXRlbWVudCB0 aGF0IHRoZSBFY3JpdCB3b3JraW5nDQo+IGdyb3VwDQo+ID4+IG1heSBub3cgZGVlbSBmaXQgdG8g aW5jbHVkZS4NCj4gPj4NCj4gPj4gS2luZCBSZWdhcmRzDQo+ID4+DQo+ID4+IFN0ZXBoZW4gRWRn ZSAoUXVhbGNvbW0gM0dQUCBTQTIgcGFydGljaXBhbnQpLCBLaXJrIEJ1cnJvdWdocw0KPiAoUXVh bGNvbW0NCj4gPj4gM0dQUDIgVFNHLVggYW5kIFRTRy1DIHBhcnRpY2lwYW50KQ0KPiA+Pg0KPiA+ PiBQUyAgdGhpcyBiZWluZyBzZW50IG9uIDIvNC8wOSBhdCAxMTo1MHBtIFBTVA0KPiA+Pg0KPiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBF Y3JpdCBtYWlsaW5nIGxpc3QNCj4gPj4gRWNyaXRAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPiA+DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBFY3JpdCBtYWlsaW5nIGxpc3QN Cj4gPiBFY3JpdEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2ln bmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmll dGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJl Y2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMg ZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KW21mMl0NCg== From sedge@qualcomm.com Thu Feb 26 23:50:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1279728C1DB for ; Thu, 26 Feb 2009 23:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+ehdnwiBOvR for ; Thu, 26 Feb 2009 23:50:44 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 80D2A28C1DA for ; Thu, 26 Feb 2009 23:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1235721067; x=1267257067; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Thomson,=20Martin"=20,=0D=0A =20=20=20=20=20=20=20=20Richard=20Barnes=0D=0A=09|CC:=20ECRIT=20|Date:=20Thu,=202 6=20Feb=202009=2023:50:41=20-0800|Subject:=20RE:=20[Ecrit ]=20Comments=20on=20Framework=20Draft|Thread-Topic:=20[Ec rit]=20Comments=20on=20Framework=20Draft|Thread-Index:=20 AcmXuikRk+dIr3f0R02FPhxVSe0AlwA1eIWgAAJKN/AAA+d9cA=3D=3D |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC53749E4B@ NASANEXMB04.na.qualcomm.com>|References:=20<1288E74A73964 940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com>< 0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132 A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEA E.6000605@bbn.com>=0D=0A=20<1288E74A73964940B132A0B9EA8D8 ABC53749E36@NASANEXMB04.na.qualcomm.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5537"=3B=20a=3D"15829071"; bh=74BVldk3VuXMZ7PdDV9nRJ02X1IMBagaztcG1/nmjec=; b=LZ7lPFR0jukPdy8Sq02hsUWErwAs6G93TagTCmWN/K8i/2QR43mM2Pyh Wk9S2Ny9zrvF9ta6e180xEZp9ByxNaFtZgQc3iTqz++V3p48z457eA3V6 6kpvSyFP4aCF0eH5Q+OdrVPjVSboU3om6kjTO3YtZEfzo+bVwx+RAJ3nD I=; X-IronPort-AV: E=McAfee;i="5300,2777,5537"; a="15829071" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Feb 2009 23:50:54 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1R7or3q017821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Feb 2009 23:50:54 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1R7oh9r007649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Feb 2009 23:50:43 -0800 (PST) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Thu, 26 Feb 2009 23:50:43 -0800 From: "Edge, Stephen" To: "Thomson, Martin" , Richard Barnes Date: Thu, 26 Feb 2009 23:50:41 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmXuikRk+dIr3f0R02FPhxVSe0AlwA1eIWgAAJKN/AAA+d9cA== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 07:50:47 -0000 Martin The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to 3= GPP/3GPP2 access networks where the serving network also acts as the VSP) a= nd the specifications for it cover in detail all possible scenarios consist= ent with these restrictions so far as we are aware. The Ecrit solution seems to claim global applicability to all types of IP a= ccess (and the more that is said about this from Ecrit participants the mor= e this gets emphasized) but does not cover in detail all possible scenarios= (in some cases does not cover in any detail) which means that at best the = solution is incomplete and at worst intrinsically inapplicable to some unst= ated set of scenarios. The missing, incomplete and problematic cases include the following: - access to PSTN capable PSAPs - handover between different IP access networks including different types= of access network - handover to/from circuit mode networks - location for cellular access (and the requirement to support LCPs that = will be useless for cellular access) - endpoint based location and routing for cellular access (issues here ar= e network and device loading as well as device impacts and problems with PS= TN capable PSAPs) - support of unauthenticated users and users who can be authenticated but= are not permitted access/VSP service except for emergency calls Stating that some of these cases are out of scope or referencing an incompl= ete and possibly questionable specification from some other national SDO wi= ll not help the user who encounters such problems. But it would certainly h= elp network operators and implementers to acknowledge their existence in on= e form or another because that would allow better planning of deployments a= nd would help focus attention on finding solutions (whether in IETF or else= where) for the missing cases. Please note that despite these drawbacks, I will acknowledge that Ecrit doe= s have a valuable solution that covers many scenarios not covered by 3GPP/3= GPP2. It would be the delineation of these supported scenarios (or equivale= ntly unsupported scenarios) in some applicability statement that would be p= articularly useful right now. Kind Regards Stephen -----Original Message----- From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] Sent: Thursday, February 26, 2009 9:45 PM To: Edge, Stephen; Richard Barnes Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft There's benefit in knowing the limitations of a framework, and every archit= ecture makes certain assumptions. Let's examine them though... The IETF might occasionally make the assumption that the standards it devel= ops are for Internet devices. That assumption probably need not be stated = explicitly. The ECRIT architecture relies on implementations of the protocols that it r= eferences. That is not extraordinary. A reliance on implementation of the= se protocols by endpoints, routing intermediaries and PSAPs should not need= to be explained. So the assumptions are: - the Internet - solutions are implemented and deployed - the end device is a key component Only that last element is particularly novel ... or not that much really. = It's a design choice. Unless you were thinking of trunking the voice els= ewhere. Of course, you're suggesting that the design choice was made in ignorance o= f all the constraints. You're suggesting that - as a result - the choice i= s flawed and the solution is not going to work for cellular services. We d= isagree. The solution is a basis for emergency calling in _any_ IP network= . Cheers, Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Edge, Stephen > Sent: Friday, 27 February 2009 3:30 PM > To: Richard Barnes > Cc: 'ECRIT' > Subject: Re: [Ecrit] Comments on Framework Draft > > Hi Richard > > Thanks for the comments. Your statement below that "SIP emergency > calling works if all parties behave as specified in these (IETF Ecrit) > documents" to some degree highlights the problems we are raising. The > documents do contain a number of implicit and explicit restrictions - > like IP capable PSAPs, global IP access (no islands of circuit mode > access for example), universal support of this solution by all access > providers and VSPs (not much good if some opt for another solution) and > end system oriented location and routing capability - which together > make them unsuitable (we believe) for cellular wireless networks. If > these restrictions and assumptions were all made explicit upfront, it > would to a large degree (and possibly completely) address our concerns. > > You are right in assuming another set of specifications for the 3GPP > and 3GPP2 solution. The applicability of this solution is explicitly > defined in TS 23.167 (or more exactly in an already agreed CR in > contribution S2-090752 which will become part of 23.167 in a few more > weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, > Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN > (LTE). So there is a restriction and arbitrary internet access is not > covered (yet) as I have stated before. > > Kind Regards > > Stephen > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, February 25, 2009 6:30 PM > To: Edge, Stephen > Cc: Brian Rosen; 'ECRIT' > Subject: Re: [Ecrit] Comments on Framework Draft > > Hi Stephen, > > I'm a little confused by the scope of what you're asking. The > framework > and phonebcp documents exist in order to describe the ECRIT solution: > They say, in effect, "SIP emergency calling works if all parties behave > as specified in these documents." > > As I understand what you're saying (and I'm by no means an expert in > 3GPP), 3GPP specifies that one or more elements of this system behave > differently. This simply means that 3GPP networks aren't complying > with > these specs. Just like there's no disclaimer in RFC 791 (IPv4) that > says "this doesn't work on X.25 networks", it's not clear to me that an > analogous disclaimer is called for here. > > I presume there are similar documents describing how emergency calling > works in 3GPP networks. Do they include notes saying that the 3GPP > solution doesn't work in the broader Internet? > > --Richard > > > > > > Edge, Stephen wrote: > > Brian > > > > First of all apologies for the likely lateness of this reply - I > actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but > it seems unlikely that my VPN, Outlook server and WiFi access > capability will cooperate together to get it sent until I return to the > office mid-next week. > > > > Anyhow thanks for your comments. There have actually been a number of > conference calls between IETF and 3GPP participants over the last > couple of years at which common features like support of IP emergency > calls were discussed and these could have been good forum for > participants on either side to have raised the kinds of issues you > elaborate on below. Given that seems not so far to have happened, it > could still be possible in future such calls. > > > > But the issues we are raising are not directly to do with further > aligning the 2 solutions or with the lack of this in the past. We are > simply pointing out that the solutions are currently different and that > from a cellular wireless perspective, the Ecrit solution is not seen as > suitable in all respects (for support of IP emergency calls originating > from such access types). That is not just our point of view. 3GPP2 sent > a liaison to Ecrit some months ago pointing out the same issues. > > > > So we are proposing that the Ecrit framework and phoneBCP spec.s > include a statement acknowledging this - e.g. by referencing the > alternative 3GPP/3GPP2 solution and indicating the IP access types for > which the Ecrit solution will work without limitation (or equivalently > the access types where limitations are not ruled out). > > > > We are not proposing further modification and extension of the Ecrit > solution - just pointing out that this would be needed (as with the > 3GPP/3GPP2 solution) to fully cover all types of access. > > > > Kind Regards > > > > Stephen > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, February 18, 2009 8:07 PM > > To: Edge, Stephen; 'ECRIT' > > Subject: RE: [Ecrit] Comments on Framework Draft > > > > I have bit my tongue on this one for a long time. > > > > Stephen, with respect, please go talk to 3GPP management and ask them > why > > there has been no participation in the ecrit effort despite multiple > YEARS > > of begging them to get involved. To put it frankly, 3GPP is quite > willing > > to bully IETF into doing its work on its schedule, but cannot be > bothered to > > get work done it knows it will eventually have to do when the IETF > asks it > > to do so. > > > > 3GPP understands the mess that is being created by not participating. > They > > know full well that when they finally get around to dealing with PS > > terminated emergency calls, that there will be a lot of resistance to > > changing fully specified and implemented standards to more closely > align > > with 3GPP standards. I expect you will have several interworking > functions > > to define and build. > > > > So, politely, please go away, we're finishing work we dearly wanted > you all > > to be involved with for years, but you refused to do anything. It's > too > > late for this rev. > > > > Now, having said that, there are quite a few people who have > participated in > > the IETF work who are IMS aware and I believe that despite your > fears, > > everything you need is in the specs. The mechanisms we have defined > provide > > the ability for the network to insert location, recognize and mark > emergency > > calls, and route on behalf of endpoints. An E-CSCF could quite > > straightforwardly provide a SIP call towards an ecrit compatible > PSAP. The > > only not-quite-nice interwork would be from SUPL to HELD (or SIP), > but it's > > pretty easy to do that. I'll also note that we have tried to get OMA > and > > IETF to cooperate on location protocols, but we have been > spectacularly > > unsuccessful at that effort also. > > > > Brian > > > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > >> Of Edge, Stephen > >> Sent: Thursday, February 05, 2009 2:50 AM > >> To: 'ECRIT' > >> Subject: [Ecrit] Comments on Framework Draft > >> > >> All > >> > >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative > >> description of how terminals and networks should support emergency > >> calls made over IP capable facilities to IP capable PSAPs. It > appears > >> intended to cover all types of access network - including fixed > line, > >> WiFi and cellular (e.g. examples involving each can be found > throughout > >> the draft). > >> > >> When we evaluated this with respect to support of wireless cellular > >> access and WiFi access associated with a cellular operator (e.g. > WLAN > >> or Femto cells integrated into a cellular network), we found that > >> certain portions of the draft exhibited one or more of the following > >> characteristics: > >> > >> (A) Inconsistent with already standardized wireless solutions > >> > >> (B) Inconsistent with essential wireless requirements and > >> conventions > >> > >> (C) Already part of wireless standards or potentially part of > >> future standards > >> > >> (A) refers to all portions of the draft framework that differ from > the > >> requirements and procedures currently standardized for wireless > >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference > of > >> solution and could be resolved through support of both solutions by > >> terminals (with each solution being used according to the type of > >> access network and VSP) or could be resolved by supporting only one > >> solution and accessing only the types of network supporting that > >> solution. To acknowledge this category, the framework document could > >> reference the applicable wireless standards and point out that these > >> are valid alternatives for wireless cellular based access. > >> > >> (B) refers to portions of the draft that would be unsuitable for > >> wireless networks even if no alternative solution existed together > with > >> other portions missing from the draft that would be needed to fully > >> support wireless networks. Examples of the former include: (a) > emphasis > >> on endpoint derivation of location, performance of Lost query and > >> receipt of local dial strings; (b) restriction of LCPs to protocols > >> that require terminal initiation (not allowing for network > initiation > >> as far as we can tell) and that include two LCPs (DHCP and LLDP) > that > >> are not applicable to (not defined for) cellular access; and (c) the > >> requirement that a terminal or at least a LIS will update the PSAP > >> whenever location changes. (a) is impractical due to network and > >> terminal loading consequences and failure to support non-IP capable > >> PSAPs; (b) makes location verification and updated location > provision > >> to PSAPs difficult or impossible; while (c) is also incompatible > with > >> support of existing non-IP capable PSAPs besides increasing terminal > >> load and possibly interfering with optimum maintenance of the RF > >> connection (e.g. if a terminal has to tune away from the serving > base > >> station or WLAN periodically to make location measurements). > Examples > >> of the latter include (d) absence of support for access to non-IP > >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in > the > >> US); (e) no support for handover from the IP to the circuit domain > when > >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; > and > >> (f) no allowance for limited access modes wherein a terminal may > access > >> a network only to place an emergency call with ensuing restrictions > on > >> (for example) location acquisition, PSAP callback and caller > >> verification and identification to the PSAP. To resolve this > category > >> either significant changes to the framework document could be made > or a > >> disclaimer/applicability statement could be added stating that > support > >> of cellular wireless networks and their associated WLAN and Femto > >> access points is not covered. > >> > >> Category (C) comprises concepts and capabilities in the draft that > are > >> either already part of the standardized solution for wireless > networks > >> or that might be added at a later time. Examples of the former > include > >> LoST, SIP location conveyance, general use of SIP, location for > routing > >> versus for dispatch, cellular positioning methods. Examples of the > >> latter include use of location references and dereferencing and > >> possible interworking between the current wireless network solutions > >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. > The > >> presence of this category could be acknowledged by following the > >> disclaimer for (B) with a statement that certain portions of the > >> solution are expected to be incorporated into wireless networks now > >> and/or in the future. > >> > >> We hope that these comments will be seen to be a useful addition to > >> this review in the sense of enabling a more precise scoping for the > >> framework document and we are willing to assist in providing wording > >> for any disclaimer/applicability statement that the Ecrit working > group > >> may now deem fit to include. > >> > >> Kind Regards > >> > >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs > (Qualcomm > >> 3GPP2 TSG-X and TSG-C participant) > >> > >> PS this being sent on 2/4/09 at 11:50pm PST > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] From br@brianrosen.net Fri Feb 27 06:52:25 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A114F28C0F8 for ; Fri, 27 Feb 2009 06:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a8ALyxPfpPl for ; Fri, 27 Feb 2009 06:52:23 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4760E3A69AC for ; Fri, 27 Feb 2009 06:52:23 -0800 (PST) Received: from brtech by ebru.winwebhosting.com with local (Exim 4.69) (envelope-from ) id 1Ld44m-00040P-2c; Fri, 27 Feb 2009 08:52:32 -0600 Received: from 24.154.127.233 ([24.154.127.233]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Fri, 27 Feb 2009 08:52:32 -0600 (CST) Message-ID: <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> Date: Fri, 27 Feb 2009 08:52:32 -0600 (CST) From: br@brianrosen.net To: "Edge, Stephen" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 - [32057 32003] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: /usr/local/cpanel/3rdparty/bin/php-cgi X-Source-Args: /usr/local/cpanel/3rdparty/bin/php-cgi /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:52:25 -0000 Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From bs7652@att.com Fri Feb 27 08:28:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0D23A68D5 for ; Fri, 27 Feb 2009 08:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghGCkRP7E5Ut for ; Fri, 27 Feb 2009 08:28:16 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id EFA8E28C122 for ; Fri, 27 Feb 2009 08:28:15 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1235752116!36222176!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 29862 invoked from network); 27 Feb 2009 16:28:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-3.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 27 Feb 2009 16:28:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1RGSapp015634; Fri, 27 Feb 2009 11:28:36 -0500 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n1RGSHWT014857; Fri, 27 Feb 2009 11:28:31 -0500 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Feb 2009 11:28:19 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Feb 2009 11:28:19 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 11:28:10 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> In-Reply-To: <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft thread-index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpA References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> From: "Stark, Barbara" To: , "Edge, Stephen" X-OriginalArrivalTime: 27 Feb 2009 16:28:19.0059 (UTC) FILETIME=[66315430:01C998F8] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 16:28:18 -0000 Thank you Brian. This is well said [except you left out the fact that ecrit also allows for devices to get their location through other mechanisms, such as GPS, SUPL, or other methods, and doesn't insist that the location be configured through DHCP or HELD]. I agree 100% that additional qualifications are unnecessary. Service providers, vendors, national bodies dealing with emergency services, and regulators aren't stupid. Please trust us to figure out for ourselves when/where/how to apply a "standard". There is no need to try to artificially limit or define scope, or to state the obvious (e.g., the architecture applies where it applies, and doesn't apply where it doesn't apply). We understand the role and scope of the IETF, and the role and scope of 3GPP and 3GPP2. And all the other SDOs (and national bodies and regulatory agencies). SDOs need to offer architectures that apply within the area of applicability for that SDO, and are useful to potential implementers, and leave it to the SPs, national bodies and regulators to decide which architectures and standards to use or to mandate within the scope of their network or jurisdiction. Again, we aren't stupid. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of br@brianrosen.net Sent: Friday, February 27, 2009 9:53 AM To: Edge, Stephen Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope.=20 Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability.=20 However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully.=20 Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols.=20 Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ ------------------------ > [mf2] > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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 From Hannes.Tschofenig@gmx.net Fri Feb 27 09:15:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636D928C200 for ; Fri, 27 Feb 2009 09:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jes3zxPK0SBZ for ; Fri, 27 Feb 2009 09:15:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3F44028C1EE for ; Fri, 27 Feb 2009 09:15:01 -0800 (PST) Received: (qmail invoked by alias); 27 Feb 2009 17:15:22 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp009) with SMTP; 27 Feb 2009 18:15:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18lxHlbEWMlqGSwGCixaaHd0JFBWlBx/TqfD3XLzX 6pFXZ+O2Oq2Kps From: "Hannes Tschofenig" To: "'ECRIT'" Date: Fri, 27 Feb 2009 19:16:22 +0200 Message-ID: <053501c998ff$1d90a170$2ab5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmY/xy+zhDgdkVYRceh4mtJCviLsQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 Subject: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:15:03 -0000 Hi all, Karl Heinz prepared some nice slides for our "virtual interim meeting" to describe the ServiceListBoundary concept, see http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/WikiStart/draft-wolf-ecr it-lost-servicelistboundary.ppt We had a couple of folks saying that this is a useful extension to LoST. Marc and I would need a few more folks who support the idea and are willing to review the document. Please drop us a note. Ciao Hannes & Marc From Hannes.Tschofenig@gmx.net Fri Feb 27 09:15:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B5D28C25A for ; Fri, 27 Feb 2009 09:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMOP5eh639Jd for ; Fri, 27 Feb 2009 09:15:36 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4956128C330 for ; Fri, 27 Feb 2009 09:15:36 -0800 (PST) Received: (qmail invoked by alias); 27 Feb 2009 17:15:57 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp055) with SMTP; 27 Feb 2009 18:15:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19WsUo90C9WOYzZVlZTCY8AZHBU5Ty7e92Qh7tiIz WjAXZkdEBSxA9p From: "Hannes Tschofenig" To: "'ECRIT'" Date: Fri, 27 Feb 2009 19:16:57 +0200 Message-ID: <053601c998ff$3233fc80$2ab5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmY/zF+km17wDr4RdSDo0+BnKYaAg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Subject: [Ecrit] Meeting Minutes, ECRIT Virtual Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:15:38 -0000 ECRIT virtual meeting notes - via Webex ======================================= Date/Time: 2/26/2009:11:00-1:00PM (Pacific, or GMT -8) Participants: James Polk John Elwell Jon Peterson Karl Heinz Wolf Milan Patel Roger Marshall Richard Barnes Tony Pike Cullen Jennings Guy Caron Gabor Bajko Brian Rosen Andrea Forte Marc Linsner Janet Gunn Anna Zacchi Bernard Aboba Keith Drage Hannes Tschofenig Notes by Roger. Slides at link: http://trac.tools.ietf.org/wg/ecrit/trac/wiki Agenda - Hannes --------------- Hannes goes through the slides and explains the status of the work. Marc: Agenda bashing? None heard. Phonebcp & Framework - Brian ---------------------------- Brian: Framework redline update - plan to release today. No substantive change, but asks now if we want to discuss Stephen Edge's comments - relating to Wireless. PhoneBCP also due out today. Good comments from John Elwell, probably will submit anyway, then if we need to update w/changes, we'll do that. At least one i-spot that needs something new, not sure what to do. Problem: if device didn't know how to do LoST, mark the call - if you don't see a route header, then default. fine. If you did see a route header, how would you know.(?) Seems like a bad idea to have every Proxy check the route header to make sure it's a PSAP URI. (repeat) phonebcp requirement that a proxy help out a call that didn't get a LoST answer. if LoST hasn't been done, then the proxy should do it. A good requirement, but how does a proxy ensure that this is done rightly? Idea is try to have a marker in the SIP message - don't know how to do this. Trying to avoid having to force the proxy from doing the check. John: isn't there something already in the geolocation field as a "use for routing" ? Keith: what about the socks parameter (?) Brian: 2 good comments, that we'll cosider. Also, another point of discussion, Henry claims that you can't do a SHOULD to an INFORMATIONAL document (downref exception). Jon: Advise would be to change the text, to be as if it would not be normative. If there are things that are normative here, replicated them (in Framework?) Keith: what's the new status? Brian: Framework will be INFORMATIONAL now. Brian: Is there a document status that is BCP? If xml2rfc has that, then I'll change it to that -- LoST Sync - Hannes ------------------ Brian: doesn't think this will see wide use. Keith: Other database sync mechanisms exist Brian: NENA is looking at OGC's database layer mechanism to replicate Hannes: maybe you could pass the OGC doc link to the list. -- ECRIT RPH - James Polk ----------------------- Diagram - 01 shows insertion of "esnet" as RPH marker Janet: short read - 7 pages w/boilerplate Marc: any comments for James? Brian: I want to make this a wg approved document. James: Already is a wg document. Hannes: We had some re-scope activity. based on our earlier hope to submit framework document to the IESG... Keith: Is this a wg doc or not? Jon: technically, a wg chair is empowered to accept anything they think s/b accepted, but there should also be an wg charter item to cover it. So, between two views. Keith: Jon: If there is a wg sense to work on it - I'm not going to say don't do it. Jon: kinda like the same tone of "resignation"? Hannes: need to read through the document, but basically, the diagram looks better than what was there before. James: describes any VSP that is a "trusted" entity with the ESInet. -- Rough location - Richard Barnes ------------------------------- Discussed geo requirements Geo - points out that the greater shape provided encompasses all of the more precise location possibilities. Civic location - harder to do, since filter areas may be harder to delineate. Roger: I think it's probably impossible to have a general solution that works with civic location. Brian: civic does work - you can provide a "precise" - but wrong civic address that routes to the same PSAP. Roger: Need to indicate that the returned location isn't correct. Richard: Need to investigate how todo this. PIDF-LO method field? Hannes: hopefully, Richard can apply some of the comments made here for the submission deadline. Richard: maybe. -- Sos-parameter - Milan Patel --------------------------- Presentation given Questions? No response. Hannes: Jon & Keith, SIP expert opinion? Keith: Haven't worked through all of part 4 yet Milan: Wouldn't recognize the contact address as an emergency use case - contact Jon: Hannes: Would be good to describe in the document what happens if the SIP UA sends an emergency registration with the SOS parameter and the proxy does not support it. Nobody really knew what happens in that case. Milan: yeah, will investigate it. -- LoST Service Boundaries - Karl Heinz ------------------------------------ Comments: Hannes: Thinks its good, but see it maybe as an experimental James: Why do you think it should be experimental? Hannes: Optimization for LoST where we don't have a lot of deployment experience with. Would be finished faster. Karl Heinz: Not an optimization - a gap in LoST. Richard: I think it's a good, useful draft. Roger: It's good - another example of this could be campus security (hole) within a greater metro region. Brian: I don't really care - don't see any danger. Cullen: Introduces hole, but probably already well down that road. Brian: yeah. Hannes: we should discuss this more on the list. maybe we get a few more folks to support it. -- Premature Disconnet - Brian --------------------------- Have asked for this to be considered, and have been told. Seems like some folks in the group only want to solve it through UI only. Don't know what to do to move this forward. Has been a discussion of solution paths Keith: Did you get my comments? Brian: Will have to go back and look - I know some were addressable, some don't know how to handle. Guy: (missed) Brian: Can't do this through UI Cullen: Do you think you could get consensus on that point, that you can't do it through UI? Brian: Depends on how you frame the requirement. Hannes: maybe I should try to set up a conference call, to include several of you who have comments or interest. Keith: I've made some detailed comments - need to have the requirements in front of me. Hannes: forgetting the requirements for the moment, could we proceed then? Keith: The solution that mimicks the PSTN is not acceptable to me. Guy: That is not what we're asking for. Hannes & Marc to put together a meeting to discuss. Should include: Henning, Ted, Keith, Randy, Guy, Brian. Guy: Just so I understand, this is not yet a working group item? Hannes/Marc: yes, not a wg item. Guy: In order to get there, we need to have rough consensus? Hannes: yes. -- Lost Extensions - Andrea ------------------------- Define the service URNs Hannes: Very much in favor of this - since in many cases, IANA mechanisms require too much effort to get extensions. we shouldn't have originally done this... expert review is all that's needed. So I would be very much in favor. Andrea: okay. Hannes: Keith, you had comments on the list on this? Some proposed wording you didn't like? Keith: the question.? Hannes: Are you in favor of changing IANA registration to expert review instead. Keith: May have thoughts regarding the hierachical structure. need to see actual words, are they in the draft? Keith: need to say what the rules are when we've got some kind of hierarchy, can't just be independent. Hannes: yeah. will have to think about that. Hannes: Andrea, will you be updating the document? Andrea: yes, will update the document, wanted here to see what the working group was thinking about this. Hannes: could you or Henning trigger the discussion on this service urn update? Andrea: yes. -- Unauthenticated Access ---------------------- Hannes: Henning couldn't participate, which is probably good since we're running out of time. -- Hannes: Was this meeting helpful? (2 or 3 yes responses) James: probably a good idea to have this kind of meeting 3 or 4 weeks ahead of a f2f (for Roger) and the rest of us. Jon: should have phone conferences in other groups as well. Brian: would agree, but not agree to having a single 2hr meeting for one document only. From root@core3.amsl.com Fri Feb 27 14:15:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 67BDC3A69FE; Fri, 27 Feb 2009 14:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090227221501.67BDC3A69FE@core3.amsl.com> Date: Fri, 27 Feb 2009 14:15:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-08.txt Pages : 36 Date : 2009-02-27 The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ecrit-framework-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-27140025.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Feb 27 14:15:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 784EE3A6A2C; Fri, 27 Feb 2009 14:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090227221501.784EE3A6A2C@core3.amsl.com> Date: Fri, 27 Feb 2009 14:15:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:15:01 -0000 --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-08.txt Pages : 45 Date : 2009-02-27 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ecrit-phonebcp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-27140037.I-D@ietf.org> --NextPart-- From br@brianrosen.net Fri Feb 27 16:16:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403F33A6AEF for ; Fri, 27 Feb 2009 16:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1G7gK1bI5Oh for ; Fri, 27 Feb 2009 16:16:11 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2A1D83A6AEA for ; Fri, 27 Feb 2009 16:16:11 -0800 (PST) Received: from brtech by ebru.winwebhosting.com with local (Exim 4.69) (envelope-from ) id 1LdCsP-00018p-SD for ecrit@ietf.org; Fri, 27 Feb 2009 18:16:21 -0600 Received: from 24.154.127.233 ([24.154.127.233]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Fri, 27 Feb 2009 19:16:21 -0500 (EST) Message-ID: <53143.24.154.127.233.1235780181.squirrel@www.brianrosen.net> In-Reply-To: <20090227221501.67BDC3A69FE@core3.amsl.com> References: <20090227221501.67BDC3A69FE@core3.amsl.com> Date: Fri, 27 Feb 2009 19:16:21 -0500 (EST) From: "Brian Rosen" To: ecrit@ietf.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 - [32057 32003] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: /usr/local/cpanel/3rdparty/bin/php-cgi X-Source-Args: /usr/local/cpanel/3rdparty/bin/php-cgi /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 00:16:13 -0000 This version has some new text as a result of comments from John Elwell (see forthcoming email for details). It is now Informational. Henning provided a large number of editorial comments, which I incorporated. I recommend you look at the diff: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/draft-ietf-ecrit-framework-08-from-07.diff.html Brian > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Emergency Context Resolution with > Internet Technologies Working Group of the IETF. > > > Title : Framework for Emergency Calling using Internet > Multimedia > Author(s) : B. Rosen, et al. > Filename : draft-ietf-ecrit-framework-08.txt > Pages : 36 > Date : 2009-02-27 > > The IETF has standardized various aspects of placing emergency calls. > This document describes how all of those component parts are used to > support emergency calls from citizens and visitors to authorities. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Fri Feb 27 16:18:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784DE3A6AEA for ; Fri, 27 Feb 2009 16:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZD9BU04La9H for ; Fri, 27 Feb 2009 16:18:02 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 42D913A68EB for ; Fri, 27 Feb 2009 16:17:58 -0800 (PST) Received: from brtech by ebru.winwebhosting.com with local (Exim 4.69) (envelope-from ) id 1LdCu9-0001G5-4t for ecrit@ietf.org; Fri, 27 Feb 2009 18:18:09 -0600 Received: from 24.154.127.233 ([24.154.127.233]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Fri, 27 Feb 2009 19:18:09 -0500 (EST) Message-ID: <53157.24.154.127.233.1235780289.squirrel@www.brianrosen.net> In-Reply-To: <20090227221501.784EE3A6A2C@core3.amsl.com> References: <20090227221501.784EE3A6A2C@core3.amsl.com> Date: Fri, 27 Feb 2009 19:18:09 -0500 (EST) From: "Brian Rosen" To: ecrit@ietf.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 - [32057 32003] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: /usr/local/cpanel/3rdparty/bin/php-cgi X-Source-Args: /usr/local/cpanel/3rdparty/bin/php-cgi /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 00:18:03 -0000 This version is now BCP status. It has several changes to resolve comments by John Elwell (see forthcoming email for specifics. I recommend you look at the diff: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/draft-ietf-ecrit-phonebcp-08-from-07.diff.html Brian > 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-08.txt > Pages : 45 > Date : 2009-02-27 > > The IETF and other standards organization have efforts targeted at > standardizing various aspects of placing emergency calls on IP > networks. This memo describes best current practice on how devices, > networks and services should use such standards to make emergency > calls. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Fri Feb 27 16:29:49 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CBD3A6B28 for ; Fri, 27 Feb 2009 16:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZClrlKADuEr for ; Fri, 27 Feb 2009 16:29:48 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id DC8FC3A676A for ; Fri, 27 Feb 2009 16:29:47 -0800 (PST) Received: from brtech by ebru.winwebhosting.com with local (Exim 4.69) (envelope-from ) id 1LdD5a-0002UT-Mv for ecrit@ietf.org; Fri, 27 Feb 2009 18:29:58 -0600 Received: from 24.154.127.233 ([24.154.127.233]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Fri, 27 Feb 2009 19:29:58 -0500 (EST) Message-ID: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> Date: Fri, 27 Feb 2009 19:29:58 -0500 (EST) From: "Brian Rosen" To: ecrit@ietf.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 - [32057 32003] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: /usr/local/cpanel/3rdparty/bin/php-cgi X-Source-Args: /usr/local/cpanel/3rdparty/bin/php-cgi /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 00:29:49 -0000 Thank you for your comments. Sorry this took so long. I am temporarily unable to create an actual "Reply all" to your email, so this is cut/pasted from a non-IETF archive (the archives are screwed up, there is no mail from Feb 2 to Feb 27). The changes are now in -framework-08 and -phonebcp-08 Enterprise = access network operator. They must meet the AN requirements. I'll point that out. Enterprises could run their own LoST server which would deliver the right things (dial string, URI, ...). I've added text on both enterprise as access network provider and potential LoST and PSAP provider in -framework, and mentioned enterprise as a possible access network provider in -phonebcp 1. ED-6 vs ED-9 is the difference between discovery with a home country code and provisioning of actual dial string. We haven't described discovery, so I'll have to delete ED-6 2. I'll Reword SP-8 to say that Service providers may provision endpoints with home dial strings (see ED-9) 3. Changes in the list clarifies this, but ED-18 says do it, and ED-21 specifies protocol support to do it. I added a reference to -21 in -18. 4. We discussed this on the interim conference call. The resolution will be to remove the requirement and have something non normative in -framework. 5. I'll downgrade the sip-sips reference to Informational. Could refer to the 3.1 text. 6. Don't know how to define a requirement which assumes the presence of a B2BUA. I propose to leave as is 7. I'll fix the text for MUST and delete "normal" 8. An actual problem. Calls out for a way to mark the Route as the emergency route. Two solutions were discussed. One is to use the sos parameter. The other is to say that the Geolocation header must not have a "used for routing" parameter unless the LoST routing was completed. I think I will recommend the second. 9. Rework to make it a SHOULD noting the issue. Unauthenticaed devices usually are allowed to make calls, but not always. I'll add text. 10. If the device is no longer registered, then the Contact can't be valid. I can insert text to this effect. Don't know how to handle B2BUAs that munge Contact headers. I can at least call out the problem in -framework. 11. Tried to make the requirement minimal (no Replaces, for example), but I think you need referred by. I'll think some more about that. I'll add text that says device implementers should consider the effect of emergency call transfer on a stressed user; generally, the device should do the transfer. 12. Don't understand the problem. The situation described is AFTER a call session is established, but before it is terminated. LoST resolution is complete. 13. a) If a call arrives while an emergency call is up, we don't want a call waiting tone, alert or other prompt, we don't want the emergency call put on hold and we don't want the incoming call to be answered. b) Although some features can be applied to incoming calls, they are also applicable to outgoing calls, which is what we want here; we don't want the emergency call put on hold, put into a client-side conference, ... c) I'll add a definition of "flash hold" to -framework. Of course "flash hold" does involve a proxy, where normal SIP hold does not. You don't want Hold (that is, disconnect the media to or from the PSAP). 14. Call waiting on an incoming call is the same as on an outgoing call: you don't alert to another call, you don't offer hold and switch. The PSAP callback stays up. Yes, 486 or voicemail is appropriate. Indeed the recognition of the callback is difficult, and I hope we will charter an item. I think the domain recognition is a reasonable first step, and I recognize it won't always work. When it doesn't, callback won't get the feature suppression. Not a good thing, but not fatal. 15. I may be misinterpreting your concern, but I think the B2BUA that maps Contact doesn't alter the caller's domain as seen by the called party. If the call arrives directed TO the Contact or AoR given out in the original emergency call, and it's FROM the same domain that answered the call, then it should be treated as a call back. 16. I don't really care much what error message we use. I can change it to 404 if there are no objections. ".test" is not registered. We probably should do that, but not in this document. It's not really required that we register it, as it's a subdomain of a registered domain. i need to get a document started to register a couple of things not dissimilar to this, so I'll put it in that 17. The response certainly should be using TLS, but it might not work. I'll add text. 18. I will delete the sentence referencing 4916. Brian ------ original message contents ------- Some WGLC comments on this. Apologies for not raising them before, but I have not participated in this WG until recently. General comment: It is not clear if and how this applies to enterprise networks. Enterprise networks are mentioned in a couple requirements involving intermediate range wireless connections, but that is all. Particular requirements of enterprise networks, which might include their own "PSAPs" in some situations, for example, and different dial strings in some circumstances, do not seem to be addressed. So perhaps it should be made clear that it does not address special requirements of enterprise networks. Detailed comments: 1. "ED-6/SP-5 Devices MUST be able to be configured with the home country from which the home dial string(s) can be determined." And later: "ED-9 Endpoints SHOULD be able to have home dial strings provisioned by configuration." I can't figure out exactly why we need two separate requirements here. 2. "SP-8 Service providers MAY provide home dial strings by configuration" It is not clear to whom or to what home dial strings are provided, and how this relates to requirements ED-6/SP-5 and ED-9. 3. "ED-18/INT-9 Endpoints SHOULD attempt to configure their own location." And later: "ED-21/INT-12 Devices MUST support both the DHCP location options [RFC4776], [RFC3825] and HELD" There appears to be some inconsistency here. If there are circumstances in which a device does not need to attempt to configure its own location (because it is only SHOULD strength), why are support for DHCP and HELD mandated? 4. "ED-59 Best Current Practice for SIP user agents [RFC4504] including handling of audio, video and real-time text [RFC4103] SHOULD be applied." Is it permissible for a Standards Track to make a SHOULD statement involving an informational RFC? I believe not. Furthermore, RFC 4504 refers back to ECRIT work, which makes it rather circular. 5. "ED-60/SP-31 TLS MUST be specified when attempting to signal an emergency call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC3986] is an acceptable alternative." I think we need to be more specific about what aspect of sip-sips we are referring to. For example, are we talking about 3.1 "Models for using TLS in SIP"? That section doesn't seem to include any normative statements, so why is it a normative reference. The normative part of sip-sips seems to relate to the SIPS URI scheme, which presumably we don't want to use. 6. " A Contact header MUST be present which MUST be globally routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid for several minutes following the termination of the call to permit an immediate call-back to the specific device which placed the emergency call." As a requirement for a user agent, I don't think this is necessary in situations where there is a B2BUA that maps a local contact URI to a globally routable contact URI. 7. "ED-58 Initial INVITES MUST provide an Offer [RFC3264]." And later: "A normal SDP offer SHOULD be included in the INVITE. If voice is supported the offer MUST include the G.711 codec, see Section 14." This seems contradictory (MUST and SHOULD). Also what is "normal"? 8. "A proxy that processes such a call looks for the presence of a SIP Route header field with a URI of a PSAP. Absence of such a Route header indicates the UAC was unable to invoke LoST and the proxy MUST perform the LoST mapping and insert a Route header field with the URI obtained." How does the proxy determine whether a URI is indeed a PSAP URI? Does it need to examine the Geolocation header field to see if the location has been used for routing? 9. "Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, MUST be included to identify the sender." A proxy cannot do this unless it has authenticated the UA or unless it violates the rules of RFC 3325 or RFC 4474. I think we need some commentary on whether unauthenticated UAs are allowed to make emergency calls, and if so, how to get around this problem of providing PAI or Identity. 10. "SP-36 Call backs to the Contact: header URI recieved within 30 minutes of an emergency call must reach the device regardless of call features or services that would normally cause the call to be routed to some other entity." a) What if the device is no longer registered? c) Also, what if there are downstream B2BUAs that map contact URIs? Will they necessarily cache that mapping after the original call has finished? If not, I don't see how a callback to the contact URI can work. 11. "ED-67/SP-38 During the course of an emergency call, devices and proxies MUST support REFER transactions and the Referred-by: header [RFC3515]." a)This is a very broad requirement. I can see the need for supporting REFER with SIP/SIPS URI and with method=INVITE. Is there a requirement beyond this? b) A UA can support REFER by consulting its user whether to go ahead and reference. The user may decline. Or UA policy might prevent certain dereferences. Does anything need to be said about this? 12. "If in the interval, an incoming call is received from the domain of the PSAP, the device MUST drop the old call and alert for the (new) incoming call." Can the device necessarily determine this? For example, if the device just submitted a dial string, or submitted a service URN without performing a LoST query, or if the call gets retargeted to a different PSAP domain? 13. "ED-70/SP-39 User Agents and proxies MUST disable outgoing call features such as o Call Waiting o Call Transfer o Three Way Call o Flash hold o Outbound Call Blocking" a) I don't see how Call Waiting can be considered an outgoing call feature. Some explanation is needed. b) I don't see call transfer, three way call (presumably 3-way conference) and hold as "outgoing call features" particularly - you can use these "features" with incoming calls too. c) "Flash hold" seems to be a north American term - use a more generic term or describe what this means. d) If "flash hold" means "hold", proxies have no influence over it. Also, if hold means "stop sending and rendering media", a device can do that simply by preventing the user turning down the microphone or speaker volume. Is this what it means? Removing any control over volume seems unwise. 14. " ED-72/SP-41 The User Agent and Proxies SHOULD disable the following incoming call features on call backs from the PSAP: o Call Waiting" a) Disabling call waiting will generally result in rejecting an incoming call with a 486, or forwarding, e.g., to voicemail. Is this really what is required? b) How does a UA or proxy determine that the callback is from a PSAP (see earlier comment, and also next comment)? 15. "ED-73 Call backs SHOULD be determined by retaining the domain of the PSAP which answers an outgoing emergency call and instantiating a timer which starts when the call is terminated. If a call is received from the same domain and within the timer period, sent to the Contact: or AoR used in the emergency call, it should be assumed to be a call back. The suggested timer period is 5 minutes." Suppose there is a B2BUA on the path that maps contact URIs. Every call the UA makes through that B2BUA will have a contact URI with the domain of that B2BUA, so every call within the time period concerned would be treated as coming from a PSAP. 16. "ED-81 INVITE requests to a service URN ending in ".test" indicates a request for an automated test. For example, "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response indicates that the address was recognized and a 404 (Not found) that it was not. A 486 (Busy Here) MUST be returned if the test service is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP does not support the test mechanism." This seems to be the wrong semantics for 488, since in this case there is nothing wrong with the session description. Wouldn't 404 be more appropriate, since the .test URN is not recognised? Also, where is ".test" registered? 17. "ED-82 In its response to the test, the PSAP MAY include a text body (text/plain) indicating the identity of the PSAP, the requested service, and the location reported with the call. For the latter, the PSAP SHOULD return location-by-value even if the original location delivered with the test was by-reference." Isn't there a security issue with this, particularly for the case where SIPS has not been used? There is no discussion in Security Considerations. 18. "The response MAY include the connected identity of the PSAP per [RFC4916]." RFC 4916 makes no provision for responses. John Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B50E3A6B3B for ; Wed, 4 Feb 2009 07:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNcRCdZt1-il for ; Wed, 4 Feb 2009 07:29:52 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B7E8B3A6837 for ; Wed, 4 Feb 2009 07:29:51 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEJ0078ASD7GH@siemenscomms.co.uk> for ecrit@ietf.org; Wed, 04 Feb 2009 15:29:31 +0000 (GMT) Date: Wed, 04 Feb 2009 15:29:33 +0000 From: "Elwell, John" To: ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0017FB89D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Comments on phonebcp-07 Thread-Index: AcmG2TzrX1PZDoMaQaWKnk3BwoYIIQ== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 15:29:53 -0000 Some WGLC comments on this. Apologies for not raising them before, but I have not participated in this WG until recently. General comment: It is not clear if and how this applies to enterprise networks. Enterprise networks are mentioned in a couple requirements involving intermediate range wireless connections, but that is all. Particular requirements of enterprise networks, which might include their own "PSAPs" in some situations, for example, and different dial strings in some circumstances, do not seem to be addressed. So perhaps it should be made clear that it does not address special requirements of enterprise networks. Detailed comments: 1. "ED-6/SP-5 Devices MUST be able to be configured with the home country from which the home dial string(s) can be determined." And later: "ED-9 Endpoints SHOULD be able to have home dial strings provisioned by configuration." I can't figure out exactly why we need two separate requirements here. 2. "SP-8 Service providers MAY provide home dial strings by configuration" It is not clear to whom or to what home dial strings are provided, and how this relates to requirements ED-6/SP-5 and ED-9. 3. "ED-18/INT-9 Endpoints SHOULD attempt to configure their own location." And later: "ED-21/INT-12 Devices MUST support both the DHCP location options [RFC4776], [RFC3825] and HELD" There appears to be some inconsistency here. If there are circumstances in which a device does not need to attempt to configure its own location (because it is only SHOULD strength), why are support for DHCP and HELD mandated? 4. "ED-59 Best Current Practice for SIP user agents [RFC4504] including handling of audio, video and real-time text [RFC4103] SHOULD be applied." Is it permissible for a Standards Track to make a SHOULD statement involving an informational RFC? I believe not. Furthermore, RFC 4504 refers back to ECRIT work, which makes it rather circular. 5. "ED-60/SP-31 TLS MUST be specified when attempting to signal an emergency call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC3986] is an acceptable alternative." I think we need to be more specific about what aspect of sip-sips we are referring to. For example, are we talking about 3.1 "Models for using TLS in SIP"? That section doesn't seem to include any normative statements, so why is it a normative reference. The normative part of sip-sips seems to relate to the SIPS URI scheme, which presumably we don't want to use. 6. " A Contact header MUST be present which MUST be globally routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid for several minutes following the termination of the call to permit an immediate call-back to the specific device which placed the emergency call." As a requirement for a user agent, I don't think this is necessary in situations where there is a B2BUA that maps a local contact URI to a globally routable contact URI. 7. "ED-58 Initial INVITES MUST provide an Offer [RFC3264]." And later: "A normal SDP offer SHOULD be included in the INVITE. If voice is supported the offer MUST include the G.711 codec, see Section 14." This seems contradictory (MUST and SHOULD). Also what is "normal"? 8. "A proxy that processes such a call looks for the presence of a SIP Route header field with a URI of a PSAP. Absence of such a Route header indicates the UAC was unable to invoke LoST and the proxy MUST perform the LoST mapping and insert a Route header field with the URI obtained." How does the proxy determine whether a URI is indeed a PSAP URI? Does it need to examine the Geolocation header field to see if the location has been used for routing? 9. "Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, MUST be included to identify the sender." A proxy cannot do this unless it has authenticated the UA or unless it violates the rules of RFC 3325 or RFC 4474. I think we need some commentary on whether unauthenticated UAs are allowed to make emergency calls, and if so, how to get around this problem of providing PAI or Identity. 10. "SP-36 Call backs to the Contact: header URI recieved within 30 minutes of an emergency call must reach the device regardless of call features or services that would normally cause the call to be routed to some other entity." a) What if the device is no longer registered? c) Also, what if there are downstream B2BUAs that map contact URIs? Will they necessarily cache that mapping after the original call has finished? If not, I don't see how a callback to the contact URI can work. 11. "ED-67/SP-38 During the course of an emergency call, devices and proxies MUST support REFER transactions and the Referred-by: header [RFC3515]." a)This is a very broad requirement. I can see the need for supporting REFER with SIP/SIPS URI and with method=3DINVITE. Is there a requirement beyond this? b) A UA can support REFER by consulting its user whether to go ahead and reference. The user may decline. Or UA policy might prevent certain dereferences. Does anything need to be said about this? 12. "If in the interval, an incoming call is received from the domain of the PSAP, the device MUST drop the old call and alert for the (new) incoming call." Can the device necessarily determine this? For example, if the device just submitted a dial string, or submitted a service URN without performing a LoST query, or if the call gets retargeted to a different PSAP domain? 13. "ED-70/SP-39 User Agents and proxies MUST disable outgoing call features such as o Call Waiting o Call Transfer o Three Way Call o Flash hold o Outbound Call Blocking" a) I don't see how Call Waiting can be considered an outgoing call feature. Some explanation is needed. b) I don't see call transfer, three way call (presumably 3-way conference) and hold as "outgoing call features" particularly - you can use these "features" with incoming calls too. c) "Flash hold" seems to be a north American term - use a more generic term or describe what this means. d) If "flash hold" means "hold", proxies have no influence over it. Also, if hold means "stop sending and rendering media", a device can do that simply by preventing the user turning down the microphone or speaker volume. Is this what it means? Removing any control over volume seems unwise. 14. " ED-72/SP-41 The User Agent and Proxies SHOULD disable the following incoming call features on call backs from the PSAP: o Call Waiting" a) Disabling call waiting will generally result in rejecting an incoming call with a 486, or forwarding, e.g., to voicemail. Is this really what is required? b) How does a UA or proxy determine that the callback is from a PSAP (see earlier comment, and also next comment)? 15. "ED-73 Call backs SHOULD be determined by retaining the domain of the PSAP which answers an outgoing emergency call and instantiating a timer which starts when the call is terminated. If a call is received from the same domain and within the timer period, sent to the Contact: or AoR used in the emergency call, it should be assumed to be a call back. The suggested timer period is 5 minutes." Suppose there is a B2BUA on the path that maps contact URIs. Every call the UA makes through that B2BUA will have a contact URI with the domain of that B2BUA, so every call within the time period concerned would be treated as coming from a PSAP. 16. "ED-81 INVITE requests to a service URN ending in ".test" indicates a request for an automated test. For example, "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response indicates that the address was recognized and a 404 (Not found) that it was not. A 486 (Busy Here) MUST be returned if the test service is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP does not support the test mechanism." This seems to be the wrong semantics for 488, since in this case there is nothing wrong with the session description. Wouldn't 404 be more appropriate, since the .test URN is not recognised? Also, where is ".test" registered? 17. "ED-82 In its response to the test, the PSAP MAY include a text body (text/plain) indicating the identity of the PSAP, the requested service, and the location reported with the call. For the latter, the PSAP SHOULD return location-by-value even if the original location delivered with the test was by-reference." Isn't there a security issue with this, particularly for the case where SIPS has not been used? There is no discussion in Security Considerations. 18. "The response MAY include the connected identity of the PSAP per [RFC4916]." RFC 4916 makes no provision for responses. John Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5C43A6B92 for ; Wed, 4 Feb 2009 09:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itgJkfm+1Txj for ; Wed, 4 Feb 2009 09:28:15 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D206C3A6AFF for ; Wed, 4 Feb 2009 09:28:14 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2009 17:27:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp040) with SMTP; 04 Feb 2009 18:27:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/5GhQzQWL5dtgbs2Sq+NCwMt5sFk/VyC49Risvbt 9247Gk7nnj5Z64 From: "Hannes Tschofenig" To: "'Richard Barnes'" , "'ECRIT'" , References: <49814474.6070606@bbn.com> Date: Wed, 4 Feb 2009 19:28:40 +0200 Message-ID: <000101c986ee$05c75de0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmB1gCc7Rx3IeywQ36KJ2K9r3YMoAEZ7Mew In-Reply-To: <49814474.6070606@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: Re: [Ecrit] Review of draft-ietf-lost-sync-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:28:16 -0000 Hi Richard, Thanks for your detailed review of the document. I produced a new version based on your feedback. Here is a snapshot: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-ietf-ecri t-lost-sync-03.txt Please look at it before I submit it to make sure that goes into the right direction of addressing your comments. More comments below: >This draft proposes an XML syntax for transferring LoST >mappings between LoST nodes. I prefer to say that it transfers mappings that are defined in LoST between different nodes. I believe that the protocol can be used even without LoST. For example, you could use this protocol in the NENA i2.5 environment. While this XML syntax seems to >have most of the necessary features for the proposed use >cases, the details of how the XML syntax is to be used to >effect the transfer are either ambiguous or completely >missing. Specific comments below. >--Richard > > >Section 1. Introduction >-- This may reflect a misunderstanding of the mapping >architecture on my part, but my impression was that the >architecture envisioned query patterns similar to the DNS, >either iterating or recursing through the tree. This document >seems to propose that instead, authoritative servers and >branch nodes would push mapping up, presumably to FGs (this >behavior has no analogue in the DNS to my knowledge). It >would be helpful if this document could clarify how these two >patterns interact. When used in the LoST mapping architecture then this document is going to be mainly used between FGs. Still, one could use this document also between other nodes. LoST itself would allow you to dynamically obtain mappings whereas this document essentially replicates cache entries. The DNS analogon would be a zone transfer. > >Section 3. Distributing Mappings via ... >-- I think there's enough description here to basically >understand how this is supposed to work, but there's not a >clear, normative specification, not a single MUST in the whole >section! It would be helpful to have clear "Sender >processing" and "Recipient processing" >instructions. Worked on it >-- Likewise, there's no clear description of who sends which >messages to whom (except by example), and no description at >all of how these messages are carried. If this is an >extension to LoST, please say so, or if it's another HTTP >usage, or bare TCP, etc. The absence of these details >(particularly message flow patterns), it's a hard to >understand the sequence of events. The transport is reused from LoST but it is certainly useful to say that. >-- The message pattern this seems to be following is a little >weird; it's "pub/sub", but without the "sub". There should be >some comment on this, e.g., that there is an expectation that >these peering relationships are established out of band, and >thus no subscription or request is necessary. That's true. There is no subscribe in the protocol. This is done in an out-of-band fashion, if desired. Alternatively, > could possibly support an "asynchronous" flag. >-- There's a stray " at the end of the fourth paragraph >-- The URIs in the example fields are invalid > OK. >Section 4. Synchronizing Mapping Stores via ... >-- Same first two comments as for Section 3. There needs to >be a much clearer, normative description of how the peers >process and transmit messages. Fixed. >-- Please change the tag to something readable >(?) Fixed. >-- The description here seems to conflate two types of query >parameters, "what I have" and "what I want". If you separate >these two out, it could simplify the semantics: the "what I >have" section would have elements that MUST have all >three identifier fields, while the "what I want" section would >have descriptions of mappings to be >returned (using subsets of identifier fields). Done. See the revised version. >-- Why can't a element have a lastUpdated attribute? >Either it should have everything or nothing. (IMO, the >optimization isn't worth the extra complexity of merging >attributes from and ) Please look at the revised version and let me know if there is some functionality we should get rid off >-- Is there a reason no content-based queries are allowed? >For example, I could imagine that it would be useful to be >able to query for all service boundaries that intersect a >given region, or to constrain a query by service URN. This is a new requirement I have not seen before in the context of LoST Sync. Currently, the document is about exchanging information between two peers. >Section 5. Security Considerations >-- The document delegates security to LoST without ever having >said that the XML defined here is carried by LoST. It is not carried by LoST but rather it references the element structure defined in LoST. > In order >for this stuff to be meaningful, there has to be a transport >protocol defined. Done. Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A015B3A6920 for ; Wed, 4 Feb 2009 09:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWXJPD6gX+V6 for ; Wed, 4 Feb 2009 09:54:14 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B5B8B3A6843 for ; Wed, 4 Feb 2009 09:54:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="242930340" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 04 Feb 2009 17:53:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n14HrtxZ014856; Wed, 4 Feb 2009 09:53:55 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n14HrtdP022341; Wed, 4 Feb 2009 17:53:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 09:53:55 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 09:53:54 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Feb 2009 11:53:53 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Hannes Tschofenig" , "ECRIT" From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFFC06@FIESEXC015.nsn-intr a.net> References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> <3D3C75174CB95F42AD6BCC56E5555B45FFFC06@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2009 17:53:54.0757 (UTC) FILETIME=[8BCE6750:01C986F1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=504; t=1233770035; x=1234634035; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda |Sender:=20; bh=cPe3AD8nj1AOXOo1sDEBV37W/gu9C7+cZvFGiWyKcdg=; b=IsAIk4fvGhJB3SFliWTAkD14HMOO0njc+STrNjuGS6t2NrUg9QG9uXGZQS ethmE/Hc92S38fHWJp02eHK5hkM/u2/ZtIW91Q+ndp/Hvcb7L5Jx1KZHziC0 KYzKTvZ9Qw; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:54:15 -0000 At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Recently Roger and Richard provided their document reviews. We discuss >their reviews. >Henning or Hannes will be the discussion lead. > >* draft-ietf-ecrit-local-emergency-rph-namespace Hannes I believe you should disqualify yourself as lead of this discussion given that you are the _lone_ voice not supporting this ID, but rather - IMO - you need to concentrate your full attention to the discussion itself. James Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251863A6A3D for ; Wed, 4 Feb 2009 09:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf98z0n5LCXq for ; Wed, 4 Feb 2009 09:58:57 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0F21E3A6A98 for ; Wed, 4 Feb 2009 09:58:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="137802436" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2009 17:58:37 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14Hwb6A025842; Wed, 4 Feb 2009 09:58:37 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n14HwbOg029788; Wed, 4 Feb 2009 17:58:37 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); Wed, 4 Feb 2009 09:58:37 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 09:58:36 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Feb 2009 11:58:35 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Hannes Tschofenig" , "ECRIT" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2009 17:58:37.0049 (UTC) FILETIME=[3410BE90:01C986F2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1171; t=1233770317; x=1234634317; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Fwd=3A=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20In terim=20Meeting=3A=20Agenda=20(my=0A=20=20mistake) |Sender:=20; bh=wuQ7jq4jpUjEEgDd6BL8BnpgM7FibSk93XB8zbdXWJI=; b=uR6fN3iwdukKqYAyIYkmjRukfru7/sIPSB9h0qNpb1YQUVEb1bchHRSoQN VxbM8bLZ79q0hFq4pGES33qWgVGgjuJwGiEv+nQ6qjRDFls18ZRQ8PmD84gB yPVjCwTUp6axOXkdoaILkTAg7QvU9sN9USSf7+HlKoJ1jjlvLi4uQ=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Ecrit] Fwd: Re: ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:58:58 -0000 I appear to have been hasty in my previous message - and not clearly viewed the order of who was leading which discussion - i.e., I viewed the name(s) above the ID to be the ones leading the discussion when I should have viewed the names below to be leading the discussion. I apologize Hannes, you have this correct and I read it wrong. >Date: Wed, 04 Feb 2009 11:53:53 -0600 >To: "Tschofenig, Hannes (NSN - FI/Espoo)" >, "ext Hannes Tschofenig" >, "ECRIT" >From: "James M. Polk" >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda > >At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Recently Roger and Richard provided their document reviews. We discuss >>their reviews. >>Henning or Hannes will be the discussion lead. >> >>* draft-ietf-ecrit-local-emergency-rph-namespace > >Hannes > >I believe you should disqualify yourself as lead of this discussion >given that you are the _lone_ voice not supporting this ID, but >rather - IMO - you need to concentrate your full attention to the >discussion itself. > >James Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C5928C228 for ; Wed, 4 Feb 2009 09:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiOmhqxsy4lg for ; Wed, 4 Feb 2009 09:59:55 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C53883A6A3D for ; Wed, 4 Feb 2009 09:59:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="137803196" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2009 17:59:36 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n14HxaA5027443; Wed, 4 Feb 2009 09:59:36 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n14HxaiS000366; Wed, 4 Feb 2009 17:59:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 09:59:36 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 09:59:35 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Feb 2009 11:59:34 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Hannes Tschofenig" , "ECRIT" From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFFC06@FIESEXC015.nsn-intr a.net> References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> <3D3C75174CB95F42AD6BCC56E5555B45FFFC06@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2009 17:59:35.0786 (UTC) FILETIME=[57134CA0:01C986F2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1986; t=1233770376; x=1234634376; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda=20(timing?) |Sender:=20; bh=ROt4rLJal0CknenZP78gZqkZaujLqATmJK2OnIW/WfM=; b=kxpHq0c+kcs68zCFzbwc8ci6ZL/MRK6zTfKHyHN+ONI20FDUpwYho4+86c R2l32secvCC2PDpQ1Bqays4CK29uG6SQjLOVfbo79T6b9wU//qXnMSVML8E2 9c3A22fNfE; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:59:56 -0000 Hannes This would be considered a full agenda for a f2f meeting. How long do you expect this call to last? James At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >This is the agenda proposal for the meeting: > >* draft-ietf-ecrit-phonebcp and draft-ietf-ecrit-framework > >Only if there are substantial comments received during WGLC that require >a discussion. >Brian will do the job. > >* draft-ietf-ecrit-lost-sync > >Recently Roger and Richard provided their document reviews. We discuss >their reviews. >Henning or Hannes will be the discussion lead. > >* draft-ietf-ecrit-local-emergency-rph-namespace > >This document received a lot of feedback. We should start our discussion >with the where the marking should happen along the e2e chain. James is >going to lead this discussion. > >* draft-barnes-ecrit-rough-loc > >Richard will lead us through this document and tell us what the >necessary steps are to complete it. > >* draft-patel-ecrit-sos-parameter > >Milan will tell us what the open issues with this document are. > >* draft-rosen-ecrit-premature-disconnect-rqmts > >Brian will inform us about the recent draft update and we will chat >whether this version can be picked up as a WG item. > >* RFC5031bis and draft-forte-ecrit-lost-extensions > >Henning or Andrea will brief us about the plans to update the Service >URN RFC and how to then deal with the extensions that have been proposed >to the group. > >* draft-wolf-ecrit-lost-servicelistboundary > >Karl Heinz wanted to give a presentation about this draft at the last >IETF meeting but we ran out of time. Let's try it again. > >* draft-schulzrinne-ecrit-unauthenticated-access > >Finally, we should chat about how we should proceed with the >unauthenticated emergency calls document. > >Ciao >Hannes >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1173A63CB for ; Wed, 4 Feb 2009 12:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqLZMHfYHRuu for ; Wed, 4 Feb 2009 12:37:03 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BAFDB28C225 for ; Wed, 4 Feb 2009 12:36:42 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2009 20:36:21 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp023) with SMTP; 04 Feb 2009 21:36:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+HgLNPqDCHqMpECTmarFkOLhgTxxDN6JTppL4A3z bT98MH8sWxBzaZ From: "Hannes Tschofenig" To: "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: Date: Wed, 4 Feb 2009 22:37:07 +0200 Message-ID: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+w In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:37:03 -0000 > James wrote: >> you are the _lone_ voice not supporting this ID, Listening to the audio recording of past meetings I have to say that I was not the only persons raising concerns about the document. That was probably the reason why you agreed to limit the scope of the document (which you didn't later do) to get folks to agree to make it a WG item. Btw, I not disagreeing with the document as such. I just want to the scope to change. The usage of RPH within the emergency services network is fine for me. I may get convinced to start the RPH marking from the the VSP towards the PSAP. I feel uneasy about the end host doing the marking. I don't see advantages -- only disadvantages. Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D910E28C11F for ; Wed, 4 Feb 2009 12:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FydwZxDXNUwK for ; Wed, 4 Feb 2009 12:42:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C6AE83A683D for ; Wed, 4 Feb 2009 12:42:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,381,1231113600"; d="scan'208";a="35965628" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2009 20:41:58 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14KfwoA024391; Wed, 4 Feb 2009 15:41:58 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14Kfw5p007818; Wed, 4 Feb 2009 20:41:58 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 15:41:58 -0500 Received: from [10.116.195.119] ([10.116.195.119]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 15:41:42 -0500 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 04 Feb 2009 15:41:40 -0500 From: Marc Linsner To: Hannes Tschofenig , James Polk , "Tschofenig, Hannes (NSN - FI/Espoo)" , "'ECRIT'" Message-ID: Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+wAABz8h8= In-Reply-To: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Feb 2009 20:41:42.0764 (UTC) FILETIME=[FCCE5AC0:01C98708] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1069; t=1233780118; x=1234644118; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda=20(my=20=20mistake) |Sender:=20 |To:=20Hannes=20Tschofenig=20,=0 A=20=20=20=20=20=20=20=20James=20Polk=20,= 0A=20=20=20=20=20=20=20=20=22Tschofenig,=20Hannes=20(NSN=20- =20FI/Espoo)=22=20,=0A=20=20=20=2 0=20=20=20=20=22'ECRIT'=22=20; bh=mYnuDNAvna4n/CaVw3lPSbhVBJkBlDZ1b4kAiL8V6J0=; b=g9EKhyoL0m2TQ9bkJ+mB5uKcHPYfsVmtN0eYgjwtAqih8t+lLhHWsKuQUo 1SbdivyWyGcd3oVo29DPXb54sr8oLdBovqomjSjfy4STT0OsS9iuIOmLfj7i bDIUafF1Ml; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:42:25 -0000 Hannes, I'm curious. Are you against the RPH in general, or just this namespace? -Marc- On 2/4/09 3:37 PM, "Hannes Tschofenig" wrote: >> James wrote: >>> you are the _lone_ voice not supporting this ID, > > Listening to the audio recording of past meetings I have to say that I was > not the only persons raising concerns about the document. > That was probably the reason why you agreed to limit the scope of the > document (which you didn't later do) to get folks to agree to make it a WG > item. > > Btw, I not disagreeing with the document as such. I just want to the scope > to change. The usage of RPH within the emergency services network is fine > for me. I may get convinced to start the RPH marking from the the VSP > towards the PSAP. I feel uneasy about the end host doing the marking. I > don't see advantages -- only disadvantages. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C88C28C135 for ; Wed, 4 Feb 2009 12:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM-ONTDsNUlU for ; Wed, 4 Feb 2009 12:53:46 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EC43E3A68F7 for ; Wed, 4 Feb 2009 12:53:45 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2009 20:53:20 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 04 Feb 2009 21:53:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18FcVhVH1UFHduY+qK9qDiSLqm47jHqEmEpLWibi9 tmmxGDukY0xO6O From: "Hannes Tschofenig" To: "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> <3D3C75174CB95F42AD6BCC56E5555B45FFFC06@FIESEXC015.nsn-intra.net> Date: Wed, 4 Feb 2009 22:54:06 +0200 Message-ID: <001201c9870a$b8a5b4e0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmG8lfM1bBVYdCVRlWREfv2a0OCRgAEpIAg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:53:47 -0000 Hi James, I was thinking of 2 hours, see http://www.ietf.org/mail-archive/web/ecrit/current/msg05849.html Based on the experience from working group meetings I believe that most items can be covered fairly quickly. In case we can come up with some action items during the meeting to move our documents along then our mission is accomplished. Ciao Hannes >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: 04 February, 2009 20:00 >To: Tschofenig, Hannes (NSN - FI/Espoo); ext Hannes Tschofenig; ECRIT >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (timing?) > >Hannes > >This would be considered a full agenda for a f2f meeting. How >long do you expect this call to last? > >James > >At 06:07 AM 2/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>This is the agenda proposal for the meeting: >> >>* draft-ietf-ecrit-phonebcp and draft-ietf-ecrit-framework >> >>Only if there are substantial comments received during WGLC that >>require a discussion. >>Brian will do the job. >> >>* draft-ietf-ecrit-lost-sync >> >>Recently Roger and Richard provided their document reviews. >We discuss >>their reviews. >>Henning or Hannes will be the discussion lead. >> >>* draft-ietf-ecrit-local-emergency-rph-namespace >> >>This document received a lot of feedback. We should start our >>discussion with the where the marking should happen along the e2e >>chain. James is going to lead this discussion. >> >>* draft-barnes-ecrit-rough-loc >> >>Richard will lead us through this document and tell us what the >>necessary steps are to complete it. >> >>* draft-patel-ecrit-sos-parameter >> >>Milan will tell us what the open issues with this document are. >> >>* draft-rosen-ecrit-premature-disconnect-rqmts >> >>Brian will inform us about the recent draft update and we will chat >>whether this version can be picked up as a WG item. >> >>* RFC5031bis and draft-forte-ecrit-lost-extensions >> >>Henning or Andrea will brief us about the plans to update the Service >>URN RFC and how to then deal with the extensions that have been >>proposed to the group. >> >>* draft-wolf-ecrit-lost-servicelistboundary >> >>Karl Heinz wanted to give a presentation about this draft at the last >>IETF meeting but we ran out of time. Let's try it again. >> >>* draft-schulzrinne-ecrit-unauthenticated-access >> >>Finally, we should chat about how we should proceed with the >>unauthenticated emergency calls document. >> >>Ciao >>Hannes >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A623A6B1C for ; Wed, 4 Feb 2009 12:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzmU1P0m9GW8 for ; Wed, 4 Feb 2009 12:56:21 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E9CA63A68F7 for ; Wed, 4 Feb 2009 12:56:20 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2009 20:56:00 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp022) with SMTP; 04 Feb 2009 21:56:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+b924UP0abaxVLjfUrtJ29ggr5xfuuZMZzdSZV96 etJeP7fb/vFcHp From: "Hannes Tschofenig" To: "'Marc Linsner'" , "'James Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> Date: Wed, 4 Feb 2009 22:56:46 +0200 Message-ID: <001301c9870b$17dfe930$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+wAABz8h8AAHUmgA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:56:22 -0000 I only don't want to let the end host todo the marking. >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com] >Sent: 04 February, 2009 22:42 >To: Hannes Tschofenig; James Polk; Tschofenig, Hannes (NSN - >FI/Espoo); 'ECRIT' >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > >Hannes, > >I'm curious. Are you against the RPH in general, or just this >namespace? > >-Marc- > > >On 2/4/09 3:37 PM, "Hannes Tschofenig" > wrote: > >>> James wrote: >>>> you are the _lone_ voice not supporting this ID, >> >> Listening to the audio recording of past meetings I have to >say that I >> was not the only persons raising concerns about the document. >> That was probably the reason why you agreed to limit the >scope of the >> document (which you didn't later do) to get folks to agree >to make it >> a WG item. >> >> Btw, I not disagreeing with the document as such. I just want to the >> scope to change. The usage of RPH within the emergency services >> network is fine for me. I may get convinced to start the RPH marking >> from the the VSP towards the PSAP. I feel uneasy about the end host >> doing the marking. I don't see advantages -- only disadvantages. >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC8A3A6B53 for ; Wed, 4 Feb 2009 13:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEFgZKHHLhgm for ; Wed, 4 Feb 2009 13:00:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 163C53A6B4F for ; Wed, 4 Feb 2009 13:00:52 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2009 21:00:32 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp043) with SMTP; 04 Feb 2009 22:00:32 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18zBaI/j8Yz8Ur3wzND3sujECbHFSQujUu8Gj+eD4 qPhAIgZ7lIQZsY From: "Hannes Tschofenig" To: "'ECRIT'" Date: Wed, 4 Feb 2009 23:01:18 +0200 Message-ID: <001401c9870b$ba0bdf20$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmHC7lzdgVRu4QcQuuHFBkg/a8uOA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: [Ecrit] ECRIT Virtual Interim Meeting: Conference Bridge X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 21:00:54 -0000 Marc kindly offered his Webex conference bridge for the meeting. I have copied the info to the ECRIT Wiki: http://trac.tools.ietf.org/wg/ecrit/trac/wiki Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D79728C12A for ; Wed, 4 Feb 2009 13:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjEZT7SKVnRS for ; Wed, 4 Feb 2009 13:01:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0EE9628C11F for ; Wed, 4 Feb 2009 13:01:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,381,1231113600"; d="scan'208";a="128731724" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2009 21:01:02 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14L12LR014311; Wed, 4 Feb 2009 13:01:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n14L12fC025857; Wed, 4 Feb 2009 21:01: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); Wed, 4 Feb 2009 13:01:02 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 13:01:01 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Feb 2009 15:01:00 -0600 To: "Hannes Tschofenig" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2009 21:01:01.0994 (UTC) FILETIME=[AFC2D0A0:01C9870B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2882; t=1233781262; x=1234645262; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Int erim=20Meeting=3A=20Agenda=20(my=20=0A=20=20mistake) |Sender:=20; bh=VR3m7h6uahgQ8WPCvQotUZYZIEw7d6xiOS8I1SSVLII=; b=b2pB0MAkEywWdRn8UFvXE7nVjC1h3WZADzCagoFOIQQwmU+r3nr/AdC9nx irunK/ToTr1JAA36K9AToiPXwHK2S0kIcS5v4SM6pIYCau+KHRqJvsNyyyLW eEvZ8KSQiLltnr6bN3b8UKXM+dqrlPuQKOAAKakwho99RNNGGyJ/Y=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 21:01:23 -0000 At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > > James wrote: > >> you are the _lone_ voice not supporting this ID, > >Listening to the audio recording of past meetings I have to say that I was >not the only persons raising concerns about the document. >That was probably the reason why you agreed to limit the scope of the >document (which you didn't later do) to get folks to agree to make it a WG >item. re-listen to the audio please Ted's concerns were consistent with most (all?) other concerns -- which were based on the premise of whether or not the UAC should be trusted to initiate the marking on the INVITE. The most recent version has backed off this to a "can" -- meaning not prohibited (i.e., no 2119 text). I also backed off the text in the SP domain part to "can", such that there is no 2119 text mandating or even recommending its usage there. I also do not prohibit its use, based on local policy. Keith has come forward with the specific request that non-ESInet networks be allowed to mark and pay attention to this priority indication -- with IMS as the specific example he wishes to have this valid for. Where there is no disagreement, save for your recent pushback - is in the ESInet, which is where Brian has requested it's definition in the IETF on behalf of NENA. He's the i3 WG chair within NENA, and if he asks for it, are you going to say you know better than he? >Btw, I not disagreeing with the document as such. I just want to the scope >to change. The usage of RPH within the emergency services network is fine >for me. I may get convinced to start the RPH marking from the the VSP >towards the PSAP. I feel uneasy about the end host doing the marking. please read what I wrote above, and then re-read the most recent version of the ID. I don't have endpoints that SHOULD or MUST mark anything wrt RPH. I also don't want to prohibit it, because there might be cases (that I don't know of) of valid uses under certain circumstances. Figure 1 is very clear that there are 3 networking parts to consider #1 - from the endpoint #2 - within the VSP #3 - within the ESInet the most recent ID version has "can" for #s 1 and 2, and 2119 language offering those supporting this specification will have RPH adherence within #3 (the ESInet). What other scope changes do you want, because I haven't heard them. I only heard you claim in email during the last IETF and in the ECRIT session that RPH should not be used for priority marking requests. This is something Keith (SIP WG chair) voiced his opposition to your views regarding creating a second means for SIP to priority mark request "when SIP already has one interoperable way to accomplish this... it's call the RP header mechanism". >I don't see advantages -- only disadvantages. > >Ciao >Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9BA3A694E for ; Wed, 4 Feb 2009 13:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJk4ARAREcHg for ; Wed, 4 Feb 2009 13:49:18 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E6B3E28C16B for ; Wed, 4 Feb 2009 13:49:17 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2009 21:48:55 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp005) with SMTP; 04 Feb 2009 22:48:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Km9k7Eq8KA1rUG7OH6KSgUAvHJzdXrrLJN/SQfF aDlcYatLgV/JDm From: "Hannes Tschofenig" To: "'ECRIT'" Date: Wed, 4 Feb 2009 23:49:41 +0200 Message-ID: <001501c98712$7c5c13a0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmHEnt+EwoFhfoQTzmAmtEnXhladQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: DISCUSS by Cullen X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 21:49:19 -0000 Cullen recently issued a DISCUSS against draft-ietf-ecrit-mapping-arch, see https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/comment /90923/ " [IESG Evaluation DISCUSS] When this document was written, LOST only did points for geo locations so the text For the former, the LoST server performs a point- in-polygon operation to find the polygon that contains the query point. (More complicated geometric matching algorithms may be added in the future.) Since then LOST was changed to support a wider range of shape. You need to update this and explain what happens when the location shape overlaps two regions. My suggestion would be to say to return both in the overlap case or say it is server defined what happens. But one way or another, it seems like this needs to be addressed. Jon and I would both very much like to have this addressed Real Soon Now so I would greatly appreciate if this could land in the priory pile. I imagine we are only talking about a few sentence that need to be written. " Cullen is right that this issue has to be addressed. The current text in the draft has to be changed from " Coverage regions are described by sets of polygons enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs a point- in-polygon operation to find the polygon that contains the query point. (More complicated geometric matching algorithms may be added in the future.) " To: " Coverage regions are described by sets of LoST-compatible shapes enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs the same matching operation as described in Section 12.2 of the LoST specification [RFC5222]. " Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5974B3A6A3A for ; Wed, 4 Feb 2009 14:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0slJqTIFNo0W for ; Wed, 4 Feb 2009 14:03:52 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 68C193A68D7 for ; Wed, 4 Feb 2009 14:03:52 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LUpq4-0003vj-Ke; Wed, 04 Feb 2009 16:03:20 -0600 From: "Brian Rosen" To: "'James M. Polk'" , "'Hannes Tschofenig'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> In-Reply-To: Date: Wed, 4 Feb 2009 17:03:28 -0500 Message-ID: <09fe01c98714$6acc7650$406562f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIw Content-Language: en-us 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: Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:03:53 -0000 Hannes This matches my understanding precisely. We wish to permit endpoints to mark. We do not require it, and don't necessarily expect it in many (even most) cases. We don't wish to see the document prohibit it. We all seem to agree it has value within the Emergency Services IP Networks. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of James M. Polk > Sent: Wednesday, February 04, 2009 4:01 PM > To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > > At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > > > James wrote: > > >> you are the _lone_ voice not supporting this ID, > > > >Listening to the audio recording of past meetings I have to say that I > was > >not the only persons raising concerns about the document. > >That was probably the reason why you agreed to limit the scope of the > >document (which you didn't later do) to get folks to agree to make it > a WG > >item. > > re-listen to the audio please > > Ted's concerns were consistent with most (all?) other concerns -- > which were based on the premise of whether or not the UAC should be > trusted to initiate the marking on the INVITE. The most recent > version has backed off this to a "can" -- meaning not prohibited > (i.e., no 2119 text). I also backed off the text in the SP domain > part to "can", such that there is no 2119 text mandating or even > recommending its usage there. I also do not prohibit its use, based > on local policy. Keith has come forward with the specific request > that non-ESInet networks be allowed to mark and pay attention to this > priority indication -- with IMS as the specific example he wishes to > have this valid for. > > Where there is no disagreement, save for your recent pushback - is in > the ESInet, which is where Brian has requested it's definition in the > IETF on behalf of NENA. He's the i3 WG chair within NENA, and if he > asks for it, are you going to say you know better than he? > > > >Btw, I not disagreeing with the document as such. I just want to the > scope > >to change. The usage of RPH within the emergency services network is > fine > >for me. I may get convinced to start the RPH marking from the the VSP > >towards the PSAP. I feel uneasy about the end host doing the marking. > > please read what I wrote above, and then re-read the most recent > version of the ID. I don't have endpoints that SHOULD or MUST mark > anything wrt RPH. I also don't want to prohibit it, because there > might be cases (that I don't know of) of valid uses under certain > circumstances. Figure 1 is very clear that there are 3 networking > parts to consider > > #1 - from the endpoint > #2 - within the VSP > #3 - within the ESInet > > the most recent ID version has "can" for #s 1 and 2, and 2119 > language offering those supporting this specification will have RPH > adherence within #3 (the ESInet). > > What other scope changes do you want, because I haven't heard them. > > I only heard you claim in email during the last IETF and in the ECRIT > session that RPH should not be used for priority marking > requests. This is something Keith (SIP WG chair) voiced his > opposition to your views regarding creating a second means for SIP to > priority mark request "when SIP already has one interoperable way to > accomplish this... it's call the RP header mechanism". > > >I don't see advantages -- only disadvantages. > > > >Ciao > >Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CF63A6A3A for ; Wed, 4 Feb 2009 14:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOH5PbaQdxvx for ; Wed, 4 Feb 2009 14:08:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A26153A68D7 for ; Wed, 4 Feb 2009 14:08:51 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2009 22:08:31 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp016) with SMTP; 04 Feb 2009 23:08:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+lbFUrio6lRMBeKF+tz+HN/N6ex7MVxl0FlzkX5K Eupo+pypXd1wbX From: "Hannes Tschofenig" To: "'Brian Rosen'" , "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> Date: Thu, 5 Feb 2009 00:09:16 +0200 Message-ID: <001c01c98715$3900b360$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeA= In-Reply-To: <09fe01c98714$6acc7650$406562f0$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:08:53 -0000 I don't even see the value in permitting the endpoint todo the RPH marking. In addition to the security concerns there is also the problem that there are more options to implement without an additional value. >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: 05 February, 2009 00:03 >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes >(NSN - FI/Espoo)'; 'ECRIT' >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > >Hannes > >This matches my understanding precisely. We wish to permit >endpoints to mark. We do not require it, and don't necessarily >expect it in many (even >most) cases. We don't wish to see the document prohibit it. >We all seem to agree it has value within the Emergency >Services IP Networks. > >Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of James M. Polk >> Sent: Wednesday, February 04, 2009 4:01 PM >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> mistake) >> >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >> > > James wrote: >> > >> you are the _lone_ voice not supporting this ID, >> > >> >Listening to the audio recording of past meetings I have to >say that >> >I >> was >> >not the only persons raising concerns about the document. >> >That was probably the reason why you agreed to limit the >scope of the >> >document (which you didn't later do) to get folks to agree >to make it >> a WG >> >item. >> >> re-listen to the audio please >> >> Ted's concerns were consistent with most (all?) other concerns -- >> which were based on the premise of whether or not the UAC should be >> trusted to initiate the marking on the INVITE. The most recent >> version has backed off this to a "can" -- meaning not prohibited >> (i.e., no 2119 text). I also backed off the text in the SP domain >> part to "can", such that there is no 2119 text mandating or even >> recommending its usage there. I also do not prohibit its >use, based on >> local policy. Keith has come forward with the specific request that >> non-ESInet networks be allowed to mark and pay attention to this >> priority indication -- with IMS as the specific example he wishes to >> have this valid for. >> >> Where there is no disagreement, save for your recent >pushback - is in >> the ESInet, which is where Brian has requested it's >definition in the >> IETF on behalf of NENA. He's the i3 WG chair within NENA, and if he >> asks for it, are you going to say you know better than he? >> >> >> >Btw, I not disagreeing with the document as such. I just want to the >> scope >> >to change. The usage of RPH within the emergency services network is >> fine >> >for me. I may get convinced to start the RPH marking from >the the VSP >> >towards the PSAP. I feel uneasy about the end host doing >the marking. >> >> please read what I wrote above, and then re-read the most recent >> version of the ID. I don't have endpoints that SHOULD or MUST mark >> anything wrt RPH. I also don't want to prohibit it, because there >> might be cases (that I don't know of) of valid uses under certain >> circumstances. Figure 1 is very clear that there are 3 networking >> parts to consider >> >> #1 - from the endpoint >> #2 - within the VSP >> #3 - within the ESInet >> >> the most recent ID version has "can" for #s 1 and 2, and >2119 language >> offering those supporting this specification will have RPH adherence >> within #3 (the ESInet). >> >> What other scope changes do you want, because I haven't heard them. >> >> I only heard you claim in email during the last IETF and in >the ECRIT >> session that RPH should not be used for priority marking requests. >> This is something Keith (SIP WG chair) voiced his opposition to your >> views regarding creating a second means for SIP to priority mark >> request "when SIP already has one interoperable way to accomplish >> this... it's call the RP header mechanism". >> >> >I don't see advantages -- only disadvantages. >> > >> >Ciao >> >Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82073A6B6E for ; Wed, 4 Feb 2009 14:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcrIuOAJK68r for ; Wed, 4 Feb 2009 14:11:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 346CC3A6A3A for ; Wed, 4 Feb 2009 14:11:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,381,1231113600"; d="scan'208";a="35980181" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2009 22:10:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n14MAVY9005636; Wed, 4 Feb 2009 17:10:31 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n14MAVf5011579; Wed, 4 Feb 2009 22:10:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 17:10:31 -0500 Received: from [10.116.195.119] ([10.116.195.119]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Feb 2009 17:10:06 -0500 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 04 Feb 2009 17:10:04 -0500 From: Marc Linsner To: Hannes Tschofenig , James Polk , "Tschofenig, Hannes (NSN - FI/Espoo)" , "'ECRIT'" Message-ID: Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) Thread-Index: AcmG8jShcSXkM0tcS9mgKe5GPc11ywAFPa+wAABz8h8AAHUmgAACoTYl In-Reply-To: <001301c9870b$17dfe930$0201a8c0@nsnintra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Feb 2009 22:10:06.0225 (UTC) FILETIME=[55EA4810:01C98715] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1655; t=1233785431; x=1234649431; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20Virtual=20Interim=20M eeting=3A=20Agenda=20(my=20=20mistake) |Sender:=20 |To:=20Hannes=20Tschofenig=20,=0 A=20=20=20=20=20=20=20=20James=20Polk=20,= 0A=20=20=20=20=20=20=20=20=22Tschofenig,=20Hannes=20(NSN=20- =20FI/Espoo)=22=20,=0A=20=20=20=2 0=20=20=20=20=22'ECRIT'=22=20; bh=nQ3C0pTpF3BdC49xE5Xw9VfIfMQukVxVZDZR2d+VafA=; b=BunVUIsokbfovcJOEtgrtAdPLSewpKibIvOKd1HcQ2pjigefDmQq+TlGSg xh6OmR0p40c32w8BqpWEUFbF5rknQCNJS8H5YcIlFpXMBD533mgSkRs3ExtK RCUCALaEkQ; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:11:07 -0000 Hannes, What if there is no proxy? -Marc- On 2/4/09 3:56 PM, "Hannes Tschofenig" wrote: > I only don't want to let the end host todo the marking. > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: 04 February, 2009 22:42 >> To: Hannes Tschofenig; James Polk; Tschofenig, Hannes (NSN - >> FI/Espoo); 'ECRIT' >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) >> >> Hannes, >> >> I'm curious. Are you against the RPH in general, or just this >> namespace? >> >> -Marc- >> >> >> On 2/4/09 3:37 PM, "Hannes Tschofenig" >> wrote: >> >>>> James wrote: >>>>> you are the _lone_ voice not supporting this ID, >>> >>> Listening to the audio recording of past meetings I have to >> say that I >>> was not the only persons raising concerns about the document. >>> That was probably the reason why you agreed to limit the >> scope of the >>> document (which you didn't later do) to get folks to agree >> to make it >>> a WG item. >>> >>> Btw, I not disagreeing with the document as such. I just want to the >>> scope to change. The usage of RPH within the emergency services >>> network is fine for me. I may get convinced to start the RPH marking >>> from the the VSP towards the PSAP. I feel uneasy about the end host >>> doing the marking. I don't see advantages -- only disadvantages. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4243A685A for ; Wed, 4 Feb 2009 14:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK7-NlPD8Txp for ; Wed, 4 Feb 2009 14:19:15 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 460FD3A6934 for ; Wed, 4 Feb 2009 14:19:15 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LUq4x-0004uc-EF; Wed, 04 Feb 2009 16:18:43 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'James M. Polk'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> In-Reply-To: <001c01c98715$3900b360$0201a8c0@nsnintra.net> Date: Wed, 4 Feb 2009 17:18:51 -0500 Message-ID: <0a1101c98716$91287db0$b3797910$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kA== Content-Language: en-us 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: Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:19:16 -0000 The value is that in some networks where priority for emergency calls is appropriate, and appropriate policing of marking is implemented, emergency calls will receive resource priority. Not all networks would need policing. Some will. Policing could be to Route header/R-URI content, but other criteria are possible. Not all networks will need resource priority for emergency calls. Fine, ignore this marking/namespace. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, February 04, 2009 5:09 PM > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - > FI/Espoo); 'ECRIT' > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > > I don't even see the value in permitting the endpoint todo the RPH > marking. > In addition to the security concerns there is also the problem that > there > are more options to implement without an additional value. > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: 05 February, 2009 00:03 > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes > >(NSN - FI/Espoo)'; 'ECRIT' > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > mistake) > > > >Hannes > > > >This matches my understanding precisely. We wish to permit > >endpoints to mark. We do not require it, and don't necessarily > >expect it in many (even > >most) cases. We don't wish to see the document prohibit it. > >We all seem to agree it has value within the Emergency > >Services IP Networks. > > > >Brian > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of James M. Polk > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> mistake) > >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> > > James wrote: > >> > >> you are the _lone_ voice not supporting this ID, > >> > > >> >Listening to the audio recording of past meetings I have to > >say that > >> >I > >> was > >> >not the only persons raising concerns about the document. > >> >That was probably the reason why you agreed to limit the > >scope of the > >> >document (which you didn't later do) to get folks to agree > >to make it > >> a WG > >> >item. > >> > >> re-listen to the audio please > >> > >> Ted's concerns were consistent with most (all?) other concerns -- > >> which were based on the premise of whether or not the UAC should be > >> trusted to initiate the marking on the INVITE. The most recent > >> version has backed off this to a "can" -- meaning not prohibited > >> (i.e., no 2119 text). I also backed off the text in the SP domain > >> part to "can", such that there is no 2119 text mandating or even > >> recommending its usage there. I also do not prohibit its > >use, based on > >> local policy. Keith has come forward with the specific request that > >> non-ESInet networks be allowed to mark and pay attention to this > >> priority indication -- with IMS as the specific example he wishes to > >> have this valid for. > >> > >> Where there is no disagreement, save for your recent > >pushback - is in > >> the ESInet, which is where Brian has requested it's > >definition in the > >> IETF on behalf of NENA. He's the i3 WG chair within NENA, and if he > >> asks for it, are you going to say you know better than he? > >> > >> > >> >Btw, I not disagreeing with the document as such. I just want to > the > >> scope > >> >to change. The usage of RPH within the emergency services network > is > >> fine > >> >for me. I may get convinced to start the RPH marking from > >the the VSP > >> >towards the PSAP. I feel uneasy about the end host doing > >the marking. > >> > >> please read what I wrote above, and then re-read the most recent > >> version of the ID. I don't have endpoints that SHOULD or MUST mark > >> anything wrt RPH. I also don't want to prohibit it, because there > >> might be cases (that I don't know of) of valid uses under certain > >> circumstances. Figure 1 is very clear that there are 3 networking > >> parts to consider > >> > >> #1 - from the endpoint > >> #2 - within the VSP > >> #3 - within the ESInet > >> > >> the most recent ID version has "can" for #s 1 and 2, and > >2119 language > >> offering those supporting this specification will have RPH adherence > >> within #3 (the ESInet). > >> > >> What other scope changes do you want, because I haven't heard them. > >> > >> I only heard you claim in email during the last IETF and in > >the ECRIT > >> session that RPH should not be used for priority marking requests. > >> This is something Keith (SIP WG chair) voiced his opposition to your > >> views regarding creating a second means for SIP to priority mark > >> request "when SIP already has one interoperable way to accomplish > >> this... it's call the RP header mechanism". > >> > >> >I don't see advantages -- only disadvantages. > >> > > >> >Ciao > >> >Hannes > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507813A685E; Wed, 4 Feb 2009 14:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ewihXzXWasH; Wed, 4 Feb 2009 14:37:40 -0800 (PST) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id A90B53A67E4; Wed, 4 Feb 2009 14:37:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-171.messagelabs.com!1233787035!22357708!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 5871 invoked from network); 4 Feb 2009 22:37:18 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 4 Feb 2009 22:37:18 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n14MbENQ000666; Wed, 4 Feb 2009 17:37:18 -0500 In-Reply-To: <001c01c98715$3900b360$0201a8c0@nsnintra.net> To: "Hannes Tschofenig" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Wed, 4 Feb 2009 17:37:17 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/04/2009 05:39:40 PM, Serialize complete at 02/04/2009 05:39:40 PM Content-Type: multipart/alternative; boundary="=_alternative 007C40DC85257553_=" Cc: ecrit-bounces@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:37:44 -0000 This is a multipart message in MIME format. --=_alternative 007C40DC85257553_= Content-Type: text/plain; charset="US-ASCII" If you do not permit the endpoint to mark with RPH, then it is very difficult to give the INVITE any kind of priority on the first "hop". In each case, this needs to be balanced against the (quite significant) issues with letting the endpoint mark with RPH. But it SHOULD NOT be prohibited. Janet ecrit-bounces@ietf.org wrote on 02/04/2009 05:09:16 PM: > I don't even see the value in permitting the endpoint todo the RPH marking. > In addition to the security concerns there is also the problem that there > are more options to implement without an additional value. > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: 05 February, 2009 00:03 > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes > >(NSN - FI/Espoo)'; 'ECRIT' > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > > > >Hannes > > > >This matches my understanding precisely. We wish to permit > >endpoints to mark. We do not require it, and don't necessarily > >expect it in many (even > >most) cases. We don't wish to see the document prohibit it. > >We all seem to agree it has value within the Emergency > >Services IP Networks. > > > >Brian > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of James M. Polk > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> mistake) > >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> > > James wrote: > >> > >> you are the _lone_ voice not supporting this ID, > >> > > >> >Listening to the audio recording of past meetings I have to > >say that > >> >I > >> was > >> >not the only persons raising concerns about the document. > >> >That was probably the reason why you agreed to limit the > >scope of the > >> >document (which you didn't later do) to get folks to agree > >to make it > >> a WG > >> >item. > >> > >> re-listen to the audio please > >> > >> Ted's concerns were consistent with most (all?) other concerns -- > >> which were based on the premise of whether or not the UAC should be > >> trusted to initiate the marking on the INVITE. The most recent > >> version has backed off this to a "can" -- meaning not prohibited > >> (i.e., no 2119 text). I also backed off the text in the SP domain > >> part to "can", such that there is no 2119 text mandating or even > >> recommending its usage there. I also do not prohibit its > >use, based on > >> local policy. Keith has come forward with the specific request that > >> non-ESInet networks be allowed to mark and pay attention to this > >> priority indication -- with IMS as the specific example he wishes to > >> have this valid for. > >> > >> Where there is no disagreement, save for your recent > >pushback - is in > >> the ESInet, which is where Brian has requested it's > >definition in the > >> IETF on behalf of NENA. He's the i3 WG chair within NENA, and if he > >> asks for it, are you going to say you know better than he? > >> > >> > >> >Btw, I not disagreeing with the document as such. I just want to the > >> scope > >> >to change. The usage of RPH within the emergency services network is > >> fine > >> >for me. I may get convinced to start the RPH marking from > >the the VSP > >> >towards the PSAP. I feel uneasy about the end host doing > >the marking. > >> > >> please read what I wrote above, and then re-read the most recent > >> version of the ID. I don't have endpoints that SHOULD or MUST mark > >> anything wrt RPH. I also don't want to prohibit it, because there > >> might be cases (that I don't know of) of valid uses under certain > >> circumstances. Figure 1 is very clear that there are 3 networking > >> parts to consider > >> > >> #1 - from the endpoint > >> #2 - within the VSP > >> #3 - within the ESInet > >> > >> the most recent ID version has "can" for #s 1 and 2, and > >2119 language > >> offering those supporting this specification will have RPH adherence > >> within #3 (the ESInet). > >> > >> What other scope changes do you want, because I haven't heard them. > >> > >> I only heard you claim in email during the last IETF and in > >the ECRIT > >> session that RPH should not be used for priority marking requests. > >> This is something Keith (SIP WG chair) voiced his opposition to your > >> views regarding creating a second means for SIP to priority mark > >> request "when SIP already has one interoperable way to accomplish > >> this... it's call the RP header mechanism". > >> > >> >I don't see advantages -- only disadvantages. > >> > > >> >Ciao > >> >Hannes > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 007C40DC85257553_= Content-Type: text/html; charset="US-ASCII"

If you do not permit the endpoint to mark with RPH, then it is very difficult to give the INVITE any kind of priority on the first "hop".

In each case, this needs to be balanced against the (quite significant) issues with letting the endpoint mark with RPH.  But it SHOULD NOT be prohibited.

Janet

ecrit-bounces@ietf.org wrote on 02/04/2009 05:09:16 PM:

> I don't even see the value in permitting the endpoint todo the RPH marking.
> In addition to the security concerns there is also the problem that there
> are more options to implement without an additional value.  
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:br@brianrosen.net]
> >Sent: 05 February, 2009 00:03
> >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, Hannes
> >(NSN - FI/Espoo)'; 'ECRIT'
> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake)
> >
> >Hannes
> >
> >This matches my understanding precisely.  We wish to permit
> >endpoints to mark. We do not require it, and don't necessarily
> >expect it in many (even
> >most) cases.  We don't wish to see the document prohibit it.  
> >We all seem to agree it has value within the Emergency
> >Services IP Networks.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> >On Behalf
> >> Of James M. Polk
> >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> mistake)
> >>
> >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> > > James wrote:
> >> > >> you are the _lone_ voice not supporting this ID,
> >> >
> >> >Listening to the audio recording of past meetings I have to
> >say that
> >> >I
> >> was
> >> >not the only persons raising concerns about the document.
> >> >That was probably the reason why you agreed to limit the
> >scope of the
> >> >document (which you didn't later do) to get folks to agree
> >to make it
> >> a WG
> >> >item.
> >>
> >> re-listen to the audio please
> >>
> >> Ted's concerns were consistent with most (all?) other concerns --
> >> which were based on the premise of whether or not the UAC should be
> >> trusted to initiate the marking on the INVITE.  The most recent
> >> version has backed off this to a "can" -- meaning not prohibited
> >> (i.e., no 2119 text).  I also backed off the text in the SP domain
> >> part to "can", such that there is no 2119 text mandating or even
> >> recommending its usage there. I also do not prohibit its
> >use, based on
> >> local policy.  Keith has come forward with the specific request that
> >> non-ESInet networks be allowed to mark and pay attention to this
> >> priority indication -- with IMS as the specific example he wishes to
> >> have this valid for.
> >>
> >> Where there is no disagreement, save for your recent
> >pushback - is in
> >> the ESInet, which is where Brian has requested it's
> >definition in the
> >> IETF on behalf of NENA.  He's the i3 WG chair within NENA, and if he
> >> asks for it, are you going to say you know better than he?
> >>
> >>
> >> >Btw, I not disagreeing with the document as such. I just want to the
> >> scope
> >> >to change. The usage of RPH within the emergency services network is
> >> fine
> >> >for me. I may get convinced to start the RPH marking from
> >the the VSP
> >> >towards the PSAP. I feel uneasy about the end host doing
> >the marking.
> >>
> >> please read what I wrote above, and then re-read the most recent
> >> version of the ID. I don't have endpoints that SHOULD or MUST mark
> >> anything wrt RPH.  I also don't want to prohibit it, because there
> >> might be cases (that I don't know of) of valid uses under certain
> >> circumstances.  Figure 1 is very clear that there are 3 networking
> >> parts to consider
> >>
> >> #1 - from the endpoint
> >> #2 - within the VSP
> >> #3 - within the ESInet
> >>
> >> the most recent ID version has "can" for #s 1 and 2, and
> >2119 language
> >> offering those supporting this specification will have RPH adherence
> >> within #3 (the ESInet).
> >>
> >> What other scope changes do you want, because I haven't heard them.
> >>
> >> I only heard you claim in email during the last IETF and in
> >the ECRIT
> >> session that RPH should not be used for priority marking requests.  
> >> This is something Keith (SIP WG chair) voiced his opposition to your
> >> views regarding creating a second means for SIP to priority mark
> >> request "when SIP already has one interoperable way to accomplish
> >> this... it's call the RP header mechanism".
> >>
> >> >I don't see advantages -- only disadvantages.
> >> >
> >> >Ciao
> >> >Hannes
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
 --=_alternative 007C40DC85257553_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008EB3A6972 for ; Wed, 4 Feb 2009 23:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoNfRy8sGXOX for ; Wed, 4 Feb 2009 23:49:53 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B9BAD3A686A for ; Wed, 4 Feb 2009 23:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1233820174; x=1265356174; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" 'ECRIT'"=20|Date:=20Wed,=204=20Feb=202009 =2023:49:30=20-0800|Subject:=20Comments=20on=20Framework =20Draft|Thread-Topic:=20Comments=20on=20Framework=20Draf t|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXw=3D=3D |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5516"=3B=20a=3D"15241325"; bh=CGsYapsln3Kc2JFLopa1S4fS0/tQHuytlxn5GQoF9u4=; b=F1sQgicdNRAVQBTJqYCgJjl0SiarzCnS9bJQjvJ3LxCTFwHq+F0ET3jk DscD4eMnnYUyOFM/gmKZ53OsbCLsSg9+5Xmxek/UfkOUNXKIcwJeRvlEh WoVADOhdgQc+UuoKu2FP50TBJ26GhtOqQRrKCZjbdpsFEglQxCeL2q1Wi I=; X-IronPort-AV: E=McAfee;i="5300,2777,5516"; a="15241325" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2009 23:49:34 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n157nXbn010900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Feb 2009 23:49:33 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n157nX7r018684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 4 Feb 2009 23:49:33 -0800 (PST) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Wed, 4 Feb 2009 23:49:33 -0800 From: "Edge, Stephen" To: "'ECRIT'" Date: Wed, 4 Feb 2009 23:49:30 -0800 Thread-Topic: Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXw== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 07:49:55 -0000 All =A0 draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative descri= ption of how terminals and networks should support emergency calls made ove= r IP capable facilities to IP capable PSAPs. It appears intended to cover a= ll types of access network - including fixed line, WiFi and cellular (e.g. = examples involving each can be found throughout the draft). =A0 When we evaluated this with respect to support of wireless cellular access = and WiFi access associated with a cellular operator (e.g. WLAN or Femto cel= ls integrated into a cellular network), we found that certain portions of t= he draft exhibited one or more of the following characteristics: =A0 =A0=A0=A0 (A) Inconsistent with already standardized wireless solutions =A0 =A0=A0=A0 (B) Inconsistent with essential wireless requirements and convent= ions =A0 =A0=A0=A0 (C) Already part of wireless standards or potentially part of fut= ure standards =A0 (A) refers to all portions of the draft framework that differ from the requ= irements and procedures currently standardized for wireless emergency acces= s by 3GPP, 3GPP2 and OMA. This is a plain difference of solution and could = be resolved through support of both solutions by terminals (with each solut= ion being used according to the type of access network and VSP) or could be= resolved by supporting only one solution and accessing only the types of n= etwork supporting that solution. To acknowledge this category, the framewor= k document could reference the applicable wireless standards and point out = that these are valid alternatives for wireless cellular based access. =A0 (B) refers to portions of the draft that would be unsuitable for wireless n= etworks even if no alternative solution existed together with other portion= s missing from the draft that would be needed to fully support wireless net= works. Examples of the former include: (a) emphasis on endpoint derivation = of location, performance of Lost query and receipt of local dial strings; (= b) restriction of LCPs to protocols that require terminal initiation (not a= llowing for network initiation as far as we can tell) and that include two = LCPs (DHCP and LLDP) that are not applicable to (not defined for) cellular = access; and (c) the requirement that a terminal or at least a LIS will upda= te the PSAP whenever location changes. (a) is impractical due to network an= d terminal loading consequences and failure to support non-IP capable PSAPs= ; (b) makes location verification and updated location provision to PSAPs d= ifficult or impossible; while (c) is also incompatible with support of exis= ting non-IP capable PSAPs besides increasing terminal load and possibly int= erfering with optimum maintenance of the RF connection (e.g. if a terminal = has to tune away from the serving base station or WLAN periodically to make= location measurements). Examples of the latter include (d) absence of supp= ort for access to non-IP capable PSAPs as already mentioned (e.g. to suppor= t E911 phase 2 in the US); (e) no support for handover from the IP to the c= ircuit domain when a terminal loses (e.g. moves out of) RF coverage in the = IP domain; and (f) no allowance for limited access modes wherein a terminal= may access a network only to place an emergency call with ensuing restrict= ions on (for example) location acquisition, PSAP callback and caller verifi= cation and identification to the PSAP. To resolve this category either sign= ificant changes to the framework document could be made or a disclaimer/app= licability statement could be added stating that support of cellular wirele= ss networks and their associated WLAN and Femto access points is not covere= d. =A0 Category (C) comprises concepts and capabilities in the draft that are eith= er already part of the standardized solution for wireless networks or that = might be added at a later time. Examples of the former include LoST, SIP lo= cation conveyance, general use of SIP, location for routing versus for disp= atch, cellular positioning methods. Examples of the latter include use of l= ocation references and dereferencing and possible interworking between the = current wireless network solutions (in 3GPP, 3GPP2 and OMA) and the solutio= n described in this draft. The presence of this category could be acknowled= ged by following the disclaimer for (B) with a statement that certain porti= ons of the solution are expected to be incorporated into wireless networks = now and/or in the future. =A0 We hope that these comments will be seen to be a useful addition to this re= view in the sense of enabling a more precise scoping for the framework docu= ment and we are willing to assist in providing wording for any disclaimer/a= pplicability statement that the Ecrit working group may now deem fit to inc= lude. =A0 Kind Regards =A0 Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm 3GPP= 2 TSG-X and TSG-C participant) PS this being sent on 2/4/09 at 11:50pm PST Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2DAD3A6782 for ; Thu, 5 Feb 2009 00:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9KpsE0d+x5k for ; Thu, 5 Feb 2009 00:11:41 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C315B3A686A for ; Thu, 5 Feb 2009 00:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1233821482; x=1265357482; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" 'ECRIT'"=20|Date:=20Thu,=205=20Feb=202009 =2000:11:19=20-0800|Subject:=20Comments=20on=20BCP=20Draf t|Thread-Topic:=20Comments=20on=20BCP=20Draft |Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAhPDw |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC535F0306@ NASANEXMB04.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5516"=3B=20a=3D"15222186"; bh=UKMWIVjF2EWScKv2c7TzmzqMX6E03ANC8XO6c33VtDQ=; b=jw+iVho7RpOF+4rVr3kI3B/vZt1LgUmwYKfVg1kjRHXaXMhrLyaYR4ug H29oErB0LeHZKIQzYdwz9LJ6A9U+daANXE+yAiIW63KY1nOcpsu4IVyFf k1Tfw6lcRFw/n1fZnIQKGqeQ/hPRg5P+vffHqO1o2Tof8sQYU8rQll8sJ g=; X-IronPort-AV: E=McAfee;i="5100,188,5516"; a="15222186" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2009 00:11:21 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n158BL7S017676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Feb 2009 00:11:21 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n158BL6B011652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 5 Feb 2009 00:11:21 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Thu, 5 Feb 2009 00:11:20 -0800 From: "Edge, Stephen" To: "'ECRIT'" Date: Thu, 5 Feb 2009 00:11:19 -0800 Thread-Topic: Comments on BCP Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAhPDw Message-ID: <1288E74A73964940B132A0B9EA8D8ABC535F0306@NASANEXMB04.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Comments on BCP Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 08:11:43 -0000 All draft-ietf-ecrit-phonebcp-07 is a more precise description and set of requi= rements concerning how terminals and networks should support emergency call= s made over IP capable facilities to IP capable PSAPs. As for the framework= draft, it appears intended to cover all types of access network - includin= g fixed line, WiFi and cellular (implicit or explicit references to which c= an be found throughout the draft). When we evaluated this with respect to support of wireless cellular access = and WiFi access associated with a cellular operator (e.g. WLAN or Femto cel= ls integrated into a cellular network), we found that many requirements exh= ibited one or more of the following characteristics: (A) Inconsistent with already standardized wireless solutions (B) Inconsistent with essential wireless requirements and conventions (C) Already part of wireless standards or potentially part of future st= andards (A) refers to all requirements (and portions of requirements) that differ f= rom the requirements and procedures currently standardized for wireless eme= rgency access by 3GPP, 3GPP2 and OMA. This is a plain difference of solutio= n and could be resolved through support of both solutions by terminals (wit= h each solution being used according to the type of access network and VSP)= or could be resolved by supporting only one solution and accessing only th= e types of network supporting that solution. To acknowledge this category, = the BCP document could reference the applicable wireless standards and poin= t out that these are valid alternatives for wireless cellular based access. (B) refers to requirements (and portions of requirements) that would be uns= uitable for wireless networks even if no alternative solution existed toget= her with other requirements missing from the BCP that would be needed to fu= lly support wireless networks. To resolve this category either significant = changes to the current draft could be made or a disclaimer/applicability st= atement could be added stating that support of cellular wireless networks a= nd their associated WLAN and Femto access points is not covered. (C) comprises requirements that are either already part of the standardized= solution for wireless networks or that might be included at a later time. = In fact there are a large number of requirements and portions of requiremen= ts in this category (far more than listed below) that demonstrate a signifi= cant overlap between the BCP and current wireless standards. The presence o= f this category could be acknowledged by following the disclaimer for (B) w= ith a statement that certain portions of the solution are expected to be in= corporated into wireless networks now and/or in the future. A partial list of the requirements corresponding to each category above is = as follows. Note that inclusion in (B) automatically implies inclusion in (= A). (A) ED-5, ED-7, ED-12, AN-7/INT-6, AN-11, ED-18, ED-20, ED-22, ED-24, ED-2= 5, ED-28, ED-36, ED-37, ED-43, ED-48, ED-49, ED-50, ED-51, SP-25, ED-52, SP= -34 (portions only),=20 (B) ED-15, AN-9, ED-21, AN-12, ED-31, ED-35, ED-38, SP-18, SP-19, ED-53, E= D-54, ED-55, ED-56, ED-66/SP-35, SP-36 (C) ED-42/SP-21, SP-26 (and many others) We hope that these comments will be seen to be a useful addition to this re= view in the sense of enabling a more precise scoping for the BCP document a= nd we are willing to assist in establishing wording for any disclaimer/appl= icability statement that the Ecrit working group may deem fit to include. Kind Regards Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm 3GPP= 2 TSG-X and TSG-C participant) PS this is being sent on 2/5/09 at 00:10am PST (since an Outlook crash at = the precise instant the Send button was hit 15 minutes ago prevented compli= ance with the 2/4/09 deadline) Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E993A67AF for ; Thu, 5 Feb 2009 01:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHfQ-4nmz21N for ; Thu, 5 Feb 2009 01:18:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2DAB53A6A43 for ; Thu, 5 Feb 2009 01:18:02 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2009 09:17:41 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp067) with SMTP; 05 Feb 2009 10:17:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/gF1k2Jm/TJPBp5nnd/dkW+6evXSutdsYzvq3MU ileMDpkkRfYXJW From: "Hannes Tschofenig" To: "'Edge, Stephen'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> Date: Thu, 5 Feb 2009 11:18:27 +0200 Message-ID: <003901c98772$b4cc7710$0201a8c0@nsnintra.net> 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: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6g In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:18:04 -0000 Hi Stephen,=20 Thanks for your review. A few minor comments.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Edge, Stephen >Sent: 05 February, 2009 09:50 >To: 'ECRIT' >Subject: [Ecrit] Comments on Framework Draft > >All >=A0 >draft-ietf-ecrit-framework-07 is (as we see it) a mostly=20 >informative description of how terminals and networks should=20 >support emergency calls made over IP capable facilities to IP=20 >capable PSAPs. It appears intended to cover all types of=20 >access network - including fixed line, WiFi and cellular (e.g.=20 >examples involving each can be found throughout the draft). Correct. The framework document is the informative description where=20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt provides the normative part.=20 We thought that this would make it easy for the reader to follow the = entire story best.=20 >=A0 >When we evaluated this with respect to support of wireless=20 >cellular access and WiFi access associated with a cellular=20 >operator (e.g. WLAN or Femto cells integrated into a cellular=20 >network), we found that certain portions of the draft=20 >exhibited one or more of the following characteristics: >=A0 >=A0=A0=A0 (A) Inconsistent with already standardized wireless solutions >=A0 >=A0=A0=A0 (B) Inconsistent with essential wireless requirements and=20 >conventions >=A0 >=A0=A0=A0 (C) Already part of wireless standards or potentially part=20 >of future standards >=A0 >(A) refers to all portions of the draft framework that differ=20 >from the requirements and procedures currently standardized=20 >for wireless emergency access by 3GPP, 3GPP2 and OMA. This is=20 >a plain difference of solution and could be resolved through=20 >support of both solutions by terminals (with each solution=20 >being used according to the type of access network and VSP) or=20 >could be resolved by supporting only one solution and=20 >accessing only the types of network supporting that solution.=20 >To acknowledge this category, the framework document could=20 >reference the applicable wireless standards and point out that=20 >these are valid alternatives for wireless cellular based access. You know that we have tried hard over the past few years to harmonize = the work done by different SDOs, including 3GPP. You were involved in some = of these activities.=20 For some reason, various companies did not like such an alignment and = hence we are left with the situation that IMS emergency calling and emergency calling for everything else works differently.=20 This is unfortunate. Your company was always a big fan of developing a harmonized solution, right?=20 I doubt that the situation is improved by summarizing other = standardization efforts in this document nor by describing the content of this document = in 3GPP, 3GPP2 or OMA documents.=20 >(B) refers to portions of the draft that would be unsuitable=20 >for wireless networks even if no alternative solution existed=20 >together with other portions missing from the draft that would=20 >be needed to fully support wireless networks. Please note that we make a differentiation between wireless and = cellular. I guess you refer to cellular.=20 Examples of the=20 >former include: (a) emphasis on endpoint derivation of=20 >location, performance of Lost query and receipt of local dial=20 >strings; Please note that we are talking about location for 2 different purposes here:=20 * Location for routing=20 * Location for dispatch It is true that the document puts a focus on the end point obtaining location (at least for routing). There is, however, a story in there for = the case where the end point does not have access to location at all.=20 Having access to local dial strings at the end point is a very useful = thing, if you think about it.=20 Regarding LoST: Please note that LoST can also be executed by the VoIP provider when routing is required.=20 >(b) restriction of LCPs to protocols that require=20 >terminal initiation (not allowing for network initiation as=20 >far as we can tell) and that include two LCPs (DHCP and LLDP)=20 >that are not applicable to (not defined for) cellular access;=20 These two LCPs are only required for devices that can also be used in a fixed / wireless (but not cellular) environment. In environments where = the end host is expected to only ever use a cellular system these two LCPs = need not to be implemented.=20 Network initiation has never found huge excitement within the members of = the GEOPRIV group. I don't see this is a limitation, to be honest.=20 >and (c) the requirement that a terminal or at least a LIS will=20 >update the PSAP whenever location changes. I guess the items below refer to the dynamic location change. (a) is impractical=20 >due to network and terminal loading consequences I guess you see it as more dramatic than it is. The LIS and the PSAP can control the rate of information disclosure, see http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt= .=20 Specifying at what rate the terminal would send up-to-date information = is policy and implementation dependent. =20 and failure=20 >to support non-IP capable PSAPs; The IETF ECRIT solution is an IP-based solution and hence the Internet = ends where the last IP node is located.=20 For interworking with non-IP capable PSAPs please take a look at the = NENA i2/i2.5 work, which is the most advanced of its kind.=20 (b) makes location=20 >verification and updated location provision to PSAPs difficult=20 >or impossible; Could you elaborate a bit? Not sure I understood the "verification" and = the "updated location provisioning" part.=20 while (c) is also incompatible with support of=20 >existing non-IP capable PSAPs besides increasing terminal load=20 >and possibly interfering with optimum maintenance of the RF=20 >connection (e.g. if a terminal has to tune away from the=20 >serving base station or WLAN periodically to make location=20 >measurements). I guess you are hunting an academic problem. The document does not say = that you provide a continues stream of location information. We are more concerned about getting rough location as fast as possible to make the emergency call routing to happen to the right PSAP and then provide up-to-date location available to the PSAP for dispatch, when available.=20 Sure, there are corner cases when the emergency caller happens to be in = a fast car driving down the highway and location is constantly changing.=20 Examples of the latter include (d) absence of=20 >support for access to non-IP capable PSAPs as already=20 >mentioned (e.g. to support E911 phase 2 in the US);=20 This is excluded by our charter and, as I said, possible with the = solution NENA has worked out with i2 and i2.5.=20 Please also note that today fixed (and wireless -- but not cellular) operators are looking for VoIP emergency solutions as they are somewhat ahead with VoIP deployment compared to cellular operators. Hence, this will give PSAP operators more time to migrate to an IP-based environment and these things are happening as we speak. Sure, this all = needs time but the cost savings for an IP-based solution (as it was reported = to use at the emergency services workshops) seems to speak in favor of IP.=20 (e) no=20 >support for handover from the IP to the circuit domain when a=20 >terminal loses (e.g. moves out of) RF coverage in the IP=20 >domain;=20 Correct. Our charter does not allow us to work on VCC.=20 and (f) no allowance for limited access modes wherein=20 >a terminal may access a network only to place an emergency=20 >call with ensuing restrictions on (for example) location=20 >acquisition, PSAP callback and caller verification and=20 >identification to the PSAP. To resolve this category either=20 >significant changes to the framework document could be made or=20 >a disclaimer/applicability statement could be added stating=20 >that support of cellular wireless networks and their=20 >associated WLAN and Femto access points is not covered. This issue in under consideration in the ECRIT working group, see http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-0= 4.t xt.=20 The reason for us to separate this aspect from the main document is = simply it's complexity and the uncertainty from a regulatory point of view.=20 When you look at the document you will quickly realize that = "unauthenticated emergency calls" in an IP-based context mean much more than they do = today.=20 We have also discussed this topic at the emergency services workshops = and the different views about this topic are interesting to observe but = leave a lot of fuzziness behind.=20 >=A0 >Category (C) comprises concepts and capabilities in the draft=20 >that are either already part of the standardized solution for=20 >wireless networks or that might be added at a later time.=20 >Examples of the former include LoST, SIP location conveyance,=20 >general use of SIP, location for routing versus for dispatch,=20 >cellular positioning methods. Examples of the latter include=20 >use of location references and dereferencing and possible=20 >interworking between the current wireless network solutions=20 >(in 3GPP, 3GPP2 and OMA) and the solution described in this=20 >draft. The presence of this category could be acknowledged by=20 >following the disclaimer for (B) with a statement that certain=20 >portions of the solution are expected to be incorporated into=20 >wireless networks now and/or in the future. I am not sure I got your point. It is true that we have produced a = couple of specifications and, in case of SIP Location Conveyance, the = standardization effort is not yet completed.=20 >=A0 >We hope that these comments will be seen to be a useful=20 >addition to this review in the sense of enabling a more=20 >precise scoping for the framework document and we are willing=20 >to assist in providing wording for any=20 >disclaimer/applicability statement that the Ecrit working=20 >group may now deem fit to include. Thanks for your help.=20 >=A0 >Kind Regards >=A0 Thanks for your detailed review and for trying to help us ensuring that = the document does not raise wrong expectations.=20 Ciao Hannes >Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs=20 >(Qualcomm 3GPP2 TSG-X and TSG-C participant) > >PS this being sent on 2/4/09 at 11:50pm PST > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B423A6927 for ; Thu, 5 Feb 2009 04:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWokIp0K0wZI for ; Thu, 5 Feb 2009 04:55:42 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 5873A3A6AA2 for ; Thu, 5 Feb 2009 04:55:42 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n15CtA0v004008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Feb 2009 13:55:11 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 5 Feb 2009 13:55:09 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'Hannes Tschofenig'" , "'James M. Polk'" , "'Tschofenig, Hannes (NSN - FI/Espoo)'" , "'ECRIT'" Date: Thu, 5 Feb 2009 13:55:09 +0100 Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> In-Reply-To: <0a1101c98716$91287db0$b3797910$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 12:55:44 -0000 Which is exactly what RFC 4412 specifies for all namespaces. regards Keith=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Wednesday, February 04, 2009 10:19 PM > To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes=20 > (NSN - FI/Espoo)'; 'ECRIT' > Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda=20 > (my mistake) >=20 > The value is that in some networks where priority for=20 > emergency calls is appropriate, and appropriate policing of=20 > marking is implemented, emergency calls will receive resource=20 > priority. >=20 > Not all networks would need policing. Some will. Policing=20 > could be to Route header/R-URI content, but other criteria=20 > are possible. >=20 > Not all networks will need resource priority for emergency=20 > calls. Fine, ignore this marking/namespace. >=20 > Brian > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, February 04, 2009 5:09 PM > > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -=20 > > FI/Espoo); 'ECRIT' > > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my=20 > > mistake) > >=20 > > I don't even see the value in permitting the endpoint todo the RPH=20 > > marking. > > In addition to the security concerns there is also the problem that=20 > > there are more options to implement without an additional value. > >=20 > > >-----Original Message----- > > >From: Brian Rosen [mailto:br@brianrosen.net] > > >Sent: 05 February, 2009 00:03 > > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,=20 > Hannes (NSN -=20 > > >FI/Espoo)'; 'ECRIT' > > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > > mistake) > > > > > >Hannes > > > > > >This matches my understanding precisely. We wish to=20 > permit endpoints=20 > > >to mark. We do not require it, and don't necessarily expect it in=20 > > >many (even > > >most) cases. We don't wish to see the document prohibit it. > > >We all seem to agree it has value within the Emergency Services IP=20 > > >Networks. > > > > > >Brian > > > > > >> -----Original Message----- > > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > >On Behalf > > >> Of James M. Polk > > >> Sent: Wednesday, February 04, 2009 4:01 PM > > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -=20 > FI/Espoo); 'ECRIT' > > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > > >> mistake) > > >> > > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > > >> > > James wrote: > > >> > >> you are the _lone_ voice not supporting this ID, > > >> > > > >> >Listening to the audio recording of past meetings I have to > > >say that > > >> >I > > >> was > > >> >not the only persons raising concerns about the document. > > >> >That was probably the reason why you agreed to limit the > > >scope of the > > >> >document (which you didn't later do) to get folks to agree > > >to make it > > >> a WG > > >> >item. > > >> > > >> re-listen to the audio please > > >> > > >> Ted's concerns were consistent with most (all?) other=20 > concerns --=20 > > >> which were based on the premise of whether or not the=20 > UAC should be=20 > > >> trusted to initiate the marking on the INVITE. The most recent=20 > > >> version has backed off this to a "can" -- meaning not prohibited=20 > > >> (i.e., no 2119 text). I also backed off the text in the=20 > SP domain=20 > > >> part to "can", such that there is no 2119 text mandating or even=20 > > >> recommending its usage there. I also do not prohibit its > > >use, based on > > >> local policy. Keith has come forward with the specific request=20 > > >> that non-ESInet networks be allowed to mark and pay attention to=20 > > >> this priority indication -- with IMS as the specific example he=20 > > >> wishes to have this valid for. > > >> > > >> Where there is no disagreement, save for your recent > > >pushback - is in > > >> the ESInet, which is where Brian has requested it's > > >definition in the > > >> IETF on behalf of NENA. He's the i3 WG chair within=20 > NENA, and if=20 > > >> he asks for it, are you going to say you know better than he? > > >> > > >> > > >> >Btw, I not disagreeing with the document as such. I just want to > > the > > >> scope > > >> >to change. The usage of RPH within the emergency=20 > services network > > is > > >> fine > > >> >for me. I may get convinced to start the RPH marking from > > >the the VSP > > >> >towards the PSAP. I feel uneasy about the end host doing > > >the marking. > > >> > > >> please read what I wrote above, and then re-read the most recent=20 > > >> version of the ID. I don't have endpoints that SHOULD or=20 > MUST mark=20 > > >> anything wrt RPH. I also don't want to prohibit it,=20 > because there=20 > > >> might be cases (that I don't know of) of valid uses=20 > under certain=20 > > >> circumstances. Figure 1 is very clear that there are 3=20 > networking=20 > > >> parts to consider > > >> > > >> #1 - from the endpoint > > >> #2 - within the VSP > > >> #3 - within the ESInet > > >> > > >> the most recent ID version has "can" for #s 1 and 2, and > > >2119 language > > >> offering those supporting this specification will have RPH=20 > > >> adherence within #3 (the ESInet). > > >> > > >> What other scope changes do you want, because I haven't=20 > heard them. > > >> > > >> I only heard you claim in email during the last IETF and in > > >the ECRIT > > >> session that RPH should not be used for priority marking=20 > requests. > > >> This is something Keith (SIP WG chair) voiced his opposition to=20 > > >> your views regarding creating a second means for SIP to priority=20 > > >> mark request "when SIP already has one interoperable way to=20 > > >> accomplish this... it's call the RP header mechanism". > > >> > > >> >I don't see advantages -- only disadvantages. > > >> > > > >> >Ciao > > >> >Hannes > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4573A6849 for ; Thu, 5 Feb 2009 11:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOrG03DSv7jd for ; Thu, 5 Feb 2009 11:05:08 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 73AD43A67F0 for ; Thu, 5 Feb 2009 11:05:04 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2009 19:05:03 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp007) with SMTP; 05 Feb 2009 20:05:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1879u8+Csc76tpMXeNWY+JB2nxAmsmgDD3FhIDdAR kMRpbW9BNBKIUN From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'Brian Rosen'" , "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net><09fe01c98714$6acc7650$406562f0$@net><001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Thu, 5 Feb 2009 21:05:47 +0200 Message-ID: <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OAACRAgtA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 19:05:09 -0000 Keith, please understand that the usage of RFC 4412 for GETS and for the type of emergency call we discuss here is different. Just looking at the header and the name of the namespace is a bit artificial. I hope you understand that. >-----Original Message----- >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 05 February, 2009 14:55 >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > >Which is exactly what RFC 4412 specifies for all namespaces. > >regards > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Brian Rosen >> Sent: Wednesday, February 04, 2009 10:19 PM >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes (NSN - >> FI/Espoo)'; 'ECRIT' >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> mistake) >> >> The value is that in some networks where priority for >emergency calls >> is appropriate, and appropriate policing of marking is implemented, >> emergency calls will receive resource priority. >> >> Not all networks would need policing. Some will. Policing could be >> to Route header/R-URI content, but other criteria are possible. >> >> Not all networks will need resource priority for emergency calls. >> Fine, ignore this marking/namespace. >> >> Brian >> > -----Original Message----- >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> > Sent: Wednesday, February 04, 2009 5:09 PM >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - >> > FI/Espoo); 'ECRIT' >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> > mistake) >> > >> > I don't even see the value in permitting the endpoint todo the RPH >> > marking. >> > In addition to the security concerns there is also the >problem that >> > there are more options to implement without an additional value. >> > >> > >-----Original Message----- >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> > >Sent: 05 February, 2009 00:03 >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, >> Hannes (NSN - >> > >FI/Espoo)'; 'ECRIT' >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> > mistake) >> > > >> > >Hannes >> > > >> > >This matches my understanding precisely. We wish to >> permit endpoints >> > >to mark. We do not require it, and don't necessarily expect it in >> > >many (even >> > >most) cases. We don't wish to see the document prohibit it. >> > >We all seem to agree it has value within the Emergency >Services IP >> > >Networks. >> > > >> > >Brian >> > > >> > >> -----Original Message----- >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> > >On Behalf >> > >> Of James M. Polk >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - >> FI/Espoo); 'ECRIT' >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> > >> mistake) >> > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >> > >> > > James wrote: >> > >> > >> you are the _lone_ voice not supporting this ID, >> > >> > >> > >> >Listening to the audio recording of past meetings I have to >> > >say that >> > >> >I >> > >> was >> > >> >not the only persons raising concerns about the document. >> > >> >That was probably the reason why you agreed to limit the >> > >scope of the >> > >> >document (which you didn't later do) to get folks to agree >> > >to make it >> > >> a WG >> > >> >item. >> > >> >> > >> re-listen to the audio please >> > >> >> > >> Ted's concerns were consistent with most (all?) other >> concerns -- >> > >> which were based on the premise of whether or not the >> UAC should be >> > >> trusted to initiate the marking on the INVITE. The most recent >> > >> version has backed off this to a "can" -- meaning not >prohibited >> > >> (i.e., no 2119 text). I also backed off the text in the >> SP domain >> > >> part to "can", such that there is no 2119 text >mandating or even >> > >> recommending its usage there. I also do not prohibit its >> > >use, based on >> > >> local policy. Keith has come forward with the specific request >> > >> that non-ESInet networks be allowed to mark and pay >attention to >> > >> this priority indication -- with IMS as the specific example he >> > >> wishes to have this valid for. >> > >> >> > >> Where there is no disagreement, save for your recent >> > >pushback - is in >> > >> the ESInet, which is where Brian has requested it's >> > >definition in the >> > >> IETF on behalf of NENA. He's the i3 WG chair within >> NENA, and if >> > >> he asks for it, are you going to say you know better than he? >> > >> >> > >> >> > >> >Btw, I not disagreeing with the document as such. I >just want to >> > the >> > >> scope >> > >> >to change. The usage of RPH within the emergency >> services network >> > is >> > >> fine >> > >> >for me. I may get convinced to start the RPH marking from >> > >the the VSP >> > >> >towards the PSAP. I feel uneasy about the end host doing >> > >the marking. >> > >> >> > >> please read what I wrote above, and then re-read the >most recent >> > >> version of the ID. I don't have endpoints that SHOULD or >> MUST mark >> > >> anything wrt RPH. I also don't want to prohibit it, >> because there >> > >> might be cases (that I don't know of) of valid uses >> under certain >> > >> circumstances. Figure 1 is very clear that there are 3 >> networking >> > >> parts to consider >> > >> >> > >> #1 - from the endpoint >> > >> #2 - within the VSP >> > >> #3 - within the ESInet >> > >> >> > >> the most recent ID version has "can" for #s 1 and 2, and >> > >2119 language >> > >> offering those supporting this specification will have RPH >> > >> adherence within #3 (the ESInet). >> > >> >> > >> What other scope changes do you want, because I haven't >> heard them. >> > >> >> > >> I only heard you claim in email during the last IETF and in >> > >the ECRIT >> > >> session that RPH should not be used for priority marking >> requests. >> > >> This is something Keith (SIP WG chair) voiced his opposition to >> > >> your views regarding creating a second means for SIP to >priority >> > >> mark request "when SIP already has one interoperable way to >> > >> accomplish this... it's call the RP header mechanism". >> > >> >> > >> >I don't see advantages -- only disadvantages. >> > >> > >> > >> >Ciao >> > >> >Hannes >> > >> >> > >> _______________________________________________ >> > >> Ecrit mailing list >> > >> Ecrit@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/ecrit >> > > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD723A69FB for ; Thu, 5 Feb 2009 15:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi9c3UwUeyZA for ; Thu, 5 Feb 2009 15:35:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D8D353A69B4 for ; Thu, 5 Feb 2009 15:35:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,388,1231113600"; d="scan'208";a="243881667" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2009 23:35:40 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n15NZepT013184; Thu, 5 Feb 2009 15:35:40 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n15NZeC5020741; Thu, 5 Feb 2009 23:35:40 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); Thu, 5 Feb 2009 15:35:40 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.21.185]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 15:35:39 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Feb 2009 17:35:39 -0600 To: "Hannes Tschofenig" , "'DRAGE, Keith \(Keith\)'" , "'Brian Rosen'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Feb 2009 23:35:39.0808 (UTC) FILETIME=[742EA200:01C987EA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9792; t=1233876940; x=1234740940; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20ECRIT=20Virtual=20Interim=20Meeting=3A=20Agenda =20(RPH) |Sender:=20; bh=kfZfeRdow+mJ3/N0d4jHs7juucRkc+0JyWbHICF6udo=; b=PlG6xtJp/Jde3F57kXqt0wmNE/tBtMKmseRR9ZGpxF91aBYd1jN5O231sT lJvcXYTJPCReQ0BWsgK4YxDjhAOWf3bs/ObV0/pRU9XLmc58Bpi4cMmI2ZlZ gbB+lu1Q6wJTShIlgplev2VAwqKzGSa3qklNDQ79EyeAVw+sqA4Ew=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 23:35:41 -0000 Hannes - I believe it is you who do not understand RFC 4412 -- and many of us are trying to get that through to you, but you don't seem to want to listen/read. RFC 4412 is *for* priority marking SIP requests, One use is GETS. One use is MLPP. These examples are in RFC 4412 because there were specific namespaces being created for the IANA section of that document. Reading the whole document, you will see that RPH can be specified for other uses than GETS or MLPP specifically. I knew when I wrote RFC 4412 that one day we would specify a namespace for ECRIT (the "esnet" namespace now) -- but I also knew it was premature for RFC 4412 to incorporate that namespace, that a future doc to RFC 4412 would have to be written to do this. Brian and I talked about this at the original NENA meeting that created the IP WGs there (in August of 03). We both agreed we should wait until it was appropriate to the work in the IETF to submit this document that is now http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt Yet, you seem to want to use some additional mechanism to indicate priority of a call in SIP. That means you want to introduce a second way to accomplish this in SIP. Why do you want to promote a separate way to do something SIP has already defined? That will cause interoperability issues and we both know that. You've said to me (and others) that you believe RPH is just another way to accomplish what sos or a URI can indicate - and you're wrong. Your way would be _the_second_way_to_do_it, because SIP already considers RPH to be *the*way* to priority mark SIP requests. If you don't believe me (no comment), then why do you not believe the SIP WG chair (who knows more about SIP than both of us) - who, on this thread, has again said to you "RFC 4412 (RPH) is the SIP mechanism to priority mark SIP requests"? Further, I believe it is inappropriate to prohibit endpoints from being able to set the esnet namespace. I absolutely believe it will not be needed most of the time, but I believe if someone does find a valid use for endpoints to mark priority in SIP, this ID - once it has become an RFC -- will have to be obsoleted with a new RFC saying the exact opposite. (color me confused ... over and over again) James At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >Keith, please understand that the usage of RFC 4412 for GETS and for the >type of emergency call we discuss here is different. Just looking at the >header and the name of the namespace is a bit artificial. I hope you >understand that. > > >-----Original Message----- > >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >Sent: 05 February, 2009 14:55 > >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; > >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > > > >Which is exactly what RFC 4412 specifies for all namespaces. > > > >regards > > > >Keith > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Brian Rosen > >> Sent: Wednesday, February 04, 2009 10:19 PM > >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes (NSN - > >> FI/Espoo)'; 'ECRIT' > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> mistake) > >> > >> The value is that in some networks where priority for > >emergency calls > >> is appropriate, and appropriate policing of marking is implemented, > >> emergency calls will receive resource priority. > >> > >> Not all networks would need policing. Some will. Policing could be > >> to Route header/R-URI content, but other criteria are possible. > >> > >> Not all networks will need resource priority for emergency calls. > >> Fine, ignore this marking/namespace. > >> > >> Brian > >> > -----Original Message----- > >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - > >> > FI/Espoo); 'ECRIT' > >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> > mistake) > >> > > >> > I don't even see the value in permitting the endpoint todo the RPH > >> > marking. > >> > In addition to the security concerns there is also the > >problem that > >> > there are more options to implement without an additional value. > >> > > >> > >-----Original Message----- > >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> > >Sent: 05 February, 2009 00:03 > >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> Hannes (NSN - > >> > >FI/Espoo)'; 'ECRIT' > >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> > mistake) > >> > > > >> > >Hannes > >> > > > >> > >This matches my understanding precisely. We wish to > >> permit endpoints > >> > >to mark. We do not require it, and don't necessarily expect it in > >> > >many (even > >> > >most) cases. We don't wish to see the document prohibit it. > >> > >We all seem to agree it has value within the Emergency > >Services IP > >> > >Networks. > >> > > > >> > >Brian > >> > > > >> > >> -----Original Message----- > >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> > >On Behalf > >> > >> Of James M. Polk > >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> FI/Espoo); 'ECRIT' > >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> > >> mistake) > >> > >> > >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> > >> > > James wrote: > >> > >> > >> you are the _lone_ voice not supporting this ID, > >> > >> > > >> > >> >Listening to the audio recording of past meetings I have to > >> > >say that > >> > >> >I > >> > >> was > >> > >> >not the only persons raising concerns about the document. > >> > >> >That was probably the reason why you agreed to limit the > >> > >scope of the > >> > >> >document (which you didn't later do) to get folks to agree > >> > >to make it > >> > >> a WG > >> > >> >item. > >> > >> > >> > >> re-listen to the audio please > >> > >> > >> > >> Ted's concerns were consistent with most (all?) other > >> concerns -- > >> > >> which were based on the premise of whether or not the > >> UAC should be > >> > >> trusted to initiate the marking on the INVITE. The most recent > >> > >> version has backed off this to a "can" -- meaning not > >prohibited > >> > >> (i.e., no 2119 text). I also backed off the text in the > >> SP domain > >> > >> part to "can", such that there is no 2119 text > >mandating or even > >> > >> recommending its usage there. I also do not prohibit its > >> > >use, based on > >> > >> local policy. Keith has come forward with the specific request > >> > >> that non-ESInet networks be allowed to mark and pay > >attention to > >> > >> this priority indication -- with IMS as the specific example he > >> > >> wishes to have this valid for. > >> > >> > >> > >> Where there is no disagreement, save for your recent > >> > >pushback - is in > >> > >> the ESInet, which is where Brian has requested it's > >> > >definition in the > >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> NENA, and if > >> > >> he asks for it, are you going to say you know better than he? > >> > >> > >> > >> > >> > >> >Btw, I not disagreeing with the document as such. I > >just want to > >> > the > >> > >> scope > >> > >> >to change. The usage of RPH within the emergency > >> services network > >> > is > >> > >> fine > >> > >> >for me. I may get convinced to start the RPH marking from > >> > >the the VSP > >> > >> >towards the PSAP. I feel uneasy about the end host doing > >> > >the marking. > >> > >> > >> > >> please read what I wrote above, and then re-read the > >most recent > >> > >> version of the ID. I don't have endpoints that SHOULD or > >> MUST mark > >> > >> anything wrt RPH. I also don't want to prohibit it, > >> because there > >> > >> might be cases (that I don't know of) of valid uses > >> under certain > >> > >> circumstances. Figure 1 is very clear that there are 3 > >> networking > >> > >> parts to consider > >> > >> > >> > >> #1 - from the endpoint > >> > >> #2 - within the VSP > >> > >> #3 - within the ESInet > >> > >> > >> > >> the most recent ID version has "can" for #s 1 and 2, and > >> > >2119 language > >> > >> offering those supporting this specification will have RPH > >> > >> adherence within #3 (the ESInet). > >> > >> > >> > >> What other scope changes do you want, because I haven't > >> heard them. > >> > >> > >> > >> I only heard you claim in email during the last IETF and in > >> > >the ECRIT > >> > >> session that RPH should not be used for priority marking > >> requests. > >> > >> This is something Keith (SIP WG chair) voiced his opposition to > >> > >> your views regarding creating a second means for SIP to > >priority > >> > >> mark request "when SIP already has one interoperable way to > >> > >> accomplish this... it's call the RP header mechanism". > >> > >> > >> > >> >I don't see advantages -- only disadvantages. > >> > >> > > >> > >> >Ciao > >> > >> >Hannes > >> > >> > >> > >> _______________________________________________ > >> > >> Ecrit mailing list > >> > >> Ecrit@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3833A6AD0 for ; Thu, 5 Feb 2009 17:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exUVQ7MU1jXM for ; Thu, 5 Feb 2009 17:51:46 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id D60463A67B6 for ; Thu, 5 Feb 2009 17:51:44 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n161pX4c007529 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2009 02:51:33 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 6 Feb 2009 02:51:33 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "'Brian Rosen'" , "'James M. Polk'" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "'ECRIT'" Date: Fri, 6 Feb 2009 02:51:33 +0100 Thread-Topic: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OAACRAgtAADBcUcA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499B7DC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net><09fe01c98714$6acc7650$406562f0$@net><001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> In-Reply-To: <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 01:51:47 -0000 RFC 4412 is not specific to a single namespace. The general principles eluc= idated by Brian apply to all the namespaces, and give a framework for their= use. I believe I understand RFC 4412, but my interpretation is certainly at vari= ance to yours. I am just glad I seem to have a common interpretation with a= number of other people. Keith=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, February 05, 2009 7:06 PM > To: DRAGE, Keith (Keith); 'Brian Rosen'; 'James M. Polk';=20 > Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda=20 > (my mistake) >=20 > Keith, please understand that the usage of RFC 4412 for GETS=20 > and for the type of emergency call we discuss here is=20 > different. Just looking at the header and the name of the=20 > namespace is a bit artificial. I hope you understand that.=20 >=20 > >-----Original Message----- > >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >Sent: 05 February, 2009 14:55 > >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,=20 > >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda=20 > (my mistake) > > > >Which is exactly what RFC 4412 specifies for all namespaces. > > > >regards > > > >Keith > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Brian Rosen > >> Sent: Wednesday, February 04, 2009 10:19 PM > >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,=20 > Hannes (NSN -=20 > >> FI/Espoo)'; 'ECRIT' > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> mistake) > >>=20 > >> The value is that in some networks where priority for > >emergency calls > >> is appropriate, and appropriate policing of marking is=20 > implemented,=20 > >> emergency calls will receive resource priority. > >>=20 > >> Not all networks would need policing. Some will. =20 > Policing could be=20 > >> to Route header/R-URI content, but other criteria are possible. > >>=20 > >> Not all networks will need resource priority for emergency calls. =20 > >> Fine, ignore this marking/namespace. > >>=20 > >> Brian > >> > -----Original Message----- > >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -=20 > >> > FI/Espoo); 'ECRIT' > >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> > mistake) > >> >=20 > >> > I don't even see the value in permitting the endpoint=20 > todo the RPH=20 > >> > marking. > >> > In addition to the security concerns there is also the > >problem that > >> > there are more options to implement without an additional value. > >> >=20 > >> > >-----Original Message----- > >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> > >Sent: 05 February, 2009 00:03 > >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> Hannes (NSN - > >> > >FI/Espoo)'; 'ECRIT' > >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> > mistake) > >> > > > >> > >Hannes > >> > > > >> > >This matches my understanding precisely. We wish to > >> permit endpoints > >> > >to mark. We do not require it, and don't necessarily=20 > expect it in=20 > >> > >many (even > >> > >most) cases. We don't wish to see the document prohibit it. > >> > >We all seem to agree it has value within the Emergency > >Services IP > >> > >Networks. > >> > > > >> > >Brian > >> > > > >> > >> -----Original Message----- > >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> > >On Behalf > >> > >> Of James M. Polk > >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> FI/Espoo); 'ECRIT' > >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> > >> mistake) > >> > >> > >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> > >> > > James wrote: > >> > >> > >> you are the _lone_ voice not supporting this ID, > >> > >> > > >> > >> >Listening to the audio recording of past meetings I have to > >> > >say that > >> > >> >I > >> > >> was > >> > >> >not the only persons raising concerns about the document. > >> > >> >That was probably the reason why you agreed to limit the > >> > >scope of the > >> > >> >document (which you didn't later do) to get folks to agree > >> > >to make it > >> > >> a WG > >> > >> >item. > >> > >> > >> > >> re-listen to the audio please > >> > >> > >> > >> Ted's concerns were consistent with most (all?) other > >> concerns -- > >> > >> which were based on the premise of whether or not the > >> UAC should be > >> > >> trusted to initiate the marking on the INVITE. The=20 > most recent=20 > >> > >> version has backed off this to a "can" -- meaning not > >prohibited > >> > >> (i.e., no 2119 text). I also backed off the text in the > >> SP domain > >> > >> part to "can", such that there is no 2119 text > >mandating or even > >> > >> recommending its usage there. I also do not prohibit its > >> > >use, based on > >> > >> local policy. Keith has come forward with the=20 > specific request=20 > >> > >> that non-ESInet networks be allowed to mark and pay > >attention to > >> > >> this priority indication -- with IMS as the specific=20 > example he=20 > >> > >> wishes to have this valid for. > >> > >> > >> > >> Where there is no disagreement, save for your recent > >> > >pushback - is in > >> > >> the ESInet, which is where Brian has requested it's > >> > >definition in the > >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> NENA, and if > >> > >> he asks for it, are you going to say you know better than he? > >> > >> > >> > >> > >> > >> >Btw, I not disagreeing with the document as such. I > >just want to > >> > the > >> > >> scope > >> > >> >to change. The usage of RPH within the emergency > >> services network > >> > is > >> > >> fine > >> > >> >for me. I may get convinced to start the RPH marking from > >> > >the the VSP > >> > >> >towards the PSAP. I feel uneasy about the end host doing > >> > >the marking. > >> > >> > >> > >> please read what I wrote above, and then re-read the > >most recent > >> > >> version of the ID. I don't have endpoints that SHOULD or > >> MUST mark > >> > >> anything wrt RPH. I also don't want to prohibit it, > >> because there > >> > >> might be cases (that I don't know of) of valid uses > >> under certain > >> > >> circumstances. Figure 1 is very clear that there are 3 > >> networking > >> > >> parts to consider > >> > >> > >> > >> #1 - from the endpoint > >> > >> #2 - within the VSP > >> > >> #3 - within the ESInet > >> > >> > >> > >> the most recent ID version has "can" for #s 1 and 2, and > >> > >2119 language > >> > >> offering those supporting this specification will have RPH=20 > >> > >> adherence within #3 (the ESInet). > >> > >> > >> > >> What other scope changes do you want, because I haven't > >> heard them. > >> > >> > >> > >> I only heard you claim in email during the last IETF and in > >> > >the ECRIT > >> > >> session that RPH should not be used for priority marking > >> requests. > >> > >> This is something Keith (SIP WG chair) voiced his=20 > opposition to=20 > >> > >> your views regarding creating a second means for SIP to > >priority > >> > >> mark request "when SIP already has one interoperable way to=20 > >> > >> accomplish this... it's call the RP header mechanism". > >> > >> > >> > >> >I don't see advantages -- only disadvantages. > >> > >> > > >> > >> >Ciao > >> > >> >Hannes > >> > >> > >> > >> _______________________________________________ > >> > >> Ecrit mailing list > >> > >> Ecrit@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > > >=20 > = Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4C53A6B80 for ; Fri, 6 Feb 2009 01:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW1T8A3sEKl6 for ; Fri, 6 Feb 2009 01:21:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BDD943A6AAF for ; Fri, 6 Feb 2009 01:21:05 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 09:21:06 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp005) with SMTP; 06 Feb 2009 10:21:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+4nXgnSVa49Xu37j9pPNBaJPh5rDrgOHMiRMqzS9 lyqIH3phYSzVqy From: "Hannes Tschofenig" To: "'James M. Polk'" , "'DRAGE, Keith \(Keith\)'" , "'Brian Rosen'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> Date: Fri, 6 Feb 2009 11:21:51 +0200 Message-ID: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcmH6nV9SIaxjsjZSBKpW3CnAousqgATEoUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 09:21:07 -0000 Hi James, I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would like to point out is that there is more than just a header and values within the header that have to be considered in order to make a judgement of what is appropriate and what isn't. There is an architectural question and whether the environment we are using the stuff is indeed providing the properties you need for the solution to be appropriate. Let me describe in more detail what I meant (and please correct me if I am wrong). Getting priority for SIP requests when using a GETS alike scenario means that the entity that issues the request is specially authorized since otherwise you introduce a nice denial of service attack. This authorization is tied to the entity that makes the request. For example, the person is working for the government and has special rights. James Bond as a (not so) secret agent might have these rights. The emergency services case (citizen-to-authority) is a bit different as there aren't really special rights with respect to authorization tied to individuals. Instead, the fact that something is an emergency is purely a judgement of the human that dials a special number. To deal with fraud, we discussed in the group on what we can actually do to ensure that end users do not bypass security procedures (such as authorization checks, charging and so on). Part of this investigation was the publication of http://www.ietf.org/rfc/rfc5069.txt that also describes this issue. So, imagine the implementation of a SIP proxy (and we implemented that stuff) that receives a call that contains a Service URN. The code branches into a special mode where everything is done so that the call receives appropriate treatment and does not get dropped on the floor. The way how the Service URN is placed in the message ensures that the call cannot go to my friend (instead of the PSAP) unless the end host ran LoST already. In the latter case, we discussed this also on the list for a while and Richard even wrote a draft about it in the context of the location hiding topic, we said that the proxy would have to run LoST if he cares about a potential fraudulent usage. So, what do we need todo in order to provide secure RFC 4412 functionality in our context? Do you think that the current text in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam espace-00.txt reflects any of the above-described issues: " The Security considerations that apply to RFC 4412 [RFC4412] apply here. This document introduces no new security issues relative to RFC 4412. " >From various discussions in GEOPRIV I recall that you are super-sensitive regarding security and privacy. For some reasons you don't seem to have the same concerns here. I would like to understand your reasoning. Please also do me another favor: Don't always say that I don't understand the subject. Even if that would be the case it isn't particular fair given that different folks had to educate you on other topics in the past as well. Additionally, if you listen to the audio recordings then you will notice that Henning, Ted, and Jon do not seem to understand the issue either as they have raised similar issues during the F2F meetings. Ciao Hannes >Hannes - I believe it is you who do not understand RFC 4412 -- >and many of us are trying to get that through to you, but you >don't seem to want to listen/read. > >RFC 4412 is *for* priority marking SIP requests, > >One use is GETS. > >One use is MLPP. > >These examples are in RFC 4412 because there were specific >namespaces being created for the IANA section of that document. > >Reading the whole document, you will see that RPH can be >specified for other uses than GETS or MLPP specifically. > >I knew when I wrote RFC 4412 that one day we would specify a >namespace for ECRIT (the "esnet" namespace now) -- but I also >knew it was premature for RFC 4412 to incorporate that >namespace, that a future doc to RFC 4412 would have to be >written to do this. Brian and I talked about this at the >original NENA meeting that created the IP WGs there (in August >of 03). We both agreed we should wait until it was >appropriate to the work in the IETF to submit this document >that is now >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >gency-rph-namespace-00.txt > >Yet, you seem to want to use some additional mechanism to >indicate priority of a call in SIP. That means you want to >introduce a second way to accomplish this in SIP. Why do you >want to promote a separate way to do something SIP has already >defined? That will cause interoperability issues and we both know that. > >You've said to me (and others) that you believe RPH is just >another way to accomplish what sos or a URI can indicate - and >you're wrong. Your way would be _the_second_way_to_do_it, >because SIP already considers RPH to be *the*way* to priority >mark SIP requests. > >If you don't believe me (no comment), then why do you not >believe the SIP WG chair (who knows more about SIP than both >of us) - who, on this thread, has again said to you "RFC 4412 >(RPH) is the SIP mechanism to priority mark SIP requests"? > >Further, I believe it is inappropriate to prohibit endpoints >from being able to set the esnet namespace. I absolutely >believe it will not be needed most of the time, but I believe >if someone does find a valid use for endpoints to mark >priority in SIP, this ID - once it has become an RFC -- will >have to be obsoleted with a new RFC saying the exact opposite. > >(color me confused ... over and over again) > >James > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >>Keith, please understand that the usage of RFC 4412 for GETS and for >>the type of emergency call we discuss here is different. Just looking >>at the header and the name of the namespace is a bit >artificial. I hope >>you understand that. >> >> >-----Original Message----- >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> >Sent: 05 February, 2009 14:55 >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >mistake) >> > >> >Which is exactly what RFC 4412 specifies for all namespaces. >> > >> >regards >> > >> >Keith >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >> Of Brian Rosen >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >Hannes (NSN >> >> - FI/Espoo)'; 'ECRIT' >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> mistake) >> >> >> >> The value is that in some networks where priority for >> >emergency calls >> >> is appropriate, and appropriate policing of marking is >implemented, >> >> emergency calls will receive resource priority. >> >> >> >> Not all networks would need policing. Some will. Policing could >> >> be to Route header/R-URI content, but other criteria are possible. >> >> >> >> Not all networks will need resource priority for emergency calls. >> >> Fine, ignore this marking/namespace. >> >> >> >> Brian >> >> > -----Original Message----- >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - >> >> > FI/Espoo); 'ECRIT' >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> > mistake) >> >> > >> >> > I don't even see the value in permitting the endpoint todo the >> >> > RPH marking. >> >> > In addition to the security concerns there is also the >> >problem that >> >> > there are more options to implement without an additional value. >> >> > >> >> > >-----Original Message----- >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> >> > >Sent: 05 February, 2009 00:03 >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, >> >> Hannes (NSN - >> >> > >FI/Espoo)'; 'ECRIT' >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> > mistake) >> >> > > >> >> > >Hannes >> >> > > >> >> > >This matches my understanding precisely. We wish to >> >> permit endpoints >> >> > >to mark. We do not require it, and don't necessarily expect it >> >> > >in many (even >> >> > >most) cases. We don't wish to see the document prohibit it. >> >> > >We all seem to agree it has value within the Emergency >> >Services IP >> >> > >Networks. >> >> > > >> >> > >Brian >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >> > >On Behalf >> >> > >> Of James M. Polk >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - >> >> FI/Espoo); 'ECRIT' >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >Agenda (my >> >> > >> mistake) >> >> > >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >> >> > >> > > James wrote: >> >> > >> > >> you are the _lone_ voice not supporting this ID, >> >> > >> > >> >> > >> >Listening to the audio recording of past meetings I have to >> >> > >say that >> >> > >> >I >> >> > >> was >> >> > >> >not the only persons raising concerns about the document. >> >> > >> >That was probably the reason why you agreed to limit the >> >> > >scope of the >> >> > >> >document (which you didn't later do) to get folks to agree >> >> > >to make it >> >> > >> a WG >> >> > >> >item. >> >> > >> >> >> > >> re-listen to the audio please >> >> > >> >> >> > >> Ted's concerns were consistent with most (all?) other >> >> concerns -- >> >> > >> which were based on the premise of whether or not the >> >> UAC should be >> >> > >> trusted to initiate the marking on the INVITE. The most >> >> > >> recent version has backed off this to a "can" -- meaning not >> >prohibited >> >> > >> (i.e., no 2119 text). I also backed off the text in the >> >> SP domain >> >> > >> part to "can", such that there is no 2119 text >> >mandating or even >> >> > >> recommending its usage there. I also do not prohibit its >> >> > >use, based on >> >> > >> local policy. Keith has come forward with the specific >> >> > >> request that non-ESInet networks be allowed to mark and pay >> >attention to >> >> > >> this priority indication -- with IMS as the specific example >> >> > >> he wishes to have this valid for. >> >> > >> >> >> > >> Where there is no disagreement, save for your recent >> >> > >pushback - is in >> >> > >> the ESInet, which is where Brian has requested it's >> >> > >definition in the >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within >> >> NENA, and if >> >> > >> he asks for it, are you going to say you know better than he? >> >> > >> >> >> > >> >> >> > >> >Btw, I not disagreeing with the document as such. I >> >just want to >> >> > the >> >> > >> scope >> >> > >> >to change. The usage of RPH within the emergency >> >> services network >> >> > is >> >> > >> fine >> >> > >> >for me. I may get convinced to start the RPH marking from >> >> > >the the VSP >> >> > >> >towards the PSAP. I feel uneasy about the end host doing >> >> > >the marking. >> >> > >> >> >> > >> please read what I wrote above, and then re-read the >> >most recent >> >> > >> version of the ID. I don't have endpoints that SHOULD or >> >> MUST mark >> >> > >> anything wrt RPH. I also don't want to prohibit it, >> >> because there >> >> > >> might be cases (that I don't know of) of valid uses >> >> under certain >> >> > >> circumstances. Figure 1 is very clear that there are 3 >> >> networking >> >> > >> parts to consider >> >> > >> >> >> > >> #1 - from the endpoint >> >> > >> #2 - within the VSP >> >> > >> #3 - within the ESInet >> >> > >> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and >> >> > >2119 language >> >> > >> offering those supporting this specification will have RPH >> >> > >> adherence within #3 (the ESInet). >> >> > >> >> >> > >> What other scope changes do you want, because I haven't >> >> heard them. >> >> > >> >> >> > >> I only heard you claim in email during the last IETF and in >> >> > >the ECRIT >> >> > >> session that RPH should not be used for priority marking >> >> requests. >> >> > >> This is something Keith (SIP WG chair) voiced his opposition >> >> > >> to your views regarding creating a second means for SIP to >> >priority >> >> > >> mark request "when SIP already has one interoperable way to >> >> > >> accomplish this... it's call the RP header mechanism". >> >> > >> >> >> > >> >I don't see advantages -- only disadvantages. >> >> > >> > >> >> > >> >Ciao >> >> > >> >Hannes >> >> > >> >> >> > >> _______________________________________________ >> >> > >> Ecrit mailing list >> >> > >> Ecrit@ietf.org >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802143A6BA0 for ; Fri, 6 Feb 2009 01:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwuUuiX282qk for ; Fri, 6 Feb 2009 01:22:51 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C51D73A6B8A for ; Fri, 6 Feb 2009 01:22:50 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 09:22:51 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp026) with SMTP; 06 Feb 2009 10:22:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19KZdtMhrxKqQwVu8OAKsvb6NVqTHIaWb9BmKHiLW DN5EiY2huUqbzo From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'Brian Rosen'" , "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net><09fe01c98714$6acc7650$406562f0$@net><001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B7DC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Fri, 6 Feb 2009 11:23:38 +0200 Message-ID: <000901c9883c$989e8270$49b5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67499B7DC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Thread-Index: AcmHC6zIdbOQB6JfQPiKYW9Ra7nZyQACHzIwAAA6PeAAAC77kAAHa6OAACRAgtAADBcUcAAR6zqA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 09:22:52 -0000 I am also glad that some folks share the security concerns I have. >-----Original Message----- >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 06 February, 2009 03:52 >To: Hannes Tschofenig; 'Brian Rosen'; 'James M. Polk'; >Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my mistake) > >RFC 4412 is not specific to a single namespace. The general >principles elucidated by Brian apply to all the namespaces, >and give a framework for their use. > >I believe I understand RFC 4412, but my interpretation is >certainly at variance to yours. I am just glad I seem to have >a common interpretation with a number of other people. > >Keith > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Thursday, February 05, 2009 7:06 PM >> To: DRAGE, Keith (Keith); 'Brian Rosen'; 'James M. Polk'; >Tschofenig, >> Hannes (NSN - FI/Espoo); 'ECRIT' >> Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> mistake) >> >> Keith, please understand that the usage of RFC 4412 for GETS and for >> the type of emergency call we discuss here is different. >Just looking >> at the header and the name of the namespace is a bit artificial. I >> hope you understand that. >> >> >-----Original Message----- >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> >Sent: 05 February, 2009 14:55 >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda >> (my mistake) >> > >> >Which is exactly what RFC 4412 specifies for all namespaces. >> > >> >regards >> > >> >Keith >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >> Of Brian Rosen >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >> Hannes (NSN - >> >> FI/Espoo)'; 'ECRIT' >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> mistake) >> >> >> >> The value is that in some networks where priority for >> >emergency calls >> >> is appropriate, and appropriate policing of marking is >> implemented, >> >> emergency calls will receive resource priority. >> >> >> >> Not all networks would need policing. Some will. >> Policing could be >> >> to Route header/R-URI content, but other criteria are possible. >> >> >> >> Not all networks will need resource priority for >emergency calls. >> >> Fine, ignore this marking/namespace. >> >> >> >> Brian >> >> > -----Original Message----- >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - >> >> > FI/Espoo); 'ECRIT' >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> > mistake) >> >> > >> >> > I don't even see the value in permitting the endpoint >> todo the RPH >> >> > marking. >> >> > In addition to the security concerns there is also the >> >problem that >> >> > there are more options to implement without an additional value. >> >> > >> >> > >-----Original Message----- >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> >> > >Sent: 05 February, 2009 00:03 >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, >> >> Hannes (NSN - >> >> > >FI/Espoo)'; 'ECRIT' >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> > mistake) >> >> > > >> >> > >Hannes >> >> > > >> >> > >This matches my understanding precisely. We wish to >> >> permit endpoints >> >> > >to mark. We do not require it, and don't necessarily >> expect it in >> >> > >many (even >> >> > >most) cases. We don't wish to see the document prohibit it. >> >> > >We all seem to agree it has value within the Emergency >> >Services IP >> >> > >Networks. >> >> > > >> >> > >Brian >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >> > >On Behalf >> >> > >> Of James M. Polk >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - >> >> FI/Espoo); 'ECRIT' >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >Agenda (my >> >> > >> mistake) >> >> > >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >> >> > >> > > James wrote: >> >> > >> > >> you are the _lone_ voice not supporting this ID, >> >> > >> > >> >> > >> >Listening to the audio recording of past meetings I have to >> >> > >say that >> >> > >> >I >> >> > >> was >> >> > >> >not the only persons raising concerns about the document. >> >> > >> >That was probably the reason why you agreed to limit the >> >> > >scope of the >> >> > >> >document (which you didn't later do) to get folks to agree >> >> > >to make it >> >> > >> a WG >> >> > >> >item. >> >> > >> >> >> > >> re-listen to the audio please >> >> > >> >> >> > >> Ted's concerns were consistent with most (all?) other >> >> concerns -- >> >> > >> which were based on the premise of whether or not the >> >> UAC should be >> >> > >> trusted to initiate the marking on the INVITE. The >> most recent >> >> > >> version has backed off this to a "can" -- meaning not >> >prohibited >> >> > >> (i.e., no 2119 text). I also backed off the text in the >> >> SP domain >> >> > >> part to "can", such that there is no 2119 text >> >mandating or even >> >> > >> recommending its usage there. I also do not prohibit its >> >> > >use, based on >> >> > >> local policy. Keith has come forward with the >> specific request >> >> > >> that non-ESInet networks be allowed to mark and pay >> >attention to >> >> > >> this priority indication -- with IMS as the specific >> example he >> >> > >> wishes to have this valid for. >> >> > >> >> >> > >> Where there is no disagreement, save for your recent >> >> > >pushback - is in >> >> > >> the ESInet, which is where Brian has requested it's >> >> > >definition in the >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within >> >> NENA, and if >> >> > >> he asks for it, are you going to say you know better than he? >> >> > >> >> >> > >> >> >> > >> >Btw, I not disagreeing with the document as such. I >> >just want to >> >> > the >> >> > >> scope >> >> > >> >to change. The usage of RPH within the emergency >> >> services network >> >> > is >> >> > >> fine >> >> > >> >for me. I may get convinced to start the RPH marking from >> >> > >the the VSP >> >> > >> >towards the PSAP. I feel uneasy about the end host doing >> >> > >the marking. >> >> > >> >> >> > >> please read what I wrote above, and then re-read the >> >most recent >> >> > >> version of the ID. I don't have endpoints that SHOULD or >> >> MUST mark >> >> > >> anything wrt RPH. I also don't want to prohibit it, >> >> because there >> >> > >> might be cases (that I don't know of) of valid uses >> >> under certain >> >> > >> circumstances. Figure 1 is very clear that there are 3 >> >> networking >> >> > >> parts to consider >> >> > >> >> >> > >> #1 - from the endpoint >> >> > >> #2 - within the VSP >> >> > >> #3 - within the ESInet >> >> > >> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and >> >> > >2119 language >> >> > >> offering those supporting this specification will have RPH >> >> > >> adherence within #3 (the ESInet). >> >> > >> >> >> > >> What other scope changes do you want, because I haven't >> >> heard them. >> >> > >> >> >> > >> I only heard you claim in email during the last IETF and in >> >> > >the ECRIT >> >> > >> session that RPH should not be used for priority marking >> >> requests. >> >> > >> This is something Keith (SIP WG chair) voiced his >> opposition to >> >> > >> your views regarding creating a second means for SIP to >> >priority >> >> > >> mark request "when SIP already has one interoperable way to >> >> > >> accomplish this... it's call the RP header mechanism". >> >> > >> >> >> > >> >I don't see advantages -- only disadvantages. >> >> > >> > >> >> > >> >Ciao >> >> > >> >Hannes >> >> > >> >> >> > >> _______________________________________________ >> >> > >> Ecrit mailing list >> >> > >> Ecrit@ietf.org >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > >> >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D7328C104; Fri, 6 Feb 2009 04:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.955 X-Spam-Level: X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id traesnLZ3ZTJ; Fri, 6 Feb 2009 04:11:13 -0800 (PST) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 5451D28C15C; Fri, 6 Feb 2009 04:11:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-164.messagelabs.com!1233922271!19997187!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 20316 invoked from network); 6 Feb 2009 12:11:13 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-9.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 12:11:13 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n16CBAj6007094; Fri, 6 Feb 2009 07:11:12 -0500 In-Reply-To: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> To: "Hannes Tschofenig" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Fri, 6 Feb 2009 07:11:11 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/06/2009 07:13:34 AM, Serialize complete at 02/06/2009 07:13:34 AM Content-Type: multipart/alternative; boundary="=_alternative 0042EC5F85257555_=" Cc: 'ECRIT' , ecrit-bounces@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 12:11:16 -0000 This is a multipart message in MIME format. --=_alternative 0042EC5F85257555_= Content-Type: text/plain; charset="US-ASCII" But there is nothing IN RFC4412 that specifically addresses how to prevent any particular namespace being used for DoS. Anyone/any UA can ATTEMPT to invoke priority treatment by attaching RPH. For all of the 4412 namespaces, as with the new proposed namespace, the mechanisms for preventing DoS are not specified in the document that defines the namespace. They are/will be specified elsewhere. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > Hi James, > > I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would > like to point out is that there is more than just a header and values within > the header that have to be considered in order to make a judgement of what > is appropriate and what isn't. There is an architectural question and > whether the environment we are using the stuff is indeed providing the > properties you need for the solution to be appropriate. > > Let me describe in more detail what I meant (and please correct me if I am > wrong). > > Getting priority for SIP requests when using a GETS alike scenario means > that the entity that issues the request is specially authorized since > otherwise you introduce a nice denial of service attack. This authorization > is tied to the entity that makes the request. For example, the person is > working for the government and has special rights. James Bond as a (not so) > secret agent might have these rights. > > The emergency services case (citizen-to-authority) is a bit different as > there aren't really special rights with respect to authorization tied to > individuals. Instead, the fact that something is an emergency is purely a > judgement of the human that dials a special number. To deal with fraud, we > discussed in the group on what we can actually do to ensure that end users > do not bypass security procedures (such as authorization checks, charging > and so on). Part of this investigation was the publication of > http://www.ietf.org/rfc/rfc5069.txt that also describes this issue. > > So, imagine the implementation of a SIP proxy (and we implemented that > stuff) that receives a call that contains a Service URN. The code branches > into a special mode where everything is done so that the call receives > appropriate treatment and does not get dropped on the floor. The way how the > Service URN is placed in the message ensures that the call cannot go to my > friend (instead of the PSAP) unless the end host ran LoST already. In the > latter case, we discussed this also on the list for a while and Richard even > wrote a draft about it in the context of the location hiding topic, we said > that the proxy would have to run LoST if he cares about a potential > fraudulent usage. > > So, what do we need todo in order to provide secure RFC 4412 functionality > in our context? > > Do you think that the current text in > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam > espace-00.txt reflects any of the above-described issues: > " > The Security considerations that apply to RFC 4412 [RFC4412] apply > here. This document introduces no new security issues relative to > RFC 4412. > " > > From various discussions in GEOPRIV I recall that you are super-sensitive > regarding security and privacy. For some reasons you don't seem to have the > same concerns here. I would like to understand your reasoning. > > Please also do me another favor: Don't always say that I don't understand > the subject. Even if that would be the case it isn't particular fair given > that different folks had to educate you on other topics in the past as well. > Additionally, if you listen to the audio recordings then you will notice > that Henning, Ted, and Jon do not seem to understand the issue either as > they have raised similar issues during the F2F meetings. > > Ciao > Hannes > > > >Hannes - I believe it is you who do not understand RFC 4412 -- > >and many of us are trying to get that through to you, but you > >don't seem to want to listen/read. > > > >RFC 4412 is *for* priority marking SIP requests, > > > >One use is GETS. > > > >One use is MLPP. > > > >These examples are in RFC 4412 because there were specific > >namespaces being created for the IANA section of that document. > > > >Reading the whole document, you will see that RPH can be > >specified for other uses than GETS or MLPP specifically. > > > >I knew when I wrote RFC 4412 that one day we would specify a > >namespace for ECRIT (the "esnet" namespace now) -- but I also > >knew it was premature for RFC 4412 to incorporate that > >namespace, that a future doc to RFC 4412 would have to be > >written to do this. Brian and I talked about this at the > >original NENA meeting that created the IP WGs there (in August > >of 03). We both agreed we should wait until it was > >appropriate to the work in the IETF to submit this document > >that is now > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >gency-rph-namespace-00.txt > > > >Yet, you seem to want to use some additional mechanism to > >indicate priority of a call in SIP. That means you want to > >introduce a second way to accomplish this in SIP. Why do you > >want to promote a separate way to do something SIP has already > >defined? That will cause interoperability issues and we both know that. > > > >You've said to me (and others) that you believe RPH is just > >another way to accomplish what sos or a URI can indicate - and > >you're wrong. Your way would be _the_second_way_to_do_it, > >because SIP already considers RPH to be *the*way* to priority > >mark SIP requests. > > > >If you don't believe me (no comment), then why do you not > >believe the SIP WG chair (who knows more about SIP than both > >of us) - who, on this thread, has again said to you "RFC 4412 > >(RPH) is the SIP mechanism to priority mark SIP requests"? > > > >Further, I believe it is inappropriate to prohibit endpoints > >from being able to set the esnet namespace. I absolutely > >believe it will not be needed most of the time, but I believe > >if someone does find a valid use for endpoints to mark > >priority in SIP, this ID - once it has become an RFC -- will > >have to be obsoleted with a new RFC saying the exact opposite. > > > >(color me confused ... over and over again) > > > >James > > > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>Keith, please understand that the usage of RFC 4412 for GETS and for > >>the type of emergency call we discuss here is different. Just looking > >>at the header and the name of the namespace is a bit > >artificial. I hope > >>you understand that. > >> > >> >-----Original Message----- > >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> >Sent: 05 February, 2009 14:55 > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >mistake) > >> > > >> >Which is exactly what RFC 4412 specifies for all namespaces. > >> > > >> >regards > >> > > >> >Keith > >> > > >> >> -----Original Message----- > >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf > >> >> Of Brian Rosen > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >Hannes (NSN > >> >> - FI/Espoo)'; 'ECRIT' > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> mistake) > >> >> > >> >> The value is that in some networks where priority for > >> >emergency calls > >> >> is appropriate, and appropriate policing of marking is > >implemented, > >> >> emergency calls will receive resource priority. > >> >> > >> >> Not all networks would need policing. Some will. Policing could > >> >> be to Route header/R-URI content, but other criteria are possible. > >> >> > >> >> Not all networks will need resource priority for emergency calls. > >> >> Fine, ignore this marking/namespace. > >> >> > >> >> Brian > >> >> > -----Original Message----- > >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - > >> >> > FI/Espoo); 'ECRIT' > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> > mistake) > >> >> > > >> >> > I don't even see the value in permitting the endpoint todo the > >> >> > RPH marking. > >> >> > In addition to the security concerns there is also the > >> >problem that > >> >> > there are more options to implement without an additional value. > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >> > >Sent: 05 February, 2009 00:03 > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> >> Hannes (NSN - > >> >> > >FI/Espoo)'; 'ECRIT' > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> > mistake) > >> >> > > > >> >> > >Hannes > >> >> > > > >> >> > >This matches my understanding precisely. We wish to > >> >> permit endpoints > >> >> > >to mark. We do not require it, and don't necessarily expect it > >> >> > >in many (even > >> >> > >most) cases. We don't wish to see the document prohibit it. > >> >> > >We all seem to agree it has value within the Emergency > >> >Services IP > >> >> > >Networks. > >> >> > > > >> >> > >Brian > >> >> > > > >> >> > >> -----Original Message----- > >> >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> > >On Behalf > >> >> > >> Of James M. Polk > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> >> FI/Espoo); 'ECRIT' > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (my > >> >> > >> mistake) > >> >> > >> > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> >> > >> > > James wrote: > >> >> > >> > >> you are the _lone_ voice not supporting this ID, > >> >> > >> > > >> >> > >> >Listening to the audio recording of past meetings I have to > >> >> > >say that > >> >> > >> >I > >> >> > >> was > >> >> > >> >not the only persons raising concerns about the document. > >> >> > >> >That was probably the reason why you agreed to limit the > >> >> > >scope of the > >> >> > >> >document (which you didn't later do) to get folks to agree > >> >> > >to make it > >> >> > >> a WG > >> >> > >> >item. > >> >> > >> > >> >> > >> re-listen to the audio please > >> >> > >> > >> >> > >> Ted's concerns were consistent with most (all?) other > >> >> concerns -- > >> >> > >> which were based on the premise of whether or not the > >> >> UAC should be > >> >> > >> trusted to initiate the marking on the INVITE. The most > >> >> > >> recent version has backed off this to a "can" -- meaning not > >> >prohibited > >> >> > >> (i.e., no 2119 text). I also backed off the text in the > >> >> SP domain > >> >> > >> part to "can", such that there is no 2119 text > >> >mandating or even > >> >> > >> recommending its usage there. I also do not prohibit its > >> >> > >use, based on > >> >> > >> local policy. Keith has come forward with the specific > >> >> > >> request that non-ESInet networks be allowed to mark and pay > >> >attention to > >> >> > >> this priority indication -- with IMS as the specific example > >> >> > >> he wishes to have this valid for. > >> >> > >> > >> >> > >> Where there is no disagreement, save for your recent > >> >> > >pushback - is in > >> >> > >> the ESInet, which is where Brian has requested it's > >> >> > >definition in the > >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> >> NENA, and if > >> >> > >> he asks for it, are you going to say you know better than he? > >> >> > >> > >> >> > >> > >> >> > >> >Btw, I not disagreeing with the document as such. I > >> >just want to > >> >> > the > >> >> > >> scope > >> >> > >> >to change. The usage of RPH within the emergency > >> >> services network > >> >> > is > >> >> > >> fine > >> >> > >> >for me. I may get convinced to start the RPH marking from > >> >> > >the the VSP > >> >> > >> >towards the PSAP. I feel uneasy about the end host doing > >> >> > >the marking. > >> >> > >> > >> >> > >> please read what I wrote above, and then re-read the > >> >most recent > >> >> > >> version of the ID. I don't have endpoints that SHOULD or > >> >> MUST mark > >> >> > >> anything wrt RPH. I also don't want to prohibit it, > >> >> because there > >> >> > >> might be cases (that I don't know of) of valid uses > >> >> under certain > >> >> > >> circumstances. Figure 1 is very clear that there are 3 > >> >> networking > >> >> > >> parts to consider > >> >> > >> > >> >> > >> #1 - from the endpoint > >> >> > >> #2 - within the VSP > >> >> > >> #3 - within the ESInet > >> >> > >> > >> >> > >> the most recent ID version has "can" for #s 1 and 2, and > >> >> > >2119 language > >> >> > >> offering those supporting this specification will have RPH > >> >> > >> adherence within #3 (the ESInet). > >> >> > >> > >> >> > >> What other scope changes do you want, because I haven't > >> >> heard them. > >> >> > >> > >> >> > >> I only heard you claim in email during the last IETF and in > >> >> > >the ECRIT > >> >> > >> session that RPH should not be used for priority marking > >> >> requests. > >> >> > >> This is something Keith (SIP WG chair) voiced his opposition > >> >> > >> to your views regarding creating a second means for SIP to > >> >priority > >> >> > >> mark request "when SIP already has one interoperable way to > >> >> > >> accomplish this... it's call the RP header mechanism". > >> >> > >> > >> >> > >> >I don't see advantages -- only disadvantages. > >> >> > >> > > >> >> > >> >Ciao > >> >> > >> >Hannes > >> >> > >> > >> >> > >> _______________________________________________ > >> >> > >> Ecrit mailing list > >> >> > >> Ecrit@ietf.org > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > > > >> >> > >> >> _______________________________________________ > >> >> Ecrit mailing list > >> >> Ecrit@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 0042EC5F85257555_= Content-Type: text/html; charset="US-ASCII"
But there is nothing IN RFC4412 that specifically addresses how to prevent any particular namespace being used for DoS.  Anyone/any UA can ATTEMPT to invoke priority treatment by attaching RPH.  For all of the 4412 namespaces, as with the new proposed namespace, the mechanisms for preventing DoS are not specified in the document that defines the namespace. They are/will be specified elsewhere.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM:

> Hi James,
>
> I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would
> like to point out is that there is more than just a header and values within
> the header that have to be considered in order to make a judgement of what
> is appropriate and what isn't. There is an architectural question and
> whether the environment we are using the stuff is indeed providing the
> properties you need for the solution to be appropriate.
>
> Let me describe in more detail what I meant (and please correct me if I am
> wrong).
>
> Getting priority for SIP requests when using a GETS alike scenario means
> that the entity that issues the request is specially authorized since
> otherwise you introduce a nice denial of service attack. This authorization
> is tied to the entity that makes the request. For example, the person is
> working for the government and has special rights. James Bond as a (not so)
> secret agent might have these rights.
>
> The emergency services case (citizen-to-authority) is a bit different as
> there aren't really special rights with respect to authorization tied to
> individuals. Instead, the fact that something is an emergency is purely a
> judgement of the human that dials a special number. To deal with fraud, we
> discussed in the group on what we can actually do to ensure that end users
> do not bypass security procedures (such as authorization checks, charging
> and so on). Part of this investigation was the publication of
> http://www.ietf.org/rfc/rfc5069.txt that also describes this issue.
>
> So, imagine the implementation of a SIP proxy (and we implemented that
> stuff) that receives a call that contains a Service URN. The code branches
> into a special mode where everything is done so that the call receives
> appropriate treatment and does not get dropped on the floor. The way how the
> Service URN is placed in the message ensures that the call cannot go to my
> friend (instead of the PSAP) unless the end host ran LoST already. In the
> latter case, we discussed this also on the list for a while and Richard even
> wrote a draft about it in the context of the location hiding topic, we said
> that the proxy would have to run LoST if he cares about a potential
> fraudulent usage.
>
> So, what do we need todo in order to provide secure RFC 4412 functionality
> in our context?
>
> Do you think that the current text in
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam
> espace-00.txt reflects any of the above-described issues:
> "
>    The Security considerations that apply to RFC 4412 [RFC4412] apply
>    here.  This document introduces no new security issues relative to
>    RFC 4412.
> "
>
> From various discussions in GEOPRIV I recall that you are super-sensitive
> regarding security and privacy. For some reasons you don't seem to have the
> same concerns here. I would like to understand your reasoning.
>
> Please also do me another favor: Don't always say that I don't understand
> the subject. Even if that would be the case it isn't particular fair given
> that different folks had to educate you on other topics in the past as well.
> Additionally, if you listen to the audio recordings then you will notice
> that Henning, Ted, and Jon do not seem to understand the issue either as
> they have raised similar issues during the F2F meetings.
>
> Ciao
> Hannes
>
>
> >Hannes - I believe it is you who do not understand RFC 4412 --
> >and many of us are trying to get that through to you, but you
> >don't seem to want to listen/read.
> >
> >RFC 4412 is *for* priority marking SIP requests,
> >
> >One use is GETS.
> >
> >One use is MLPP.
> >
> >These examples are in RFC 4412 because there were specific
> >namespaces being created for the IANA section of that document.
> >
> >Reading the whole document, you will see that RPH can be
> >specified for other uses than GETS or MLPP specifically.
> >
> >I knew when I wrote RFC 4412 that one day we would specify a
> >namespace for ECRIT (the "esnet" namespace now) -- but I also
> >knew it was premature for RFC 4412 to incorporate that
> >namespace, that a future doc to RFC 4412 would have to be
> >written to do this. Brian and I talked about this at the
> >original NENA meeting that created the IP WGs there (in August
> >of 03).  We both agreed we should wait until it was
> >appropriate to the work in the IETF to submit this document
> >that is now
> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer
> >gency-rph-namespace-00.txt
> >
> >Yet, you seem to want to use some additional mechanism to
> >indicate priority of a call in SIP.  That means you want to
> >introduce a second way to accomplish this in SIP.  Why do you
> >want to promote a separate way to do something SIP has already
> >defined? That will cause interoperability issues and we both know that.
> >
> >You've said to me (and others) that you believe RPH is just
> >another way to accomplish what sos or a URI can indicate - and
> >you're wrong.  Your way would be _the_second_way_to_do_it,
> >because SIP already considers RPH to be *the*way* to priority
> >mark SIP requests.
> >
> >If you don't believe me (no comment), then why do you not
> >believe the SIP WG chair (who knows more about SIP than both
> >of us) - who, on this thread, has again said to you "RFC 4412
> >(RPH) is the SIP mechanism to priority mark SIP requests"?
> >
> >Further, I believe it is inappropriate to prohibit endpoints
> >from being able to set the esnet namespace.  I absolutely
> >believe it will not be needed most of the time, but I believe
> >if someone does find a valid use for endpoints to mark
> >priority in SIP, this ID - once it has become an RFC -- will
> >have to be obsoleted with a new RFC saying the exact opposite.
> >
> >(color me confused ... over and over again)
> >
> >James
> >
> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote:
> >>Keith, please understand that the usage of RFC 4412 for GETS and for
> >>the type of emergency call we discuss here is different. Just looking
> >>at the header and the name of the namespace is a bit
> >artificial. I hope
> >>you understand that.
> >>
> >> >-----Original Message-----
> >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> >> >Sent: 05 February, 2009 14:55
> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >> >Hannes (NSN - FI/Espoo)'; 'ECRIT'
> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >mistake)
> >> >
> >> >Which is exactly what RFC 4412 specifies for all namespaces.
> >> >
> >> >regards
> >> >
> >> >Keith
> >> >
> >> >> -----Original Message-----
> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> >> >On Behalf
> >> >> Of Brian Rosen
> >> >> Sent: Wednesday, February 04, 2009 10:19 PM
> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig,
> >Hannes (NSN
> >> >> - FI/Espoo)'; 'ECRIT'
> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> mistake)
> >> >>
> >> >> The value is that in some networks where priority for
> >> >emergency calls
> >> >> is appropriate, and appropriate policing of marking is
> >implemented,
> >> >> emergency calls will receive resource priority.
> >> >>
> >> >> Not all networks would need policing.  Some will.  Policing could
> >> >> be to Route header/R-URI content, but other criteria are possible.
> >> >>
> >> >> Not all networks will need resource priority for emergency calls.
> >> >> Fine, ignore this marking/namespace.
> >> >>
> >> >> Brian
> >> >> > -----Original Message-----
> >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM
> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN -
> >> >> > FI/Espoo); 'ECRIT'
> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> > mistake)
> >> >> >
> >> >> > I don't even see the value in permitting the endpoint todo the
> >> >> > RPH marking.
> >> >> > In addition to the security concerns there is also the
> >> >problem that
> >> >> > there are more options to implement without an additional value.
> >> >> >
> >> >> > >-----Original Message-----
> >> >> > >From: Brian Rosen [mailto:br@brianrosen.net]
> >> >> > >Sent: 05 February, 2009 00:03
> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig,
> >> >> Hannes (NSN -
> >> >> > >FI/Espoo)'; 'ECRIT'
> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my
> >> >> > mistake)
> >> >> > >
> >> >> > >Hannes
> >> >> > >
> >> >> > >This matches my understanding precisely.  We wish to
> >> >> permit endpoints
> >> >> > >to mark. We do not require it, and don't necessarily expect it
> >> >> > >in many (even
> >> >> > >most) cases.  We don't wish to see the document prohibit it.
> >> >> > >We all seem to agree it has value within the Emergency
> >> >Services IP
> >> >> > >Networks.
> >> >> > >
> >> >> > >Brian
> >> >> > >
> >> >> > >> -----Original Message-----
> >> >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> >> >> > >On Behalf
> >> >> > >> Of James M. Polk
> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM
> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN -
> >> >> FI/Espoo); 'ECRIT'
> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting:
> >Agenda (my
> >> >> > >> mistake)
> >> >> > >>
> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote:
> >> >> > >> > > James wrote:
> >> >> > >> > >> you are the _lone_ voice not supporting this ID,
> >> >> > >> >
> >> >> > >> >Listening to the audio recording of past meetings I have to
> >> >> > >say that
> >> >> > >> >I
> >> >> > >> was
> >> >> > >> >not the only persons raising concerns about the document.
> >> >> > >> >That was probably the reason why you agreed to limit the
> >> >> > >scope of the
> >> >> > >> >document (which you didn't later do) to get folks to agree
> >> >> > >to make it
> >> >> > >> a WG
> >> >> > >> >item.
> >> >> > >>
> >> >> > >> re-listen to the audio please
> >> >> > >>
> >> >> > >> Ted's concerns were consistent with most (all?) other
> >> >> concerns --
> >> >> > >> which were based on the premise of whether or not the
> >> >> UAC should be
> >> >> > >> trusted to initiate the marking on the INVITE.  The most
> >> >> > >> recent version has backed off this to a "can" -- meaning not
> >> >prohibited
> >> >> > >> (i.e., no 2119 text).  I also backed off the text in the
> >> >> SP domain
> >> >> > >> part to "can", such that there is no 2119 text
> >> >mandating or even
> >> >> > >> recommending its usage there. I also do not prohibit its
> >> >> > >use, based on
> >> >> > >> local policy.  Keith has come forward with the specific
> >> >> > >> request that non-ESInet networks be allowed to mark and pay
> >> >attention to
> >> >> > >> this priority indication -- with IMS as the specific example
> >> >> > >> he wishes to have this valid for.
> >> >> > >>
> >> >> > >> Where there is no disagreement, save for your recent
> >> >> > >pushback - is in
> >> >> > >> the ESInet, which is where Brian has requested it's
> >> >> > >definition in the
> >> >> > >> IETF on behalf of NENA.  He's the i3 WG chair within
> >> >> NENA, and if
> >> >> > >> he asks for it, are you going to say you know better than he?
> >> >> > >>
> >> >> > >>
> >> >> > >> >Btw, I not disagreeing with the document as such. I
> >> >just want to
> >> >> > the
> >> >> > >> scope
> >> >> > >> >to change. The usage of RPH within the emergency
> >> >> services network
> >> >> > is
> >> >> > >> fine
> >> >> > >> >for me. I may get convinced to start the RPH marking from
> >> >> > >the the VSP
> >> >> > >> >towards the PSAP. I feel uneasy about the end host doing
> >> >> > >the marking.
> >> >> > >>
> >> >> > >> please read what I wrote above, and then re-read the
> >> >most recent
> >> >> > >> version of the ID. I don't have endpoints that SHOULD or
> >> >> MUST mark
> >> >> > >> anything wrt RPH.  I also don't want to prohibit it,
> >> >> because there
> >> >> > >> might be cases (that I don't know of) of valid uses
> >> >> under certain
> >> >> > >> circumstances.  Figure 1 is very clear that there are 3
> >> >> networking
> >> >> > >> parts to consider
> >> >> > >>
> >> >> > >> #1 - from the endpoint
> >> >> > >> #2 - within the VSP
> >> >> > >> #3 - within the ESInet
> >> >> > >>
> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and
> >> >> > >2119 language
> >> >> > >> offering those supporting this specification will have RPH
> >> >> > >> adherence within #3 (the ESInet).
> >> >> > >>
> >> >> > >> What other scope changes do you want, because I haven't
> >> >> heard them.
> >> >> > >>
> >> >> > >> I only heard you claim in email during the last IETF and in
> >> >> > >the ECRIT
> >> >> > >> session that RPH should not be used for priority marking
> >> >> requests.
> >> >> > >> This is something Keith (SIP WG chair) voiced his opposition
> >> >> > >> to your views regarding creating a second means for SIP to
> >> >priority
> >> >> > >> mark request "when SIP already has one interoperable way to
> >> >> > >> accomplish this... it's call the RP header mechanism".
> >> >> > >>
> >> >> > >> >I don't see advantages -- only disadvantages.
> >> >> > >> >
> >> >> > >> >Ciao
> >> >> > >> >Hannes
> >> >> > >>
> >> >> > >> _______________________________________________
> >> >> > >> Ecrit mailing list
> >> >> > >> Ecrit@ietf.org
> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >> > >
> >> >>
> >> >> _______________________________________________
> >> >> Ecrit mailing list
> >> >> Ecrit@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/ecrit
> >> >>
> >> >
> >
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
 --=_alternative 0042EC5F85257555_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB9028C1B1 for ; Fri, 6 Feb 2009 05:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfLBpd3mMEaf for ; Fri, 6 Feb 2009 05:06:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3D5EB28C10D for ; Fri, 6 Feb 2009 05:06:29 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 13:06:29 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp025) with SMTP; 06 Feb 2009 14:06:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+vK4YNeKOvZ7io7Po99ho8RS9Q1m+rqO3S2qKUIh ama/lVPkv47o/q From: "Hannes Tschofenig" To: "'Janet P Gunn'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> Date: Fri, 6 Feb 2009 15:07:15 +0200 Message-ID: <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.00 Cc: 'ECRIT' , ecrit-bounces@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 13:06:31 -0000 Who would define something that could prevent DoS problems? ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: 06 February, 2009 14:11 To: Hannes Tschofenig Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); 'James M. Polk' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) But there is nothing IN RFC4412 that specifically addresses how to prevent any particular namespace being used for DoS. Anyone/any UA can ATTEMPT to invoke priority treatment by attaching RPH. For all of the 4412 namespaces, as with the new proposed namespace, the mechanisms for preventing DoS are not specified in the document that defines the namespace. They are/will be specified elsewhere. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > Hi James, > > I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would > like to point out is that there is more than just a header and values within > the header that have to be considered in order to make a judgement of what > is appropriate and what isn't. There is an architectural question and > whether the environment we are using the stuff is indeed providing the > properties you need for the solution to be appropriate. > > Let me describe in more detail what I meant (and please correct me if I am > wrong). > > Getting priority for SIP requests when using a GETS alike scenario means > that the entity that issues the request is specially authorized since > otherwise you introduce a nice denial of service attack. This authorization > is tied to the entity that makes the request. For example, the person is > working for the government and has special rights. James Bond as a (not so) > secret agent might have these rights. > > The emergency services case (citizen-to-authority) is a bit different as > there aren't really special rights with respect to authorization tied to > individuals. Instead, the fact that something is an emergency is purely a > judgement of the human that dials a special number. To deal with fraud, we > discussed in the group on what we can actually do to ensure that end users > do not bypass security procedures (such as authorization checks, charging > and so on). Part of this investigation was the publication of > http://www.ietf.org/rfc/rfc5069.txt that also describes this issue. > > So, imagine the implementation of a SIP proxy (and we implemented that > stuff) that receives a call that contains a Service URN. The code branches > into a special mode where everything is done so that the call receives > appropriate treatment and does not get dropped on the floor. The way how the > Service URN is placed in the message ensures that the call cannot go to my > friend (instead of the PSAP) unless the end host ran LoST already. In the > latter case, we discussed this also on the list for a while and Richard even > wrote a draft about it in the context of the location hiding topic, we said > that the proxy would have to run LoST if he cares about a potential > fraudulent usage. > > So, what do we need todo in order to provide secure RFC 4412 functionality > in our context? > > Do you think that the current text in > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam > espace-00.txt reflects any of the above-described issues: > " > The Security considerations that apply to RFC 4412 [RFC4412] apply > here. This document introduces no new security issues relative to > RFC 4412. > " > > From various discussions in GEOPRIV I recall that you are super-sensitive > regarding security and privacy. For some reasons you don't seem to have the > same concerns here. I would like to understand your reasoning. > > Please also do me another favor: Don't always say that I don't understand > the subject. Even if that would be the case it isn't particular fair given > that different folks had to educate you on other topics in the past as well. > Additionally, if you listen to the audio recordings then you will notice > that Henning, Ted, and Jon do not seem to understand the issue either as > they have raised similar issues during the F2F meetings. > > Ciao > Hannes > > > >Hannes - I believe it is you who do not understand RFC 4412 -- > >and many of us are trying to get that through to you, but you > >don't seem to want to listen/read. > > > >RFC 4412 is *for* priority marking SIP requests, > > > >One use is GETS. > > > >One use is MLPP. > > > >These examples are in RFC 4412 because there were specific > >namespaces being created for the IANA section of that document. > > > >Reading the whole document, you will see that RPH can be > >specified for other uses than GETS or MLPP specifically. > > > >I knew when I wrote RFC 4412 that one day we would specify a > >namespace for ECRIT (the "esnet" namespace now) -- but I also > >knew it was premature for RFC 4412 to incorporate that > >namespace, that a future doc to RFC 4412 would have to be > >written to do this. Brian and I talked about this at the > >original NENA meeting that created the IP WGs there (in August > >of 03). We both agreed we should wait until it was > >appropriate to the work in the IETF to submit this document > >that is now > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >gency-rph-namespace-00.txt > > > >Yet, you seem to want to use some additional mechanism to > >indicate priority of a call in SIP. That means you want to > >introduce a second way to accomplish this in SIP. Why do you > >want to promote a separate way to do something SIP has already > >defined? That will cause interoperability issues and we both know that. > > > >You've said to me (and others) that you believe RPH is just > >another way to accomplish what sos or a URI can indicate - and > >you're wrong. Your way would be _the_second_way_to_do_it, > >because SIP already considers RPH to be *the*way* to priority > >mark SIP requests. > > > >If you don't believe me (no comment), then why do you not > >believe the SIP WG chair (who knows more about SIP than both > >of us) - who, on this thread, has again said to you "RFC 4412 > >(RPH) is the SIP mechanism to priority mark SIP requests"? > > > >Further, I believe it is inappropriate to prohibit endpoints > >from being able to set the esnet namespace. I absolutely > >believe it will not be needed most of the time, but I believe > >if someone does find a valid use for endpoints to mark > >priority in SIP, this ID - once it has become an RFC -- will > >have to be obsoleted with a new RFC saying the exact opposite. > > > >(color me confused ... over and over again) > > > >James > > > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>Keith, please understand that the usage of RFC 4412 for GETS and for > >>the type of emergency call we discuss here is different. Just looking > >>at the header and the name of the namespace is a bit > >artificial. I hope > >>you understand that. > >> > >> >-----Original Message----- > >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> >Sent: 05 February, 2009 14:55 > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >mistake) > >> > > >> >Which is exactly what RFC 4412 specifies for all namespaces. > >> > > >> >regards > >> > > >> >Keith > >> > > >> >> -----Original Message----- > >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf > >> >> Of Brian Rosen > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >Hannes (NSN > >> >> - FI/Espoo)'; 'ECRIT' > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> mistake) > >> >> > >> >> The value is that in some networks where priority for > >> >emergency calls > >> >> is appropriate, and appropriate policing of marking is > >implemented, > >> >> emergency calls will receive resource priority. > >> >> > >> >> Not all networks would need policing. Some will. Policing could > >> >> be to Route header/R-URI content, but other criteria are possible. > >> >> > >> >> Not all networks will need resource priority for emergency calls. > >> >> Fine, ignore this marking/namespace. > >> >> > >> >> Brian > >> >> > -----Original Message----- > >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - > >> >> > FI/Espoo); 'ECRIT' > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> > mistake) > >> >> > > >> >> > I don't even see the value in permitting the endpoint todo the > >> >> > RPH marking. > >> >> > In addition to the security concerns there is also the > >> >problem that > >> >> > there are more options to implement without an additional value. > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >> > >Sent: 05 February, 2009 00:03 > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> >> Hannes (NSN - > >> >> > >FI/Espoo)'; 'ECRIT' > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> > mistake) > >> >> > > > >> >> > >Hannes > >> >> > > > >> >> > >This matches my understanding precisely. We wish to > >> >> permit endpoints > >> >> > >to mark. We do not require it, and don't necessarily expect it > >> >> > >in many (even > >> >> > >most) cases. We don't wish to see the document prohibit it. > >> >> > >We all seem to agree it has value within the Emergency > >> >Services IP > >> >> > >Networks. > >> >> > > > >> >> > >Brian > >> >> > > > >> >> > >> -----Original Message----- > >> >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> > >On Behalf > >> >> > >> Of James M. Polk > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> >> FI/Espoo); 'ECRIT' > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (my > >> >> > >> mistake) > >> >> > >> > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> >> > >> > > James wrote: > >> >> > >> > >> you are the _lone_ voice not supporting this ID, > >> >> > >> > > >> >> > >> >Listening to the audio recording of past meetings I have to > >> >> > >say that > >> >> > >> >I > >> >> > >> was > >> >> > >> >not the only persons raising concerns about the document. > >> >> > >> >That was probably the reason why you agreed to limit the > >> >> > >scope of the > >> >> > >> >document (which you didn't later do) to get folks to agree > >> >> > >to make it > >> >> > >> a WG > >> >> > >> >item. > >> >> > >> > >> >> > >> re-listen to the audio please > >> >> > >> > >> >> > >> Ted's concerns were consistent with most (all?) other > >> >> concerns -- > >> >> > >> which were based on the premise of whether or not the > >> >> UAC should be > >> >> > >> trusted to initiate the marking on the INVITE. The most > >> >> > >> recent version has backed off this to a "can" -- meaning not > >> >prohibited > >> >> > >> (i.e., no 2119 text). I also backed off the text in the > >> >> SP domain > >> >> > >> part to "can", such that there is no 2119 text > >> >mandating or even > >> >> > >> recommending its usage there. I also do not prohibit its > >> >> > >use, based on > >> >> > >> local policy. Keith has come forward with the specific > >> >> > >> request that non-ESInet networks be allowed to mark and pay > >> >attention to > >> >> > >> this priority indication -- with IMS as the specific example > >> >> > >> he wishes to have this valid for. > >> >> > >> > >> >> > >> Where there is no disagreement, save for your recent > >> >> > >pushback - is in > >> >> > >> the ESInet, which is where Brian has requested it's > >> >> > >definition in the > >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> >> NENA, and if > >> >> > >> he asks for it, are you going to say you know better than he? > >> >> > >> > >> >> > >> > >> >> > >> >Btw, I not disagreeing with the document as such. I > >> >just want to > >> >> > the > >> >> > >> scope > >> >> > >> >to change. The usage of RPH within the emergency > >> >> services network > >> >> > is > >> >> > >> fine > >> >> > >> >for me. I may get convinced to start the RPH marking from > >> >> > >the the VSP > >> >> > >> >towards the PSAP. I feel uneasy about the end host doing > >> >> > >the marking. > >> >> > >> > >> >> > >> please read what I wrote above, and then re-read the > >> >most recent > >> >> > >> version of the ID. I don't have endpoints that SHOULD or > >> >> MUST mark > >> >> > >> anything wrt RPH. I also don't want to prohibit it, > >> >> because there > >> >> > >> might be cases (that I don't know of) of valid uses > >> >> under certain > >> >> > >> circumstances. Figure 1 is very clear that there are 3 > >> >> networking > >> >> > >> parts to consider > >> >> > >> > >> >> > >> #1 - from the endpoint > >> >> > >> #2 - within the VSP > >> >> > >> #3 - within the ESInet > >> >> > >> > >> >> > >> the most recent ID version has "can" for #s 1 and 2, and > >> >> > >2119 language > >> >> > >> offering those supporting this specification will have RPH > >> >> > >> adherence within #3 (the ESInet). > >> >> > >> > >> >> > >> What other scope changes do you want, because I haven't > >> >> heard them. > >> >> > >> > >> >> > >> I only heard you claim in email during the last IETF and in > >> >> > >the ECRIT > >> >> > >> session that RPH should not be used for priority marking > >> >> requests. > >> >> > >> This is something Keith (SIP WG chair) voiced his opposition > >> >> > >> to your views regarding creating a second means for SIP to > >> >priority > >> >> > >> mark request "when SIP already has one interoperable way to > >> >> > >> accomplish this... it's call the RP header mechanism". > >> >> > >> > >> >> > >> >I don't see advantages -- only disadvantages. > >> >> > >> > > >> >> > >> >Ciao > >> >> > >> >Hannes > >> >> > >> > >> >> > >> _______________________________________________ > >> >> > >> Ecrit mailing list > >> >> > >> Ecrit@ietf.org > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > > > >> >> > >> >> _______________________________________________ > >> >> Ecrit mailing list > >> >> Ecrit@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E763A6ACE for ; Fri, 6 Feb 2009 05:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z37v8C7q6oUd for ; Fri, 6 Feb 2009 05:47:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D7D933A6BA0 for ; Fri, 6 Feb 2009 05:47:01 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 13:40:21 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp058) with SMTP; 06 Feb 2009 14:40:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+5zWBuKIC5TSq3BmyZUaFw20oO1NHcbz+/z9bLlq /wpG0UdersQBUa From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , "'Janet P Gunn'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> Date: Fri, 6 Feb 2009 15:41:06 +0200 Message-ID: <001f01c98860$910658c0$49b5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFgAAA2fKA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' , ecrit-bounces@ietf.org Subject: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 13:47:02 -0000 Over lunch I was also thinking how an outbound proxy would implement some of the emergency procedures. Here are some thoughts: --------------------------------------------------- // Process incoming message Parse(msg); // SIP INVITE without Service URN // legacy devices If (recognize-dialstring(msg)==TRUE) { // we got an emergency call going on emergency=TRUE; if (dialstring(msg) == 911) serviceURN=urn:service:sos; } else if (recognize-serviceURN(msg)==TRUE) { // oh. A updated device that has a service URN attached to the call serviceURN=retrieve_ServiceURN(msg); emergency=TRUE; } else { // standard SIP message // regular processing process(msg); emergency=FALSE; } If (emergency == TRUE) { // make sure that the emergency call does not get dropped on the floor // skip authorization failures // give the call a special treatment lots-of-code-here(); // trigger all the QoS signaling you have in the network to make James happy trigger-qos(); // query location location=retrieve-location(); // determine next hop next-hop=lost(location, serviceURN) // attach RPH marking to outgoing msg to make James and Keith happy msg=add(msg, RPH); send(msg, next-hop); } If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { // all the emergency related processing done already upfront // hence I log something. log(RPH_WAS_PRESENT_JUHU); } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) { // this is not an emergency call // this is something like GETS result=special-authorization-procedure(user); if (result == AUTHORIZED) { // do some priority & preemption thing here. // trigger all the QoS you have lots-of-code-here(); } else { log("NOT AUTHORIZED; don't DoS my network"); } } else { // don't need todo any RPH processing // this includes the case where the call was an emergency call but the RPH // marking was not there. nothing(); } --------------------------------------------------- Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Hannes Tschofenig >Sent: 06 February, 2009 15:07 >To: 'Janet P Gunn' >Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - FI/Espoo) >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > >Who would define something that could prevent DoS problems? > >________________________________ > > From: Janet P Gunn [mailto:jgunn6@csc.com] > Sent: 06 February, 2009 14:11 > To: Hannes Tschofenig > Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >'James M. Polk' > Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > > > > But there is nothing IN RFC4412 that specifically >addresses how to prevent any particular namespace being used >for DoS. Anyone/any UA can ATTEMPT to invoke priority >treatment by attaching RPH. For all of the 4412 namespaces, >as with the new proposed namespace, the mechanisms for >preventing DoS are not specified in the document that defines >the namespace. >They are/will be specified elsewhere. > > Janet > > This is a PRIVATE message. If you are not the intended >recipient, please delete without copying and kindly advise us >by e-mail of the mistake in delivery. > NOTE: Regardless of content, this e-mail shall not >operate to bind CSC to any order or other contract unless >pursuant to explicit written agreement or government >initiative expressly permitting the use of e-mail for such purpose. > > ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > > > Hi James, > > > > I have read RFC 4412 and also the GETS/MLPP IETF >documents. What I would > > like to point out is that there is more than just a >header and values within > > the header that have to be considered in order to >make a judgement of what > > is appropriate and what isn't. There is an >architectural question and > > whether the environment we are using the stuff is >indeed providing the > > properties you need for the solution to be appropriate. > > > > Let me describe in more detail what I meant (and >please correct me if I am > > wrong). > > > > Getting priority for SIP requests when using a GETS >alike scenario means > > that the entity that issues the request is specially >authorized since > > otherwise you introduce a nice denial of service >attack. This authorization > > is tied to the entity that makes the request. For >example, the person is > > working for the government and has special rights. >James Bond as a (not so) > > secret agent might have these rights. > > > > The emergency services case (citizen-to-authority) is >a bit different as > > there aren't really special rights with respect to >authorization tied to > > individuals. Instead, the fact that something is an >emergency is purely a > > judgement of the human that dials a special number. >To deal with fraud, we > > discussed in the group on what we can actually do to >ensure that end users > > do not bypass security procedures (such as >authorization checks, charging > > and so on). Part of this investigation was the publication of > > http://www.ietf.org/rfc/rfc5069.txt that also >describes this issue. > > > > So, imagine the implementation of a SIP proxy (and we >implemented that > > stuff) that receives a call that contains a Service >URN. The code branches > > into a special mode where everything is done so that >the call receives > > appropriate treatment and does not get dropped on the >floor. The way how the > > Service URN is placed in the message ensures that the >call cannot go to my > > friend (instead of the PSAP) unless the end host ran >LoST already. >In the > > latter case, we discussed this also on the list for a >while and Richard even > > wrote a draft about it in the context of the location >hiding topic, we said > > that the proxy would have to run LoST if he cares >about a potential > > fraudulent usage. > > > > So, what do we need todo in order to provide secure >RFC 4412 functionality > > in our context? > > > > Do you think that the current text in > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >gency-rph-nam > > espace-00.txt reflects any of the above-described issues: > > " > > The Security considerations that apply to RFC 4412 >[RFC4412] >apply > > here. This document introduces no new security >issues relative >to > > RFC 4412. > > " > > > > From various discussions in GEOPRIV I recall that you >are super-sensitive > > regarding security and privacy. For some reasons you >don't seem to have the > > same concerns here. I would like to understand your reasoning. > > > > Please also do me another favor: Don't always say >that I don't understand > > the subject. Even if that would be the case it isn't >particular fair given > > that different folks had to educate you on other >topics in the past as well. > > Additionally, if you listen to the audio recordings >then you will notice > > that Henning, Ted, and Jon do not seem to understand >the issue either as > > they have raised similar issues during the F2F meetings. > > > > Ciao > > Hannes > > > > > > >Hannes - I believe it is you who do not understand >RFC 4412 -- > > >and many of us are trying to get that through to >you, but you > > >don't seem to want to listen/read. > > > > > >RFC 4412 is *for* priority marking SIP requests, > > > > > >One use is GETS. > > > > > >One use is MLPP. > > > > > >These examples are in RFC 4412 because there were specific > > >namespaces being created for the IANA section of >that document. > > > > > >Reading the whole document, you will see that RPH can be > > >specified for other uses than GETS or MLPP specifically. > > > > > >I knew when I wrote RFC 4412 that one day we would specify a > > >namespace for ECRIT (the "esnet" namespace now) -- >but I also > > >knew it was premature for RFC 4412 to incorporate that > > >namespace, that a future doc to RFC 4412 would have to be > > >written to do this. Brian and I talked about this at the > > >original NENA meeting that created the IP WGs there >(in August > > >of 03). We both agreed we should wait until it was > > >appropriate to the work in the IETF to submit this document > > >that is now > > >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > > >gency-rph-namespace-00.txt > > > > > >Yet, you seem to want to use some additional mechanism to > > >indicate priority of a call in SIP. That means you want to > > >introduce a second way to accomplish this in SIP. >Why do you > > >want to promote a separate way to do something SIP >has already > > >defined? That will cause interoperability issues and >we both know that. > > > > > >You've said to me (and others) that you believe RPH is just > > >another way to accomplish what sos or a URI can >indicate - and > > >you're wrong. Your way would be _the_second_way_to_do_it, > > >because SIP already considers RPH to be *the*way* to >priority > > >mark SIP requests. > > > > > >If you don't believe me (no comment), then why do you not > > >believe the SIP WG chair (who knows more about SIP than both > > >of us) - who, on this thread, has again said to you >"RFC 4412 > > >(RPH) is the SIP mechanism to priority mark SIP requests"? > > > > > >Further, I believe it is inappropriate to prohibit endpoints > > >from being able to set the esnet namespace. I absolutely > > >believe it will not be needed most of the time, but >I believe > > >if someone does find a valid use for endpoints to mark > > >priority in SIP, this ID - once it has become an RFC -- will > > >have to be obsoleted with a new RFC saying the exact >opposite. > > > > > >(color me confused ... over and over again) > > > > > >James > > > > > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > > >>Keith, please understand that the usage of RFC 4412 >for GETS and for > > >>the type of emergency call we discuss here is >different. Just looking > > >>at the header and the name of the namespace is a bit > > >artificial. I hope > > >>you understand that. > > >> > > >> >-----Original Message----- > > >> >From: DRAGE, Keith (Keith) >[mailto:drage@alcatel-lucent.com] > > >> >Sent: 05 February, 2009 14:55 > > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >Polk'; 'Tschofenig, > > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >Meeting: Agenda (my > > > >> >mistake) > > >> > > > >> >Which is exactly what RFC 4412 specifies for all >namespaces. > > >> > > > >> >regards > > >> > > > >> >Keith > > >> > > > >> >> -----Original Message----- > > >> >> From: ecrit-bounces@ietf.org >[mailto:ecrit-bounces@ietf.org] > > >> >On Behalf > > >> >> Of Brian Rosen > > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > > >Hannes (NSN > > >> >> - FI/Espoo)'; 'ECRIT' > > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >Meeting: Agenda (my > > >> >> mistake) > > >> >> > > >> >> The value is that in some networks where priority for > > >> >emergency calls > > >> >> is appropriate, and appropriate policing of marking is > > >implemented, > > >> >> emergency calls will receive resource priority. > > >> >> > > >> >> Not all networks would need policing. Some >will. Policing could > > >> >> be to Route header/R-URI content, but other >criteria are possible. > > >> >> > > >> >> Not all networks will need resource priority >for emergency calls. > > >> >> Fine, ignore this marking/namespace. > > >> >> > > >> >> Brian > > >> >> > -----Original Message----- > > >> >> > From: Hannes Tschofenig >[mailto:Hannes.Tschofenig@gmx.net] > > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >Tschofenig, Hannes (NSN - > > >> >> > FI/Espoo); 'ECRIT' > > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >Meeting: Agenda (my > > >> >> > mistake) > > >> >> > > > >> >> > I don't even see the value in permitting the >endpoint todo the > > >> >> > RPH marking. > > >> >> > In addition to the security concerns there is also the > > >> >problem that > > >> >> > there are more options to implement without >an additional value. > > >> >> > > > >> >> > >-----Original Message----- > > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > > >> >> > >Sent: 05 February, 2009 00:03 > > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >'Tschofenig, > > >> >> Hannes (NSN - > > >> >> > >FI/Espoo)'; 'ECRIT' > > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: >Agenda (my > > >> >> > mistake) > > >> >> > > > > >> >> > >Hannes > > >> >> > > > > >> >> > >This matches my understanding precisely. We wish to > > >> >> permit endpoints > > >> >> > >to mark. We do not require it, and don't >necessarily expect it > > >> >> > >in many (even > > >> >> > >most) cases. We don't wish to see the >document prohibit it. > > >> >> > >We all seem to agree it has value within the >Emergency > > >> >Services IP > > >> >> > >Networks. > > >> >> > > > > >> >> > >Brian > > >> >> > > > > >> >> > >> -----Original Message----- > > >> >> > >> From: ecrit-bounces@ietf.org >[mailto:ecrit-bounces@ietf.org] > > >> >> > >On Behalf > > >> >> > >> Of James M. Polk > > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > > >> >> FI/Espoo); 'ECRIT' > > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >Meeting: > > >Agenda (my > > >> >> > >> mistake) > > >> >> > >> > > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > > >> >> > >> > > James wrote: > > >> >> > >> > >> you are the _lone_ voice not >supporting this ID, > > >> >> > >> > > > >> >> > >> >Listening to the audio recording of past >meetings I have to > > >> >> > >say that > > >> >> > >> >I > > >> >> > >> was > > >> >> > >> >not the only persons raising concerns >about the document. > > >> >> > >> >That was probably the reason why you >agreed to limit the > > >> >> > >scope of the > > >> >> > >> >document (which you didn't later do) to >get folks to agree > > >> >> > >to make it > > >> >> > >> a WG > > >> >> > >> >item. > > >> >> > >> > > >> >> > >> re-listen to the audio please > > >> >> > >> > > >> >> > >> Ted's concerns were consistent with most >(all?) other > > >> >> concerns -- > > >> >> > >> which were based on the premise of whether >or not the > > >> >> UAC should be > > >> >> > >> trusted to initiate the marking on the >INVITE. The most > > >> >> > >> recent version has backed off this to a >"can" -- meaning not > > >> >prohibited > > >> >> > >> (i.e., no 2119 text). I also backed off >the text in the > > >> >> SP domain > > >> >> > >> part to "can", such that there is no 2119 text > > >> >mandating or even > > >> >> > >> recommending its usage there. I also do >not prohibit its > > >> >> > >use, based on > > >> >> > >> local policy. Keith has come forward with >the specific > > > >> >> > >> request that non-ESInet networks be >allowed to mark and pay > > >> >attention to > > >> >> > >> this priority indication -- with IMS as >the specific example > > >> >> > >> he wishes to have this valid for. > > >> >> > >> > > >> >> > >> Where there is no disagreement, save for >your recent > > >> >> > >pushback - is in > > >> >> > >> the ESInet, which is where Brian has requested it's > > >> >> > >definition in the > > >> >> > >> IETF on behalf of NENA. He's the i3 WG >chair within > > >> >> NENA, and if > > >> >> > >> he asks for it, are you going to say you >know better than he? > > >> >> > >> > > >> >> > >> > > >> >> > >> >Btw, I not disagreeing with the document >as such. I > > >> >just want to > > >> >> > the > > >> >> > >> scope > > >> >> > >> >to change. The usage of RPH within the emergency > > >> >> services network > > >> >> > is > > >> >> > >> fine > > >> >> > >> >for me. I may get convinced to start the >RPH marking from > > >> >> > >the the VSP > > >> >> > >> >towards the PSAP. I feel uneasy about the >end host doing > > >> >> > >the marking. > > >> >> > >> > > >> >> > >> please read what I wrote above, and then >re-read the > > >> >most recent > > >> >> > >> version of the ID. I don't have endpoints >that SHOULD or > > >> >> MUST mark > > >> >> > >> anything wrt RPH. I also don't want to >prohibit it, > > >> >> because there > > >> >> > >> might be cases (that I don't know of) of valid uses > > >> >> under certain > > >> >> > >> circumstances. Figure 1 is very clear >that there are 3 > > >> >> networking > > >> >> > >> parts to consider > > >> >> > >> > > >> >> > >> #1 - from the endpoint > > >> >> > >> #2 - within the VSP > > >> >> > >> #3 - within the ESInet > > >> >> > >> > > >> >> > >> the most recent ID version has "can" for >#s 1 and 2, and > > >> >> > >2119 language > > >> >> > >> offering those supporting this >specification will have RPH > > >> >> > >> adherence within #3 (the ESInet). > > >> >> > >> > > >> >> > >> What other scope changes do you want, >because I haven't > > >> >> heard them. > > >> >> > >> > > >> >> > >> I only heard you claim in email during the >last IETF and in > > >> >> > >the ECRIT > > >> >> > >> session that RPH should not be used for >priority marking > > >> >> requests. > > >> >> > >> This is something Keith (SIP WG chair) >voiced his opposition > > >> >> > >> to your views regarding creating a second >means for SIP to > > >> >priority > > >> >> > >> mark request "when SIP already has one >interoperable way to > > >> >> > >> accomplish this... it's call the RP header >mechanism". > > >> >> > >> > > >> >> > >> >I don't see advantages -- only disadvantages. > > >> >> > >> > > > >> >> > >> >Ciao > > >> >> > >> >Hannes > > >> >> > >> > > >> >> > >> _______________________________________________ > > >> >> > >> Ecrit mailing list > > >> >> > >> Ecrit@ietf.org > > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > > >> >> > > > > >> >> > > >> >> _______________________________________________ > > >> >> Ecrit mailing list > > >> >> Ecrit@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/ecrit > > >> >> > > >> > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F653A6952; Fri, 6 Feb 2009 06:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlqH5AEm5MFw; Fri, 6 Feb 2009 06:59:55 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B09D93A63EB; Fri, 6 Feb 2009 06:59:55 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LVSBI-0004lo-V1; Fri, 06 Feb 2009 08:59:50 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Janet P Gunn'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> In-Reply-To: <001f01c98860$910658c0$49b5b70a@nsnintra.net> Date: Fri, 6 Feb 2009 09:58:47 -0500 Message-ID: <0d6901c9886b$6c9bfc50$45d3f4f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFgAAA2fKAAAyK5gA== Content-Language: en-us 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: Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:59:58 -0000 Hannes You need to talk to people who really implement this kind of thing. You are way off. When you implement a resource priority system, the point of doing that is to look though the queue of work and pick out the ones with priority, handling them first. You don't do all the parsing, you don't do a lot of decision tree. Typically: Check for DoS things, like too big messages, etc Do a quick scan for the RPH message header If found: Parse the message Determine validity Determine priority Queue on the correct work queue The first two actions have to be very fast. Anyone who builds a SIP thingie will tell you that parsing is one of the big cycle consumers: if you have to parse every message BEFORE you determine priority, you can't give much resource priority. Once you get the whole message parsed, you might as well finish working on it, because you've done so much of the work. OTHOH, finding the end-of-message delimiter and doing a quick string search for RPH is fast. If you are doing priority, you need to keep all the priority processing pretty uniform, and pretty simple, or you tend to spend too much time futzing around figuring out what to do. You put all the priority related stuff together, and use as much common code as possible. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Friday, February 06, 2009 8:41 AM > To: 'Hannes Tschofenig'; 'Janet P Gunn' > Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > bounces@ietf.org > Subject: [Ecrit] RPH > > Over lunch I was also thinking how an outbound proxy would implement > some of > the emergency procedures. Here are some thoughts: > > --------------------------------------------------- > > // Process incoming message > Parse(msg); > > // SIP INVITE without Service URN > // legacy devices > If (recognize-dialstring(msg)==TRUE) { > // we got an emergency call going on > emergency=TRUE; > if (dialstring(msg) == 911) serviceURN=urn:service:sos; > } else if (recognize-serviceURN(msg)==TRUE) { > // oh. A updated device that has a service URN attached to the call > serviceURN=retrieve_ServiceURN(msg); > emergency=TRUE; > } else { > // standard SIP message > // regular processing > process(msg); > emergency=FALSE; > } > > If (emergency == TRUE) { > // make sure that the emergency call does not get dropped on the > floor > // skip authorization failures > // give the call a special treatment > lots-of-code-here(); > > // trigger all the QoS signaling you have in the network to make > James > happy > trigger-qos(); > > // query location > location=retrieve-location(); > > // determine next hop > next-hop=lost(location, serviceURN) > > // attach RPH marking to outgoing msg to make James and Keith happy > msg=add(msg, RPH); > > send(msg, next-hop); > } > > If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { > // all the emergency related processing done already upfront > // hence I log something. > log(RPH_WAS_PRESENT_JUHU); > } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) { > // this is not an emergency call > // this is something like GETS > result=special-authorization-procedure(user); > > if (result == AUTHORIZED) { > // do some priority & preemption thing here. > // trigger all the QoS you have > lots-of-code-here(); > } else { > log("NOT AUTHORIZED; don't DoS my network"); > } > } else { > // don't need todo any RPH processing > // this includes the case where the call was an emergency call but > the RPH > > // marking was not there. > nothing(); > } > > --------------------------------------------------- > > > Ciao > Hannes > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Hannes Tschofenig > >Sent: 06 February, 2009 15:07 > >To: 'Janet P Gunn' > >Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > FI/Espoo) > >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > > > >Who would define something that could prevent DoS problems? > > > >________________________________ > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > Sent: 06 February, 2009 14:11 > > To: Hannes Tschofenig > > Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); > >'James M. Polk' > > Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > > > > > > > > But there is nothing IN RFC4412 that specifically > >addresses how to prevent any particular namespace being used > >for DoS. Anyone/any UA can ATTEMPT to invoke priority > >treatment by attaching RPH. For all of the 4412 namespaces, > >as with the new proposed namespace, the mechanisms for > >preventing DoS are not specified in the document that defines > >the namespace. > >They are/will be specified elsewhere. > > > > Janet > > > > This is a PRIVATE message. If you are not the intended > >recipient, please delete without copying and kindly advise us > >by e-mail of the mistake in delivery. > > NOTE: Regardless of content, this e-mail shall not > >operate to bind CSC to any order or other contract unless > >pursuant to explicit written agreement or government > >initiative expressly permitting the use of e-mail for such purpose. > > > > ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > > > > > Hi James, > > > > > > I have read RFC 4412 and also the GETS/MLPP IETF > >documents. What I would > > > like to point out is that there is more than just a > >header and values within > > > the header that have to be considered in order to > >make a judgement of what > > > is appropriate and what isn't. There is an > >architectural question and > > > whether the environment we are using the stuff is > >indeed providing the > > > properties you need for the solution to be appropriate. > > > > > > Let me describe in more detail what I meant (and > >please correct me if I am > > > wrong). > > > > > > Getting priority for SIP requests when using a GETS > >alike scenario means > > > that the entity that issues the request is specially > >authorized since > > > otherwise you introduce a nice denial of service > >attack. This authorization > > > is tied to the entity that makes the request. For > >example, the person is > > > working for the government and has special rights. > >James Bond as a (not so) > > > secret agent might have these rights. > > > > > > The emergency services case (citizen-to-authority) is > >a bit different as > > > there aren't really special rights with respect to > >authorization tied to > > > individuals. Instead, the fact that something is an > >emergency is purely a > > > judgement of the human that dials a special number. > >To deal with fraud, we > > > discussed in the group on what we can actually do to > >ensure that end users > > > do not bypass security procedures (such as > >authorization checks, charging > > > and so on). Part of this investigation was the publication of > > > http://www.ietf.org/rfc/rfc5069.txt that also > >describes this issue. > > > > > > So, imagine the implementation of a SIP proxy (and we > >implemented that > > > stuff) that receives a call that contains a Service > >URN. The code branches > > > into a special mode where everything is done so that > >the call receives > > > appropriate treatment and does not get dropped on the > >floor. The way how the > > > Service URN is placed in the message ensures that the > >call cannot go to my > > > friend (instead of the PSAP) unless the end host ran > >LoST already. > >In the > > > latter case, we discussed this also on the list for a > >while and Richard even > > > wrote a draft about it in the context of the location > >hiding topic, we said > > > that the proxy would have to run LoST if he cares > >about a potential > > > fraudulent usage. > > > > > > So, what do we need todo in order to provide secure > >RFC 4412 functionality > > > in our context? > > > > > > Do you think that the current text in > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >gency-rph-nam > > > espace-00.txt reflects any of the above-described issues: > > > " > > > The Security considerations that apply to RFC 4412 > >[RFC4412] > >apply > > > here. This document introduces no new security > >issues relative > >to > > > RFC 4412. > > > " > > > > > > From various discussions in GEOPRIV I recall that you > >are super-sensitive > > > regarding security and privacy. For some reasons you > >don't seem to have the > > > same concerns here. I would like to understand your reasoning. > > > > > > Please also do me another favor: Don't always say > >that I don't understand > > > the subject. Even if that would be the case it isn't > >particular fair given > > > that different folks had to educate you on other > >topics in the past as well. > > > Additionally, if you listen to the audio recordings > >then you will notice > > > that Henning, Ted, and Jon do not seem to understand > >the issue either as > > > they have raised similar issues during the F2F meetings. > > > > > > Ciao > > > Hannes > > > > > > > > > >Hannes - I believe it is you who do not understand > >RFC 4412 -- > > > >and many of us are trying to get that through to > >you, but you > > > >don't seem to want to listen/read. > > > > > > > >RFC 4412 is *for* priority marking SIP requests, > > > > > > > >One use is GETS. > > > > > > > >One use is MLPP. > > > > > > > >These examples are in RFC 4412 because there were specific > > > >namespaces being created for the IANA section of > >that document. > > > > > > > >Reading the whole document, you will see that RPH can be > > > >specified for other uses than GETS or MLPP specifically. > > > > > > > >I knew when I wrote RFC 4412 that one day we would specify a > > > >namespace for ECRIT (the "esnet" namespace now) -- > >but I also > > > >knew it was premature for RFC 4412 to incorporate that > > > >namespace, that a future doc to RFC 4412 would have to be > > > >written to do this. Brian and I talked about this at the > > > >original NENA meeting that created the IP WGs there > >(in August > > > >of 03). We both agreed we should wait until it was > > > >appropriate to the work in the IETF to submit this document > > > >that is now > > > > >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > > > >gency-rph-namespace-00.txt > > > > > > > >Yet, you seem to want to use some additional mechanism to > > > >indicate priority of a call in SIP. That means you want to > > > >introduce a second way to accomplish this in SIP. > >Why do you > > > >want to promote a separate way to do something SIP > >has already > > > >defined? That will cause interoperability issues and > >we both know that. > > > > > > > >You've said to me (and others) that you believe RPH is just > > > >another way to accomplish what sos or a URI can > >indicate - and > > > >you're wrong. Your way would be _the_second_way_to_do_it, > > > >because SIP already considers RPH to be *the*way* to > >priority > > > >mark SIP requests. > > > > > > > >If you don't believe me (no comment), then why do you not > > > >believe the SIP WG chair (who knows more about SIP than both > > > >of us) - who, on this thread, has again said to you > >"RFC 4412 > > > >(RPH) is the SIP mechanism to priority mark SIP requests"? > > > > > > > >Further, I believe it is inappropriate to prohibit endpoints > > > >from being able to set the esnet namespace. I absolutely > > > >believe it will not be needed most of the time, but > >I believe > > > >if someone does find a valid use for endpoints to mark > > > >priority in SIP, this ID - once it has become an RFC -- will > > > >have to be obsoleted with a new RFC saying the exact > >opposite. > > > > > > > >(color me confused ... over and over again) > > > > > > > >James > > > > > > > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > > > >>Keith, please understand that the usage of RFC 4412 > >for GETS and for > > > >>the type of emergency call we discuss here is > >different. Just looking > > > >>at the header and the name of the namespace is a bit > > > >artificial. I hope > > > >>you understand that. > > > >> > > > >> >-----Original Message----- > > > >> >From: DRAGE, Keith (Keith) > >[mailto:drage@alcatel-lucent.com] > > > >> >Sent: 05 February, 2009 14:55 > > > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >Polk'; 'Tschofenig, > > > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > > > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >Meeting: Agenda (my > > > > > >> >mistake) > > > >> > > > > >> >Which is exactly what RFC 4412 specifies for all > >namespaces. > > > >> > > > > >> >regards > > > >> > > > > >> >Keith > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: ecrit-bounces@ietf.org > >[mailto:ecrit-bounces@ietf.org] > > > >> >On Behalf > > > >> >> Of Brian Rosen > > > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > > > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > > > >Hannes (NSN > > > >> >> - FI/Espoo)'; 'ECRIT' > > > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >Meeting: Agenda (my > > > >> >> mistake) > > > >> >> > > > >> >> The value is that in some networks where priority for > > > >> >emergency calls > > > >> >> is appropriate, and appropriate policing of marking is > > > >implemented, > > > >> >> emergency calls will receive resource priority. > > > >> >> > > > >> >> Not all networks would need policing. Some > >will. Policing could > > > >> >> be to Route header/R-URI content, but other > >criteria are possible. > > > >> >> > > > >> >> Not all networks will need resource priority > >for emergency calls. > > > >> >> Fine, ignore this marking/namespace. > > > >> >> > > > >> >> Brian > > > >> >> > -----Original Message----- > > > >> >> > From: Hannes Tschofenig > >[mailto:Hannes.Tschofenig@gmx.net] > > > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > > > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >Tschofenig, Hannes (NSN - > > > >> >> > FI/Espoo); 'ECRIT' > > > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >Meeting: Agenda (my > > > >> >> > mistake) > > > >> >> > > > > >> >> > I don't even see the value in permitting the > >endpoint todo the > > > >> >> > RPH marking. > > > >> >> > In addition to the security concerns there is also the > > > >> >problem that > > > >> >> > there are more options to implement without > >an additional value. > > > >> >> > > > > >> >> > >-----Original Message----- > > > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > > > >> >> > >Sent: 05 February, 2009 00:03 > > > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >'Tschofenig, > > > >> >> Hannes (NSN - > > > >> >> > >FI/Espoo)'; 'ECRIT' > > > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (my > > > >> >> > mistake) > > > >> >> > > > > > >> >> > >Hannes > > > >> >> > > > > > >> >> > >This matches my understanding precisely. We wish to > > > >> >> permit endpoints > > > >> >> > >to mark. We do not require it, and don't > >necessarily expect it > > > >> >> > >in many (even > > > >> >> > >most) cases. We don't wish to see the > >document prohibit it. > > > >> >> > >We all seem to agree it has value within the > >Emergency > > > >> >Services IP > > > >> >> > >Networks. > > > >> >> > > > > > >> >> > >Brian > > > >> >> > > > > > >> >> > >> -----Original Message----- > > > >> >> > >> From: ecrit-bounces@ietf.org > >[mailto:ecrit-bounces@ietf.org] > > > >> >> > >On Behalf > > > >> >> > >> Of James M. Polk > > > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > > > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > > > >> >> FI/Espoo); 'ECRIT' > > > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >Meeting: > > > >Agenda (my > > > >> >> > >> mistake) > > > >> >> > >> > > > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > > > >> >> > >> > > James wrote: > > > >> >> > >> > >> you are the _lone_ voice not > >supporting this ID, > > > >> >> > >> > > > > >> >> > >> >Listening to the audio recording of past > >meetings I have to > > > >> >> > >say that > > > >> >> > >> >I > > > >> >> > >> was > > > >> >> > >> >not the only persons raising concerns > >about the document. > > > >> >> > >> >That was probably the reason why you > >agreed to limit the > > > >> >> > >scope of the > > > >> >> > >> >document (which you didn't later do) to > >get folks to agree > > > >> >> > >to make it > > > >> >> > >> a WG > > > >> >> > >> >item. > > > >> >> > >> > > > >> >> > >> re-listen to the audio please > > > >> >> > >> > > > >> >> > >> Ted's concerns were consistent with most > >(all?) other > > > >> >> concerns -- > > > >> >> > >> which were based on the premise of whether > >or not the > > > >> >> UAC should be > > > >> >> > >> trusted to initiate the marking on the > >INVITE. The most > > > >> >> > >> recent version has backed off this to a > >"can" -- meaning not > > > >> >prohibited > > > >> >> > >> (i.e., no 2119 text). I also backed off > >the text in the > > > >> >> SP domain > > > >> >> > >> part to "can", such that there is no 2119 text > > > >> >mandating or even > > > >> >> > >> recommending its usage there. I also do > >not prohibit its > > > >> >> > >use, based on > > > >> >> > >> local policy. Keith has come forward with > >the specific > > > > > >> >> > >> request that non-ESInet networks be > >allowed to mark and pay > > > >> >attention to > > > >> >> > >> this priority indication -- with IMS as > >the specific example > > > >> >> > >> he wishes to have this valid for. > > > >> >> > >> > > > >> >> > >> Where there is no disagreement, save for > >your recent > > > >> >> > >pushback - is in > > > >> >> > >> the ESInet, which is where Brian has requested it's > > > >> >> > >definition in the > > > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >chair within > > > >> >> NENA, and if > > > >> >> > >> he asks for it, are you going to say you > >know better than he? > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> >Btw, I not disagreeing with the document > >as such. I > > > >> >just want to > > > >> >> > the > > > >> >> > >> scope > > > >> >> > >> >to change. The usage of RPH within the emergency > > > >> >> services network > > > >> >> > is > > > >> >> > >> fine > > > >> >> > >> >for me. I may get convinced to start the > >RPH marking from > > > >> >> > >the the VSP > > > >> >> > >> >towards the PSAP. I feel uneasy about the > >end host doing > > > >> >> > >the marking. > > > >> >> > >> > > > >> >> > >> please read what I wrote above, and then > >re-read the > > > >> >most recent > > > >> >> > >> version of the ID. I don't have endpoints > >that SHOULD or > > > >> >> MUST mark > > > >> >> > >> anything wrt RPH. I also don't want to > >prohibit it, > > > >> >> because there > > > >> >> > >> might be cases (that I don't know of) of valid uses > > > >> >> under certain > > > >> >> > >> circumstances. Figure 1 is very clear > >that there are 3 > > > >> >> networking > > > >> >> > >> parts to consider > > > >> >> > >> > > > >> >> > >> #1 - from the endpoint > > > >> >> > >> #2 - within the VSP > > > >> >> > >> #3 - within the ESInet > > > >> >> > >> > > > >> >> > >> the most recent ID version has "can" for > >#s 1 and 2, and > > > >> >> > >2119 language > > > >> >> > >> offering those supporting this > >specification will have RPH > > > >> >> > >> adherence within #3 (the ESInet). > > > >> >> > >> > > > >> >> > >> What other scope changes do you want, > >because I haven't > > > >> >> heard them. > > > >> >> > >> > > > >> >> > >> I only heard you claim in email during the > >last IETF and in > > > >> >> > >the ECRIT > > > >> >> > >> session that RPH should not be used for > >priority marking > > > >> >> requests. > > > >> >> > >> This is something Keith (SIP WG chair) > >voiced his opposition > > > >> >> > >> to your views regarding creating a second > >means for SIP to > > > >> >priority > > > >> >> > >> mark request "when SIP already has one > >interoperable way to > > > >> >> > >> accomplish this... it's call the RP header > >mechanism". > > > >> >> > >> > > > >> >> > >> >I don't see advantages -- only disadvantages. > > > >> >> > >> > > > > >> >> > >> >Ciao > > > >> >> > >> >Hannes > > > >> >> > >> > > > >> >> > >> _______________________________________________ > > > >> >> > >> Ecrit mailing list > > > >> >> > >> Ecrit@ietf.org > > > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > > > >> >> > > > > > >> >> > > > >> >> _______________________________________________ > > > >> >> Ecrit mailing list > > > >> >> Ecrit@ietf.org > > > >> >> https://www.ietf.org/mailman/listinfo/ecrit > > > >> >> > > > >> > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E12628C244 for ; Fri, 6 Feb 2009 07:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEivgLPr816d for ; Fri, 6 Feb 2009 07:20:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CA28928C23E for ; Fri, 6 Feb 2009 07:19:59 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 15:20:00 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp015) with SMTP; 06 Feb 2009 16:20:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19fgg8Xf9dfRqd8yGSdCxL/mJ6nsw9MJyc2KkD0Z2 eIiQg2WbgEIES8 From: "Hannes Tschofenig" To: "'Brian Rosen'" , "'Janet P Gunn'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> Date: Fri, 6 Feb 2009 17:20:47 +0200 Message-ID: <003001c9886e$7d133280$49b5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0d6901c9886b$6c9bfc50$45d3f4f0$@net> Thread-Index: AcmIVAF3NI3DU70UTkON98fIFS1CsgAB6cFgAAA2fKAAAyK5gAAA8CeQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:20:02 -0000 Don't get hung up on the details. There are ways to optimize it. That was not the point of the code example. The problem that my pseudo code should have shown you is that you * don't gain anything with RPH marking for the emergency call case from the SIP UA towards the outbound proxy since the functionality is already provide otherwise. How often does the proxy need to get told that this is an emergency call todo whatever emergency call handling procedures are necessary? * you only introduce fraud problems (if you are not careful and you understand the security stuff well enough) If you can point me to people who implement the RPH emergency call case please do so. I would love to talk to them. Ciao Hannes PS: You need to parse incoming messages to some extend so that you know what it contains :-) Only looking for the emergency RPH header (and not for the Service URN/dial string) would exactly be the DoS/fraud attack I am worried about. That's the thing Henning was worried about (go and listen to the past meeting minutes). >Hannes > >You need to talk to people who really implement this kind of >thing. You are way off. > >When you implement a resource priority system, the point of >doing that is to look though the queue of work and pick out >the ones with priority, handling them first. You don't do all >the parsing, you don't do a lot of decision tree. > >Typically: >Check for DoS things, like too big messages, etc Do a quick >scan for the RPH message header If found: >Parse the message >Determine validity >Determine priority >Queue on the correct work queue > >The first two actions have to be very fast. Anyone who builds >a SIP thingie will tell you that parsing is one of the big >cycle consumers: if you have to parse every message BEFORE you >determine priority, you can't give much resource priority. >Once you get the whole message parsed, you might as well >finish working on it, because you've done so much of the work. >OTHOH, finding the end-of-message delimiter and doing a quick >string search for RPH is fast. If you are doing priority, you >need to keep all the priority processing pretty uniform, and >pretty simple, or you tend to spend too much time futzing >around figuring out what to do. You put all the priority >related stuff together, and use as much common code as possible. > >Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Hannes Tschofenig >> Sent: Friday, February 06, 2009 8:41 AM >> To: 'Hannes Tschofenig'; 'Janet P Gunn' >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >> bounces@ietf.org >> Subject: [Ecrit] RPH >> >> Over lunch I was also thinking how an outbound proxy would implement >> some of the emergency procedures. Here are some thoughts: >> >> --------------------------------------------------- >> >> // Process incoming message >> Parse(msg); >> >> // SIP INVITE without Service URN >> // legacy devices >> If (recognize-dialstring(msg)==TRUE) { >> // we got an emergency call going on >> emergency=TRUE; >> if (dialstring(msg) == 911) serviceURN=urn:service:sos; } else if >> (recognize-serviceURN(msg)==TRUE) { >> // oh. A updated device that has a service URN attached to the call >> serviceURN=retrieve_ServiceURN(msg); >> emergency=TRUE; >> } else { >> // standard SIP message >> // regular processing >> process(msg); >> emergency=FALSE; >> } >> >> If (emergency == TRUE) { >> // make sure that the emergency call does not get dropped on the >> floor >> // skip authorization failures >> // give the call a special treatment >> lots-of-code-here(); >> >> // trigger all the QoS signaling you have in the network to make >> James happy >> trigger-qos(); >> >> // query location >> location=retrieve-location(); >> >> // determine next hop >> next-hop=lost(location, serviceURN) >> >> // attach RPH marking to outgoing msg to make James and >Keith happy >> msg=add(msg, RPH); >> >> send(msg, next-hop); >> } >> >> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >> // all the emergency related processing done already upfront >> // hence I log something. >> log(RPH_WAS_PRESENT_JUHU); >> } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) { >> // this is not an emergency call >> // this is something like GETS >> result=special-authorization-procedure(user); >> >> if (result == AUTHORIZED) { >> // do some priority & preemption thing here. >> // trigger all the QoS you have >> lots-of-code-here(); >> } else { >> log("NOT AUTHORIZED; don't DoS my network"); >> } >> } else { >> // don't need todo any RPH processing >> // this includes the case where the call was an emergency call but >> the RPH >> >> // marking was not there. >> nothing(); >> } >> >> --------------------------------------------------- >> >> >> Ciao >> Hannes >> >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >Behalf Of Hannes Tschofenig >> >Sent: 06 February, 2009 15:07 >> >To: 'Janet P Gunn' >> >Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >> FI/Espoo) >> >Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >> > >> >Who would define something that could prevent DoS problems? >> > >> >________________________________ >> > >> > From: Janet P Gunn [mailto:jgunn6@csc.com] >> > Sent: 06 February, 2009 14:11 >> > To: Hannes Tschofenig >> > Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >> >ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); 'James >> >M. Polk' >> > Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >> > >> > >> > >> > But there is nothing IN RFC4412 that specifically >addresses how to >> >prevent any particular namespace being used for DoS. Anyone/any UA >> >can ATTEMPT to invoke priority treatment by attaching RPH. For all >> >of the 4412 namespaces, as with the new proposed namespace, the >> >mechanisms for preventing DoS are not specified in the >document that >> >defines the namespace. >> >They are/will be specified elsewhere. >> > >> > Janet >> > >> > This is a PRIVATE message. If you are not the intended >recipient, >> >please delete without copying and kindly advise us by e-mail of the >> >mistake in delivery. >> > NOTE: Regardless of content, this e-mail shall not >operate to bind >> >CSC to any order or other contract unless pursuant to explicit >> >written agreement or government initiative expressly permitting the >> >use of e-mail for such purpose. >> > >> > ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: >> > >> > > Hi James, >> > > >> > > I have read RFC 4412 and also the GETS/MLPP IETF >documents. What I >> >would >> > > like to point out is that there is more than just a >header and >> >values within >> > > the header that have to be considered in order to >make a judgement >> >of what >> > > is appropriate and what isn't. There is an >architectural question >> >and >> > > whether the environment we are using the stuff is >indeed providing >> >the >> > > properties you need for the solution to be appropriate. >> > > >> > > Let me describe in more detail what I meant (and >please correct me >> >if I am >> > > wrong). >> > > >> > > Getting priority for SIP requests when using a GETS >alike scenario >> >means >> > > that the entity that issues the request is specially >authorized >> >since >> > > otherwise you introduce a nice denial of service attack. This >> >authorization >> > > is tied to the entity that makes the request. For >example, the >> >person is >> > > working for the government and has special rights. >> >James Bond as a (not so) >> > > secret agent might have these rights. >> > > >> > > The emergency services case (citizen-to-authority) is a bit >> >different as >> > > there aren't really special rights with respect to >authorization >> >tied to >> > > individuals. Instead, the fact that something is an >emergency is >> >purely a >> > > judgement of the human that dials a special number. >> >To deal with fraud, we >> > > discussed in the group on what we can actually do to >ensure that >> >end users >> > > do not bypass security procedures (such as >authorization checks, >> >charging >> > > and so on). Part of this investigation was the publication of >> > > http://www.ietf.org/rfc/rfc5069.txt that also describes this >> >issue. >> > > >> > > So, imagine the implementation of a SIP proxy (and we >implemented >> >that >> > > stuff) that receives a call that contains a Service >URN. The code >> >branches >> > > into a special mode where everything is done so that the call >> >receives >> > > appropriate treatment and does not get dropped on the >floor. The >> >way how the >> > > Service URN is placed in the message ensures that the >call cannot >> >go to my >> > > friend (instead of the PSAP) unless the end host ran >LoST already. >> >In the >> > > latter case, we discussed this also on the list for a >while and >> >Richard even >> > > wrote a draft about it in the context of the location hiding >> >topic, we said >> > > that the proxy would have to run LoST if he cares about a >> >potential >> > > fraudulent usage. >> > > >> > > So, what do we need todo in order to provide secure RFC 4412 >> >functionality >> > > in our context? >> > > >> > > Do you think that the current text in >> > > >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >gency-rph-nam >> > > espace-00.txt reflects any of the above-described issues: >> > > " >> > > The Security considerations that apply to RFC 4412 >> >[RFC4412] >> >apply >> > > here. This document introduces no new security >> >issues relative >> >to >> > > RFC 4412. >> > > " >> > > >> > > From various discussions in GEOPRIV I recall that you are >> >super-sensitive >> > > regarding security and privacy. For some reasons you >don't seem to >> >have the >> > > same concerns here. I would like to understand your reasoning. >> > > >> > > Please also do me another favor: Don't always say >that I don't >> >understand >> > > the subject. Even if that would be the case it isn't >particular >> >fair given >> > > that different folks had to educate you on other >topics in the >> >past as well. >> > > Additionally, if you listen to the audio recordings >then you will >> >notice >> > > that Henning, Ted, and Jon do not seem to understand >the issue >> >either as >> > > they have raised similar issues during the F2F meetings. >> > > >> > > Ciao >> > > Hannes >> > > >> > > >> > > >Hannes - I believe it is you who do not understand >RFC 4412 -- >> > > >and many of us are trying to get that through to you, but you >> > > >don't seem to want to listen/read. >> > > > >> > > >RFC 4412 is *for* priority marking SIP requests, >> > > > >> > > >One use is GETS. >> > > > >> > > >One use is MLPP. >> > > > >> > > >These examples are in RFC 4412 because there were specific >> > > >namespaces being created for the IANA section of >that document. >> > > > >> > > >Reading the whole document, you will see that RPH can be >> > > >specified for other uses than GETS or MLPP specifically. >> > > > >> > > >I knew when I wrote RFC 4412 that one day we would specify a >> > > >namespace for ECRIT (the "esnet" namespace now) -- but I also >> > > >knew it was premature for RFC 4412 to incorporate that >> > > >namespace, that a future doc to RFC 4412 would have to be >> > > >written to do this. Brian and I talked about this at the >> > > >original NENA meeting that created the IP WGs there >(in August >> > > >of 03). We both agreed we should wait until it was >> > > >appropriate to the work in the IETF to submit this document >> > > >that is now >> > > >> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> > > >gency-rph-namespace-00.txt >> > > > >> > > >Yet, you seem to want to use some additional mechanism to >> > > >indicate priority of a call in SIP. That means you want to >> > > >introduce a second way to accomplish this in SIP. >> >Why do you >> > > >want to promote a separate way to do something SIP >has already >> > > >defined? That will cause interoperability issues and >we both know >> >that. >> > > > >> > > >You've said to me (and others) that you believe RPH is just >> > > >another way to accomplish what sos or a URI can >indicate - and >> > > >you're wrong. Your way would be _the_second_way_to_do_it, >> > > >because SIP already considers RPH to be *the*way* to priority >> > > >mark SIP requests. >> > > > >> > > >If you don't believe me (no comment), then why do you not >> > > >believe the SIP WG chair (who knows more about SIP than both >> > > >of us) - who, on this thread, has again said to you "RFC 4412 >> > > >(RPH) is the SIP mechanism to priority mark SIP requests"? >> > > > >> > > >Further, I believe it is inappropriate to prohibit endpoints >> > > >from being able to set the esnet namespace. I absolutely >> > > >believe it will not be needed most of the time, but I believe >> > > >if someone does find a valid use for endpoints to mark >> > > >priority in SIP, this ID - once it has become an RFC -- will >> > > >have to be obsoleted with a new RFC saying the exact >opposite. >> > > > >> > > >(color me confused ... over and over again) >> > > > >> > > >James >> > > > >> > > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >> > > >>Keith, please understand that the usage of RFC 4412 >for GETS and >> >for >> > > >>the type of emergency call we discuss here is >different. Just >> >looking >> > > >>at the header and the name of the namespace is a bit >> > > >artificial. I hope >> > > >>you understand that. >> > > >> >> > > >> >-----Original Message----- >> > > >> >From: DRAGE, Keith (Keith) >> >[mailto:drage@alcatel-lucent.com] >> > > >> >Sent: 05 February, 2009 14:55 >> > > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >> >Polk'; 'Tschofenig, >> > > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >> > > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >> >Meeting: Agenda (my >> > >> > > >> >mistake) >> > > >> > >> > > >> >Which is exactly what RFC 4412 specifies for all >namespaces. >> > > >> > >> > > >> >regards >> > > >> > >> > > >> >Keith >> > > >> > >> > > >> >> -----Original Message----- >> > > >> >> From: ecrit-bounces@ietf.org >[mailto:ecrit-bounces@ietf.org] >> > > >> >On Behalf >> > > >> >> Of Brian Rosen >> > > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> > > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >> > > >Hannes (NSN >> > > >> >> - FI/Espoo)'; 'ECRIT' >> > > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >Meeting: Agenda (my >> > > >> >> mistake) >> > > >> >> >> > > >> >> The value is that in some networks where priority for >> > > >> >emergency calls >> > > >> >> is appropriate, and appropriate policing of marking is >> > > >implemented, >> > > >> >> emergency calls will receive resource priority. >> > > >> >> >> > > >> >> Not all networks would need policing. Some >will. Policing >> >could >> > > >> >> be to Route header/R-URI content, but other >criteria are >> >possible. >> > > >> >> >> > > >> >> Not all networks will need resource priority >for emergency >> >calls. >> > > >> >> Fine, ignore this marking/namespace. >> > > >> >> >> > > >> >> Brian >> > > >> >> > -----Original Message----- >> > > >> >> > From: Hannes Tschofenig >> >[mailto:Hannes.Tschofenig@gmx.net] >> > > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> > > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >Tschofenig, Hannes >> >(NSN - >> > > >> >> > FI/Espoo); 'ECRIT' >> > > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >> >Meeting: Agenda (my >> > > >> >> > mistake) >> > > >> >> > >> > > >> >> > I don't even see the value in permitting the >endpoint todo >> >the >> > > >> >> > RPH marking. >> > > >> >> > In addition to the security concerns there is also the >> > > >> >problem that >> > > >> >> > there are more options to implement without >an additional >> >value. >> > > >> >> > >> > > >> >> > >-----Original Message----- >> > > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> > > >> >> > >Sent: 05 February, 2009 00:03 >> > > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >'Tschofenig, >> > > >> >> Hannes (NSN - >> > > >> >> > >FI/Espoo)'; 'ECRIT' >> > > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: >> >Agenda (my >> > > >> >> > mistake) >> > > >> >> > > >> > > >> >> > >Hannes >> > > >> >> > > >> > > >> >> > >This matches my understanding precisely. We wish to >> > > >> >> permit endpoints >> > > >> >> > >to mark. We do not require it, and don't necessarily >> >expect it >> > > >> >> > >in many (even >> > > >> >> > >most) cases. We don't wish to see the >document prohibit >> >it. >> > > >> >> > >We all seem to agree it has value within the >Emergency >> > > >> >Services IP >> > > >> >> > >Networks. >> > > >> >> > > >> > > >> >> > >Brian >> > > >> >> > > >> > > >> >> > >> -----Original Message----- >> > > >> >> > >> From: ecrit-bounces@ietf.org >> >[mailto:ecrit-bounces@ietf.org] >> > > >> >> > >On Behalf >> > > >> >> > >> Of James M. Polk >> > > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> > > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - >> > > >> >> FI/Espoo); 'ECRIT' >> > > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >Meeting: >> > > >Agenda (my >> > > >> >> > >> mistake) >> > > >> >> > >> >> > > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >> > > >> >> > >> > > James wrote: >> > > >> >> > >> > >> you are the _lone_ voice not >supporting this ID, >> > > >> >> > >> > >> > > >> >> > >> >Listening to the audio recording of past >meetings I >> >have to >> > > >> >> > >say that >> > > >> >> > >> >I >> > > >> >> > >> was >> > > >> >> > >> >not the only persons raising concerns about the >> >document. >> > > >> >> > >> >That was probably the reason why you >agreed to limit >> >the >> > > >> >> > >scope of the >> > > >> >> > >> >document (which you didn't later do) to >get folks to >> >agree >> > > >> >> > >to make it >> > > >> >> > >> a WG >> > > >> >> > >> >item. >> > > >> >> > >> >> > > >> >> > >> re-listen to the audio please >> > > >> >> > >> >> > > >> >> > >> Ted's concerns were consistent with most >> >(all?) other >> > > >> >> concerns -- >> > > >> >> > >> which were based on the premise of whether >or not the >> > > >> >> UAC should be >> > > >> >> > >> trusted to initiate the marking on the >INVITE. The >> >most >> > > >> >> > >> recent version has backed off this to a "can" -- >> >meaning not >> > > >> >prohibited >> > > >> >> > >> (i.e., no 2119 text). I also backed off >the text in >> >the >> > > >> >> SP domain >> > > >> >> > >> part to "can", such that there is no 2119 text >> > > >> >mandating or even >> > > >> >> > >> recommending its usage there. I also do >not prohibit >> >its >> > > >> >> > >use, based on >> > > >> >> > >> local policy. Keith has come forward with >the specific >> > >> > > >> >> > >> request that non-ESInet networks be >allowed to mark and >> >pay >> > > >> >attention to >> > > >> >> > >> this priority indication -- with IMS as >the specific >> >example >> > > >> >> > >> he wishes to have this valid for. >> > > >> >> > >> >> > > >> >> > >> Where there is no disagreement, save for >your recent >> > > >> >> > >pushback - is in >> > > >> >> > >> the ESInet, which is where Brian has requested it's >> > > >> >> > >definition in the >> > > >> >> > >> IETF on behalf of NENA. He's the i3 WG >chair within >> > > >> >> NENA, and if >> > > >> >> > >> he asks for it, are you going to say you >know better >> >than he? >> > > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >Btw, I not disagreeing with the document >as such. I >> > > >> >just want to >> > > >> >> > the >> > > >> >> > >> scope >> > > >> >> > >> >to change. The usage of RPH within the emergency >> > > >> >> services network >> > > >> >> > is >> > > >> >> > >> fine >> > > >> >> > >> >for me. I may get convinced to start the >RPH marking >> >from >> > > >> >> > >the the VSP >> > > >> >> > >> >towards the PSAP. I feel uneasy about the >end host >> >doing >> > > >> >> > >the marking. >> > > >> >> > >> >> > > >> >> > >> please read what I wrote above, and then >re-read the >> > > >> >most recent >> > > >> >> > >> version of the ID. I don't have endpoints >that SHOULD >> >or >> > > >> >> MUST mark >> > > >> >> > >> anything wrt RPH. I also don't want to >prohibit it, >> > > >> >> because there >> > > >> >> > >> might be cases (that I don't know of) of valid uses >> > > >> >> under certain >> > > >> >> > >> circumstances. Figure 1 is very clear >that there are 3 >> > > >> >> networking >> > > >> >> > >> parts to consider >> > > >> >> > >> >> > > >> >> > >> #1 - from the endpoint >> > > >> >> > >> #2 - within the VSP >> > > >> >> > >> #3 - within the ESInet >> > > >> >> > >> >> > > >> >> > >> the most recent ID version has "can" for >#s 1 and 2, >> >and >> > > >> >> > >2119 language >> > > >> >> > >> offering those supporting this >specification will have >> >RPH >> > > >> >> > >> adherence within #3 (the ESInet). >> > > >> >> > >> >> > > >> >> > >> What other scope changes do you want, >because I haven't >> > > >> >> heard them. >> > > >> >> > >> >> > > >> >> > >> I only heard you claim in email during the >last IETF >> >and in >> > > >> >> > >the ECRIT >> > > >> >> > >> session that RPH should not be used for priority >> >marking >> > > >> >> requests. >> > > >> >> > >> This is something Keith (SIP WG chair) voiced his >> >opposition >> > > >> >> > >> to your views regarding creating a second >means for SIP >> >to >> > > >> >priority >> > > >> >> > >> mark request "when SIP already has one >interoperable >> >way to >> > > >> >> > >> accomplish this... it's call the RP header >mechanism". >> > > >> >> > >> >> > > >> >> > >> >I don't see advantages -- only disadvantages. >> > > >> >> > >> > >> > > >> >> > >> >Ciao >> > > >> >> > >> >Hannes >> > > >> >> > >> >> > > >> >> > >> _______________________________________________ >> > > >> >> > >> Ecrit mailing list >> > > >> >> > >> Ecrit@ietf.org >> > > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >> > > >> >> > > >> > > >> >> >> > > >> >> _______________________________________________ >> > > >> >> Ecrit mailing list >> > > >> >> Ecrit@ietf.org >> > > >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > > >> >> >> > > >> > >> > > > >> > > >> > > _______________________________________________ >> > > Ecrit mailing list >> > > Ecrit@ietf.org >> > > https://www.ietf.org/mailman/listinfo/ecrit >> > >> > >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6462A3A69BB for ; Fri, 6 Feb 2009 07:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HujnSDzAR6AL for ; Fri, 6 Feb 2009 07:33:38 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 23B3528C138 for ; Fri, 6 Feb 2009 07:33:38 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16FXSO3016622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 10:33:28 -0500 (EST) Message-Id: <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> From: Henning Schulzrinne To: "Hannes Tschofenig" In-Reply-To: <003001c9886e$7d133280$49b5b70a@nsnintra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 10:33:28 -0500 References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:33:40 -0000 To chime in here: I don't think it's productive to simply state that 4412 doesn't worry about authorization, so we shouldn't either (simplifying a bit). Authorization was discussed repeatedly, and the general assumption was that there were two conditions: Either the user invoking resource- priority was well known and had a set of permissions that could be checked in real time or there are ways to deal with abuse after the fact in ways that deter abuse (the court-martial kind of thing in a military context). The RFC 4412 security consideration (11.2) call this out in pretty strong language: Prioritized access to network and end-system resources imposes particularly stringent requirements on authentication and authorization mechanisms, since access to prioritized resources may impact overall system stability and performance and not just result in theft of, say, a single phone call. Thus, the question is whether we have such strong authentication in emergency calling. In some cases, such as residential fixed line deployments where ISP = VSP, we're probably pretty close, in others, such as prepaid cell phones or hot spots or VSP-only providers, we aren't. The other point that I think Hannes is making is that the information is either redundant or dangerous. If a processing element recognizes the call as being an emergency call, it can apply whatever treatment it deems appropriate and doesn't need additional information. If it doesn't or can't, using just the RPH can be rather dangerous unless that element can be reasonably certain that there is strong authentication and recourse. I don't buy the argument that somehow finding the RPH is faster than just looking for the identifier. Thus, given that the information is either redundant or dangerous, I fail to see the advantage. Henning On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > Don't get hung up on the details. There are ways to optimize it. > That was > not the point of the code example. > > The problem that my pseudo code should have shown you is that you > * don't gain anything with RPH marking for the emergency call case > from the > SIP UA towards the outbound proxy since the functionality is already > provide > otherwise. How often does the proxy need to get told that this is an > emergency call todo whatever emergency call handling procedures are > necessary? > * you only introduce fraud problems (if you are not careful and you > understand the security stuff well enough) > > If you can point me to people who implement the RPH emergency call > case > please do so. I would love to talk to them. > > Ciao > Hannes > > PS: You need to parse incoming messages to some extend so that you > know what > it contains :-) > Only looking for the emergency RPH header (and not for the Service > URN/dial > string) would exactly be the DoS/fraud attack I am worried about. > That's the thing Henning was worried about (go and listen to the past > meeting minutes). > > >> Hannes >> >> You need to talk to people who really implement this kind of >> thing. You are way off. >> >> When you implement a resource priority system, the point of >> doing that is to look though the queue of work and pick out >> the ones with priority, handling them first. You don't do all >> the parsing, you don't do a lot of decision tree. >> >> Typically: >> Check for DoS things, like too big messages, etc Do a quick >> scan for the RPH message header If found: >> Parse the message >> Determine validity >> Determine priority >> Queue on the correct work queue >> >> The first two actions have to be very fast. Anyone who builds >> a SIP thingie will tell you that parsing is one of the big >> cycle consumers: if you have to parse every message BEFORE you >> determine priority, you can't give much resource priority. >> Once you get the whole message parsed, you might as well >> finish working on it, because you've done so much of the work. >> OTHOH, finding the end-of-message delimiter and doing a quick >> string search for RPH is fast. If you are doing priority, you >> need to keep all the priority processing pretty uniform, and >> pretty simple, or you tend to spend too much time futzing >> around figuring out what to do. You put all the priority >> related stuff together, and use as much common code as possible. >> >> Brian >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf >>> Of Hannes Tschofenig >>> Sent: Friday, February 06, 2009 8:41 AM >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >>> bounces@ietf.org >>> Subject: [Ecrit] RPH >>> >>> Over lunch I was also thinking how an outbound proxy would implement >>> some of the emergency procedures. Here are some thoughts: >>> >>> --------------------------------------------------- >>> >>> // Process incoming message >>> Parse(msg); >>> >>> // SIP INVITE without Service URN >>> // legacy devices >>> If (recognize-dialstring(msg)==TRUE) { >>> // we got an emergency call going on >>> emergency=TRUE; >>> if (dialstring(msg) == 911) serviceURN=urn:service:sos; } else if >>> (recognize-serviceURN(msg)==TRUE) { >>> // oh. A updated device that has a service URN attached to the call >>> serviceURN=retrieve_ServiceURN(msg); >>> emergency=TRUE; >>> } else { >>> // standard SIP message >>> // regular processing >>> process(msg); >>> emergency=FALSE; >>> } >>> >>> If (emergency == TRUE) { >>> // make sure that the emergency call does not get dropped on the >>> floor >>> // skip authorization failures >>> // give the call a special treatment >>> lots-of-code-here(); >>> >>> // trigger all the QoS signaling you have in the network to make >>> James happy >>> trigger-qos(); >>> >>> // query location >>> location=retrieve-location(); >>> >>> // determine next hop >>> next-hop=lost(location, serviceURN) >>> >>> // attach RPH marking to outgoing msg to make James and >> Keith happy >>> msg=add(msg, RPH); >>> >>> send(msg, next-hop); >>> } >>> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >>> // all the emergency related processing done already upfront >>> // hence I log something. >>> log(RPH_WAS_PRESENT_JUHU); >>> } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) { >>> // this is not an emergency call >>> // this is something like GETS >>> result=special-authorization-procedure(user); >>> >>> if (result == AUTHORIZED) { >>> // do some priority & preemption thing here. >>> // trigger all the QoS you have >>> lots-of-code-here(); >>> } else { >>> log("NOT AUTHORIZED; don't DoS my network"); >>> } >>> } else { >>> // don't need todo any RPH processing >>> // this includes the case where the call was an emergency call but >>> the RPH >>> >>> // marking was not there. >>> nothing(); >>> } >>> >>> --------------------------------------------------- >>> >>> >>> Ciao >>> Hannes >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Hannes Tschofenig >>>> Sent: 06 February, 2009 15:07 >>>> To: 'Janet P Gunn' >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >>> FI/Espoo) >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >>>> >>>> Who would define something that could prevent DoS problems? >>>> >>>> ________________________________ >>>> >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>>> Sent: 06 February, 2009 14:11 >>>> To: Hannes Tschofenig >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); 'James >>>> M. Polk' >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >>>> >>>> >>>> >>>> But there is nothing IN RFC4412 that specifically >> addresses how to >>>> prevent any particular namespace being used for DoS. Anyone/any UA >>>> can ATTEMPT to invoke priority treatment by attaching RPH. For all >>>> of the 4412 namespaces, as with the new proposed namespace, the >>>> mechanisms for preventing DoS are not specified in the >> document that >>>> defines the namespace. >>>> They are/will be specified elsewhere. >>>> >>>> Janet >>>> >>>> This is a PRIVATE message. If you are not the intended >> recipient, >>>> please delete without copying and kindly advise us by e-mail of the >>>> mistake in delivery. >>>> NOTE: Regardless of content, this e-mail shall not >> operate to bind >>>> CSC to any order or other contract unless pursuant to explicit >>>> written agreement or government initiative expressly permitting the >>>> use of e-mail for such purpose. >>>> >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: >>>> >>>> > Hi James, >>>> > >>>> > I have read RFC 4412 and also the GETS/MLPP IETF >> documents. What I >>>> would >>>> > like to point out is that there is more than just a >> header and >>>> values within >>>> > the header that have to be considered in order to >> make a judgement >>>> of what >>>> > is appropriate and what isn't. There is an >> architectural question >>>> and >>>> > whether the environment we are using the stuff is >> indeed providing >>>> the >>>> > properties you need for the solution to be appropriate. >>>> > >>>> > Let me describe in more detail what I meant (and >> please correct me >>>> if I am >>>> > wrong). >>>> > >>>> > Getting priority for SIP requests when using a GETS >> alike scenario >>>> means >>>> > that the entity that issues the request is specially >> authorized >>>> since >>>> > otherwise you introduce a nice denial of service attack. This >>>> authorization >>>> > is tied to the entity that makes the request. For >> example, the >>>> person is >>>> > working for the government and has special rights. >>>> James Bond as a (not so) >>>> > secret agent might have these rights. >>>> > >>>> > The emergency services case (citizen-to-authority) is a bit >>>> different as >>>> > there aren't really special rights with respect to >> authorization >>>> tied to >>>> > individuals. Instead, the fact that something is an >> emergency is >>>> purely a >>>> > judgement of the human that dials a special number. >>>> To deal with fraud, we >>>> > discussed in the group on what we can actually do to >> ensure that >>>> end users >>>> > do not bypass security procedures (such as >> authorization checks, >>>> charging >>>> > and so on). Part of this investigation was the publication of >>>> > http://www.ietf.org/rfc/rfc5069.txt that also describes this >>>> issue. >>>> > >>>> > So, imagine the implementation of a SIP proxy (and we >> implemented >>>> that >>>> > stuff) that receives a call that contains a Service >> URN. The code >>>> branches >>>> > into a special mode where everything is done so that the call >>>> receives >>>> > appropriate treatment and does not get dropped on the >> floor. The >>>> way how the >>>> > Service URN is placed in the message ensures that the >> call cannot >>>> go to my >>>> > friend (instead of the PSAP) unless the end host ran >> LoST already. >>>> In the >>>> > latter case, we discussed this also on the list for a >> while and >>>> Richard even >>>> > wrote a draft about it in the context of the location hiding >>>> topic, we said >>>> > that the proxy would have to run LoST if he cares about a >>>> potential >>>> > fraudulent usage. >>>> > >>>> > So, what do we need todo in order to provide secure RFC 4412 >>>> functionality >>>> > in our context? >>>> > >>>> > Do you think that the current text in >>>> > >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>> gency-rph-nam >>>> > espace-00.txt reflects any of the above-described issues: >>>> > " >>>> > The Security considerations that apply to RFC 4412 >>>> [RFC4412] >>>> apply >>>> > here. This document introduces no new security >>>> issues relative >>>> to >>>> > RFC 4412. >>>> > " >>>> > >>>> > From various discussions in GEOPRIV I recall that you are >>>> super-sensitive >>>> > regarding security and privacy. For some reasons you >> don't seem to >>>> have the >>>> > same concerns here. I would like to understand your reasoning. >>>> > >>>> > Please also do me another favor: Don't always say >> that I don't >>>> understand >>>> > the subject. Even if that would be the case it isn't >> particular >>>> fair given >>>> > that different folks had to educate you on other >> topics in the >>>> past as well. >>>> > Additionally, if you listen to the audio recordings >> then you will >>>> notice >>>> > that Henning, Ted, and Jon do not seem to understand >> the issue >>>> either as >>>> > they have raised similar issues during the F2F meetings. >>>> > >>>> > Ciao >>>> > Hannes >>>> > >>>> > >>>> > >Hannes - I believe it is you who do not understand >> RFC 4412 -- >>>> > >and many of us are trying to get that through to you, but you >>>> > >don't seem to want to listen/read. >>>> > > >>>> > >RFC 4412 is *for* priority marking SIP requests, >>>> > > >>>> > >One use is GETS. >>>> > > >>>> > >One use is MLPP. >>>> > > >>>> > >These examples are in RFC 4412 because there were specific >>>> > >namespaces being created for the IANA section of >> that document. >>>> > > >>>> > >Reading the whole document, you will see that RPH can be >>>> > >specified for other uses than GETS or MLPP specifically. >>>> > > >>>> > >I knew when I wrote RFC 4412 that one day we would specify a >>>> > >namespace for ECRIT (the "esnet" namespace now) -- but I also >>>> > >knew it was premature for RFC 4412 to incorporate that >>>> > >namespace, that a future doc to RFC 4412 would have to be >>>> > >written to do this. Brian and I talked about this at the >>>> > >original NENA meeting that created the IP WGs there >> (in August >>>> > >of 03). We both agreed we should wait until it was >>>> > >appropriate to the work in the IETF to submit this document >>>> > >that is now >>>> > >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>> > >gency-rph-namespace-00.txt >>>> > > >>>> > >Yet, you seem to want to use some additional mechanism to >>>> > >indicate priority of a call in SIP. That means you want to >>>> > >introduce a second way to accomplish this in SIP. >>>> Why do you >>>> > >want to promote a separate way to do something SIP >> has already >>>> > >defined? That will cause interoperability issues and >> we both know >>>> that. >>>> > > >>>> > >You've said to me (and others) that you believe RPH is just >>>> > >another way to accomplish what sos or a URI can >> indicate - and >>>> > >you're wrong. Your way would be _the_second_way_to_do_it, >>>> > >because SIP already considers RPH to be *the*way* to priority >>>> > >mark SIP requests. >>>> > > >>>> > >If you don't believe me (no comment), then why do you not >>>> > >believe the SIP WG chair (who knows more about SIP than both >>>> > >of us) - who, on this thread, has again said to you "RFC 4412 >>>> > >(RPH) is the SIP mechanism to priority mark SIP requests"? >>>> > > >>>> > >Further, I believe it is inappropriate to prohibit endpoints >>>> > >from being able to set the esnet namespace. I absolutely >>>> > >believe it will not be needed most of the time, but I believe >>>> > >if someone does find a valid use for endpoints to mark >>>> > >priority in SIP, this ID - once it has become an RFC -- will >>>> > >have to be obsoleted with a new RFC saying the exact >> opposite. >>>> > > >>>> > >(color me confused ... over and over again) >>>> > > >>>> > >James >>>> > > >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >>>> > >>Keith, please understand that the usage of RFC 4412 >> for GETS and >>>> for >>>> > >>the type of emergency call we discuss here is >> different. Just >>>> looking >>>> > >>at the header and the name of the namespace is a bit >>>> > >artificial. I hope >>>> > >>you understand that. >>>> > >> >>>> > >> >-----Original Message----- >>>> > >> >From: DRAGE, Keith (Keith) >>>> [mailto:drage@alcatel-lucent.com] >>>> > >> >Sent: 05 February, 2009 14:55 >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >>>> Polk'; 'Tschofenig, >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >>>> Meeting: Agenda (my >>>> >>>> > >> >mistake) >>>> > >> > >>>> > >> >Which is exactly what RFC 4412 specifies for all >> namespaces. >>>> > >> > >>>> > >> >regards >>>> > >> > >>>> > >> >Keith >>>> > >> > >>>> > >> >> -----Original Message----- >>>> > >> >> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] >>>> > >> >On Behalf >>>> > >> >> Of Brian Rosen >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >>>> > >Hannes (NSN >>>> > >> >> - FI/Espoo)'; 'ECRIT' >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>> Meeting: Agenda (my >>>> > >> >> mistake) >>>> > >> >> >>>> > >> >> The value is that in some networks where priority for >>>> > >> >emergency calls >>>> > >> >> is appropriate, and appropriate policing of marking is >>>> > >implemented, >>>> > >> >> emergency calls will receive resource priority. >>>> > >> >> >>>> > >> >> Not all networks would need policing. Some >> will. Policing >>>> could >>>> > >> >> be to Route header/R-URI content, but other >> criteria are >>>> possible. >>>> > >> >> >>>> > >> >> Not all networks will need resource priority >> for emergency >>>> calls. >>>> > >> >> Fine, ignore this marking/namespace. >>>> > >> >> >>>> > >> >> Brian >>>> > >> >> > -----Original Message----- >>>> > >> >> > From: Hannes Tschofenig >>>> [mailto:Hannes.Tschofenig@gmx.net] >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >> Tschofenig, Hannes >>>> (NSN - >>>> > >> >> > FI/Espoo); 'ECRIT' >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >>>> Meeting: Agenda (my >>>> > >> >> > mistake) >>>> > >> >> > >>>> > >> >> > I don't even see the value in permitting the >> endpoint todo >>>> the >>>> > >> >> > RPH marking. >>>> > >> >> > In addition to the security concerns there is also the >>>> > >> >problem that >>>> > >> >> > there are more options to implement without >> an additional >>>> value. >>>> > >> >> > >>>> > >> >> > >-----Original Message----- >>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >>>> > >> >> > >Sent: 05 February, 2009 00:03 >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >> 'Tschofenig, >>>> > >> >> Hannes (NSN - >>>> > >> >> > >FI/Espoo)'; 'ECRIT' >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: >>>> Agenda (my >>>> > >> >> > mistake) >>>> > >> >> > > >>>> > >> >> > >Hannes >>>> > >> >> > > >>>> > >> >> > >This matches my understanding precisely. We wish to >>>> > >> >> permit endpoints >>>> > >> >> > >to mark. We do not require it, and don't necessarily >>>> expect it >>>> > >> >> > >in many (even >>>> > >> >> > >most) cases. We don't wish to see the >> document prohibit >>>> it. >>>> > >> >> > >We all seem to agree it has value within the >> Emergency >>>> > >> >Services IP >>>> > >> >> > >Networks. >>>> > >> >> > > >>>> > >> >> > >Brian >>>> > >> >> > > >>>> > >> >> > >> -----Original Message----- >>>> > >> >> > >> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] >>>> > >> >> > >On Behalf >>>> > >> >> > >> Of James M. Polk >>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - >>>> > >> >> FI/Espoo); 'ECRIT' >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>> Meeting: >>>> > >Agenda (my >>>> > >> >> > >> mistake) >>>> > >> >> > >> >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >>>> > >> >> > >> > > James wrote: >>>> > >> >> > >> > >> you are the _lone_ voice not >> supporting this ID, >>>> > >> >> > >> > >>>> > >> >> > >> >Listening to the audio recording of past >> meetings I >>>> have to >>>> > >> >> > >say that >>>> > >> >> > >> >I >>>> > >> >> > >> was >>>> > >> >> > >> >not the only persons raising concerns about the >>>> document. >>>> > >> >> > >> >That was probably the reason why you >> agreed to limit >>>> the >>>> > >> >> > >scope of the >>>> > >> >> > >> >document (which you didn't later do) to >> get folks to >>>> agree >>>> > >> >> > >to make it >>>> > >> >> > >> a WG >>>> > >> >> > >> >item. >>>> > >> >> > >> >>>> > >> >> > >> re-listen to the audio please >>>> > >> >> > >> >>>> > >> >> > >> Ted's concerns were consistent with most >>>> (all?) other >>>> > >> >> concerns -- >>>> > >> >> > >> which were based on the premise of whether >> or not the >>>> > >> >> UAC should be >>>> > >> >> > >> trusted to initiate the marking on the >> INVITE. The >>>> most >>>> > >> >> > >> recent version has backed off this to a "can" -- >>>> meaning not >>>> > >> >prohibited >>>> > >> >> > >> (i.e., no 2119 text). I also backed off >> the text in >>>> the >>>> > >> >> SP domain >>>> > >> >> > >> part to "can", such that there is no 2119 text >>>> > >> >mandating or even >>>> > >> >> > >> recommending its usage there. I also do >> not prohibit >>>> its >>>> > >> >> > >use, based on >>>> > >> >> > >> local policy. Keith has come forward with >> the specific >>>> >>>> > >> >> > >> request that non-ESInet networks be >> allowed to mark and >>>> pay >>>> > >> >attention to >>>> > >> >> > >> this priority indication -- with IMS as >> the specific >>>> example >>>> > >> >> > >> he wishes to have this valid for. >>>> > >> >> > >> >>>> > >> >> > >> Where there is no disagreement, save for >> your recent >>>> > >> >> > >pushback - is in >>>> > >> >> > >> the ESInet, which is where Brian has requested it's >>>> > >> >> > >definition in the >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >> chair within >>>> > >> >> NENA, and if >>>> > >> >> > >> he asks for it, are you going to say you >> know better >>>> than he? >>>> > >> >> > >> >>>> > >> >> > >> >>>> > >> >> > >> >Btw, I not disagreeing with the document >> as such. I >>>> > >> >just want to >>>> > >> >> > the >>>> > >> >> > >> scope >>>> > >> >> > >> >to change. The usage of RPH within the emergency >>>> > >> >> services network >>>> > >> >> > is >>>> > >> >> > >> fine >>>> > >> >> > >> >for me. I may get convinced to start the >> RPH marking >>>> from >>>> > >> >> > >the the VSP >>>> > >> >> > >> >towards the PSAP. I feel uneasy about the >> end host >>>> doing >>>> > >> >> > >the marking. >>>> > >> >> > >> >>>> > >> >> > >> please read what I wrote above, and then >> re-read the >>>> > >> >most recent >>>> > >> >> > >> version of the ID. I don't have endpoints >> that SHOULD >>>> or >>>> > >> >> MUST mark >>>> > >> >> > >> anything wrt RPH. I also don't want to >> prohibit it, >>>> > >> >> because there >>>> > >> >> > >> might be cases (that I don't know of) of valid uses >>>> > >> >> under certain >>>> > >> >> > >> circumstances. Figure 1 is very clear >> that there are 3 >>>> > >> >> networking >>>> > >> >> > >> parts to consider >>>> > >> >> > >> >>>> > >> >> > >> #1 - from the endpoint >>>> > >> >> > >> #2 - within the VSP >>>> > >> >> > >> #3 - within the ESInet >>>> > >> >> > >> >>>> > >> >> > >> the most recent ID version has "can" for >> #s 1 and 2, >>>> and >>>> > >> >> > >2119 language >>>> > >> >> > >> offering those supporting this >> specification will have >>>> RPH >>>> > >> >> > >> adherence within #3 (the ESInet). >>>> > >> >> > >> >>>> > >> >> > >> What other scope changes do you want, >> because I haven't >>>> > >> >> heard them. >>>> > >> >> > >> >>>> > >> >> > >> I only heard you claim in email during the >> last IETF >>>> and in >>>> > >> >> > >the ECRIT >>>> > >> >> > >> session that RPH should not be used for priority >>>> marking >>>> > >> >> requests. >>>> > >> >> > >> This is something Keith (SIP WG chair) voiced his >>>> opposition >>>> > >> >> > >> to your views regarding creating a second >> means for SIP >>>> to >>>> > >> >priority >>>> > >> >> > >> mark request "when SIP already has one >> interoperable >>>> way to >>>> > >> >> > >> accomplish this... it's call the RP header >> mechanism". >>>> > >> >> > >> >>>> > >> >> > >> >I don't see advantages -- only disadvantages. >>>> > >> >> > >> > >>>> > >> >> > >> >Ciao >>>> > >> >> > >> >Hannes >>>> > >> >> > >> >>>> > >> >> > >> _______________________________________________ >>>> > >> >> > >> Ecrit mailing list >>>> > >> >> > >> Ecrit@ietf.org >>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >>>> > >> >> > > >>>> > >> >> >>>> > >> >> _______________________________________________ >>>> > >> >> Ecrit mailing list >>>> > >> >> Ecrit@ietf.org >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >>>> > >> >> >>>> > >> > >>>> > > >>>> > >>>> > _______________________________________________ >>>> > Ecrit mailing list >>>> > Ecrit@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DE828C22F for ; Fri, 6 Feb 2009 07:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-MjRBuqvX49 for ; Fri, 6 Feb 2009 07:50:38 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id F0F2528C0FF for ; Fri, 6 Feb 2009 07:50:37 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LVSyN-0008NS-FX; Fri, 06 Feb 2009 09:50:32 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> In-Reply-To: <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> Date: Fri, 6 Feb 2009 10:49:19 -0500 Message-ID: <0d9101c98872$7b2129b0$71637d10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXw Content-Language: en-us 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: Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:50:40 -0000 I agree that not all networks will permit (or pay attention to) a priority request from an end device. No one has asked for that. The namespace request has several uses, one of which is within an emergency services IP network, one of which is between elements within a public network controlled by the operator, and one of which is an endpoint request for resource priority. Those of us requesting this work proceed are happy if the endpoint part is simply left as possible (MAY), and, speaking for myself, having the draft discuss the security implications of endpoint marking is reasonable. Having discussed this issue with an implementation team who worked on MLPP systems, I am confident I know what I'm talking about, but YMMV. The fact that you could, if you wanted to, give resource priority to a call you decided, however you decided, was an emergency call is an implementation decision, and not subject to standardization. RPH is the IETF standard way for one entity to request resource priority of another entity in a SIP system. We're asking for a namespace to use that within the domain of emergency calls. That is, I think, a VERY reasonable request. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, February 06, 2009 10:33 AM > To: Hannes Tschofenig > Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > Subject: Re: [Ecrit] RPH > > To chime in here: > > I don't think it's productive to simply state that 4412 doesn't worry > about authorization, so we shouldn't either (simplifying a bit). > Authorization was discussed repeatedly, and the general assumption was > that there were two conditions: Either the user invoking resource- > priority was well known and had a set of permissions that could be > checked in real time or there are ways to deal with abuse after the > fact in ways that deter abuse (the court-martial kind of thing in a > military context). > > The RFC 4412 security consideration (11.2) call this out in pretty > strong language: > > Prioritized access to network and end-system resources imposes > particularly stringent requirements on authentication and > authorization mechanisms, since access to prioritized resources may > impact overall system stability and performance and not just result > in theft of, say, a single phone call. > Thus, the question is whether we have such strong authentication in > emergency calling. In some cases, such as residential fixed line > deployments where ISP = VSP, we're probably pretty close, in others, > such as prepaid cell phones or hot spots or VSP-only providers, we > aren't. > > The other point that I think Hannes is making is that the information > is either redundant or dangerous. If a processing element recognizes > the call as being an emergency call, it can apply whatever treatment > it deems appropriate and doesn't need additional information. If it > doesn't or can't, using just the RPH can be rather dangerous unless > that element can be reasonably certain that there is strong > authentication and recourse. > > I don't buy the argument that somehow finding the RPH is faster than > just looking for the identifier. Thus, given that the information is > either redundant or dangerous, I fail to see the advantage. > > Henning > > > On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > > > Don't get hung up on the details. There are ways to optimize it. > > That was > > not the point of the code example. > > > > The problem that my pseudo code should have shown you is that you > > * don't gain anything with RPH marking for the emergency call case > > from the > > SIP UA towards the outbound proxy since the functionality is already > > provide > > otherwise. How often does the proxy need to get told that this is an > > emergency call todo whatever emergency call handling procedures are > > necessary? > > * you only introduce fraud problems (if you are not careful and you > > understand the security stuff well enough) > > > > If you can point me to people who implement the RPH emergency call > > case > > please do so. I would love to talk to them. > > > > Ciao > > Hannes > > > > PS: You need to parse incoming messages to some extend so that you > > know what > > it contains :-) > > Only looking for the emergency RPH header (and not for the Service > > URN/dial > > string) would exactly be the DoS/fraud attack I am worried about. > > That's the thing Henning was worried about (go and listen to the past > > meeting minutes). > > > > > >> Hannes > >> > >> You need to talk to people who really implement this kind of > >> thing. You are way off. > >> > >> When you implement a resource priority system, the point of > >> doing that is to look though the queue of work and pick out > >> the ones with priority, handling them first. You don't do all > >> the parsing, you don't do a lot of decision tree. > >> > >> Typically: > >> Check for DoS things, like too big messages, etc Do a quick > >> scan for the RPH message header If found: > >> Parse the message > >> Determine validity > >> Determine priority > >> Queue on the correct work queue > >> > >> The first two actions have to be very fast. Anyone who builds > >> a SIP thingie will tell you that parsing is one of the big > >> cycle consumers: if you have to parse every message BEFORE you > >> determine priority, you can't give much resource priority. > >> Once you get the whole message parsed, you might as well > >> finish working on it, because you've done so much of the work. > >> OTHOH, finding the end-of-message delimiter and doing a quick > >> string search for RPH is fast. If you are doing priority, you > >> need to keep all the priority processing pretty uniform, and > >> pretty simple, or you tend to spend too much time futzing > >> around figuring out what to do. You put all the priority > >> related stuff together, and use as much common code as possible. > >> > >> Brian > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf > >>> Of Hannes Tschofenig > >>> Sent: Friday, February 06, 2009 8:41 AM > >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' > >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >>> bounces@ietf.org > >>> Subject: [Ecrit] RPH > >>> > >>> Over lunch I was also thinking how an outbound proxy would > implement > >>> some of the emergency procedures. Here are some thoughts: > >>> > >>> --------------------------------------------------- > >>> > >>> // Process incoming message > >>> Parse(msg); > >>> > >>> // SIP INVITE without Service URN > >>> // legacy devices > >>> If (recognize-dialstring(msg)==TRUE) { > >>> // we got an emergency call going on > >>> emergency=TRUE; > >>> if (dialstring(msg) == 911) serviceURN=urn:service:sos; } else if > >>> (recognize-serviceURN(msg)==TRUE) { > >>> // oh. A updated device that has a service URN attached to the > call > >>> serviceURN=retrieve_ServiceURN(msg); > >>> emergency=TRUE; > >>> } else { > >>> // standard SIP message > >>> // regular processing > >>> process(msg); > >>> emergency=FALSE; > >>> } > >>> > >>> If (emergency == TRUE) { > >>> // make sure that the emergency call does not get dropped on the > >>> floor > >>> // skip authorization failures > >>> // give the call a special treatment > >>> lots-of-code-here(); > >>> > >>> // trigger all the QoS signaling you have in the network to make > >>> James happy > >>> trigger-qos(); > >>> > >>> // query location > >>> location=retrieve-location(); > >>> > >>> // determine next hop > >>> next-hop=lost(location, serviceURN) > >>> > >>> // attach RPH marking to outgoing msg to make James and > >> Keith happy > >>> msg=add(msg, RPH); > >>> > >>> send(msg, next-hop); > >>> } > >>> > >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { > >>> // all the emergency related processing done already upfront > >>> // hence I log something. > >>> log(RPH_WAS_PRESENT_JUHU); > >>> } else if ((rph-present(msg) == TRUE) && (emergency == FALSE)) { > >>> // this is not an emergency call > >>> // this is something like GETS > >>> result=special-authorization-procedure(user); > >>> > >>> if (result == AUTHORIZED) { > >>> // do some priority & preemption thing here. > >>> // trigger all the QoS you have > >>> lots-of-code-here(); > >>> } else { > >>> log("NOT AUTHORIZED; don't DoS my network"); > >>> } > >>> } else { > >>> // don't need todo any RPH processing > >>> // this includes the case where the call was an emergency call but > >>> the RPH > >>> > >>> // marking was not there. > >>> nothing(); > >>> } > >>> > >>> --------------------------------------------------- > >>> > >>> > >>> Ciao > >>> Hannes > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>> Behalf Of Hannes Tschofenig > >>>> Sent: 06 February, 2009 15:07 > >>>> To: 'Janet P Gunn' > >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > >>> FI/Espoo) > >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > >>>> > >>>> Who would define something that could prevent DoS problems? > >>>> > >>>> ________________________________ > >>>> > >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >>>> Sent: 06 February, 2009 14:11 > >>>> To: Hannes Tschofenig > >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); > 'James > >>>> M. Polk' > >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > >>>> > >>>> > >>>> > >>>> But there is nothing IN RFC4412 that specifically > >> addresses how to > >>>> prevent any particular namespace being used for DoS. Anyone/any > UA > >>>> can ATTEMPT to invoke priority treatment by attaching RPH. For > all > >>>> of the 4412 namespaces, as with the new proposed namespace, the > >>>> mechanisms for preventing DoS are not specified in the > >> document that > >>>> defines the namespace. > >>>> They are/will be specified elsewhere. > >>>> > >>>> Janet > >>>> > >>>> This is a PRIVATE message. If you are not the intended > >> recipient, > >>>> please delete without copying and kindly advise us by e-mail of > the > >>>> mistake in delivery. > >>>> NOTE: Regardless of content, this e-mail shall not > >> operate to bind > >>>> CSC to any order or other contract unless pursuant to explicit > >>>> written agreement or government initiative expressly permitting > the > >>>> use of e-mail for such purpose. > >>>> > >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > >>>> > >>>> > Hi James, > >>>> > > >>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >> documents. What I > >>>> would > >>>> > like to point out is that there is more than just a > >> header and > >>>> values within > >>>> > the header that have to be considered in order to > >> make a judgement > >>>> of what > >>>> > is appropriate and what isn't. There is an > >> architectural question > >>>> and > >>>> > whether the environment we are using the stuff is > >> indeed providing > >>>> the > >>>> > properties you need for the solution to be appropriate. > >>>> > > >>>> > Let me describe in more detail what I meant (and > >> please correct me > >>>> if I am > >>>> > wrong). > >>>> > > >>>> > Getting priority for SIP requests when using a GETS > >> alike scenario > >>>> means > >>>> > that the entity that issues the request is specially > >> authorized > >>>> since > >>>> > otherwise you introduce a nice denial of service attack. This > >>>> authorization > >>>> > is tied to the entity that makes the request. For > >> example, the > >>>> person is > >>>> > working for the government and has special rights. > >>>> James Bond as a (not so) > >>>> > secret agent might have these rights. > >>>> > > >>>> > The emergency services case (citizen-to-authority) is a bit > >>>> different as > >>>> > there aren't really special rights with respect to > >> authorization > >>>> tied to > >>>> > individuals. Instead, the fact that something is an > >> emergency is > >>>> purely a > >>>> > judgement of the human that dials a special number. > >>>> To deal with fraud, we > >>>> > discussed in the group on what we can actually do to > >> ensure that > >>>> end users > >>>> > do not bypass security procedures (such as > >> authorization checks, > >>>> charging > >>>> > and so on). Part of this investigation was the publication of > >>>> > http://www.ietf.org/rfc/rfc5069.txt that also describes this > >>>> issue. > >>>> > > >>>> > So, imagine the implementation of a SIP proxy (and we > >> implemented > >>>> that > >>>> > stuff) that receives a call that contains a Service > >> URN. The code > >>>> branches > >>>> > into a special mode where everything is done so that the call > >>>> receives > >>>> > appropriate treatment and does not get dropped on the > >> floor. The > >>>> way how the > >>>> > Service URN is placed in the message ensures that the > >> call cannot > >>>> go to my > >>>> > friend (instead of the PSAP) unless the end host ran > >> LoST already. > >>>> In the > >>>> > latter case, we discussed this also on the list for a > >> while and > >>>> Richard even > >>>> > wrote a draft about it in the context of the location hiding > >>>> topic, we said > >>>> > that the proxy would have to run LoST if he cares about a > >>>> potential > >>>> > fraudulent usage. > >>>> > > >>>> > So, what do we need todo in order to provide secure RFC 4412 > >>>> functionality > >>>> > in our context? > >>>> > > >>>> > Do you think that the current text in > >>>> > > >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >>>> gency-rph-nam > >>>> > espace-00.txt reflects any of the above-described issues: > >>>> > " > >>>> > The Security considerations that apply to RFC 4412 > >>>> [RFC4412] > >>>> apply > >>>> > here. This document introduces no new security > >>>> issues relative > >>>> to > >>>> > RFC 4412. > >>>> > " > >>>> > > >>>> > From various discussions in GEOPRIV I recall that you are > >>>> super-sensitive > >>>> > regarding security and privacy. For some reasons you > >> don't seem to > >>>> have the > >>>> > same concerns here. I would like to understand your reasoning. > >>>> > > >>>> > Please also do me another favor: Don't always say > >> that I don't > >>>> understand > >>>> > the subject. Even if that would be the case it isn't > >> particular > >>>> fair given > >>>> > that different folks had to educate you on other > >> topics in the > >>>> past as well. > >>>> > Additionally, if you listen to the audio recordings > >> then you will > >>>> notice > >>>> > that Henning, Ted, and Jon do not seem to understand > >> the issue > >>>> either as > >>>> > they have raised similar issues during the F2F meetings. > >>>> > > >>>> > Ciao > >>>> > Hannes > >>>> > > >>>> > > >>>> > >Hannes - I believe it is you who do not understand > >> RFC 4412 -- > >>>> > >and many of us are trying to get that through to you, but you > >>>> > >don't seem to want to listen/read. > >>>> > > > >>>> > >RFC 4412 is *for* priority marking SIP requests, > >>>> > > > >>>> > >One use is GETS. > >>>> > > > >>>> > >One use is MLPP. > >>>> > > > >>>> > >These examples are in RFC 4412 because there were specific > >>>> > >namespaces being created for the IANA section of > >> that document. > >>>> > > > >>>> > >Reading the whole document, you will see that RPH can be > >>>> > >specified for other uses than GETS or MLPP specifically. > >>>> > > > >>>> > >I knew when I wrote RFC 4412 that one day we would specify a > >>>> > >namespace for ECRIT (the "esnet" namespace now) -- but I also > >>>> > >knew it was premature for RFC 4412 to incorporate that > >>>> > >namespace, that a future doc to RFC 4412 would have to be > >>>> > >written to do this. Brian and I talked about this at the > >>>> > >original NENA meeting that created the IP WGs there > >> (in August > >>>> > >of 03). We both agreed we should wait until it was > >>>> > >appropriate to the work in the IETF to submit this document > >>>> > >that is now > >>>> > > >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >>>> > >gency-rph-namespace-00.txt > >>>> > > > >>>> > >Yet, you seem to want to use some additional mechanism to > >>>> > >indicate priority of a call in SIP. That means you want to > >>>> > >introduce a second way to accomplish this in SIP. > >>>> Why do you > >>>> > >want to promote a separate way to do something SIP > >> has already > >>>> > >defined? That will cause interoperability issues and > >> we both know > >>>> that. > >>>> > > > >>>> > >You've said to me (and others) that you believe RPH is just > >>>> > >another way to accomplish what sos or a URI can > >> indicate - and > >>>> > >you're wrong. Your way would be _the_second_way_to_do_it, > >>>> > >because SIP already considers RPH to be *the*way* to priority > >>>> > >mark SIP requests. > >>>> > > > >>>> > >If you don't believe me (no comment), then why do you not > >>>> > >believe the SIP WG chair (who knows more about SIP than both > >>>> > >of us) - who, on this thread, has again said to you "RFC 4412 > >>>> > >(RPH) is the SIP mechanism to priority mark SIP requests"? > >>>> > > > >>>> > >Further, I believe it is inappropriate to prohibit endpoints > >>>> > >from being able to set the esnet namespace. I absolutely > >>>> > >believe it will not be needed most of the time, but I believe > >>>> > >if someone does find a valid use for endpoints to mark > >>>> > >priority in SIP, this ID - once it has become an RFC -- will > >>>> > >have to be obsoleted with a new RFC saying the exact > >> opposite. > >>>> > > > >>>> > >(color me confused ... over and over again) > >>>> > > > >>>> > >James > >>>> > > > >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>>> > >>Keith, please understand that the usage of RFC 4412 > >> for GETS and > >>>> for > >>>> > >>the type of emergency call we discuss here is > >> different. Just > >>>> looking > >>>> > >>at the header and the name of the namespace is a bit > >>>> > >artificial. I hope > >>>> > >>you understand that. > >>>> > >> > >>>> > >> >-----Original Message----- > >>>> > >> >From: DRAGE, Keith (Keith) > >>>> [mailto:drage@alcatel-lucent.com] > >>>> > >> >Sent: 05 February, 2009 14:55 > >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >>>> Polk'; 'Tschofenig, > >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: Agenda (my > >>>> > >>>> > >> >mistake) > >>>> > >> > > >>>> > >> >Which is exactly what RFC 4412 specifies for all > >> namespaces. > >>>> > >> > > >>>> > >> >regards > >>>> > >> > > >>>> > >> >Keith > >>>> > >> > > >>>> > >> >> -----Original Message----- > >>>> > >> >> From: ecrit-bounces@ietf.org > >> [mailto:ecrit-bounces@ietf.org] > >>>> > >> >On Behalf > >>>> > >> >> Of Brian Rosen > >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >>>> > >Hannes (NSN > >>>> > >> >> - FI/Espoo)'; 'ECRIT' > >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: Agenda (my > >>>> > >> >> mistake) > >>>> > >> >> > >>>> > >> >> The value is that in some networks where priority for > >>>> > >> >emergency calls > >>>> > >> >> is appropriate, and appropriate policing of marking is > >>>> > >implemented, > >>>> > >> >> emergency calls will receive resource priority. > >>>> > >> >> > >>>> > >> >> Not all networks would need policing. Some > >> will. Policing > >>>> could > >>>> > >> >> be to Route header/R-URI content, but other > >> criteria are > >>>> possible. > >>>> > >> >> > >>>> > >> >> Not all networks will need resource priority > >> for emergency > >>>> calls. > >>>> > >> >> Fine, ignore this marking/namespace. > >>>> > >> >> > >>>> > >> >> Brian > >>>> > >> >> > -----Original Message----- > >>>> > >> >> > From: Hannes Tschofenig > >>>> [mailto:Hannes.Tschofenig@gmx.net] > >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >> Tschofenig, Hannes > >>>> (NSN - > >>>> > >> >> > FI/Espoo); 'ECRIT' > >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: Agenda (my > >>>> > >> >> > mistake) > >>>> > >> >> > > >>>> > >> >> > I don't even see the value in permitting the > >> endpoint todo > >>>> the > >>>> > >> >> > RPH marking. > >>>> > >> >> > In addition to the security concerns there is also the > >>>> > >> >problem that > >>>> > >> >> > there are more options to implement without > >> an additional > >>>> value. > >>>> > >> >> > > >>>> > >> >> > >-----Original Message----- > >>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >>>> > >> >> > >Sent: 05 February, 2009 00:03 > >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >> 'Tschofenig, > >>>> > >> >> Hannes (NSN - > >>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: > >>>> Agenda (my > >>>> > >> >> > mistake) > >>>> > >> >> > > > >>>> > >> >> > >Hannes > >>>> > >> >> > > > >>>> > >> >> > >This matches my understanding precisely. We wish to > >>>> > >> >> permit endpoints > >>>> > >> >> > >to mark. We do not require it, and don't necessarily > >>>> expect it > >>>> > >> >> > >in many (even > >>>> > >> >> > >most) cases. We don't wish to see the > >> document prohibit > >>>> it. > >>>> > >> >> > >We all seem to agree it has value within the > >> Emergency > >>>> > >> >Services IP > >>>> > >> >> > >Networks. > >>>> > >> >> > > > >>>> > >> >> > >Brian > >>>> > >> >> > > > >>>> > >> >> > >> -----Original Message----- > >>>> > >> >> > >> From: ecrit-bounces@ietf.org > >>>> [mailto:ecrit-bounces@ietf.org] > >>>> > >> >> > >On Behalf > >>>> > >> >> > >> Of James M. Polk > >>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >>>> > >> >> FI/Espoo); 'ECRIT' > >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: > >>>> > >Agenda (my > >>>> > >> >> > >> mistake) > >>>> > >> >> > >> > >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >>>> > >> >> > >> > > James wrote: > >>>> > >> >> > >> > >> you are the _lone_ voice not > >> supporting this ID, > >>>> > >> >> > >> > > >>>> > >> >> > >> >Listening to the audio recording of past > >> meetings I > >>>> have to > >>>> > >> >> > >say that > >>>> > >> >> > >> >I > >>>> > >> >> > >> was > >>>> > >> >> > >> >not the only persons raising concerns about the > >>>> document. > >>>> > >> >> > >> >That was probably the reason why you > >> agreed to limit > >>>> the > >>>> > >> >> > >scope of the > >>>> > >> >> > >> >document (which you didn't later do) to > >> get folks to > >>>> agree > >>>> > >> >> > >to make it > >>>> > >> >> > >> a WG > >>>> > >> >> > >> >item. > >>>> > >> >> > >> > >>>> > >> >> > >> re-listen to the audio please > >>>> > >> >> > >> > >>>> > >> >> > >> Ted's concerns were consistent with most > >>>> (all?) other > >>>> > >> >> concerns -- > >>>> > >> >> > >> which were based on the premise of whether > >> or not the > >>>> > >> >> UAC should be > >>>> > >> >> > >> trusted to initiate the marking on the > >> INVITE. The > >>>> most > >>>> > >> >> > >> recent version has backed off this to a "can" -- > >>>> meaning not > >>>> > >> >prohibited > >>>> > >> >> > >> (i.e., no 2119 text). I also backed off > >> the text in > >>>> the > >>>> > >> >> SP domain > >>>> > >> >> > >> part to "can", such that there is no 2119 text > >>>> > >> >mandating or even > >>>> > >> >> > >> recommending its usage there. I also do > >> not prohibit > >>>> its > >>>> > >> >> > >use, based on > >>>> > >> >> > >> local policy. Keith has come forward with > >> the specific > >>>> > >>>> > >> >> > >> request that non-ESInet networks be > >> allowed to mark and > >>>> pay > >>>> > >> >attention to > >>>> > >> >> > >> this priority indication -- with IMS as > >> the specific > >>>> example > >>>> > >> >> > >> he wishes to have this valid for. > >>>> > >> >> > >> > >>>> > >> >> > >> Where there is no disagreement, save for > >> your recent > >>>> > >> >> > >pushback - is in > >>>> > >> >> > >> the ESInet, which is where Brian has requested it's > >>>> > >> >> > >definition in the > >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >> chair within > >>>> > >> >> NENA, and if > >>>> > >> >> > >> he asks for it, are you going to say you > >> know better > >>>> than he? > >>>> > >> >> > >> > >>>> > >> >> > >> > >>>> > >> >> > >> >Btw, I not disagreeing with the document > >> as such. I > >>>> > >> >just want to > >>>> > >> >> > the > >>>> > >> >> > >> scope > >>>> > >> >> > >> >to change. The usage of RPH within the emergency > >>>> > >> >> services network > >>>> > >> >> > is > >>>> > >> >> > >> fine > >>>> > >> >> > >> >for me. I may get convinced to start the > >> RPH marking > >>>> from > >>>> > >> >> > >the the VSP > >>>> > >> >> > >> >towards the PSAP. I feel uneasy about the > >> end host > >>>> doing > >>>> > >> >> > >the marking. > >>>> > >> >> > >> > >>>> > >> >> > >> please read what I wrote above, and then > >> re-read the > >>>> > >> >most recent > >>>> > >> >> > >> version of the ID. I don't have endpoints > >> that SHOULD > >>>> or > >>>> > >> >> MUST mark > >>>> > >> >> > >> anything wrt RPH. I also don't want to > >> prohibit it, > >>>> > >> >> because there > >>>> > >> >> > >> might be cases (that I don't know of) of valid uses > >>>> > >> >> under certain > >>>> > >> >> > >> circumstances. Figure 1 is very clear > >> that there are 3 > >>>> > >> >> networking > >>>> > >> >> > >> parts to consider > >>>> > >> >> > >> > >>>> > >> >> > >> #1 - from the endpoint > >>>> > >> >> > >> #2 - within the VSP > >>>> > >> >> > >> #3 - within the ESInet > >>>> > >> >> > >> > >>>> > >> >> > >> the most recent ID version has "can" for > >> #s 1 and 2, > >>>> and > >>>> > >> >> > >2119 language > >>>> > >> >> > >> offering those supporting this > >> specification will have > >>>> RPH > >>>> > >> >> > >> adherence within #3 (the ESInet). > >>>> > >> >> > >> > >>>> > >> >> > >> What other scope changes do you want, > >> because I haven't > >>>> > >> >> heard them. > >>>> > >> >> > >> > >>>> > >> >> > >> I only heard you claim in email during the > >> last IETF > >>>> and in > >>>> > >> >> > >the ECRIT > >>>> > >> >> > >> session that RPH should not be used for priority > >>>> marking > >>>> > >> >> requests. > >>>> > >> >> > >> This is something Keith (SIP WG chair) voiced his > >>>> opposition > >>>> > >> >> > >> to your views regarding creating a second > >> means for SIP > >>>> to > >>>> > >> >priority > >>>> > >> >> > >> mark request "when SIP already has one > >> interoperable > >>>> way to > >>>> > >> >> > >> accomplish this... it's call the RP header > >> mechanism". > >>>> > >> >> > >> > >>>> > >> >> > >> >I don't see advantages -- only disadvantages. > >>>> > >> >> > >> > > >>>> > >> >> > >> >Ciao > >>>> > >> >> > >> >Hannes > >>>> > >> >> > >> > >>>> > >> >> > >> _______________________________________________ > >>>> > >> >> > >> Ecrit mailing list > >>>> > >> >> > >> Ecrit@ietf.org > >>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> >> > > > >>>> > >> >> > >>>> > >> >> _______________________________________________ > >>>> > >> >> Ecrit mailing list > >>>> > >> >> Ecrit@ietf.org > >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> >> > >>>> > >> > > >>>> > > > >>>> > > >>>> > _______________________________________________ > >>>> > Ecrit mailing list > >>>> > Ecrit@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC0928C112 for ; Fri, 6 Feb 2009 07:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+dZwqxOceqz for ; Fri, 6 Feb 2009 07:58:21 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 3358728C0FB for ; Fri, 6 Feb 2009 07:58:02 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n16FvnM7031701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2009 16:57:49 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 6 Feb 2009 16:57:49 +0100 From: "DRAGE, Keith (Keith)" To: Henning Schulzrinne , Hannes Tschofenig Date: Fri, 6 Feb 2009 16:57:47 +0100 Thread-Topic: [Ecrit] RPH Thread-Index: AcmIcFpkoHyDmBXoS2CnsbC/fahubQAAEjQg Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499B993@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> In-Reply-To: <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:58:23 -0000 One of the points I was going to make was that RPH in itself does not neces= sarily create DOS as Hannes seems to be thinking. Henning seems to also be = saying that below, in that after the event restrictions can be used to deal= with problems. As Brian has indicated you place traffic relating to differ= ent namespaces and different priorities within namespaces (if defined) with= in different queues. Unmarked traffic goes into another queue or queues. Yo= u then process those queues according to some algorithm. The main way of reaching a DOS attach with RPH is if the algorithm always p= rocess all the traffic in a particular queue before processing any of the o= thers, and I suspect most RPH usages will not do that, and in any case, the= re are good reasons for not doing this on emergency calls. I believe I have= made the point repeatedly in the past that RPH does not mean first come fi= rst served. It means I have made an commitment with the namespace owner to = handle the traffic with certain defined criteria. And in some respects any emergency call handling in the network that is not= well specified can cause a denial of service attack, whether it is RPH mar= ked or not. This is merely because you are funnelling potentially large amo= unts of traffic to few endpoints. So RPH is a tool. Poor usage can cause problems, as can not setting up your= routing handling correctly to deal with multiple calls to a single destina= tion. We don't specify good practice for either. But in general authorisation works very simply, and I am not arguing for no= authorisation. Essentially it consists of: Do I trust the prior entity in the chain to send me a request RPH header wi= th a particular namespace and priority level. If yes I put it in the approp= riate queue. In no I either throw the RPH header away, pass it on without s= pecial handling of the request, or perform my own authorisation of that use= r. Which I use is based on network design, and agrements between service pr= oviders. Authorisation of the user in this respect generally checks a very limited n= umber of criteria: - Is this call addressed to a PSAP - Is this user allowed to make an emergency call Keith regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Friday, February 06, 2009 3:33 PM > To: Hannes Tschofenig > Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > Subject: Re: [Ecrit] RPH > > To chime in here: > > I don't think it's productive to simply state that 4412 > doesn't worry about authorization, so we shouldn't either > (simplifying a bit). > Authorization was discussed repeatedly, and the general > assumption was that there were two conditions: Either the > user invoking resource- priority was well known and had a set > of permissions that could be checked in real time or there > are ways to deal with abuse after the fact in ways that deter > abuse (the court-martial kind of thing in a military context). > > The RFC 4412 security consideration (11.2) call this out in > pretty strong language: > > Prioritized access to network and end-system resources imposes > particularly stringent requirements on authentication and > authorization mechanisms, since access to prioritized > resources may > impact overall system stability and performance and not > just result > in theft of, say, a single phone call. > Thus, the question is whether we have such strong > authentication in emergency calling. In some cases, such as > residential fixed line deployments where ISP =3D VSP, we're > probably pretty close, in others, such as prepaid cell phones > or hot spots or VSP-only providers, we aren't. > > The other point that I think Hannes is making is that the > information is either redundant or dangerous. If a processing > element recognizes the call as being an emergency call, it > can apply whatever treatment it deems appropriate and doesn't > need additional information. If it doesn't or can't, using > just the RPH can be rather dangerous unless that element can > be reasonably certain that there is strong authentication and > recourse. > > I don't buy the argument that somehow finding the RPH is > faster than just looking for the identifier. Thus, given that > the information is either redundant or dangerous, I fail to > see the advantage. > > Henning > > > On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > > > Don't get hung up on the details. There are ways to optimize it. > > That was > > not the point of the code example. > > > > The problem that my pseudo code should have shown you is that you > > * don't gain anything with RPH marking for the emergency call case > > from the SIP UA towards the outbound proxy since the > functionality is > > already provide otherwise. How often does the proxy need to > get told > > that this is an emergency call todo whatever emergency call > handling > > procedures are necessary? > > * you only introduce fraud problems (if you are not careful and you > > understand the security stuff well enough) > > > > If you can point me to people who implement the RPH emergency call > > case please do so. I would love to talk to them. > > > > Ciao > > Hannes > > > > PS: You need to parse incoming messages to some extend so that you > > know what it contains :-) Only looking for the emergency RPH header > > (and not for the Service URN/dial > > string) would exactly be the DoS/fraud attack I am worried about. > > That's the thing Henning was worried about (go and listen > to the past > > meeting minutes). > > > > > >> Hannes > >> > >> You need to talk to people who really implement this kind > of thing. > >> You are way off. > >> > >> When you implement a resource priority system, the point of doing > >> that is to look though the queue of work and pick out the > ones with > >> priority, handling them first. You don't do all the parsing, you > >> don't do a lot of decision tree. > >> > >> Typically: > >> Check for DoS things, like too big messages, etc Do a > quick scan for > >> the RPH message header If found: > >> Parse the message > >> Determine validity > >> Determine priority > >> Queue on the correct work queue > >> > >> The first two actions have to be very fast. Anyone who > builds a SIP > >> thingie will tell you that parsing is one of the big cycle > consumers: > >> if you have to parse every message BEFORE you determine > priority, you > >> can't give much resource priority. > >> Once you get the whole message parsed, you might as well finish > >> working on it, because you've done so much of the work. > >> OTHOH, finding the end-of-message delimiter and doing a > quick string > >> search for RPH is fast. If you are doing priority, you > need to keep > >> all the priority processing pretty uniform, and pretty > simple, or you > >> tend to spend too much time futzing around figuring out > what to do. > >> You put all the priority related stuff together, and use as much > >> common code as possible. > >> > >> Brian > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf > >>> Of Hannes Tschofenig > >>> Sent: Friday, February 06, 2009 8:41 AM > >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' > >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >>> bounces@ietf.org > >>> Subject: [Ecrit] RPH > >>> > >>> Over lunch I was also thinking how an outbound proxy > would implement > >>> some of the emergency procedures. Here are some thoughts: > >>> > >>> --------------------------------------------------- > >>> > >>> // Process incoming message > >>> Parse(msg); > >>> > >>> // SIP INVITE without Service URN > >>> // legacy devices > >>> If (recognize-dialstring(msg)=3D=3DTRUE) { // we got an > emergency call > >>> going on emergency=3DTRUE; if (dialstring(msg) =3D=3D 911) > >>> serviceURN=3Durn:service:sos; } else if > >>> (recognize-serviceURN(msg)=3D=3DTRUE) { > >>> // oh. A updated device that has a service URN attached > to the call > >>> serviceURN=3Dretrieve_ServiceURN(msg); > >>> emergency=3DTRUE; > >>> } else { > >>> // standard SIP message > >>> // regular processing > >>> process(msg); > >>> emergency=3DFALSE; > >>> } > >>> > >>> If (emergency =3D=3D TRUE) { > >>> // make sure that the emergency call does not get > dropped on the > >>> floor > >>> // skip authorization failures > >>> // give the call a special treatment > >>> lots-of-code-here(); > >>> > >>> // trigger all the QoS signaling you have in the > network to make > >>> James happy > >>> trigger-qos(); > >>> > >>> // query location > >>> location=3Dretrieve-location(); > >>> > >>> // determine next hop > >>> next-hop=3Dlost(location, serviceURN) > >>> > >>> // attach RPH marking to outgoing msg to make James and > >> Keith happy > >>> msg=3Dadd(msg, RPH); > >>> > >>> send(msg, next-hop); > >>> } > >>> > >>> If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) { > >>> // all the emergency related processing done already upfront > >>> // hence I log something. > >>> log(RPH_WAS_PRESENT_JUHU); > >>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D > FALSE)) { // > >>> this is not an emergency call // this is something like GETS > >>> result=3Dspecial-authorization-procedure(user); > >>> > >>> if (result =3D=3D AUTHORIZED) { > >>> // do some priority & preemption thing here. > >>> // trigger all the QoS you have > >>> lots-of-code-here(); > >>> } else { > >>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // > >>> don't need todo any RPH processing // this includes the > case where > >>> the call was an emergency call but the RPH > >>> > >>> // marking was not there. > >>> nothing(); > >>> } > >>> > >>> --------------------------------------------------- > >>> > >>> > >>> Ciao > >>> Hannes > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>> Behalf Of Hannes Tschofenig > >>>> Sent: 06 February, 2009 15:07 > >>>> To: 'Janet P Gunn' > >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > >>> FI/Espoo) > >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > >>>> > >>>> Who would define something that could prevent DoS problems? > >>>> > >>>> ________________________________ > >>>> > >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >>>> Sent: 06 February, 2009 14:11 > >>>> To: Hannes Tschofenig > >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - > FI/Espoo); 'James > >>>> M. Polk' > >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > >>>> > >>>> > >>>> > >>>> But there is nothing IN RFC4412 that specifically > >> addresses how to > >>>> prevent any particular namespace being used for DoS. > Anyone/any UA > >>>> can ATTEMPT to invoke priority treatment by attaching > RPH. For all > >>>> of the 4412 namespaces, as with the new proposed namespace, the > >>>> mechanisms for preventing DoS are not specified in the > >> document that > >>>> defines the namespace. > >>>> They are/will be specified elsewhere. > >>>> > >>>> Janet > >>>> > >>>> This is a PRIVATE message. If you are not the intended > >> recipient, > >>>> please delete without copying and kindly advise us by > e-mail of the > >>>> mistake in delivery. > >>>> NOTE: Regardless of content, this e-mail shall not > >> operate to bind > >>>> CSC to any order or other contract unless pursuant to explicit > >>>> written agreement or government initiative expressly > permitting the > >>>> use of e-mail for such purpose. > >>>> > >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > >>>> > >>>> > Hi James, > >>>> > > >>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >> documents. What I > >>>> would > >>>> > like to point out is that there is more than just a > >> header and > >>>> values within > >>>> > the header that have to be considered in order to > >> make a judgement > >>>> of what > >>>> > is appropriate and what isn't. There is an > >> architectural question > >>>> and > >>>> > whether the environment we are using the stuff is > >> indeed providing > >>>> the > >>>> > properties you need for the solution to be appropriate. > >>>> > > >>>> > Let me describe in more detail what I meant (and > >> please correct me > >>>> if I am > >>>> > wrong). > >>>> > > >>>> > Getting priority for SIP requests when using a GETS > >> alike scenario > >>>> means > >>>> > that the entity that issues the request is specially > >> authorized > >>>> since > >>>> > otherwise you introduce a nice denial of service attack. This > >>>> authorization > >>>> > is tied to the entity that makes the request. For > >> example, the > >>>> person is > >>>> > working for the government and has special rights. > >>>> James Bond as a (not so) > >>>> > secret agent might have these rights. > >>>> > > >>>> > The emergency services case (citizen-to-authority) is a bit > >>>> different as > >>>> > there aren't really special rights with respect to > >> authorization > >>>> tied to > >>>> > individuals. Instead, the fact that something is an > >> emergency is > >>>> purely a > >>>> > judgement of the human that dials a special number. > >>>> To deal with fraud, we > >>>> > discussed in the group on what we can actually do to > >> ensure that > >>>> end users > >>>> > do not bypass security procedures (such as > >> authorization checks, > >>>> charging > >>>> > and so on). Part of this investigation was the publication of > >>>> > http://www.ietf.org/rfc/rfc5069.txt that also describes this > >>>> issue. > >>>> > > >>>> > So, imagine the implementation of a SIP proxy (and we > >> implemented > >>>> that > >>>> > stuff) that receives a call that contains a Service > >> URN. The code > >>>> branches > >>>> > into a special mode where everything is done so that the call > >>>> receives > >>>> > appropriate treatment and does not get dropped on the > >> floor. The > >>>> way how the > >>>> > Service URN is placed in the message ensures that the > >> call cannot > >>>> go to my > >>>> > friend (instead of the PSAP) unless the end host ran > >> LoST already. > >>>> In the > >>>> > latter case, we discussed this also on the list for a > >> while and > >>>> Richard even > >>>> > wrote a draft about it in the context of the location hiding > >>>> topic, we said > >>>> > that the proxy would have to run LoST if he cares about a > >>>> potential > >>>> > fraudulent usage. > >>>> > > >>>> > So, what do we need todo in order to provide secure RFC 4412 > >>>> functionality > >>>> > in our context? > >>>> > > >>>> > Do you think that the current text in > >>>> > > >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >>>> gency-rph-nam > >>>> > espace-00.txt reflects any of the above-described issues: > >>>> > " > >>>> > The Security considerations that apply to RFC 4412 > >>>> [RFC4412] > >>>> apply > >>>> > here. This document introduces no new security > >>>> issues relative > >>>> to > >>>> > RFC 4412. > >>>> > " > >>>> > > >>>> > From various discussions in GEOPRIV I recall that you are > >>>> super-sensitive > >>>> > regarding security and privacy. For some reasons you > >> don't seem to > >>>> have the > >>>> > same concerns here. I would like to understand your reasoning. > >>>> > > >>>> > Please also do me another favor: Don't always say > >> that I don't > >>>> understand > >>>> > the subject. Even if that would be the case it isn't > >> particular > >>>> fair given > >>>> > that different folks had to educate you on other > >> topics in the > >>>> past as well. > >>>> > Additionally, if you listen to the audio recordings > >> then you will > >>>> notice > >>>> > that Henning, Ted, and Jon do not seem to understand > >> the issue > >>>> either as > >>>> > they have raised similar issues during the F2F meetings. > >>>> > > >>>> > Ciao > >>>> > Hannes > >>>> > > >>>> > > >>>> > >Hannes - I believe it is you who do not understand > >> RFC 4412 -- > >>>> > >and many of us are trying to get that through to you, but you > >>>> > >don't seem to want to listen/read. > >>>> > > > >>>> > >RFC 4412 is *for* priority marking SIP requests, > >>>> > > > >>>> > >One use is GETS. > >>>> > > > >>>> > >One use is MLPP. > >>>> > > > >>>> > >These examples are in RFC 4412 because there were specific > >>>> > >namespaces being created for the IANA section of > >> that document. > >>>> > > > >>>> > >Reading the whole document, you will see that RPH can be > >>>> > >specified for other uses than GETS or MLPP specifically. > >>>> > > > >>>> > >I knew when I wrote RFC 4412 that one day we would specify a > >>>> > >namespace for ECRIT (the "esnet" namespace now) -- but I also > >>>> > >knew it was premature for RFC 4412 to incorporate that > >>>> > >namespace, that a future doc to RFC 4412 would have to be > >>>> > >written to do this. Brian and I talked about this at the > >>>> > >original NENA meeting that created the IP WGs there > >> (in August > >>>> > >of 03). We both agreed we should wait until it was > >>>> > >appropriate to the work in the IETF to submit this document > >>>> > >that is now > >>>> > > >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >>>> > >gency-rph-namespace-00.txt > >>>> > > > >>>> > >Yet, you seem to want to use some additional mechanism to > >>>> > >indicate priority of a call in SIP. That means you want to > >>>> > >introduce a second way to accomplish this in SIP. > >>>> Why do you > >>>> > >want to promote a separate way to do something SIP > >> has already > >>>> > >defined? That will cause interoperability issues and > >> we both know > >>>> that. > >>>> > > > >>>> > >You've said to me (and others) that you believe RPH is just > >>>> > >another way to accomplish what sos or a URI can > >> indicate - and > >>>> > >you're wrong. Your way would be _the_second_way_to_do_it, > >>>> > >because SIP already considers RPH to be *the*way* to priority > >>>> > >mark SIP requests. > >>>> > > > >>>> > >If you don't believe me (no comment), then why do you not > >>>> > >believe the SIP WG chair (who knows more about SIP than both > >>>> > >of us) - who, on this thread, has again said to you "RFC 4412 > >>>> > >(RPH) is the SIP mechanism to priority mark SIP requests"? > >>>> > > > >>>> > >Further, I believe it is inappropriate to prohibit endpoints > >>>> > >from being able to set the esnet namespace. I absolutely > >>>> > >believe it will not be needed most of the time, but I believe > >>>> > >if someone does find a valid use for endpoints to mark > >>>> > >priority in SIP, this ID - once it has become an RFC -- will > >>>> > >have to be obsoleted with a new RFC saying the exact > >> opposite. > >>>> > > > >>>> > >(color me confused ... over and over again) > >>>> > > > >>>> > >James > >>>> > > > >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>>> > >>Keith, please understand that the usage of RFC 4412 > >> for GETS and > >>>> for > >>>> > >>the type of emergency call we discuss here is > >> different. Just > >>>> looking > >>>> > >>at the header and the name of the namespace is a bit > >>>> > >artificial. I hope > >>>> > >>you understand that. > >>>> > >> > >>>> > >> >-----Original Message----- > >>>> > >> >From: DRAGE, Keith (Keith) > >>>> [mailto:drage@alcatel-lucent.com] > >>>> > >> >Sent: 05 February, 2009 14:55 > >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >>>> Polk'; 'Tschofenig, > >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: Agenda (my > >>>> > >>>> > >> >mistake) > >>>> > >> > > >>>> > >> >Which is exactly what RFC 4412 specifies for all > >> namespaces. > >>>> > >> > > >>>> > >> >regards > >>>> > >> > > >>>> > >> >Keith > >>>> > >> > > >>>> > >> >> -----Original Message----- > >>>> > >> >> From: ecrit-bounces@ietf.org > >> [mailto:ecrit-bounces@ietf.org] > >>>> > >> >On Behalf > >>>> > >> >> Of Brian Rosen > >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >>>> > >Hannes (NSN > >>>> > >> >> - FI/Espoo)'; 'ECRIT' > >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: Agenda (my > >>>> > >> >> mistake) > >>>> > >> >> > >>>> > >> >> The value is that in some networks where priority for > >>>> > >> >emergency calls > >>>> > >> >> is appropriate, and appropriate policing of marking is > >>>> > >implemented, > >>>> > >> >> emergency calls will receive resource priority. > >>>> > >> >> > >>>> > >> >> Not all networks would need policing. Some > >> will. Policing > >>>> could > >>>> > >> >> be to Route header/R-URI content, but other > >> criteria are > >>>> possible. > >>>> > >> >> > >>>> > >> >> Not all networks will need resource priority > >> for emergency > >>>> calls. > >>>> > >> >> Fine, ignore this marking/namespace. > >>>> > >> >> > >>>> > >> >> Brian > >>>> > >> >> > -----Original Message----- > >>>> > >> >> > From: Hannes Tschofenig > >>>> [mailto:Hannes.Tschofenig@gmx.net] > >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >> Tschofenig, Hannes > >>>> (NSN - > >>>> > >> >> > FI/Espoo); 'ECRIT' > >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: Agenda (my > >>>> > >> >> > mistake) > >>>> > >> >> > > >>>> > >> >> > I don't even see the value in permitting the > >> endpoint todo > >>>> the > >>>> > >> >> > RPH marking. > >>>> > >> >> > In addition to the security concerns there is also the > >>>> > >> >problem that > >>>> > >> >> > there are more options to implement without > >> an additional > >>>> value. > >>>> > >> >> > > >>>> > >> >> > >-----Original Message----- > >>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >>>> > >> >> > >Sent: 05 February, 2009 00:03 > >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >> 'Tschofenig, > >>>> > >> >> Hannes (NSN - > >>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: > >>>> Agenda (my > >>>> > >> >> > mistake) > >>>> > >> >> > > > >>>> > >> >> > >Hannes > >>>> > >> >> > > > >>>> > >> >> > >This matches my understanding precisely. We wish to > >>>> > >> >> permit endpoints > >>>> > >> >> > >to mark. We do not require it, and don't necessarily > >>>> expect it > >>>> > >> >> > >in many (even > >>>> > >> >> > >most) cases. We don't wish to see the > >> document prohibit > >>>> it. > >>>> > >> >> > >We all seem to agree it has value within the > >> Emergency > >>>> > >> >Services IP > >>>> > >> >> > >Networks. > >>>> > >> >> > > > >>>> > >> >> > >Brian > >>>> > >> >> > > > >>>> > >> >> > >> -----Original Message----- > >>>> > >> >> > >> From: ecrit-bounces@ietf.org > >>>> [mailto:ecrit-bounces@ietf.org] > >>>> > >> >> > >On Behalf > >>>> > >> >> > >> Of James M. Polk > >>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >>>> > >> >> FI/Espoo); 'ECRIT' > >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>> Meeting: > >>>> > >Agenda (my > >>>> > >> >> > >> mistake) > >>>> > >> >> > >> > >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >>>> > >> >> > >> > > James wrote: > >>>> > >> >> > >> > >> you are the _lone_ voice not > >> supporting this ID, > >>>> > >> >> > >> > > >>>> > >> >> > >> >Listening to the audio recording of past > >> meetings I > >>>> have to > >>>> > >> >> > >say that > >>>> > >> >> > >> >I > >>>> > >> >> > >> was > >>>> > >> >> > >> >not the only persons raising concerns about the > >>>> document. > >>>> > >> >> > >> >That was probably the reason why you > >> agreed to limit > >>>> the > >>>> > >> >> > >scope of the > >>>> > >> >> > >> >document (which you didn't later do) to > >> get folks to > >>>> agree > >>>> > >> >> > >to make it > >>>> > >> >> > >> a WG > >>>> > >> >> > >> >item. > >>>> > >> >> > >> > >>>> > >> >> > >> re-listen to the audio please > >>>> > >> >> > >> > >>>> > >> >> > >> Ted's concerns were consistent with most > >>>> (all?) other > >>>> > >> >> concerns -- > >>>> > >> >> > >> which were based on the premise of whether > >> or not the > >>>> > >> >> UAC should be > >>>> > >> >> > >> trusted to initiate the marking on the > >> INVITE. The > >>>> most > >>>> > >> >> > >> recent version has backed off this to a "can" -- > >>>> meaning not > >>>> > >> >prohibited > >>>> > >> >> > >> (i.e., no 2119 text). I also backed off > >> the text in > >>>> the > >>>> > >> >> SP domain > >>>> > >> >> > >> part to "can", such that there is no 2119 text > >>>> > >> >mandating or even > >>>> > >> >> > >> recommending its usage there. I also do > >> not prohibit > >>>> its > >>>> > >> >> > >use, based on > >>>> > >> >> > >> local policy. Keith has come forward with > >> the specific > >>>> > >>>> > >> >> > >> request that non-ESInet networks be > >> allowed to mark and > >>>> pay > >>>> > >> >attention to > >>>> > >> >> > >> this priority indication -- with IMS as > >> the specific > >>>> example > >>>> > >> >> > >> he wishes to have this valid for. > >>>> > >> >> > >> > >>>> > >> >> > >> Where there is no disagreement, save for > >> your recent > >>>> > >> >> > >pushback - is in > >>>> > >> >> > >> the ESInet, which is where Brian has requested it's > >>>> > >> >> > >definition in the > >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >> chair within > >>>> > >> >> NENA, and if > >>>> > >> >> > >> he asks for it, are you going to say you > >> know better > >>>> than he? > >>>> > >> >> > >> > >>>> > >> >> > >> > >>>> > >> >> > >> >Btw, I not disagreeing with the document > >> as such. I > >>>> > >> >just want to > >>>> > >> >> > the > >>>> > >> >> > >> scope > >>>> > >> >> > >> >to change. The usage of RPH within the emergency > >>>> > >> >> services network > >>>> > >> >> > is > >>>> > >> >> > >> fine > >>>> > >> >> > >> >for me. I may get convinced to start the > >> RPH marking > >>>> from > >>>> > >> >> > >the the VSP > >>>> > >> >> > >> >towards the PSAP. I feel uneasy about the > >> end host > >>>> doing > >>>> > >> >> > >the marking. > >>>> > >> >> > >> > >>>> > >> >> > >> please read what I wrote above, and then > >> re-read the > >>>> > >> >most recent > >>>> > >> >> > >> version of the ID. I don't have endpoints > >> that SHOULD > >>>> or > >>>> > >> >> MUST mark > >>>> > >> >> > >> anything wrt RPH. I also don't want to > >> prohibit it, > >>>> > >> >> because there > >>>> > >> >> > >> might be cases (that I don't know of) of valid uses > >>>> > >> >> under certain > >>>> > >> >> > >> circumstances. Figure 1 is very clear > >> that there are 3 > >>>> > >> >> networking > >>>> > >> >> > >> parts to consider > >>>> > >> >> > >> > >>>> > >> >> > >> #1 - from the endpoint > >>>> > >> >> > >> #2 - within the VSP > >>>> > >> >> > >> #3 - within the ESInet > >>>> > >> >> > >> > >>>> > >> >> > >> the most recent ID version has "can" for > >> #s 1 and 2, > >>>> and > >>>> > >> >> > >2119 language > >>>> > >> >> > >> offering those supporting this > >> specification will have > >>>> RPH > >>>> > >> >> > >> adherence within #3 (the ESInet). > >>>> > >> >> > >> > >>>> > >> >> > >> What other scope changes do you want, > >> because I haven't > >>>> > >> >> heard them. > >>>> > >> >> > >> > >>>> > >> >> > >> I only heard you claim in email during the > >> last IETF > >>>> and in > >>>> > >> >> > >the ECRIT > >>>> > >> >> > >> session that RPH should not be used for priority > >>>> marking > >>>> > >> >> requests. > >>>> > >> >> > >> This is something Keith (SIP WG chair) voiced his > >>>> opposition > >>>> > >> >> > >> to your views regarding creating a second > >> means for SIP > >>>> to > >>>> > >> >priority > >>>> > >> >> > >> mark request "when SIP already has one > >> interoperable > >>>> way to > >>>> > >> >> > >> accomplish this... it's call the RP header > >> mechanism". > >>>> > >> >> > >> > >>>> > >> >> > >> >I don't see advantages -- only disadvantages. > >>>> > >> >> > >> > > >>>> > >> >> > >> >Ciao > >>>> > >> >> > >> >Hannes > >>>> > >> >> > >> > >>>> > >> >> > >> _______________________________________________ > >>>> > >> >> > >> Ecrit mailing list > >>>> > >> >> > >> Ecrit@ietf.org > >>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> >> > > > >>>> > >> >> > >>>> > >> >> _______________________________________________ > >>>> > >> >> Ecrit mailing list > >>>> > >> >> Ecrit@ietf.org > >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> >> > >>>> > >> > > >>>> > > > >>>> > > >>>> > _______________________________________________ > >>>> > Ecrit mailing list > >>>> > Ecrit@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183333A6BB5 for ; Fri, 6 Feb 2009 10:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE3dgLKgBcxG for ; Fri, 6 Feb 2009 10:32:38 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EFCAB3A69C0 for ; Fri, 6 Feb 2009 10:32:37 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 18:32:38 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp052) with SMTP; 06 Feb 2009 19:32:38 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181n4QKXas1czwaLgTRJDO9Gkx56Sq9ppUAOLz+uV 9os9mbjs9GOWCT From: "Hannes Tschofenig" To: "'Brian Rosen'" , "'Henning Schulzrinne'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> Date: Fri, 6 Feb 2009 20:33:25 +0200 Message-ID: <003d01c98889$666c23f0$49b5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0d9101c98872$7b2129b0$71637d10$@net> Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 18:32:41 -0000 To the story short here is the code for the proxy: --------------------- IF emergency call was recognized THEN execute emergency call specific procedures (priority queuing, preemption, fetch location, determine routing, do funny QoS things & co) ELSE normal call handling procedures. --------------------- If you can make this differentiation between an emergency call and a regular call then you can also do everything that is necessary for emergency call handling. Brian + Keith: Please tell me that we cannot do the above with our currently specified mechanisms. Ciao Hannes >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: 06 February, 2009 17:49 >To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >Subject: RE: [Ecrit] RPH > >I agree that not all networks will permit (or pay attention >to) a priority request from an end device. > >No one has asked for that. > >The namespace request has several uses, one of which is within >an emergency services IP network, one of which is between >elements within a public network controlled by the operator, >and one of which is an endpoint request for resource priority. > >Those of us requesting this work proceed are happy if the >endpoint part is simply left as possible (MAY), and, speaking >for myself, having the draft discuss the security implications >of endpoint marking is reasonable. > >Having discussed this issue with an implementation team who >worked on MLPP systems, I am confident I know what I'm talking >about, but YMMV. The fact that you could, if you wanted to, >give resource priority to a call you decided, however you >decided, was an emergency call is an implementation decision, >and not subject to standardization. > >RPH is the IETF standard way for one entity to request >resource priority of another entity in a SIP system. We're >asking for a namespace to use that within the domain of >emergency calls. That is, I think, a VERY reasonable request. > >Brian > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Friday, February 06, 2009 10:33 AM >> To: Hannes Tschofenig >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> Subject: Re: [Ecrit] RPH >> >> To chime in here: >> >> I don't think it's productive to simply state that 4412 >doesn't worry >> about authorization, so we shouldn't either (simplifying a bit). >> Authorization was discussed repeatedly, and the general >assumption was >> that there were two conditions: Either the user invoking resource- >> priority was well known and had a set of permissions that could be >> checked in real time or there are ways to deal with abuse after the >> fact in ways that deter abuse (the court-martial kind of thing in a >> military context). >> >> The RFC 4412 security consideration (11.2) call this out in pretty >> strong language: >> >> Prioritized access to network and end-system resources imposes >> particularly stringent requirements on authentication and >> authorization mechanisms, since access to prioritized >resources may >> impact overall system stability and performance and not >just result >> in theft of, say, a single phone call. >> Thus, the question is whether we have such strong authentication in >> emergency calling. In some cases, such as residential fixed line >> deployments where ISP = VSP, we're probably pretty close, in others, >> such as prepaid cell phones or hot spots or VSP-only providers, we >> aren't. >> >> The other point that I think Hannes is making is that the >information >> is either redundant or dangerous. If a processing element recognizes >> the call as being an emergency call, it can apply whatever treatment >> it deems appropriate and doesn't need additional information. If it >> doesn't or can't, using just the RPH can be rather dangerous unless >> that element can be reasonably certain that there is strong >> authentication and recourse. >> >> I don't buy the argument that somehow finding the RPH is faster than >> just looking for the identifier. Thus, given that the information is >> either redundant or dangerous, I fail to see the advantage. >> >> Henning >> >> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >> >> > Don't get hung up on the details. There are ways to optimize it. >> > That was >> > not the point of the code example. >> > >> > The problem that my pseudo code should have shown you is that you >> > * don't gain anything with RPH marking for the emergency call case >> > from the SIP UA towards the outbound proxy since the functionality >> > is already provide otherwise. How often does the proxy need to get >> > told that this is an emergency call todo whatever emergency call >> > handling procedures are necessary? >> > * you only introduce fraud problems (if you are not >careful and you >> > understand the security stuff well enough) >> > >> > If you can point me to people who implement the RPH emergency call >> > case please do so. I would love to talk to them. >> > >> > Ciao >> > Hannes >> > >> > PS: You need to parse incoming messages to some extend so that you >> > know what it contains :-) Only looking for the emergency >RPH header >> > (and not for the Service URN/dial >> > string) would exactly be the DoS/fraud attack I am worried about. >> > That's the thing Henning was worried about (go and listen to the >> > past meeting minutes). >> > >> > >> >> Hannes >> >> >> >> You need to talk to people who really implement this kind >of thing. >> >> You are way off. >> >> >> >> When you implement a resource priority system, the point of doing >> >> that is to look though the queue of work and pick out the >ones with >> >> priority, handling them first. You don't do all the parsing, you >> >> don't do a lot of decision tree. >> >> >> >> Typically: >> >> Check for DoS things, like too big messages, etc Do a quick scan >> >> for the RPH message header If found: >> >> Parse the message >> >> Determine validity >> >> Determine priority >> >> Queue on the correct work queue >> >> >> >> The first two actions have to be very fast. Anyone who builds a >> >> SIP thingie will tell you that parsing is one of the big cycle >> >> consumers: if you have to parse every message BEFORE you >determine >> >> priority, you can't give much resource priority. >> >> Once you get the whole message parsed, you might as well finish >> >> working on it, because you've done so much of the work. >> >> OTHOH, finding the end-of-message delimiter and doing a quick >> >> string search for RPH is fast. If you are doing >priority, you need >> >> to keep all the priority processing pretty uniform, and pretty >> >> simple, or you tend to spend too much time futzing around >figuring >> >> out what to do. You put all the priority related stuff together, >> >> and use as much common code as possible. >> >> >> >> Brian >> >> >> >>> -----Original Message----- >> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >> On Behalf >> >>> Of Hannes Tschofenig >> >>> Sent: Friday, February 06, 2009 8:41 AM >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >> >>> bounces@ietf.org >> >>> Subject: [Ecrit] RPH >> >>> >> >>> Over lunch I was also thinking how an outbound proxy would >> implement >> >>> some of the emergency procedures. Here are some thoughts: >> >>> >> >>> --------------------------------------------------- >> >>> >> >>> // Process incoming message >> >>> Parse(msg); >> >>> >> >>> // SIP INVITE without Service URN >> >>> // legacy devices >> >>> If (recognize-dialstring(msg)==TRUE) { // we got an emergency >> >>> call going on emergency=TRUE; if (dialstring(msg) == 911) >> >>> serviceURN=urn:service:sos; } else if >> >>> (recognize-serviceURN(msg)==TRUE) { // oh. A updated >device that >> >>> has a service URN attached to the >> call >> >>> serviceURN=retrieve_ServiceURN(msg); >> >>> emergency=TRUE; >> >>> } else { >> >>> // standard SIP message >> >>> // regular processing >> >>> process(msg); >> >>> emergency=FALSE; >> >>> } >> >>> >> >>> If (emergency == TRUE) { >> >>> // make sure that the emergency call does not get >dropped on the >> >>> floor >> >>> // skip authorization failures >> >>> // give the call a special treatment >> >>> lots-of-code-here(); >> >>> >> >>> // trigger all the QoS signaling you have in the >network to make >> >>> James happy >> >>> trigger-qos(); >> >>> >> >>> // query location >> >>> location=retrieve-location(); >> >>> >> >>> // determine next hop >> >>> next-hop=lost(location, serviceURN) >> >>> >> >>> // attach RPH marking to outgoing msg to make James and >> >> Keith happy >> >>> msg=add(msg, RPH); >> >>> >> >>> send(msg, next-hop); >> >>> } >> >>> >> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >> >>> // all the emergency related processing done already upfront >> >>> // hence I log something. >> >>> log(RPH_WAS_PRESENT_JUHU); >> >>> } else if ((rph-present(msg) == TRUE) && (emergency == >FALSE)) { >> >>> // this is not an emergency call // this is something >like GETS >> >>> result=special-authorization-procedure(user); >> >>> >> >>> if (result == AUTHORIZED) { >> >>> // do some priority & preemption thing here. >> >>> // trigger all the QoS you have >> >>> lots-of-code-here(); >> >>> } else { >> >>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // >> >>> don't need todo any RPH processing // this includes the case >> >>> where the call was an emergency call but the RPH >> >>> >> >>> // marking was not there. >> >>> nothing(); >> >>> } >> >>> >> >>> --------------------------------------------------- >> >>> >> >>> >> >>> Ciao >> >>> Hannes >> >>> >> >>>> -----Original Message----- >> >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >>>> Behalf Of Hannes Tschofenig >> >>>> Sent: 06 February, 2009 15:07 >> >>>> To: 'Janet P Gunn' >> >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >> >>> FI/Espoo) >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >> >>>> >> >>>> Who would define something that could prevent DoS problems? >> >>>> >> >>>> ________________________________ >> >>>> >> >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >> >>>> Sent: 06 February, 2009 14:11 >> >>>> To: Hannes Tschofenig >> >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >> >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >> 'James >> >>>> M. Polk' >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >Meeting: Agenda (RPH) >> >>>> >> >>>> >> >>>> >> >>>> But there is nothing IN RFC4412 that specifically >> >> addresses how to >> >>>> prevent any particular namespace being used for DoS. Anyone/any >> UA >> >>>> can ATTEMPT to invoke priority treatment by attaching RPH. For >> all >> >>>> of the 4412 namespaces, as with the new proposed namespace, the >> >>>> mechanisms for preventing DoS are not specified in the >> >> document that >> >>>> defines the namespace. >> >>>> They are/will be specified elsewhere. >> >>>> >> >>>> Janet >> >>>> >> >>>> This is a PRIVATE message. If you are not the intended >> >> recipient, >> >>>> please delete without copying and kindly advise us by e-mail of >> the >> >>>> mistake in delivery. >> >>>> NOTE: Regardless of content, this e-mail shall not >> >> operate to bind >> >>>> CSC to any order or other contract unless pursuant to explicit >> >>>> written agreement or government initiative expressly permitting >> the >> >>>> use of e-mail for such purpose. >> >>>> >> >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: >> >>>> >> >>>> > Hi James, >> >>>> > >> >>>> > I have read RFC 4412 and also the GETS/MLPP IETF >> >> documents. What I >> >>>> would >> >>>> > like to point out is that there is more than just a >> >> header and >> >>>> values within >> >>>> > the header that have to be considered in order to >> >> make a judgement >> >>>> of what >> >>>> > is appropriate and what isn't. There is an >> >> architectural question >> >>>> and >> >>>> > whether the environment we are using the stuff is >> >> indeed providing >> >>>> the >> >>>> > properties you need for the solution to be >appropriate. >> >>>> > >> >>>> > Let me describe in more detail what I meant (and >> >> please correct me >> >>>> if I am >> >>>> > wrong). >> >>>> > >> >>>> > Getting priority for SIP requests when using a GETS >> >> alike scenario >> >>>> means >> >>>> > that the entity that issues the request is specially >> >> authorized >> >>>> since >> >>>> > otherwise you introduce a nice denial of >service attack. This >> >>>> authorization >> >>>> > is tied to the entity that makes the request. For >> >> example, the >> >>>> person is >> >>>> > working for the government and has special rights. >> >>>> James Bond as a (not so) >> >>>> > secret agent might have these rights. >> >>>> > >> >>>> > The emergency services case >(citizen-to-authority) is a bit >> >>>> different as >> >>>> > there aren't really special rights with respect to >> >> authorization >> >>>> tied to >> >>>> > individuals. Instead, the fact that something is an >> >> emergency is >> >>>> purely a >> >>>> > judgement of the human that dials a special number. >> >>>> To deal with fraud, we >> >>>> > discussed in the group on what we can actually do to >> >> ensure that >> >>>> end users >> >>>> > do not bypass security procedures (such as >> >> authorization checks, >> >>>> charging >> >>>> > and so on). Part of this investigation was >the publication of >> >>>> > http://www.ietf.org/rfc/rfc5069.txt that also >describes this >> >>>> issue. >> >>>> > >> >>>> > So, imagine the implementation of a SIP proxy (and we >> >> implemented >> >>>> that >> >>>> > stuff) that receives a call that contains a Service >> >> URN. The code >> >>>> branches >> >>>> > into a special mode where everything is done >so that the call >> >>>> receives >> >>>> > appropriate treatment and does not get dropped on the >> >> floor. The >> >>>> way how the >> >>>> > Service URN is placed in the message ensures that the >> >> call cannot >> >>>> go to my >> >>>> > friend (instead of the PSAP) unless the end host ran >> >> LoST already. >> >>>> In the >> >>>> > latter case, we discussed this also on the list for a >> >> while and >> >>>> Richard even >> >>>> > wrote a draft about it in the context of the >location hiding >> >>>> topic, we said >> >>>> > that the proxy would have to run LoST if he >cares about a >> >>>> potential >> >>>> > fraudulent usage. >> >>>> > >> >>>> > So, what do we need todo in order to provide >secure RFC 4412 >> >>>> functionality >> >>>> > in our context? >> >>>> > >> >>>> > Do you think that the current text in >> >>>> > >> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >>>> gency-rph-nam >> >>>> > espace-00.txt reflects any of the >above-described issues: >> >>>> > " >> >>>> > The Security considerations that apply to RFC 4412 >> >>>> [RFC4412] >> >>>> apply >> >>>> > here. This document introduces no new security >> >>>> issues relative >> >>>> to >> >>>> > RFC 4412. >> >>>> > " >> >>>> > >> >>>> > From various discussions in GEOPRIV I recall >that you are >> >>>> super-sensitive >> >>>> > regarding security and privacy. For some reasons you >> >> don't seem to >> >>>> have the >> >>>> > same concerns here. I would like to >understand your reasoning. >> >>>> > >> >>>> > Please also do me another favor: Don't always say >> >> that I don't >> >>>> understand >> >>>> > the subject. Even if that would be the case it isn't >> >> particular >> >>>> fair given >> >>>> > that different folks had to educate you on other >> >> topics in the >> >>>> past as well. >> >>>> > Additionally, if you listen to the audio recordings >> >> then you will >> >>>> notice >> >>>> > that Henning, Ted, and Jon do not seem to understand >> >> the issue >> >>>> either as >> >>>> > they have raised similar issues during the >F2F meetings. >> >>>> > >> >>>> > Ciao >> >>>> > Hannes >> >>>> > >> >>>> > >> >>>> > >Hannes - I believe it is you who do not understand >> >> RFC 4412 -- >> >>>> > >and many of us are trying to get that >through to you, but you >> >>>> > >don't seem to want to listen/read. >> >>>> > > >> >>>> > >RFC 4412 is *for* priority marking SIP requests, >> >>>> > > >> >>>> > >One use is GETS. >> >>>> > > >> >>>> > >One use is MLPP. >> >>>> > > >> >>>> > >These examples are in RFC 4412 because there >were specific >> >>>> > >namespaces being created for the IANA section of >> >> that document. >> >>>> > > >> >>>> > >Reading the whole document, you will see >that RPH can be >> >>>> > >specified for other uses than GETS or MLPP >specifically. >> >>>> > > >> >>>> > >I knew when I wrote RFC 4412 that one day we >would specify a >> >>>> > >namespace for ECRIT (the "esnet" namespace >now) -- but I also >> >>>> > >knew it was premature for RFC 4412 to >incorporate that >> >>>> > >namespace, that a future doc to RFC 4412 >would have to be >> >>>> > >written to do this. Brian and I talked about >this at the >> >>>> > >original NENA meeting that created the IP WGs there >> >> (in August >> >>>> > >of 03). We both agreed we should wait until it was >> >>>> > >appropriate to the work in the IETF to >submit this document >> >>>> > >that is now >> >>>> > >> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >>>> > >gency-rph-namespace-00.txt >> >>>> > > >> >>>> > >Yet, you seem to want to use some additional >mechanism to >> >>>> > >indicate priority of a call in SIP. That >means you want to >> >>>> > >introduce a second way to accomplish this in SIP. >> >>>> Why do you >> >>>> > >want to promote a separate way to do something SIP >> >> has already >> >>>> > >defined? That will cause interoperability issues and >> >> we both know >> >>>> that. >> >>>> > > >> >>>> > >You've said to me (and others) that you >believe RPH is just >> >>>> > >another way to accomplish what sos or a URI can >> >> indicate - and >> >>>> > >you're wrong. Your way would be >_the_second_way_to_do_it, >> >>>> > >because SIP already considers RPH to be >*the*way* to priority >> >>>> > >mark SIP requests. >> >>>> > > >> >>>> > >If you don't believe me (no comment), then >why do you not >> >>>> > >believe the SIP WG chair (who knows more >about SIP than both >> >>>> > >of us) - who, on this thread, has again said >to you "RFC 4412 >> >>>> > >(RPH) is the SIP mechanism to priority mark >SIP requests"? >> >>>> > > >> >>>> > >Further, I believe it is inappropriate to >prohibit endpoints >> >>>> > >from being able to set the esnet namespace. >I absolutely >> >>>> > >believe it will not be needed most of the >time, but I believe >> >>>> > >if someone does find a valid use for >endpoints to mark >> >>>> > >priority in SIP, this ID - once it has >become an RFC -- will >> >>>> > >have to be obsoleted with a new RFC saying the exact >> >> opposite. >> >>>> > > >> >>>> > >(color me confused ... over and over again) >> >>>> > > >> >>>> > >James >> >>>> > > >> >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >> >>>> > >>Keith, please understand that the usage of RFC 4412 >> >> for GETS and >> >>>> for >> >>>> > >>the type of emergency call we discuss here is >> >> different. Just >> >>>> looking >> >>>> > >>at the header and the name of the namespace is a bit >> >>>> > >artificial. I hope >> >>>> > >>you understand that. >> >>>> > >> >> >>>> > >> >-----Original Message----- >> >>>> > >> >From: DRAGE, Keith (Keith) >> >>>> [mailto:drage@alcatel-lucent.com] >> >>>> > >> >Sent: 05 February, 2009 14:55 >> >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >> >>>> Polk'; 'Tschofenig, >> >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >> >>>> Meeting: Agenda (my >> >>>> >> >>>> > >> >mistake) >> >>>> > >> > >> >>>> > >> >Which is exactly what RFC 4412 specifies for all >> >> namespaces. >> >>>> > >> > >> >>>> > >> >regards >> >>>> > >> > >> >>>> > >> >Keith >> >>>> > >> > >> >>>> > >> >> -----Original Message----- >> >>>> > >> >> From: ecrit-bounces@ietf.org >> >> [mailto:ecrit-bounces@ietf.org] >> >>>> > >> >On Behalf >> >>>> > >> >> Of Brian Rosen >> >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >Polk'; 'Tschofenig, >> >>>> > >Hannes (NSN >> >>>> > >> >> - FI/Espoo)'; 'ECRIT' >> >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >>>> Meeting: Agenda (my >> >>>> > >> >> mistake) >> >>>> > >> >> >> >>>> > >> >> The value is that in some networks >where priority for >> >>>> > >> >emergency calls >> >>>> > >> >> is appropriate, and appropriate >policing of marking is >> >>>> > >implemented, >> >>>> > >> >> emergency calls will receive resource priority. >> >>>> > >> >> >> >>>> > >> >> Not all networks would need policing. Some >> >> will. Policing >> >>>> could >> >>>> > >> >> be to Route header/R-URI content, but other >> >> criteria are >> >>>> possible. >> >>>> > >> >> >> >>>> > >> >> Not all networks will need resource priority >> >> for emergency >> >>>> calls. >> >>>> > >> >> Fine, ignore this marking/namespace. >> >>>> > >> >> >> >>>> > >> >> Brian >> >>>> > >> >> > -----Original Message----- >> >>>> > >> >> > From: Hannes Tschofenig >> >>>> [mailto:Hannes.Tschofenig@gmx.net] >> >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >> >> Tschofenig, Hannes >> >>>> (NSN - >> >>>> > >> >> > FI/Espoo); 'ECRIT' >> >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >> >>>> Meeting: Agenda (my >> >>>> > >> >> > mistake) >> >>>> > >> >> > >> >>>> > >> >> > I don't even see the value in permitting the >> >> endpoint todo >> >>>> the >> >>>> > >> >> > RPH marking. >> >>>> > >> >> > In addition to the security concerns >there is also the >> >>>> > >> >problem that >> >>>> > >> >> > there are more options to implement without >> >> an additional >> >>>> value. >> >>>> > >> >> > >> >>>> > >> >> > >-----Original Message----- >> >>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> >>>> > >> >> > >Sent: 05 February, 2009 00:03 >> >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >> >> 'Tschofenig, >> >>>> > >> >> Hannes (NSN - >> >>>> > >> >> > >FI/Espoo)'; 'ECRIT' >> >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >Interim Meeting: >> >>>> Agenda (my >> >>>> > >> >> > mistake) >> >>>> > >> >> > > >> >>>> > >> >> > >Hannes >> >>>> > >> >> > > >> >>>> > >> >> > >This matches my understanding >precisely. We wish to >> >>>> > >> >> permit endpoints >> >>>> > >> >> > >to mark. We do not require it, and >don't necessarily >> >>>> expect it >> >>>> > >> >> > >in many (even >> >>>> > >> >> > >most) cases. We don't wish to see the >> >> document prohibit >> >>>> it. >> >>>> > >> >> > >We all seem to agree it has value within the >> >> Emergency >> >>>> > >> >Services IP >> >>>> > >> >> > >Networks. >> >>>> > >> >> > > >> >>>> > >> >> > >Brian >> >>>> > >> >> > > >> >>>> > >> >> > >> -----Original Message----- >> >>>> > >> >> > >> From: ecrit-bounces@ietf.org >> >>>> [mailto:ecrit-bounces@ietf.org] >> >>>> > >> >> > >On Behalf >> >>>> > >> >> > >> Of James M. Polk >> >>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >Hannes (NSN - >> >>>> > >> >> FI/Espoo); 'ECRIT' >> >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >>>> Meeting: >> >>>> > >Agenda (my >> >>>> > >> >> > >> mistake) >> >>>> > >> >> > >> >> >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >Tschofenig wrote: >> >>>> > >> >> > >> > > James wrote: >> >>>> > >> >> > >> > >> you are the _lone_ voice not >> >> supporting this ID, >> >>>> > >> >> > >> > >> >>>> > >> >> > >> >Listening to the audio recording of past >> >> meetings I >> >>>> have to >> >>>> > >> >> > >say that >> >>>> > >> >> > >> >I >> >>>> > >> >> > >> was >> >>>> > >> >> > >> >not the only persons raising >concerns about the >> >>>> document. >> >>>> > >> >> > >> >That was probably the reason why you >> >> agreed to limit >> >>>> the >> >>>> > >> >> > >scope of the >> >>>> > >> >> > >> >document (which you didn't later do) to >> >> get folks to >> >>>> agree >> >>>> > >> >> > >to make it >> >>>> > >> >> > >> a WG >> >>>> > >> >> > >> >item. >> >>>> > >> >> > >> >> >>>> > >> >> > >> re-listen to the audio please >> >>>> > >> >> > >> >> >>>> > >> >> > >> Ted's concerns were consistent with most >> >>>> (all?) other >> >>>> > >> >> concerns -- >> >>>> > >> >> > >> which were based on the premise of whether >> >> or not the >> >>>> > >> >> UAC should be >> >>>> > >> >> > >> trusted to initiate the marking on the >> >> INVITE. The >> >>>> most >> >>>> > >> >> > >> recent version has backed off this >to a "can" -- >> >>>> meaning not >> >>>> > >> >prohibited >> >>>> > >> >> > >> (i.e., no 2119 text). I also backed off >> >> the text in >> >>>> the >> >>>> > >> >> SP domain >> >>>> > >> >> > >> part to "can", such that there is >no 2119 text >> >>>> > >> >mandating or even >> >>>> > >> >> > >> recommending its usage there. I also do >> >> not prohibit >> >>>> its >> >>>> > >> >> > >use, based on >> >>>> > >> >> > >> local policy. Keith has come forward with >> >> the specific >> >>>> >> >>>> > >> >> > >> request that non-ESInet networks be >> >> allowed to mark and >> >>>> pay >> >>>> > >> >attention to >> >>>> > >> >> > >> this priority indication -- with IMS as >> >> the specific >> >>>> example >> >>>> > >> >> > >> he wishes to have this valid for. >> >>>> > >> >> > >> >> >>>> > >> >> > >> Where there is no disagreement, save for >> >> your recent >> >>>> > >> >> > >pushback - is in >> >>>> > >> >> > >> the ESInet, which is where Brian >has requested it's >> >>>> > >> >> > >definition in the >> >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >> >> chair within >> >>>> > >> >> NENA, and if >> >>>> > >> >> > >> he asks for it, are you going to say you >> >> know better >> >>>> than he? >> >>>> > >> >> > >> >> >>>> > >> >> > >> >> >>>> > >> >> > >> >Btw, I not disagreeing with the document >> >> as such. I >> >>>> > >> >just want to >> >>>> > >> >> > the >> >>>> > >> >> > >> scope >> >>>> > >> >> > >> >to change. The usage of RPH >within the emergency >> >>>> > >> >> services network >> >>>> > >> >> > is >> >>>> > >> >> > >> fine >> >>>> > >> >> > >> >for me. I may get convinced to start the >> >> RPH marking >> >>>> from >> >>>> > >> >> > >the the VSP >> >>>> > >> >> > >> >towards the PSAP. I feel uneasy about the >> >> end host >> >>>> doing >> >>>> > >> >> > >the marking. >> >>>> > >> >> > >> >> >>>> > >> >> > >> please read what I wrote above, and then >> >> re-read the >> >>>> > >> >most recent >> >>>> > >> >> > >> version of the ID. I don't have endpoints >> >> that SHOULD >> >>>> or >> >>>> > >> >> MUST mark >> >>>> > >> >> > >> anything wrt RPH. I also don't want to >> >> prohibit it, >> >>>> > >> >> because there >> >>>> > >> >> > >> might be cases (that I don't know >of) of valid uses >> >>>> > >> >> under certain >> >>>> > >> >> > >> circumstances. Figure 1 is very clear >> >> that there are 3 >> >>>> > >> >> networking >> >>>> > >> >> > >> parts to consider >> >>>> > >> >> > >> >> >>>> > >> >> > >> #1 - from the endpoint >> >>>> > >> >> > >> #2 - within the VSP >> >>>> > >> >> > >> #3 - within the ESInet >> >>>> > >> >> > >> >> >>>> > >> >> > >> the most recent ID version has "can" for >> >> #s 1 and 2, >> >>>> and >> >>>> > >> >> > >2119 language >> >>>> > >> >> > >> offering those supporting this >> >> specification will have >> >>>> RPH >> >>>> > >> >> > >> adherence within #3 (the ESInet). >> >>>> > >> >> > >> >> >>>> > >> >> > >> What other scope changes do you want, >> >> because I haven't >> >>>> > >> >> heard them. >> >>>> > >> >> > >> >> >>>> > >> >> > >> I only heard you claim in email during the >> >> last IETF >> >>>> and in >> >>>> > >> >> > >the ECRIT >> >>>> > >> >> > >> session that RPH should not be >used for priority >> >>>> marking >> >>>> > >> >> requests. >> >>>> > >> >> > >> This is something Keith (SIP WG >chair) voiced his >> >>>> opposition >> >>>> > >> >> > >> to your views regarding creating a second >> >> means for SIP >> >>>> to >> >>>> > >> >priority >> >>>> > >> >> > >> mark request "when SIP already has one >> >> interoperable >> >>>> way to >> >>>> > >> >> > >> accomplish this... it's call the RP header >> >> mechanism". >> >>>> > >> >> > >> >> >>>> > >> >> > >> >I don't see advantages -- only >disadvantages. >> >>>> > >> >> > >> > >> >>>> > >> >> > >> >Ciao >> >>>> > >> >> > >> >Hannes >> >>>> > >> >> > >> >> >>>> > >> >> > >> >_______________________________________________ >> >>>> > >> >> > >> Ecrit mailing list >> >>>> > >> >> > >> Ecrit@ietf.org >> >>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >> >>>> > >> >> > > >> >>>> > >> >> >> >>>> > >> >> _______________________________________________ >> >>>> > >> >> Ecrit mailing list >> >>>> > >> >> Ecrit@ietf.org >> >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >>>> > >> >> >> >>>> > >> > >> >>>> > > >> >>>> > >> >>>> > _______________________________________________ >> >>>> > Ecrit mailing list >> >>>> > Ecrit@ietf.org >> >>>> > https://www.ietf.org/mailman/listinfo/ecrit >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Ecrit mailing list >> >>>> Ecrit@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/ecrit >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A10C3A68F9 for ; Fri, 6 Feb 2009 12:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mankdJmhyBkg for ; Fri, 6 Feb 2009 12:03:40 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2B8A33A67D6 for ; Fri, 6 Feb 2009 12:01:58 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_06_14_21_10 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); Fri, 06 Feb 2009 14:21:10 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 14:01:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 14:01:37 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RPH Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/Jg== References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 06 Feb 2009 20:01:58.0812 (UTC) FILETIME=[C4AFA5C0:01C98895] Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 20:03:43 -0000 Hi All,=0D=0A=0D=0AI have followed thi thread with some interest and I stru= ggling to see a use case for the=0D=0Aproviding RPH for emergency calls fro= m the end-point.=0D=0A=0D=0AThe reference-model call in ECRIT, for better o= r worse, is for all calls to go back through a home-VSP.=0D=0AWe placed qui= te a lot of emphasis, largely for traffing reasons, for the VSP to be able = to verify that=20=0D=0Aa call is in fact an emergency call. This is done by= the proxy taking the inband location, doing a LoST=0D=0Aquery with the pro= vided URN, and verifying that the resulting destination URI is the same as = the destination=0D=0AURI provide in the SIP INVITE. My understanding was th= at VSPs would always do this check so they could=0D=0Atell if they could bi= ll for the call or not, and because the VSP can be use that the call is an = emergency call=0D=0Ait can apply any special priorities that may be applica= ble. This obviates the need for RPH from the end-point=0D=0Ato the network.=0D= =0A=0D=0AThis leaves us with the argument of "it doesn't hurt to it", which= is not a good reason to write a specification.=0D=0AIt was intimated on th= e geopriv mailing list last year that great pains had been taken to keep SI= P with in the=0D=0AMTU limits of UDP over Ethernet (http://www.ietf.org/mai= l-archive/web/geopriv/current/msg06120.html). Assuming=0D=0Athat this is th= e case, perhaps there is harm in including information that we know will be= ignored.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: ecrit-bounces@ietf.org on behalf of Hannes Tschofe= nig=0D=0ASent: Fri 2/6/2009 12:33 PM=0D=0ATo: 'Brian Rosen'; 'Henning Schul= zrinne'=0D=0ACc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'=0D=0ASubject:= Re: [Ecrit] RPH=0D=0A=20=0D=0ATo the story short here is the code for the = proxy:=20=0D=0A=0D=0A---------------------=0D=0A=0D=0AIF emergency call was= recognized THEN=0D=0A execute emergency call specific procedures (prior= ity queuing,=0D=0Apreemption, fetch location, determine routing, do funny Q= oS things & co)=0D=0AELSE=0D=0A normal call handling procedures.=20=0D=0A=0D= =0A---------------------=0D=0A=0D=0AIf you can make this differentiation be= tween an emergency call and a regular=0D=0Acall then you can also do everyt= hing that is necessary for emergency call=0D=0Ahandling.=20=0D=0A=0D=0ABria= n + Keith: Please tell me that we cannot do the above with our currently=0D= =0Aspecified mechanisms.=20=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0A>-----Or= iginal Message-----=0D=0A>From: Brian Rosen [mailto:br@brianrosen.net]=20=0D= =0A>Sent: 06 February, 2009 17:49=0D=0A>To: 'Henning Schulzrinne'; 'Hannes = Tschofenig'=0D=0A>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'=0D=0A>= Subject: RE: [Ecrit] RPH=0D=0A>=0D=0A>I agree that not all networks will pe= rmit (or pay attention=20=0D=0A>to) a priority request from an end device.=0D= =0A>=0D=0A>No one has asked for that.=0D=0A>=0D=0A>The namespace request ha= s several uses, one of which is within=20=0D=0A>an emergency services IP ne= twork, one of which is between=20=0D=0A>elements within a public network co= ntrolled by the operator,=20=0D=0A>and one of which is an endpoint request = for resource priority.=0D=0A>=0D=0A>Those of us requesting this work procee= d are happy if the=20=0D=0A>endpoint part is simply left as possible (MAY),= and, speaking=20=0D=0A>for myself, having the draft discuss the security i= mplications=20=0D=0A>of endpoint marking is reasonable.=0D=0A>=0D=0A>Having= discussed this issue with an implementation team who=20=0D=0A>worked on ML= PP systems, I am confident I know what I'm talking=20=0D=0A>about, but YMMV= =2E The fact that you could, if you wanted to,=20=0D=0A>give resource prio= rity to a call you decided, however you=20=0D=0A>decided, was an emergency = call is an implementation decision,=20=0D=0A>and not subject to standardiza= tion. =20=0D=0A>=0D=0A>RPH is the IETF standard way for one entity to reque= st=20=0D=0A>resource priority of another entity in a SIP system. We're=20=0D= =0A>asking for a namespace to use that within the domain of=20=0D=0A>emerge= ncy calls. That is, I think, a VERY reasonable request.=0D=0A>=0D=0A>Brian=0D= =0A>=0D=0A>> -----Original Message-----=0D=0A>> From: Henning Schulzrinne [= mailto:hgs@cs.columbia.edu]=0D=0A>> Sent: Friday, February 06, 2009 10:33 A= M=0D=0A>> To: Hannes Tschofenig=0D=0A>> Cc: Brian Rosen; Tschofenig, Hannes= (NSN - FI/Espoo); ECRIT=0D=0A>> Subject: Re: [Ecrit] RPH=0D=0A>>=20=0D=0A>= > To chime in here:=0D=0A>>=20=0D=0A>> I don't think it's productive to sim= ply state that 4412=20=0D=0A>doesn't worry=20=0D=0A>> about authorization, = so we shouldn't either (simplifying a bit).=0D=0A>> Authorization was discu= ssed repeatedly, and the general=20=0D=0A>assumption was=20=0D=0A>> that th= ere were two conditions: Either the user invoking resource-=20=0D=0A>> prio= rity was well known and had a set of permissions that could be=20=0D=0A>> c= hecked in real time or there are ways to deal with abuse after the=20=0D=0A= >> fact in ways that deter abuse (the court-martial kind of thing in a=20=0D= =0A>> military context).=0D=0A>>=20=0D=0A>> The RFC 4412 security considera= tion (11.2) call this out in pretty=20=0D=0A>> strong language:=0D=0A>>=20=0D= =0A>> Prioritized access to network and end-system resources imposes=0D=0A= >> particularly stringent requirements on authentication and=0D=0A>> = authorization mechanisms, since access to prioritized=20=0D=0A>resources = may=0D=0A>> impact overall system stability and performance and not=20=0D= =0A>just result=0D=0A>> in theft of, say, a single phone call.=0D=0A>> = Thus, the question is whether we have such strong authentication in=20=0D=0A= >> emergency calling. In some cases, such as residential fixed line=20=0D=0A= >> deployments where ISP =3D VSP, we're probably pretty close, in others, =0D= =0A>> such as prepaid cell phones or hot spots or VSP-only providers, we =0D= =0A>> aren't.=0D=0A>>=20=0D=0A>> The other point that I think Hannes is mak= ing is that the=20=0D=0A>information=20=0D=0A>> is either redundant or dang= erous. If a processing element recognizes=20=0D=0A>> the call as being an e= mergency call, it can apply whatever treatment=20=0D=0A>> it deems appropri= ate and doesn't need additional information. If it=20=0D=0A>> doesn't or ca= n't, using just the RPH can be rather dangerous unless=20=0D=0A>> that elem= ent can be reasonably certain that there is strong=20=0D=0A>> authenticatio= n and recourse.=0D=0A>>=20=0D=0A>> I don't buy the argument that somehow fi= nding the RPH is faster than=20=0D=0A>> just looking for the identifier. Th= us, given that the information is=20=0D=0A>> either redundant or dangerous,= I fail to see the advantage.=0D=0A>>=20=0D=0A>> Henning=0D=0A>>=20=0D=0A>>= =20=0D=0A>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote:=0D=0A>> =0D= =0A>> > Don't get hung up on the details. There are ways to optimize it.=0D= =0A>> > That was=0D=0A>> > not the point of the code example.=0D=0A>> >=0D=0A= >> > The problem that my pseudo code should have shown you is that you=0D=0A= >> > * don't gain anything with RPH marking for the emergency call case=20=0D= =0A>> > from the SIP UA towards the outbound proxy since the functionality =0D= =0A>> > is already provide otherwise. How often does the proxy need to get =0D= =0A>> > told that this is an emergency call todo whatever emergency call =0D= =0A>> > handling procedures are necessary=3F=0D=0A>> > * you only introduce= fraud problems (if you are not=20=0D=0A>careful and you=20=0D=0A>> > under= stand the security stuff well enough)=0D=0A>> >=0D=0A>> > If you can point = me to people who implement the RPH emergency call=20=0D=0A>> > case please = do so. I would love to talk to them.=0D=0A>> >=0D=0A>> > Ciao=0D=0A>> > Han= nes=0D=0A>> >=0D=0A>> > PS: You need to parse incoming messages to some ext= end so that you=20=0D=0A>> > know what it contains :-) Only looking for the= emergency=20=0D=0A>RPH header=20=0D=0A>> > (and not for the Service URN/di= al=0D=0A>> > string) would exactly be the DoS/fraud attack I am worried abo= ut.=0D=0A>> > That's the thing Henning was worried about (go and listen to = the=20=0D=0A>> > past meeting minutes).=0D=0A>> >=0D=0A>> >=0D=0A>> >> Hann= es=0D=0A>> >>=0D=0A>> >> You need to talk to people who really implement th= is kind=20=0D=0A>of thing. =20=0D=0A>> >> You are way off.=0D=0A>> >>=0D=0A= >> >> When you implement a resource priority system, the point of doing=20=0D= =0A>> >> that is to look though the queue of work and pick out the=20=0D=0A= >ones with=20=0D=0A>> >> priority, handling them first. You don't do all t= he parsing, you=20=0D=0A>> >> don't do a lot of decision tree.=0D=0A>> >>=0D= =0A>> >> Typically:=0D=0A>> >> Check for DoS things, like too big messages,= etc Do a quick scan=20=0D=0A>> >> for the RPH message header If found:=0D=0A= >> >> Parse the message=0D=0A>> >> Determine validity=0D=0A>> >> Determine = priority=0D=0A>> >> Queue on the correct work queue=0D=0A>> >>=0D=0A>> >> T= he first two actions have to be very fast. Anyone who builds a=20=0D=0A>> = >> SIP thingie will tell you that parsing is one of the big cycle=20=0D=0A>= > >> consumers: if you have to parse every message BEFORE you=20=0D=0A>dete= rmine=20=0D=0A>> >> priority, you can't give much resource priority.=0D=0A>= > >> Once you get the whole message parsed, you might as well finish=20=0D=0A= >> >> working on it, because you've done so much of the work.=0D=0A>> >> OT= HOH, finding the end-of-message delimiter and doing a quick=20=0D=0A>> >> s= tring search for RPH is fast. If you are doing=20=0D=0A>priority, you need= =20=0D=0A>> >> to keep all the priority processing pretty uniform, and pret= ty=20=0D=0A>> >> simple, or you tend to spend too much time futzing around =0D= =0A>figuring=20=0D=0A>> >> out what to do. You put all the priority relate= d stuff together,=20=0D=0A>> >> and use as much common code as possible.=0D= =0A>> >>=0D=0A>> >> Brian=0D=0A>> >>=0D=0A>> >>> -----Original Message-----=0D= =0A>> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=0D=0A= >> >> On Behalf=0D=0A>> >>> Of Hannes Tschofenig=0D=0A>> >>> Sent: Friday, = February 06, 2009 8:41 AM=0D=0A>> >>> To: 'Hannes Tschofenig'; 'Janet P Gun= n'=0D=0A>> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit-=20=0D= =0A>> >>> bounces@ietf.org=0D=0A>> >>> Subject: [Ecrit] RPH=0D=0A>> >>>=0D=0A= >> >>> Over lunch I was also thinking how an outbound proxy would=0D=0A>> i= mplement=0D=0A>> >>> some of the emergency procedures. Here are some though= ts:=0D=0A>> >>>=0D=0A>> >>> -----------------------------------------------= ----=0D=0A>> >>>=0D=0A>> >>> // Process incoming message=0D=0A>> >>> Parse(= msg);=0D=0A>> >>>=0D=0A>> >>> // SIP INVITE without Service URN=0D=0A>> >>>= // legacy devices=0D=0A>> >>> If (recognize-dialstring(msg)=3D=3DTRUE) { = // we got an emergency=20=0D=0A>> >>> call going on emergency=3DTRUE; if = (dialstring(msg) =3D=3D 911)=20=0D=0A>> >>> serviceURN=3Durn:service:sos; }= else if=0D=0A>> >>> (recognize-serviceURN(msg)=3D=3DTRUE) { // oh. A upda= ted=20=0D=0A>device that=20=0D=0A>> >>> has a service URN attached to the=0D= =0A>> call=0D=0A>> >>> serviceURN=3Dretrieve_ServiceURN(msg);=0D=0A>> >>> = emergency=3DTRUE;=0D=0A>> >>> } else {=0D=0A>> >>> // standard SIP messag= e=0D=0A>> >>> // regular processing=0D=0A>> >>> process(msg);=0D=0A>> >>>= emergency=3DFALSE;=0D=0A>> >>> }=0D=0A>> >>>=0D=0A>> >>> If (emergency =3D= =3D TRUE) {=0D=0A>> >>> // make sure that the emergency call does not get= =20=0D=0A>dropped on the=20=0D=0A>> >>> floor=0D=0A>> >>> // skip authori= zation failures=0D=0A>> >>> // give the call a special treatment=0D=0A>> = >>> lots-of-code-here();=0D=0A>> >>>=0D=0A>> >>> // trigger all the QoS= signaling you have in the=20=0D=0A>network to make=20=0D=0A>> >>> James ha= ppy=0D=0A>> >>> trigger-qos();=0D=0A>> >>>=0D=0A>> >>> // query locatio= n=0D=0A>> >>> location=3Dretrieve-location();=0D=0A>> >>>=0D=0A>> >>> /= / determine next hop=0D=0A>> >>> next-hop=3Dlost(location, serviceURN)=0D= =0A>> >>>=0D=0A>> >>> // attach RPH marking to outgoing msg to make James= and=0D=0A>> >> Keith happy=0D=0A>> >>> msg=3Dadd(msg, RPH);=0D=0A>> >>>=0D= =0A>> >>> send(msg, next-hop);=0D=0A>> >>> }=0D=0A>> >>>=0D=0A>> >>> If (= (rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) {=0D=0A>> >>> = // all the emergency related processing done already upfront=0D=0A>> >>> = // hence I log something.=0D=0A>> >>> log(RPH_WAS_PRESENT_JUHU);=0D=0A>> = >>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D=20=0D=0A= >FALSE)) { =20=0D=0A>> >>> // this is not an emergency call // this is som= ething=20=0D=0A>like GETS =20=0D=0A>> >>> result=3Dspecial-authorization-pr= ocedure(user);=0D=0A>> >>>=0D=0A>> >>> if (result =3D=3D AUTHORIZED) {=0D=0A= >> >>> // do some priority & preemption thing here.=0D=0A>> >>> // tr= igger all the QoS you have=0D=0A>> >>> lots-of-code-here();=0D=0A>> >>> = } else {=0D=0A>> >>> log("NOT AUTHORIZED; don't DoS my network"); } } = else { //=20=0D=0A>> >>> don't need todo any RPH processing // this inclu= des the case=20=0D=0A>> >>> where the call was an emergency call but the RP= H=0D=0A>> >>>=0D=0A>> >>> // marking was not there.=0D=0A>> >>> nothing()= ;=0D=0A>> >>> }=0D=0A>> >>>=0D=0A>> >>> -----------------------------------= ----------------=0D=0A>> >>>=0D=0A>> >>>=0D=0A>> >>> Ciao=0D=0A>> >>> Hanne= s=0D=0A>> >>>=0D=0A>> >>>> -----Original Message-----=0D=0A>> >>>> From: ec= rit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20=0D=0A>> >>>> Beh= alf Of Hannes Tschofenig=0D=0A>> >>>> Sent: 06 February, 2009 15:07=0D=0A>>= >>>> To: 'Janet P Gunn'=0D=0A>> >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; = Tschofenig,Hannes (NSN -=0D=0A>> >>> FI/Espoo)=0D=0A>> >>>> Subject: Re: [E= crit] ECRIT Virtual Interim Meeting: Agenda (RPH)=0D=0A>> >>>>=0D=0A>> >>>>= Who would define something that could prevent DoS problems=3F=0D=0A>> >>>>=0D= =0A>> >>>> ________________________________=0D=0A>> >>>>=0D=0A>> >>>> =09Fr= om: Janet P Gunn [mailto:jgunn6@csc.com]=0D=0A>> >>>> =09Sent: 06 February,= 2009 14:11=0D=0A>> >>>> =09To: Hannes Tschofenig=0D=0A>> >>>> =09Cc: 'Bria= n Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT';=20=0D=0A>> >>>> ecrit-bounces@ie= tf.org; Tschofenig, Hannes (NSN - FI/Espoo);=0D=0A>> 'James=0D=0A>> >>>> M.= Polk'=0D=0A>> >>>> =09Subject: Re: [Ecrit] ECRIT Virtual Interim=20=0D=0A>= Meeting: Agenda (RPH)=0D=0A>> >>>>=0D=0A>> >>>>=0D=0A>> >>>>=0D=0A>> >>>> =09= But there is nothing IN RFC4412 that specifically=0D=0A>> >> addresses how = to=0D=0A>> >>>> prevent any particular namespace being used for DoS. Anyon= e/any=0D=0A>> UA=0D=0A>> >>>> can ATTEMPT to invoke priority treatment by a= ttaching RPH. For=0D=0A>> all=0D=0A>> >>>> of the 4412 namespaces, as with= the new proposed namespace, the=20=0D=0A>> >>>> mechanisms for preventing = DoS are not specified in the=0D=0A>> >> document that=0D=0A>> >>>> defines = the namespace.=0D=0A>> >>>> They are/will be specified elsewhere.=0D=0A>> >= >>>=0D=0A>> >>>> =09Janet=0D=0A>> >>>>=0D=0A>> >>>> =09This is a PRIVATE me= ssage. If you are not the intended=0D=0A>> >> recipient,=0D=0A>> >>>> pleas= e delete without copying and kindly advise us by e-mail of=0D=0A>> the=0D=0A= >> >>>> mistake in delivery.=0D=0A>> >>>> =09NOTE: Regardless of content, t= his e-mail shall not=0D=0A>> >> operate to bind=0D=0A>> >>>> CSC to any ord= er or other contract unless pursuant to explicit=20=0D=0A>> >>>> written ag= reement or government initiative expressly permitting=0D=0A>> the=0D=0A>> >= >>> use of e-mail for such purpose.=0D=0A>> >>>>=0D=0A>> >>>> =09ecrit-boun= ces@ietf.org wrote on 02/06/2009 04:21:51 AM:=0D=0A>> >>>>=0D=0A>> >>>> =09= > Hi James,=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> I have read RFC 4412 and al= so the GETS/MLPP IETF=0D=0A>> >> documents. What I=0D=0A>> >>>> would=0D=0A= >> >>>> =09> like to point out is that there is more than just a=0D=0A>> >>= header and=0D=0A>> >>>> values within=0D=0A>> >>>> =09> the header that ha= ve to be considered in order to=0D=0A>> >> make a judgement=0D=0A>> >>>> of= what=0D=0A>> >>>> =09> is appropriate and what isn't. There is an=0D=0A>> = >> architectural question=0D=0A>> >>>> and=0D=0A>> >>>> =09> whether the en= vironment we are using the stuff is=0D=0A>> >> indeed providing=0D=0A>> >>>= > the=0D=0A>> >>>> =09> properties you need for the solution to be=20=0D=0A= >appropriate.=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> Let me describe in more d= etail what I meant (and=0D=0A>> >> please correct me=0D=0A>> >>>> if I am=0D= =0A>> >>>> =09> wrong).=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> Getting priorit= y for SIP requests when using a GETS=0D=0A>> >> alike scenario=0D=0A>> >>>>= means=0D=0A>> >>>> =09> that the entity that issues the request is special= ly=0D=0A>> >> authorized=0D=0A>> >>>> since=0D=0A>> >>>> =09> otherwise you= introduce a nice denial of=20=0D=0A>service attack. This=20=0D=0A>> >>>> a= uthorization=0D=0A>> >>>> =09> is tied to the entity that makes the request= =2E For=0D=0A>> >> example, the=0D=0A>> >>>> person is=0D=0A>> >>>> =09> wo= rking for the government and has special rights.=0D=0A>> >>>> James Bond as= a (not so)=0D=0A>> >>>> =09> secret agent might have these rights.=0D=0A>>= >>>> =09>=0D=0A>> >>>> =09> The emergency services case=20=0D=0A>(citizen-= to-authority) is a bit=20=0D=0A>> >>>> different as=0D=0A>> >>>> =09> there= aren't really special rights with respect to=0D=0A>> >> authorization=0D=0A= >> >>>> tied to=0D=0A>> >>>> =09> individuals. Instead, the fact that somet= hing is an=0D=0A>> >> emergency is=0D=0A>> >>>> purely a=0D=0A>> >>>> =09> = judgement of the human that dials a special number.=0D=0A>> >>>> To deal wi= th fraud, we=0D=0A>> >>>> =09> discussed in the group on what we can actual= ly do to=0D=0A>> >> ensure that=0D=0A>> >>>> end users=0D=0A>> >>>> =09> do= not bypass security procedures (such as=0D=0A>> >> authorization checks,=0D= =0A>> >>>> charging=0D=0A>> >>>> =09> and so on). Part of this investigatio= n was=20=0D=0A>the publication of=0D=0A>> >>>> =09> http://www.ietf.org/rfc= /rfc5069.txt that also=20=0D=0A>describes this=20=0D=0A>> >>>> issue.=0D=0A= >> >>>> =09>=0D=0A>> >>>> =09> So, imagine the implementation of a SIP prox= y (and we=0D=0A>> >> implemented=0D=0A>> >>>> that=0D=0A>> >>>> =09> stuff)= that receives a call that contains a Service=0D=0A>> >> URN. The code=0D=0A= >> >>>> branches=0D=0A>> >>>> =09> into a special mode where everything is = done=20=0D=0A>so that the call=20=0D=0A>> >>>> receives=0D=0A>> >>>> =09> a= ppropriate treatment and does not get dropped on the=0D=0A>> >> floor. The=0D= =0A>> >>>> way how the=0D=0A>> >>>> =09> Service URN is placed in the messa= ge ensures that the=0D=0A>> >> call cannot=0D=0A>> >>>> go to my=0D=0A>> >>= >> =09> friend (instead of the PSAP) unless the end host ran=0D=0A>> >> LoS= T already.=0D=0A>> >>>> In the=0D=0A>> >>>> =09> latter case, we discussed = this also on the list for a=0D=0A>> >> while and=0D=0A>> >>>> Richard even=0D= =0A>> >>>> =09> wrote a draft about it in the context of the=20=0D=0A>locat= ion hiding=20=0D=0A>> >>>> topic, we said=0D=0A>> >>>> =09> that the proxy = would have to run LoST if he=20=0D=0A>cares about a=20=0D=0A>> >>>> potenti= al=0D=0A>> >>>> =09> fraudulent usage.=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> = So, what do we need todo in order to provide=20=0D=0A>secure RFC 4412=20=0D= =0A>> >>>> functionality=0D=0A>> >>>> =09> in our context=3F=0D=0A>> >>>> =09= >=0D=0A>> >>>> =09> Do you think that the current text in=0D=0A>> >>>> =09>=0D= =0A>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer=0D= =0A>> >>>> gency-rph-nam=0D=0A>> >>>> =09> espace-00.txt reflects any of th= e=20=0D=0A>above-described issues:=0D=0A>> >>>> =09> "=0D=0A>> >>>> =09> = The Security considerations that apply to RFC 4412=0D=0A>> >>>> [RFC4412]=0D= =0A>> >>>> apply=0D=0A>> >>>> =09> here. This document introduces no ne= w security=0D=0A>> >>>> issues relative=0D=0A>> >>>> to=0D=0A>> >>>> =09> = RFC 4412.=0D=0A>> >>>> =09> "=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> From va= rious discussions in GEOPRIV I recall=20=0D=0A>that you are=20=0D=0A>> >>>>= super-sensitive=0D=0A>> >>>> =09> regarding security and privacy. For some= reasons you=0D=0A>> >> don't seem to=0D=0A>> >>>> have the=0D=0A>> >>>> =09= > same concerns here. I would like to=20=0D=0A>understand your reasoning.=0D= =0A>> >>>> =09>=0D=0A>> >>>> =09> Please also do me another favor: Don't al= ways say=0D=0A>> >> that I don't=0D=0A>> >>>> understand=0D=0A>> >>>> =09> = the subject. Even if that would be the case it isn't=0D=0A>> >> particular=0D= =0A>> >>>> fair given=0D=0A>> >>>> =09> that different folks had to educate= you on other=0D=0A>> >> topics in the=0D=0A>> >>>> past as well.=0D=0A>> >= >>> =09> Additionally, if you listen to the audio recordings=0D=0A>> >> the= n you will=0D=0A>> >>>> notice=0D=0A>> >>>> =09> that Henning, Ted, and Jon= do not seem to understand=0D=0A>> >> the issue=0D=0A>> >>>> either as=0D=0A= >> >>>> =09> they have raised similar issues during the=20=0D=0A>F2F meetin= gs.=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> Ciao=0D=0A>> >>>> =09> Hannes=0D=0A= >> >>>> =09>=0D=0A>> >>>> =09>=0D=0A>> >>>> =09> >Hannes - I believe it is = you who do not understand=0D=0A>> >> RFC 4412 --=0D=0A>> >>>> =09> >and man= y of us are trying to get that=20=0D=0A>through to you, but you=0D=0A>> >>>= > =09> >don't seem to want to listen/read.=0D=0A>> >>>> =09> >=0D=0A>> >>>>= =09> >RFC 4412 is *for* priority marking SIP requests,=0D=0A>> >>>> =09> >=0D= =0A>> >>>> =09> >One use is GETS.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >On= e use is MLPP.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >These examples are in= RFC 4412 because there=20=0D=0A>were specific=0D=0A>> >>>> =09> >namespace= s being created for the IANA section of=0D=0A>> >> that document.=0D=0A>> >= >>> =09> >=0D=0A>> >>>> =09> >Reading the whole document, you will see=20=0D= =0A>that RPH can be=0D=0A>> >>>> =09> >specified for other uses than GETS o= r MLPP=20=0D=0A>specifically.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >I knew= when I wrote RFC 4412 that one day we=20=0D=0A>would specify a=0D=0A>> >>>= > =09> >namespace for ECRIT (the "esnet" namespace=20=0D=0A>now) -- but I a= lso=0D=0A>> >>>> =09> >knew it was premature for RFC 4412 to=20=0D=0A>incor= porate that=0D=0A>> >>>> =09> >namespace, that a future doc to RFC 4412=20=0D= =0A>would have to be=0D=0A>> >>>> =09> >written to do this. Brian and I tal= ked about=20=0D=0A>this at the=0D=0A>> >>>> =09> >original NENA meeting tha= t created the IP WGs there=0D=0A>> >> (in August=0D=0A>> >>>> =09> >of 03).= We both agreed we should wait until it was=0D=0A>> >>>> =09> >appropriate= to the work in the IETF to=20=0D=0A>submit this document=0D=0A>> >>>> =09>= >that is now=0D=0A>> >>>> =09>=0D=0A>> >>>>> http://www.ietf.org/internet-= drafts/draft-ietf-ecrit-local-emer=0D=0A>> >>>> =09> >gency-rph-namespace-0= 0.txt=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >Yet, you seem to want to use s= ome additional=20=0D=0A>mechanism to=0D=0A>> >>>> =09> >indicate priority o= f a call in SIP. That=20=0D=0A>means you want to=0D=0A>> >>>> =09> >introd= uce a second way to accomplish this in SIP.=0D=0A>> >>>> Why do you=0D=0A>>= >>>> =09> >want to promote a separate way to do something SIP=0D=0A>> >> h= as already=0D=0A>> >>>> =09> >defined=3F That will cause interoperability i= ssues and=0D=0A>> >> we both know=0D=0A>> >>>> that.=0D=0A>> >>>> =09> >=0D= =0A>> >>>> =09> >You've said to me (and others) that you=20=0D=0A>believe R= PH is just=0D=0A>> >>>> =09> >another way to accomplish what sos or a URI c= an=0D=0A>> >> indicate - and=0D=0A>> >>>> =09> >you're wrong. Your way wou= ld be=20=0D=0A>_the_second_way_to_do_it,=0D=0A>> >>>> =09> >because SIP alr= eady considers RPH to be=20=0D=0A>*the*way* to priority=0D=0A>> >>>> =09> >= mark SIP requests.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >If you don't beli= eve me (no comment), then=20=0D=0A>why do you not=0D=0A>> >>>> =09> >believ= e the SIP WG chair (who knows more=20=0D=0A>about SIP than both=0D=0A>> >>>= > =09> >of us) - who, on this thread, has again said=20=0D=0A>to you "RFC 4= 412=0D=0A>> >>>> =09> >(RPH) is the SIP mechanism to priority mark=20=0D=0A= >SIP requests"=3F=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >Further, I believe= it is inappropriate to=20=0D=0A>prohibit endpoints=0D=0A>> >>>> =09> >from= being able to set the esnet namespace. =20=0D=0A>I absolutely=0D=0A>> >>>>= =09> >believe it will not be needed most of the=20=0D=0A>time, but I belie= ve=0D=0A>> >>>> =09> >if someone does find a valid use for=20=0D=0A>endpoin= ts to mark=0D=0A>> >>>> =09> >priority in SIP, this ID - once it has=20=0D=0A= >become an RFC -- will=0D=0A>> >>>> =09> >have to be obsoleted with a new R= FC saying the exact=0D=0A>> >> opposite.=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09= > >(color me confused ... over and over again)=0D=0A>> >>>> =09> >=0D=0A>> = >>>> =09> >James=0D=0A>> >>>> =09> >=0D=0A>> >>>> =09> >At 01:05 PM 2/5/200= 9, Hannes Tschofenig wrote:=0D=0A>> >>>> =09> >>Keith, please understand th= at the usage of RFC 4412=0D=0A>> >> for GETS and=0D=0A>> >>>> for=0D=0A>> >= >>> =09> >>the type of emergency call we discuss here is=0D=0A>> >> differe= nt. Just=0D=0A>> >>>> looking=0D=0A>> >>>> =09> >>at the header and the nam= e of the namespace is a bit=0D=0A>> >>>> =09> >artificial. I hope=0D=0A>> >= >>> =09> >>you understand that.=0D=0A>> >>>> =09> >>=0D=0A>> >>>> =09> >> >= -----Original Message-----=0D=0A>> >>>> =09> >> >From: DRAGE, Keith (Keith)= =20=0D=0A>> >>>> [mailto:drage@alcatel-lucent.com]=0D=0A>> >>>> =09> >> >Se= nt: 05 February, 2009 14:55=0D=0A>> >>>> =09> >> >To: Brian Rosen; 'Hannes = Tschofenig'; 'James M.=0D=0A>> >>>> Polk'; 'Tschofenig,=0D=0A>> >>>> =09> >= > >Hannes (NSN - FI/Espoo)'; 'ECRIT'=0D=0A>> >>>> =09> >> >Subject: RE: [Ec= rit] ECRIT Virtual Interim=0D=0A>> >>>> Meeting: Agenda (my=0D=0A>> >>>>=0D= =0A>> >>>> =09> >> >mistake)=0D=0A>> >>>> =09> >> >=0D=0A>> >>>> =09> >> >W= hich is exactly what RFC 4412 specifies for all=0D=0A>> >> namespaces.=0D=0A= >> >>>> =09> >> >=0D=0A>> >>>> =09> >> >regards=0D=0A>> >>>> =09> >> >=0D=0A= >> >>>> =09> >> >Keith=0D=0A>> >>>> =09> >> >=0D=0A>> >>>> =09> >> >> -----= Original Message-----=0D=0A>> >>>> =09> >> >> From: ecrit-bounces@ietf.org=0D= =0A>> >> [mailto:ecrit-bounces@ietf.org]=0D=0A>> >>>> =09> >> >On Behalf=0D= =0A>> >>>> =09> >> >> Of Brian Rosen=0D=0A>> >>>> =09> >> >> Sent: Wednesda= y, February 04, 2009 10:19 PM=0D=0A>> >>>> =09> >> >> To: 'Hannes Tschofeni= g'; 'James M.=20=0D=0A>Polk'; 'Tschofenig,=0D=0A>> >>>> =09> >Hannes (NSN=0D= =0A>> >>>> =09> >> >> - FI/Espoo)'; 'ECRIT'=0D=0A>> >>>> =09> >> >> Subject= : Re: [Ecrit] ECRIT Virtual Interim=0D=0A>> >>>> Meeting: Agenda (my=0D=0A>= > >>>> =09> >> >> mistake)=0D=0A>> >>>> =09> >> >>=0D=0A>> >>>> =09> >> >> = The value is that in some networks=20=0D=0A>where priority for=0D=0A>> >>>>= =09> >> >emergency calls=0D=0A>> >>>> =09> >> >> is appropriate, and appro= priate=20=0D=0A>policing of marking is=0D=0A>> >>>> =09> >implemented,=0D=0A= >> >>>> =09> >> >> emergency calls will receive resource priority.=0D=0A>> = >>>> =09> >> >>=0D=0A>> >>>> =09> >> >> Not all networks would need policin= g. Some=0D=0A>> >> will. Policing=0D=0A>> >>>> could=0D=0A>> >>>> =09> >>= >> be to Route header/R-URI content, but other=0D=0A>> >> criteria are=0D=0A= >> >>>> possible.=0D=0A>> >>>> =09> >> >>=0D=0A>> >>>> =09> >> >> Not all n= etworks will need resource priority=0D=0A>> >> for emergency=0D=0A>> >>>> c= alls.=0D=0A>> >>>> =09> >> >> Fine, ignore this marking/namespace.=0D=0A>> = >>>> =09> >> >>=0D=0A>> >>>> =09> >> >> Brian=0D=0A>> >>>> =09> >> >> > ---= --Original Message-----=0D=0A>> >>>> =09> >> >> > From: Hannes Tschofenig =0D= =0A>> >>>> [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>> >>>> =09> >> >> > Sen= t: Wednesday, February 04, 2009 5:09 PM=0D=0A>> >>>> =09> >> >> > To: 'Bria= n Rosen'; 'James M. Polk';=0D=0A>> >> Tschofenig, Hannes=0D=0A>> >>>> (NSN = -=0D=0A>> >>>> =09> >> >> > FI/Espoo); 'ECRIT'=0D=0A>> >>>> =09> >> >> > Su= bject: RE: [Ecrit] ECRIT Virtual Interim=0D=0A>> >>>> Meeting: Agenda (my=0D= =0A>> >>>> =09> >> >> > mistake)=0D=0A>> >>>> =09> >> >> >=0D=0A>> >>>> =09= > >> >> > I don't even see the value in permitting the=0D=0A>> >> endpoint = todo=0D=0A>> >>>> the=0D=0A>> >>>> =09> >> >> > RPH marking.=0D=0A>> >>>> =09= > >> >> > In addition to the security concerns=20=0D=0A>there is also the=0D= =0A>> >>>> =09> >> >problem that=0D=0A>> >>>> =09> >> >> > there are more o= ptions to implement without=0D=0A>> >> an additional=0D=0A>> >>>> value.=0D= =0A>> >>>> =09> >> >> >=0D=0A>> >>>> =09> >> >> > >-----Original Message---= --=0D=0A>> >>>> =09> >> >> > >From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A>> >>>> =09> >> >> > >Sent: 05 February, 2009 00:03=0D=0A>> >>>> =09> >>= >> > >To: 'James M. Polk'; 'Hannes Tschofenig';=0D=0A>> >> 'Tschofenig,=0D= =0A>> >>>> =09> >> >> Hannes (NSN -=0D=0A>> >>>> =09> >> >> > >FI/Espoo)'; = 'ECRIT'=0D=0A>> >>>> =09> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual=20=0D= =0A>Interim Meeting:=0D=0A>> >>>> Agenda (my=0D=0A>> >>>> =09> >> >> > mist= ake)=0D=0A>> >>>> =09> >> >> > >=0D=0A>> >>>> =09> >> >> > >Hannes=0D=0A>> = >>>> =09> >> >> > >=0D=0A>> >>>> =09> >> >> > >This matches my understandin= g=20=0D=0A>precisely. We wish to=0D=0A>> >>>> =09> >> >> permit endpoints=0D= =0A>> >>>> =09> >> >> > >to mark. We do not require it, and=20=0D=0A>don't = necessarily=20=0D=0A>> >>>> expect it=0D=0A>> >>>> =09> >> >> > >in many (e= ven=0D=0A>> >>>> =09> >> >> > >most) cases. We don't wish to see the=0D=0A= >> >> document prohibit=0D=0A>> >>>> it.=0D=0A>> >>>> =09> >> >> > >We all = seem to agree it has value within the=0D=0A>> >> Emergency=0D=0A>> >>>> =09= > >> >Services IP=0D=0A>> >>>> =09> >> >> > >Networks.=0D=0A>> >>>> =09> >>= >> > >=0D=0A>> >>>> =09> >> >> > >Brian=0D=0A>> >>>> =09> >> >> > >=0D=0A>= > >>>> =09> >> >> > >> -----Original Message-----=0D=0A>> >>>> =09> >> >> >= >> From: ecrit-bounces@ietf.org=20=0D=0A>> >>>> [mailto:ecrit-bounces@ietf= =2Eorg]=0D=0A>> >>>> =09> >> >> > >On Behalf=0D=0A>> >>>> =09> >> >> > >> O= f James M. Polk=0D=0A>> >>>> =09> >> >> > >> Sent: Wednesday, February 04, = 2009 4:01 PM=0D=0A>> >>>> =09> >> >> > >> To: Hannes Tschofenig; Tschofenig= ,=20=0D=0A>Hannes (NSN -=0D=0A>> >>>> =09> >> >> FI/Espoo); 'ECRIT'=0D=0A>>= >>>> =09> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim=0D=0A>> >>= >> Meeting:=0D=0A>> >>>> =09> >Agenda (my=0D=0A>> >>>> =09> >> >> > >> mist= ake)=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> At 02:37 PM = 2/4/2009, Hannes=20=0D=0A>Tschofenig wrote:=0D=0A>> >>>> =09> >> >> > >> > = > James wrote:=0D=0A>> >>>> =09> >> >> > >> > >> you are the _lone_ voice n= ot=0D=0A>> >> supporting this ID,=0D=0A>> >>>> =09> >> >> > >> >=0D=0A>> >>= >> =09> >> >> > >> >Listening to the audio recording of past=0D=0A>> >> mee= tings I=0D=0A>> >>>> have to=0D=0A>> >>>> =09> >> >> > >say that=0D=0A>> >>= >> =09> >> >> > >> >I=0D=0A>> >>>> =09> >> >> > >> was=0D=0A>> >>>> =09> >>= >> > >> >not the only persons raising=20=0D=0A>concerns about the=20=0D=0A= >> >>>> document.=0D=0A>> >>>> =09> >> >> > >> >That was probably the reaso= n why you=0D=0A>> >> agreed to limit=0D=0A>> >>>> the=0D=0A>> >>>> =09> >> = >> > >scope of the=0D=0A>> >>>> =09> >> >> > >> >document (which you didn't= later do) to=0D=0A>> >> get folks to=0D=0A>> >>>> agree=0D=0A>> >>>> =09> = >> >> > >to make it=0D=0A>> >>>> =09> >> >> > >> a WG=0D=0A>> >>>> =09> >> = >> > >> >item.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> re= -listen to the audio please=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> = >> >> > >> Ted's concerns were consistent with most=0D=0A>> >>>> (all=3F) o= ther=0D=0A>> >>>> =09> >> >> concerns --=0D=0A>> >>>> =09> >> >> > >> which= were based on the premise of whether=0D=0A>> >> or not the=0D=0A>> >>>> =09= > >> >> UAC should be=0D=0A>> >>>> =09> >> >> > >> trusted to initiate the = marking on the=0D=0A>> >> INVITE. The=0D=0A>> >>>> most=0D=0A>> >>>> =09> = >> >> > >> recent version has backed off this=20=0D=0A>to a "can" --=20=0D=0A= >> >>>> meaning not=0D=0A>> >>>> =09> >> >prohibited=0D=0A>> >>>> =09> >> >= > > >> (i.e., no 2119 text). I also backed off=0D=0A>> >> the text in=0D=0A= >> >>>> the=0D=0A>> >>>> =09> >> >> SP domain=0D=0A>> >>>> =09> >> >> > >> = part to "can", such that there is=20=0D=0A>no 2119 text=0D=0A>> >>>> =09> >= > >mandating or even=0D=0A>> >>>> =09> >> >> > >> recommending its usage th= ere. I also do=0D=0A>> >> not prohibit=0D=0A>> >>>> its=0D=0A>> >>>> =09> >= > >> > >use, based on=0D=0A>> >>>> =09> >> >> > >> local policy. Keith has= come forward with=0D=0A>> >> the specific=0D=0A>> >>>>=0D=0A>> >>>> =09> >= > >> > >> request that non-ESInet networks be=0D=0A>> >> allowed to mark an= d=0D=0A>> >>>> pay=0D=0A>> >>>> =09> >> >attention to=0D=0A>> >>>> =09> >> = >> > >> this priority indication -- with IMS as=0D=0A>> >> the specific=0D=0A= >> >>>> example=0D=0A>> >>>> =09> >> >> > >> he wishes to have this valid f= or.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> Where there i= s no disagreement, save for=0D=0A>> >> your recent=0D=0A>> >>>> =09> >> >> = > >pushback - is in=0D=0A>> >>>> =09> >> >> > >> the ESInet, which is where= Brian=20=0D=0A>has requested it's=0D=0A>> >>>> =09> >> >> > >definition in= the=0D=0A>> >>>> =09> >> >> > >> IETF on behalf of NENA. He's the i3 WG=0D= =0A>> >> chair within=0D=0A>> >>>> =09> >> >> NENA, and if=0D=0A>> >>>> =09= > >> >> > >> he asks for it, are you going to say you=0D=0A>> >> know bette= r=0D=0A>> >>>> than he=3F=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >>= >> > >>=0D=0A>> >>>> =09> >> >> > >> >Btw, I not disagreeing with the docu= ment=0D=0A>> >> as such. I=0D=0A>> >>>> =09> >> >just want to=0D=0A>> >>>> = =09> >> >> > the=0D=0A>> >>>> =09> >> >> > >> scope=0D=0A>> >>>> =09> >> >>= > >> >to change. The usage of RPH=20=0D=0A>within the emergency=0D=0A>> >>= >> =09> >> >> services network=0D=0A>> >>>> =09> >> >> > is=0D=0A>> >>>> =09= > >> >> > >> fine=0D=0A>> >>>> =09> >> >> > >> >for me. I may get convinced= to start the=0D=0A>> >> RPH marking=0D=0A>> >>>> from=0D=0A>> >>>> =09> >>= >> > >the the VSP=0D=0A>> >>>> =09> >> >> > >> >towards the PSAP. I feel u= neasy about the=0D=0A>> >> end host=0D=0A>> >>>> doing=0D=0A>> >>>> =09> >>= >> > >the marking.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > = >> please read what I wrote above, and then=0D=0A>> >> re-read the=0D=0A>> = >>>> =09> >> >most recent=0D=0A>> >>>> =09> >> >> > >> version of the ID. I= don't have endpoints=0D=0A>> >> that SHOULD=0D=0A>> >>>> or=0D=0A>> >>>> =09= > >> >> MUST mark=0D=0A>> >>>> =09> >> >> > >> anything wrt RPH. I also do= n't want to=0D=0A>> >> prohibit it,=0D=0A>> >>>> =09> >> >> because there=0D= =0A>> >>>> =09> >> >> > >> might be cases (that I don't know=20=0D=0A>of) o= f valid uses=0D=0A>> >>>> =09> >> >> under certain=0D=0A>> >>>> =09> >> >> = > >> circumstances. Figure 1 is very clear=0D=0A>> >> that there are 3=0D=0A= >> >>>> =09> >> >> networking=0D=0A>> >>>> =09> >> >> > >> parts to conside= r=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> #1 - from the e= ndpoint=0D=0A>> >>>> =09> >> >> > >> #2 - within the VSP=0D=0A>> >>>> =09> = >> >> > >> #3 - within the ESInet=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>>= =09> >> >> > >> the most recent ID version has "can" for=0D=0A>> >> #s 1 a= nd 2,=0D=0A>> >>>> and=0D=0A>> >>>> =09> >> >> > >2119 language=0D=0A>> >>>= > =09> >> >> > >> offering those supporting this=0D=0A>> >> specification w= ill have=0D=0A>> >>>> RPH=0D=0A>> >>>> =09> >> >> > >> adherence within #3 = (the ESInet).=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> Wha= t other scope changes do you want,=0D=0A>> >> because I haven't=0D=0A>> >>>= > =09> >> >> heard them.=0D=0A>> >>>> =09> >> >> > >>=0D=0A>> >>>> =09> >> = >> > >> I only heard you claim in email during the=0D=0A>> >> last IETF=0D=0A= >> >>>> and in=0D=0A>> >>>> =09> >> >> > >the ECRIT=0D=0A>> >>>> =09> >> >>= > >> session that RPH should not be=20=0D=0A>used for priority=20=0D=0A>> = >>>> marking=0D=0A>> >>>> =09> >> >> requests.=0D=0A>> >>>> =09> >> >> > >>= This is something Keith (SIP WG=20=0D=0A>chair) voiced his=20=0D=0A>> >>>>= opposition=0D=0A>> >>>> =09> >> >> > >> to your views regarding creating a= second=0D=0A>> >> means for SIP=0D=0A>> >>>> to=0D=0A>> >>>> =09> >> >prio= rity=0D=0A>> >>>> =09> >> >> > >> mark request "when SIP already has one=0D= =0A>> >> interoperable=0D=0A>> >>>> way to=0D=0A>> >>>> =09> >> >> > >> acc= omplish this... it's call the RP header=0D=0A>> >> mechanism".=0D=0A>> >>>>= =09> >> >> > >>=0D=0A>> >>>> =09> >> >> > >> >I don't see advantages -- on= ly=20=0D=0A>disadvantages.=0D=0A>> >>>> =09> >> >> > >> >=0D=0A>> >>>> =09>= >> >> > >> >Ciao=0D=0A>> >>>> =09> >> >> > >> >Hannes=0D=0A>> >>>> =09> >>= >> > >>=0D=0A>> >>>> =09> >> >> > >>=20=0D=0A>____________________________= ___________________=0D=0A>> >>>> =09> >> >> > >> Ecrit mailing list=0D=0A>>= >>>> =09> >> >> > >> Ecrit@ietf.org=0D=0A>> >>>> =09> >> >> > >> https://w= ww.ietf.org/mailman/listinfo/ecrit=0D=0A>> >>>> =09> >> >> > >=0D=0A>> >>>>= =09> >> >>=0D=0A>> >>>> =09> >> >> _______________________________________= ________=0D=0A>> >>>> =09> >> >> Ecrit mailing list=0D=0A>> >>>> =09> >> >>= Ecrit@ietf.org=0D=0A>> >>>> =09> >> >> https://www.ietf.org/mailman/listin= fo/ecrit=0D=0A>> >>>> =09> >> >>=0D=0A>> >>>> =09> >> >=0D=0A>> >>>> =09> >=0D= =0A>> >>>> =09>=0D=0A>> >>>> =09> _________________________________________= ______=0D=0A>> >>>> =09> Ecrit mailing list=0D=0A>> >>>> =09> Ecrit@ietf.or= g=0D=0A>> >>>> =09> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >>>= >=0D=0A>> >>>>=0D=0A>> >>>>=0D=0A>> >>>> __________________________________= _____________=0D=0A>> >>>> Ecrit mailing list=0D=0A>> >>>> Ecrit@ietf.org=0D= =0A>> >>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >>>>=0D=0A>>= >>>=0D=0A>> >>> _______________________________________________=0D=0A>> >>= > Ecrit mailing list=0D=0A>> >>> Ecrit@ietf.org=0D=0A>> >>> https://www.iet= f.org/mailman/listinfo/ecrit=0D=0A>> >>=0D=0A>> >=0D=0A>> > _______________= ________________________________=0D=0A>> > Ecrit mailing list=0D=0A>> > Ecr= it@ietf.org=0D=0A>> > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >=0D= =0A>=0D=0A=0D=0A_______________________________________________=0D=0AEcrit = mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo= /ecrit=0D=0A=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5353A672F for ; Fri, 6 Feb 2009 13:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHW27wzsManm for ; Fri, 6 Feb 2009 13:05:16 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id CD1293A6C18 for ; Fri, 6 Feb 2009 13:05:15 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16L572d001433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 16:05:08 -0500 (EST) Message-Id: <28F08C20-0FCC-4E0D-953D-F6C9850BF9EF@cs.columbia.edu> From: Henning Schulzrinne To: "Winterbottom, James" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 16:05:07 -0500 References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 21:05:18 -0000 There's another problem with the "it doesn't hurt argument". Assume for a moment we have a "UA MAY include RPH" wording. There are now two cases: (1) All UAs implement it. (2) Only some UAs implement it. (1) seems unlikely for a MAY. If (2) occurs, we have the choice between two undesirable outcomes: (a) some UAs that are otherwise compliant get worse service just because they didn't include the RPH; OR (b) the proxy has to look for the service URN to give the call the appropriate treatment, thus obviating any advantage of having the header, yet incurring more complicated processing logic. I have no objection to whatever markings people want to apply to calls within an ESN - that's largely a private matter. Henning On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: > Hi All, > > I have followed thi thread with some interest and I struggling to > see a use case for the > providing RPH for emergency calls from the end-point. > > The reference-model call in ECRIT, for better or worse, is for all > calls to go back through a home-VSP. > We placed quite a lot of emphasis, largely for traffing reasons, for > the VSP to be able to verify that > a call is in fact an emergency call. This is done by the proxy > taking the inband location, doing a LoST > query with the provided URN, and verifying that the resulting > destination URI is the same as the destination > URI provide in the SIP INVITE. My understanding was that VSPs would > always do this check so they could > tell if they could bill for the call or not, and because the VSP can > be use that the call is an emergency call > it can apply any special priorities that may be applicable. This > obviates the need for RPH from the end-point > to the network. > > This leaves us with the argument of "it doesn't hurt to it", which > is not a good reason to write a specification. > It was intimated on the geopriv mailing list last year that great > pains had been taken to keep SIP with in the > MTU limits of UDP over Ethernet (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html > ). Assuming > that this is the case, perhaps there is harm in including > information that we know will be ignored. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Fri 2/6/2009 12:33 PM > To: 'Brian Rosen'; 'Henning Schulzrinne' > Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > Subject: Re: [Ecrit] RPH > > To the story short here is the code for the proxy: > > --------------------- > > IF emergency call was recognized THEN > execute emergency call specific procedures (priority queuing, > preemption, fetch location, determine routing, do funny QoS things & > co) > ELSE > normal call handling procedures. > > --------------------- > > If you can make this differentiation between an emergency call and a > regular > call then you can also do everything that is necessary for emergency > call > handling. > > Brian + Keith: Please tell me that we cannot do the above with our > currently > specified mechanisms. > > Ciao > Hannes > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: 06 February, 2009 17:49 >> To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> Subject: RE: [Ecrit] RPH >> >> I agree that not all networks will permit (or pay attention >> to) a priority request from an end device. >> >> No one has asked for that. >> >> The namespace request has several uses, one of which is within >> an emergency services IP network, one of which is between >> elements within a public network controlled by the operator, >> and one of which is an endpoint request for resource priority. >> >> Those of us requesting this work proceed are happy if the >> endpoint part is simply left as possible (MAY), and, speaking >> for myself, having the draft discuss the security implications >> of endpoint marking is reasonable. >> >> Having discussed this issue with an implementation team who >> worked on MLPP systems, I am confident I know what I'm talking >> about, but YMMV. The fact that you could, if you wanted to, >> give resource priority to a call you decided, however you >> decided, was an emergency call is an implementation decision, >> and not subject to standardization. >> >> RPH is the IETF standard way for one entity to request >> resource priority of another entity in a SIP system. We're >> asking for a namespace to use that within the domain of >> emergency calls. That is, I think, a VERY reasonable request. >> >> Brian >> >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> Sent: Friday, February 06, 2009 10:33 AM >>> To: Hannes Tschofenig >>> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >>> Subject: Re: [Ecrit] RPH >>> >>> To chime in here: >>> >>> I don't think it's productive to simply state that 4412 >> doesn't worry >>> about authorization, so we shouldn't either (simplifying a bit). >>> Authorization was discussed repeatedly, and the general >> assumption was >>> that there were two conditions: Either the user invoking resource- >>> priority was well known and had a set of permissions that could be >>> checked in real time or there are ways to deal with abuse after the >>> fact in ways that deter abuse (the court-martial kind of thing in a >>> military context). >>> >>> The RFC 4412 security consideration (11.2) call this out in pretty >>> strong language: >>> >>> Prioritized access to network and end-system resources imposes >>> particularly stringent requirements on authentication and >>> authorization mechanisms, since access to prioritized >> resources may >>> impact overall system stability and performance and not >> just result >>> in theft of, say, a single phone call. >>> Thus, the question is whether we have such strong authentication in >>> emergency calling. In some cases, such as residential fixed line >>> deployments where ISP = VSP, we're probably pretty close, in others, >>> such as prepaid cell phones or hot spots or VSP-only providers, we >>> aren't. >>> >>> The other point that I think Hannes is making is that the >> information >>> is either redundant or dangerous. If a processing element recognizes >>> the call as being an emergency call, it can apply whatever treatment >>> it deems appropriate and doesn't need additional information. If it >>> doesn't or can't, using just the RPH can be rather dangerous unless >>> that element can be reasonably certain that there is strong >>> authentication and recourse. >>> >>> I don't buy the argument that somehow finding the RPH is faster than >>> just looking for the identifier. Thus, given that the information is >>> either redundant or dangerous, I fail to see the advantage. >>> >>> Henning >>> >>> >>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >>> >>>> Don't get hung up on the details. There are ways to optimize it. >>>> That was >>>> not the point of the code example. >>>> >>>> The problem that my pseudo code should have shown you is that you >>>> * don't gain anything with RPH marking for the emergency call case >>>> from the SIP UA towards the outbound proxy since the functionality >>>> is already provide otherwise. How often does the proxy need to get >>>> told that this is an emergency call todo whatever emergency call >>>> handling procedures are necessary? >>>> * you only introduce fraud problems (if you are not >> careful and you >>>> understand the security stuff well enough) >>>> >>>> If you can point me to people who implement the RPH emergency call >>>> case please do so. I would love to talk to them. >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: You need to parse incoming messages to some extend so that you >>>> know what it contains :-) Only looking for the emergency >> RPH header >>>> (and not for the Service URN/dial >>>> string) would exactly be the DoS/fraud attack I am worried about. >>>> That's the thing Henning was worried about (go and listen to the >>>> past meeting minutes). >>>> >>>> >>>>> Hannes >>>>> >>>>> You need to talk to people who really implement this kind >> of thing. >>>>> You are way off. >>>>> >>>>> When you implement a resource priority system, the point of doing >>>>> that is to look though the queue of work and pick out the >> ones with >>>>> priority, handling them first. You don't do all the parsing, you >>>>> don't do a lot of decision tree. >>>>> >>>>> Typically: >>>>> Check for DoS things, like too big messages, etc Do a quick scan >>>>> for the RPH message header If found: >>>>> Parse the message >>>>> Determine validity >>>>> Determine priority >>>>> Queue on the correct work queue >>>>> >>>>> The first two actions have to be very fast. Anyone who builds a >>>>> SIP thingie will tell you that parsing is one of the big cycle >>>>> consumers: if you have to parse every message BEFORE you >> determine >>>>> priority, you can't give much resource priority. >>>>> Once you get the whole message parsed, you might as well finish >>>>> working on it, because you've done so much of the work. >>>>> OTHOH, finding the end-of-message delimiter and doing a quick >>>>> string search for RPH is fast. If you are doing >> priority, you need >>>>> to keep all the priority processing pretty uniform, and pretty >>>>> simple, or you tend to spend too much time futzing around >> figuring >>>>> out what to do. You put all the priority related stuff together, >>>>> and use as much common code as possible. >>>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>> On Behalf >>>>>> Of Hannes Tschofenig >>>>>> Sent: Friday, February 06, 2009 8:41 AM >>>>>> To: 'Hannes Tschofenig'; 'Janet P Gunn' >>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >>>>>> bounces@ietf.org >>>>>> Subject: [Ecrit] RPH >>>>>> >>>>>> Over lunch I was also thinking how an outbound proxy would >>> implement >>>>>> some of the emergency procedures. Here are some thoughts: >>>>>> >>>>>> --------------------------------------------------- >>>>>> >>>>>> // Process incoming message >>>>>> Parse(msg); >>>>>> >>>>>> // SIP INVITE without Service URN >>>>>> // legacy devices >>>>>> If (recognize-dialstring(msg)==TRUE) { // we got an emergency >>>>>> call going on emergency=TRUE; if (dialstring(msg) == 911) >>>>>> serviceURN=urn:service:sos; } else if >>>>>> (recognize-serviceURN(msg)==TRUE) { // oh. A updated >> device that >>>>>> has a service URN attached to the >>> call >>>>>> serviceURN=retrieve_ServiceURN(msg); >>>>>> emergency=TRUE; >>>>>> } else { >>>>>> // standard SIP message >>>>>> // regular processing >>>>>> process(msg); >>>>>> emergency=FALSE; >>>>>> } >>>>>> >>>>>> If (emergency == TRUE) { >>>>>> // make sure that the emergency call does not get >> dropped on the >>>>>> floor >>>>>> // skip authorization failures >>>>>> // give the call a special treatment >>>>>> lots-of-code-here(); >>>>>> >>>>>> // trigger all the QoS signaling you have in the >> network to make >>>>>> James happy >>>>>> trigger-qos(); >>>>>> >>>>>> // query location >>>>>> location=retrieve-location(); >>>>>> >>>>>> // determine next hop >>>>>> next-hop=lost(location, serviceURN) >>>>>> >>>>>> // attach RPH marking to outgoing msg to make James and >>>>> Keith happy >>>>>> msg=add(msg, RPH); >>>>>> >>>>>> send(msg, next-hop); >>>>>> } >>>>>> >>>>>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >>>>>> // all the emergency related processing done already upfront >>>>>> // hence I log something. >>>>>> log(RPH_WAS_PRESENT_JUHU); >>>>>> } else if ((rph-present(msg) == TRUE) && (emergency == >> FALSE)) { >>>>>> // this is not an emergency call // this is something >> like GETS >>>>>> result=special-authorization-procedure(user); >>>>>> >>>>>> if (result == AUTHORIZED) { >>>>>> // do some priority & preemption thing here. >>>>>> // trigger all the QoS you have >>>>>> lots-of-code-here(); >>>>>> } else { >>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // >>>>>> don't need todo any RPH processing // this includes the case >>>>>> where the call was an emergency call but the RPH >>>>>> >>>>>> // marking was not there. >>>>>> nothing(); >>>>>> } >>>>>> >>>>>> --------------------------------------------------- >>>>>> >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>> Behalf Of Hannes Tschofenig >>>>>>> Sent: 06 February, 2009 15:07 >>>>>>> To: 'Janet P Gunn' >>>>>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >>>>>> FI/Espoo) >>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >>>>>>> >>>>>>> Who would define something that could prevent DoS problems? >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>>>>>> Sent: 06 February, 2009 14:11 >>>>>>> To: Hannes Tschofenig >>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >>>>>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >>> 'James >>>>>>> M. Polk' >>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >> Meeting: Agenda (RPH) >>>>>>> >>>>>>> >>>>>>> >>>>>>> But there is nothing IN RFC4412 that specifically >>>>> addresses how to >>>>>>> prevent any particular namespace being used for DoS. Anyone/any >>> UA >>>>>>> can ATTEMPT to invoke priority treatment by attaching RPH. For >>> all >>>>>>> of the 4412 namespaces, as with the new proposed namespace, the >>>>>>> mechanisms for preventing DoS are not specified in the >>>>> document that >>>>>>> defines the namespace. >>>>>>> They are/will be specified elsewhere. >>>>>>> >>>>>>> Janet >>>>>>> >>>>>>> This is a PRIVATE message. If you are not the intended >>>>> recipient, >>>>>>> please delete without copying and kindly advise us by e-mail of >>> the >>>>>>> mistake in delivery. >>>>>>> NOTE: Regardless of content, this e-mail shall not >>>>> operate to bind >>>>>>> CSC to any order or other contract unless pursuant to explicit >>>>>>> written agreement or government initiative expressly permitting >>> the >>>>>>> use of e-mail for such purpose. >>>>>>> >>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: >>>>>>> >>>>>>> > Hi James, >>>>>>> > >>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF >>>>> documents. What I >>>>>>> would >>>>>>> > like to point out is that there is more than just a >>>>> header and >>>>>>> values within >>>>>>> > the header that have to be considered in order to >>>>> make a judgement >>>>>>> of what >>>>>>> > is appropriate and what isn't. There is an >>>>> architectural question >>>>>>> and >>>>>>> > whether the environment we are using the stuff is >>>>> indeed providing >>>>>>> the >>>>>>> > properties you need for the solution to be >> appropriate. >>>>>>> > >>>>>>> > Let me describe in more detail what I meant (and >>>>> please correct me >>>>>>> if I am >>>>>>> > wrong). >>>>>>> > >>>>>>> > Getting priority for SIP requests when using a GETS >>>>> alike scenario >>>>>>> means >>>>>>> > that the entity that issues the request is specially >>>>> authorized >>>>>>> since >>>>>>> > otherwise you introduce a nice denial of >> service attack. This >>>>>>> authorization >>>>>>> > is tied to the entity that makes the request. For >>>>> example, the >>>>>>> person is >>>>>>> > working for the government and has special rights. >>>>>>> James Bond as a (not so) >>>>>>> > secret agent might have these rights. >>>>>>> > >>>>>>> > The emergency services case >> (citizen-to-authority) is a bit >>>>>>> different as >>>>>>> > there aren't really special rights with respect to >>>>> authorization >>>>>>> tied to >>>>>>> > individuals. Instead, the fact that something is an >>>>> emergency is >>>>>>> purely a >>>>>>> > judgement of the human that dials a special number. >>>>>>> To deal with fraud, we >>>>>>> > discussed in the group on what we can actually do to >>>>> ensure that >>>>>>> end users >>>>>>> > do not bypass security procedures (such as >>>>> authorization checks, >>>>>>> charging >>>>>>> > and so on). Part of this investigation was >> the publication of >>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also >> describes this >>>>>>> issue. >>>>>>> > >>>>>>> > So, imagine the implementation of a SIP proxy (and we >>>>> implemented >>>>>>> that >>>>>>> > stuff) that receives a call that contains a Service >>>>> URN. The code >>>>>>> branches >>>>>>> > into a special mode where everything is done >> so that the call >>>>>>> receives >>>>>>> > appropriate treatment and does not get dropped on the >>>>> floor. The >>>>>>> way how the >>>>>>> > Service URN is placed in the message ensures that the >>>>> call cannot >>>>>>> go to my >>>>>>> > friend (instead of the PSAP) unless the end host ran >>>>> LoST already. >>>>>>> In the >>>>>>> > latter case, we discussed this also on the list for a >>>>> while and >>>>>>> Richard even >>>>>>> > wrote a draft about it in the context of the >> location hiding >>>>>>> topic, we said >>>>>>> > that the proxy would have to run LoST if he >> cares about a >>>>>>> potential >>>>>>> > fraudulent usage. >>>>>>> > >>>>>>> > So, what do we need todo in order to provide >> secure RFC 4412 >>>>>>> functionality >>>>>>> > in our context? >>>>>>> > >>>>>>> > Do you think that the current text in >>>>>>> > >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>>>>> gency-rph-nam >>>>>>> > espace-00.txt reflects any of the >> above-described issues: >>>>>>> > " >>>>>>> > The Security considerations that apply to RFC 4412 >>>>>>> [RFC4412] >>>>>>> apply >>>>>>> > here. This document introduces no new security >>>>>>> issues relative >>>>>>> to >>>>>>> > RFC 4412. >>>>>>> > " >>>>>>> > >>>>>>> > From various discussions in GEOPRIV I recall >> that you are >>>>>>> super-sensitive >>>>>>> > regarding security and privacy. For some reasons you >>>>> don't seem to >>>>>>> have the >>>>>>> > same concerns here. I would like to >> understand your reasoning. >>>>>>> > >>>>>>> > Please also do me another favor: Don't always say >>>>> that I don't >>>>>>> understand >>>>>>> > the subject. Even if that would be the case it isn't >>>>> particular >>>>>>> fair given >>>>>>> > that different folks had to educate you on other >>>>> topics in the >>>>>>> past as well. >>>>>>> > Additionally, if you listen to the audio recordings >>>>> then you will >>>>>>> notice >>>>>>> > that Henning, Ted, and Jon do not seem to understand >>>>> the issue >>>>>>> either as >>>>>>> > they have raised similar issues during the >> F2F meetings. >>>>>>> > >>>>>>> > Ciao >>>>>>> > Hannes >>>>>>> > >>>>>>> > >>>>>>> > >Hannes - I believe it is you who do not understand >>>>> RFC 4412 -- >>>>>>> > >and many of us are trying to get that >> through to you, but you >>>>>>> > >don't seem to want to listen/read. >>>>>>> > > >>>>>>> > >RFC 4412 is *for* priority marking SIP requests, >>>>>>> > > >>>>>>> > >One use is GETS. >>>>>>> > > >>>>>>> > >One use is MLPP. >>>>>>> > > >>>>>>> > >These examples are in RFC 4412 because there >> were specific >>>>>>> > >namespaces being created for the IANA section of >>>>> that document. >>>>>>> > > >>>>>>> > >Reading the whole document, you will see >> that RPH can be >>>>>>> > >specified for other uses than GETS or MLPP >> specifically. >>>>>>> > > >>>>>>> > >I knew when I wrote RFC 4412 that one day we >> would specify a >>>>>>> > >namespace for ECRIT (the "esnet" namespace >> now) -- but I also >>>>>>> > >knew it was premature for RFC 4412 to >> incorporate that >>>>>>> > >namespace, that a future doc to RFC 4412 >> would have to be >>>>>>> > >written to do this. Brian and I talked about >> this at the >>>>>>> > >original NENA meeting that created the IP WGs there >>>>> (in August >>>>>>> > >of 03). We both agreed we should wait until it was >>>>>>> > >appropriate to the work in the IETF to >> submit this document >>>>>>> > >that is now >>>>>>> > >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>>>>> > >gency-rph-namespace-00.txt >>>>>>> > > >>>>>>> > >Yet, you seem to want to use some additional >> mechanism to >>>>>>> > >indicate priority of a call in SIP. That >> means you want to >>>>>>> > >introduce a second way to accomplish this in SIP. >>>>>>> Why do you >>>>>>> > >want to promote a separate way to do something SIP >>>>> has already >>>>>>> > >defined? That will cause interoperability issues and >>>>> we both know >>>>>>> that. >>>>>>> > > >>>>>>> > >You've said to me (and others) that you >> believe RPH is just >>>>>>> > >another way to accomplish what sos or a URI can >>>>> indicate - and >>>>>>> > >you're wrong. Your way would be >> _the_second_way_to_do_it, >>>>>>> > >because SIP already considers RPH to be >> *the*way* to priority >>>>>>> > >mark SIP requests. >>>>>>> > > >>>>>>> > >If you don't believe me (no comment), then >> why do you not >>>>>>> > >believe the SIP WG chair (who knows more >> about SIP than both >>>>>>> > >of us) - who, on this thread, has again said >> to you "RFC 4412 >>>>>>> > >(RPH) is the SIP mechanism to priority mark >> SIP requests"? >>>>>>> > > >>>>>>> > >Further, I believe it is inappropriate to >> prohibit endpoints >>>>>>> > >from being able to set the esnet namespace. >> I absolutely >>>>>>> > >believe it will not be needed most of the >> time, but I believe >>>>>>> > >if someone does find a valid use for >> endpoints to mark >>>>>>> > >priority in SIP, this ID - once it has >> become an RFC -- will >>>>>>> > >have to be obsoleted with a new RFC saying the exact >>>>> opposite. >>>>>>> > > >>>>>>> > >(color me confused ... over and over again) >>>>>>> > > >>>>>>> > >James >>>>>>> > > >>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >>>>>>> > >>Keith, please understand that the usage of RFC 4412 >>>>> for GETS and >>>>>>> for >>>>>>> > >>the type of emergency call we discuss here is >>>>> different. Just >>>>>>> looking >>>>>>> > >>at the header and the name of the namespace is a bit >>>>>>> > >artificial. I hope >>>>>>> > >>you understand that. >>>>>>> > >> >>>>>>> > >> >-----Original Message----- >>>>>>> > >> >From: DRAGE, Keith (Keith) >>>>>>> [mailto:drage@alcatel-lucent.com] >>>>>>> > >> >Sent: 05 February, 2009 14:55 >>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >>>>>>> Polk'; 'Tschofenig, >>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>> Meeting: Agenda (my >>>>>>> >>>>>>> > >> >mistake) >>>>>>> > >> > >>>>>>> > >> >Which is exactly what RFC 4412 specifies for all >>>>> namespaces. >>>>>>> > >> > >>>>>>> > >> >regards >>>>>>> > >> > >>>>>>> > >> >Keith >>>>>>> > >> > >>>>>>> > >> >> -----Original Message----- >>>>>>> > >> >> From: ecrit-bounces@ietf.org >>>>> [mailto:ecrit-bounces@ietf.org] >>>>>>> > >> >On Behalf >>>>>>> > >> >> Of Brian Rosen >>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >> Polk'; 'Tschofenig, >>>>>>> > >Hannes (NSN >>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' >>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>> Meeting: Agenda (my >>>>>>> > >> >> mistake) >>>>>>> > >> >> >>>>>>> > >> >> The value is that in some networks >> where priority for >>>>>>> > >> >emergency calls >>>>>>> > >> >> is appropriate, and appropriate >> policing of marking is >>>>>>> > >implemented, >>>>>>> > >> >> emergency calls will receive resource priority. >>>>>>> > >> >> >>>>>>> > >> >> Not all networks would need policing. Some >>>>> will. Policing >>>>>>> could >>>>>>> > >> >> be to Route header/R-URI content, but other >>>>> criteria are >>>>>>> possible. >>>>>>> > >> >> >>>>>>> > >> >> Not all networks will need resource priority >>>>> for emergency >>>>>>> calls. >>>>>>> > >> >> Fine, ignore this marking/namespace. >>>>>>> > >> >> >>>>>>> > >> >> Brian >>>>>>> > >> >> > -----Original Message----- >>>>>>> > >> >> > From: Hannes Tschofenig >>>>>>> [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >>>>> Tschofenig, Hannes >>>>>>> (NSN - >>>>>>> > >> >> > FI/Espoo); 'ECRIT' >>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>> Meeting: Agenda (my >>>>>>> > >> >> > mistake) >>>>>>> > >> >> > >>>>>>> > >> >> > I don't even see the value in permitting the >>>>> endpoint todo >>>>>>> the >>>>>>> > >> >> > RPH marking. >>>>>>> > >> >> > In addition to the security concerns >> there is also the >>>>>>> > >> >problem that >>>>>>> > >> >> > there are more options to implement without >>>>> an additional >>>>>>> value. >>>>>>> > >> >> > >>>>>>> > >> >> > >-----Original Message----- >>>>>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 >>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >>>>> 'Tschofenig, >>>>>>> > >> >> Hannes (NSN - >>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' >>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >> Interim Meeting: >>>>>>> Agenda (my >>>>>>> > >> >> > mistake) >>>>>>> > >> >> > > >>>>>>> > >> >> > >Hannes >>>>>>> > >> >> > > >>>>>>> > >> >> > >This matches my understanding >> precisely. We wish to >>>>>>> > >> >> permit endpoints >>>>>>> > >> >> > >to mark. We do not require it, and >> don't necessarily >>>>>>> expect it >>>>>>> > >> >> > >in many (even >>>>>>> > >> >> > >most) cases. We don't wish to see the >>>>> document prohibit >>>>>>> it. >>>>>>> > >> >> > >We all seem to agree it has value within the >>>>> Emergency >>>>>>> > >> >Services IP >>>>>>> > >> >> > >Networks. >>>>>>> > >> >> > > >>>>>>> > >> >> > >Brian >>>>>>> > >> >> > > >>>>>>> > >> >> > >> -----Original Message----- >>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org >>>>>>> [mailto:ecrit-bounces@ietf.org] >>>>>>> > >> >> > >On Behalf >>>>>>> > >> >> > >> Of James M. Polk >>>>>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >> Hannes (NSN - >>>>>>> > >> >> FI/Espoo); 'ECRIT' >>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>> Meeting: >>>>>>> > >Agenda (my >>>>>>> > >> >> > >> mistake) >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >> Tschofenig wrote: >>>>>>> > >> >> > >> > > James wrote: >>>>>>> > >> >> > >> > >> you are the _lone_ voice not >>>>> supporting this ID, >>>>>>> > >> >> > >> > >>>>>>> > >> >> > >> >Listening to the audio recording of past >>>>> meetings I >>>>>>> have to >>>>>>> > >> >> > >say that >>>>>>> > >> >> > >> >I >>>>>>> > >> >> > >> was >>>>>>> > >> >> > >> >not the only persons raising >> concerns about the >>>>>>> document. >>>>>>> > >> >> > >> >That was probably the reason why you >>>>> agreed to limit >>>>>>> the >>>>>>> > >> >> > >scope of the >>>>>>> > >> >> > >> >document (which you didn't later do) to >>>>> get folks to >>>>>>> agree >>>>>>> > >> >> > >to make it >>>>>>> > >> >> > >> a WG >>>>>>> > >> >> > >> >item. >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> re-listen to the audio please >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> Ted's concerns were consistent with most >>>>>>> (all?) other >>>>>>> > >> >> concerns -- >>>>>>> > >> >> > >> which were based on the premise of whether >>>>> or not the >>>>>>> > >> >> UAC should be >>>>>>> > >> >> > >> trusted to initiate the marking on the >>>>> INVITE. The >>>>>>> most >>>>>>> > >> >> > >> recent version has backed off this >> to a "can" -- >>>>>>> meaning not >>>>>>> > >> >prohibited >>>>>>> > >> >> > >> (i.e., no 2119 text). I also backed off >>>>> the text in >>>>>>> the >>>>>>> > >> >> SP domain >>>>>>> > >> >> > >> part to "can", such that there is >> no 2119 text >>>>>>> > >> >mandating or even >>>>>>> > >> >> > >> recommending its usage there. I also do >>>>> not prohibit >>>>>>> its >>>>>>> > >> >> > >use, based on >>>>>>> > >> >> > >> local policy. Keith has come forward with >>>>> the specific >>>>>>> >>>>>>> > >> >> > >> request that non-ESInet networks be >>>>> allowed to mark and >>>>>>> pay >>>>>>> > >> >attention to >>>>>>> > >> >> > >> this priority indication -- with IMS as >>>>> the specific >>>>>>> example >>>>>>> > >> >> > >> he wishes to have this valid for. >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> Where there is no disagreement, save for >>>>> your recent >>>>>>> > >> >> > >pushback - is in >>>>>>> > >> >> > >> the ESInet, which is where Brian >> has requested it's >>>>>>> > >> >> > >definition in the >>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >>>>> chair within >>>>>>> > >> >> NENA, and if >>>>>>> > >> >> > >> he asks for it, are you going to say you >>>>> know better >>>>>>> than he? >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> >Btw, I not disagreeing with the document >>>>> as such. I >>>>>>> > >> >just want to >>>>>>> > >> >> > the >>>>>>> > >> >> > >> scope >>>>>>> > >> >> > >> >to change. The usage of RPH >> within the emergency >>>>>>> > >> >> services network >>>>>>> > >> >> > is >>>>>>> > >> >> > >> fine >>>>>>> > >> >> > >> >for me. I may get convinced to start the >>>>> RPH marking >>>>>>> from >>>>>>> > >> >> > >the the VSP >>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy about the >>>>> end host >>>>>>> doing >>>>>>> > >> >> > >the marking. >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> please read what I wrote above, and then >>>>> re-read the >>>>>>> > >> >most recent >>>>>>> > >> >> > >> version of the ID. I don't have endpoints >>>>> that SHOULD >>>>>>> or >>>>>>> > >> >> MUST mark >>>>>>> > >> >> > >> anything wrt RPH. I also don't want to >>>>> prohibit it, >>>>>>> > >> >> because there >>>>>>> > >> >> > >> might be cases (that I don't know >> of) of valid uses >>>>>>> > >> >> under certain >>>>>>> > >> >> > >> circumstances. Figure 1 is very clear >>>>> that there are 3 >>>>>>> > >> >> networking >>>>>>> > >> >> > >> parts to consider >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> #1 - from the endpoint >>>>>>> > >> >> > >> #2 - within the VSP >>>>>>> > >> >> > >> #3 - within the ESInet >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> the most recent ID version has "can" for >>>>> #s 1 and 2, >>>>>>> and >>>>>>> > >> >> > >2119 language >>>>>>> > >> >> > >> offering those supporting this >>>>> specification will have >>>>>>> RPH >>>>>>> > >> >> > >> adherence within #3 (the ESInet). >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> What other scope changes do you want, >>>>> because I haven't >>>>>>> > >> >> heard them. >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> I only heard you claim in email during the >>>>> last IETF >>>>>>> and in >>>>>>> > >> >> > >the ECRIT >>>>>>> > >> >> > >> session that RPH should not be >> used for priority >>>>>>> marking >>>>>>> > >> >> requests. >>>>>>> > >> >> > >> This is something Keith (SIP WG >> chair) voiced his >>>>>>> opposition >>>>>>> > >> >> > >> to your views regarding creating a second >>>>> means for SIP >>>>>>> to >>>>>>> > >> >priority >>>>>>> > >> >> > >> mark request "when SIP already has one >>>>> interoperable >>>>>>> way to >>>>>>> > >> >> > >> accomplish this... it's call the RP header >>>>> mechanism". >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> >I don't see advantages -- only >> disadvantages. >>>>>>> > >> >> > >> > >>>>>>> > >> >> > >> >Ciao >>>>>>> > >> >> > >> >Hannes >>>>>>> > >> >> > >> >>>>>>> > >> >> > >> >> _______________________________________________ >>>>>>> > >> >> > >> Ecrit mailing list >>>>>>> > >> >> > >> Ecrit@ietf.org >>>>>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> > >> >> > > >>>>>>> > >> >> >>>>>>> > >> >> _______________________________________________ >>>>>>> > >> >> Ecrit mailing list >>>>>>> > >> >> Ecrit@ietf.org >>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> > >> >> >>>>>>> > >> > >>>>>>> > > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Ecrit mailing list >>>>>>> > Ecrit@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCB53A6830 for ; Fri, 6 Feb 2009 13:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahgz6SFXSdai for ; Fri, 6 Feb 2009 13:27:55 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BD6873A6BF1 for ; Fri, 6 Feb 2009 13:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1233955678; x=1265491678; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<28F08C20-0FCC-4E0D-953D- F6C9850BF9EF@cs.columbia.edu>|References:=20<000701c9883c $59b095d0$49b5b70a@nsnintra.net>=0D=0A =20<001d01c9885b$d5d705d0$49b5b70a@nsnintra.net>=0D=0A=20 <001f01c98860$910658c0$49b5b70a@nsnintra.net>=0D=0A=20<0d 6901c9886b$6c9bfc50$45d3f4f0$@net>=0D=0A=20<003001c9886e$ 7d133280$49b5b70a@nsnintra.net>=0D=0A=20<1CC6E7BB-98D9-4D 96-9340-2CA9A81F2562@cs.columbia.edu>=0D=0A=20<0d9101c988 72$7b2129b0$71637d10$@net>=0D=0A=20<003d01c98889$666c23f0 $49b5b70a@nsnintra.net>=0D=0A=20=0D=0A=20<28F08C20-0FC C-4E0D-953D-F6C9850BF9EF@cs.columbia.edu>|Date:=20Fri,=20 6=20Feb=202009=2013:27:54=20-0800|To:=20Henning=20Schulzr inne=20,=0D=0A=20=20=20=20=20=20=20 =20"Winterbottom,=20James"=0D=0A=09|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20RPH|CC:=20"Tschofenig,=20Hann es=20(NSN=20-=20FI/Espoo)"=20, =0D=0A=20=20=20=20=20=20=20=20ECRIT=0D=0A=09|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5518"=3B=20a =3D"15283026"; bh=dI6hFXVYKK8jVWL6Z2F5EWYMSkXcsNAGExiDIiGP6JE=; b=Qi9F/0nPS9by6bUjCvRpPTLzqZTByU69yBepCeqe13bMQnMd1s0TjPdF 6r0Fej54KQPz42o8G+kczn5AuDDkNounMLVGE9vKk2E+JBbSiRsNbRfDq CoSWxBW/miI+aRmkIBVOUfweH8pkrNO9XYNUnnvNBjW6R7Cj6F7NMGDwI E=; X-IronPort-AV: E=McAfee;i="5100,188,5518"; a="15283026" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Feb 2009 13:27:58 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n16LRvUG024349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Feb 2009 13:27:58 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n16LRvR8014564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2009 13:27:57 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 6 Feb 2009 13:27:56 -0800 Received: from [10.227.68.59] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 6 Feb 2009 13:27:56 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <28F08C20-0FCC-4E0D-953D-F6C9850BF9EF@cs.columbia.edu> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> <28F08C20-0FCC-4E0D-953D-F6C9850BF9EF@cs.columbia.edu> Date: Fri, 6 Feb 2009 13:27:54 -0800 To: Henning Schulzrinne , "Winterbottom, James" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 21:27:58 -0000 At 1:05 PM -0800 2/6/09, Henning Schulzrinne wrote: >There's another problem with the "it doesn't hurt argument". Assume >for a moment we have a "UA MAY include RPH" wording. There are now two >cases: Is it ever a protocol error for a SIP entity to include RPH? Or is it always the expectation that it generally might be included, and may be roundly ignored? If the latter is true, then the key thing is for those interested in having this work in a specific context to publish the namespace they will use in that context. Others in similar contexts may adopt that, if they like. But the UA/general SIP handling isn't different here just because it is an emergency call. It's only different in contexts where that RPH namespace is in use, and only because of an agreement to do so; presumably the interested party could assign RPH values to non-emergency calls too, so it isn't a tight linkage between emergency-special handling. I'm just trying to figure out whether we're introducing a new situation in which the call processing for emergency calls is different. We've agreed previously to try to minimize those. If the call processing here is the standard RPH processing (which seems to be "your mileage may vary"), then we probably don't even need to call it out. Possibly confused, Ted >(1) All UAs implement it. > >(2) Only some UAs implement it. > >(1) seems unlikely for a MAY. If (2) occurs, we have the choice >between two undesirable outcomes: > >(a) some UAs that are otherwise compliant get worse service just >because they didn't include the RPH; > >OR > >(b) the proxy has to look for the service URN to give the call the >appropriate treatment, thus obviating any advantage of having the >header, yet incurring more complicated processing logic. > > >I have no objection to whatever markings people want to apply to calls >within an ESN - that's largely a private matter. > >Henning > >On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: > >> Hi All, >> >> I have followed thi thread with some interest and I struggling to >> see a use case for the >> providing RPH for emergency calls from the end-point. >> >> The reference-model call in ECRIT, for better or worse, is for all >> calls to go back through a home-VSP. >> We placed quite a lot of emphasis, largely for traffing reasons, for >> the VSP to be able to verify that >> a call is in fact an emergency call. This is done by the proxy >> taking the inband location, doing a LoST >> query with the provided URN, and verifying that the resulting >> destination URI is the same as the destination >> URI provide in the SIP INVITE. My understanding was that VSPs would >> always do this check so they could >> tell if they could bill for the call or not, and because the VSP can >> be use that the call is an emergency call >> it can apply any special priorities that may be applicable. This >> obviates the need for RPH from the end-point >> to the network. >> >> This leaves us with the argument of "it doesn't hurt to it", which >> is not a good reason to write a specification. >> It was intimated on the geopriv mailing list last year that great >> pains had been taken to keep SIP with in the >> MTU limits of UDP over Ethernet (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html >> ). Assuming >> that this is the case, perhaps there is harm in including >> information that we know will be ignored. >> >> Cheers >> James >> >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >> Sent: Fri 2/6/2009 12:33 PM >> To: 'Brian Rosen'; 'Henning Schulzrinne' >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >> Subject: Re: [Ecrit] RPH >> >> To the story short here is the code for the proxy: >> >> --------------------- >> >> IF emergency call was recognized THEN >> execute emergency call specific procedures (priority queuing, > > preemption, fetch location, determine routing, do funny QoS things & >> co) >> ELSE >> normal call handling procedures. >> >> --------------------- >> >> If you can make this differentiation between an emergency call and a >> regular >> call then you can also do everything that is necessary for emergency >> call >> handling. >> >> Brian + Keith: Please tell me that we cannot do the above with our >> currently >> specified mechanisms. >> >> Ciao >> Hannes >> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: 06 February, 2009 17:49 >>> To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >>> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >>> Subject: RE: [Ecrit] RPH >>> >>> I agree that not all networks will permit (or pay attention >>> to) a priority request from an end device. >>> >>> No one has asked for that. >>> >>> The namespace request has several uses, one of which is within >>> an emergency services IP network, one of which is between >>> elements within a public network controlled by the operator, >>> and one of which is an endpoint request for resource priority. >>> >>> Those of us requesting this work proceed are happy if the >>> endpoint part is simply left as possible (MAY), and, speaking >>> for myself, having the draft discuss the security implications >>> of endpoint marking is reasonable. >>> >>> Having discussed this issue with an implementation team who >>> worked on MLPP systems, I am confident I know what I'm talking >>> about, but YMMV. The fact that you could, if you wanted to, >>> give resource priority to a call you decided, however you >>> decided, was an emergency call is an implementation decision, >>> and not subject to standardization. >>> >>> RPH is the IETF standard way for one entity to request >>> resource priority of another entity in a SIP system. We're >>> asking for a namespace to use that within the domain of >>> emergency calls. That is, I think, a VERY reasonable request. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>> Sent: Friday, February 06, 2009 10:33 AM >>>> To: Hannes Tschofenig >>>> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >>>> Subject: Re: [Ecrit] RPH >>>> >>>> To chime in here: >>>> >>>> I don't think it's productive to simply state that 4412 >>> doesn't worry >>>> about authorization, so we shouldn't either (simplifying a bit). >>>> Authorization was discussed repeatedly, and the general >>> assumption was >>>> that there were two conditions: Either the user invoking resource- >>>> priority was well known and had a set of permissions that could be >>>> checked in real time or there are ways to deal with abuse after the >>>> fact in ways that deter abuse (the court-martial kind of thing in a >>>> military context). >>>> >>>> The RFC 4412 security consideration (11.2) call this out in pretty >>>> strong language: >>>> >>>> Prioritized access to network and end-system resources imposes >>>> particularly stringent requirements on authentication and >>>> authorization mechanisms, since access to prioritized >>> resources may >>>> impact overall system stability and performance and not >>> just result >>>> in theft of, say, a single phone call. >>>> Thus, the question is whether we have such strong authentication in >>>> emergency calling. In some cases, such as residential fixed line >>>> deployments where ISP = VSP, we're probably pretty close, in others, >>>> such as prepaid cell phones or hot spots or VSP-only providers, we >>>> aren't. >>>> >>>> The other point that I think Hannes is making is that the >>> information >>>> is either redundant or dangerous. If a processing element recognizes >>>> the call as being an emergency call, it can apply whatever treatment >>>> it deems appropriate and doesn't need additional information. If it >>>> doesn't or can't, using just the RPH can be rather dangerous unless >>>> that element can be reasonably certain that there is strong >>>> authentication and recourse. >>>> >>>> I don't buy the argument that somehow finding the RPH is faster than >>>> just looking for the identifier. Thus, given that the information is > >>> either redundant or dangerous, I fail to see the advantage. >>>> >>>> Henning >>>> >>>> >>>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >>>> >>>>> Don't get hung up on the details. There are ways to optimize it. >>>>> That was >>>>> not the point of the code example. >>>>> >>>>> The problem that my pseudo code should have shown you is that you >>>>> * don't gain anything with RPH marking for the emergency call case >>>>> from the SIP UA towards the outbound proxy since the functionality >>>>> is already provide otherwise. How often does the proxy need to get >>>>> told that this is an emergency call todo whatever emergency call >>>>> handling procedures are necessary? >>>>> * you only introduce fraud problems (if you are not >>> careful and you >>>>> understand the security stuff well enough) >>>>> >>>>> If you can point me to people who implement the RPH emergency call >>>>> case please do so. I would love to talk to them. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> PS: You need to parse incoming messages to some extend so that you >>>>> know what it contains :-) Only looking for the emergency >>> RPH header >>>>> (and not for the Service URN/dial >>>>> string) would exactly be the DoS/fraud attack I am worried about. >>>>> That's the thing Henning was worried about (go and listen to the >>>>> past meeting minutes). >>>>> >>>>> >>>>>> Hannes >>>>>> >>>>>> You need to talk to people who really implement this kind >>> of thing. >>>>>> You are way off. >>>>>> >>>>>> When you implement a resource priority system, the point of doing >>>>>> that is to look though the queue of work and pick out the >>> ones with >>>>>> priority, handling them first. You don't do all the parsing, you >>>>>> don't do a lot of decision tree. >>>>>> >>>>>> Typically: >>>>>> Check for DoS things, like too big messages, etc Do a quick scan >>>>>> for the RPH message header If found: >>>>>> Parse the message >>>>>> Determine validity >>>>>> Determine priority >>>>>> Queue on the correct work queue >>>>>> >>>>>> The first two actions have to be very fast. Anyone who builds a >>>>>> SIP thingie will tell you that parsing is one of the big cycle >>>>>> consumers: if you have to parse every message BEFORE you >>> determine >>>>>> priority, you can't give much resource priority. >>>>>> Once you get the whole message parsed, you might as well finish >>>>>> working on it, because you've done so much of the work. >>>>>> OTHOH, finding the end-of-message delimiter and doing a quick >>>>>> string search for RPH is fast. If you are doing >>> priority, you need >>>>>> to keep all the priority processing pretty uniform, and pretty >>>>>> simple, or you tend to spend too much time futzing around >>> figuring >>>>>> out what to do. You put all the priority related stuff together, >>>>>> and use as much common code as possible. >>>>>> >>>>>> Brian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>> On Behalf >>>>>>> Of Hannes Tschofenig >>>>>>> Sent: Friday, February 06, 2009 8:41 AM >>>>>>> To: 'Hannes Tschofenig'; 'Janet P Gunn' >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >>>>>>> bounces@ietf.org >>>>>>> Subject: [Ecrit] RPH >>>>>>> >>>>>>> Over lunch I was also thinking how an outbound proxy would >>>> implement >>>>>>> some of the emergency procedures. Here are some thoughts: >>>>>>> >>>>>>> --------------------------------------------------- >>>>>>> >>>>>>> // Process incoming message >>>>>>> Parse(msg); >>>>>>> >>>>>>> // SIP INVITE without Service URN >>>>>>> // legacy devices >>>>>>> If (recognize-dialstring(msg)==TRUE) { // we got an emergency >>>>>>> call going on emergency=TRUE; if (dialstring(msg) == 911) >>>>>>> serviceURN=urn:service:sos; } else if >>>>>>> (recognize-serviceURN(msg)==TRUE) { // oh. A updated >>> device that >>>>>>> has a service URN attached to the >>>> call >>>>>>> serviceURN=retrieve_ServiceURN(msg); >>>>>>> emergency=TRUE; >>>>>>> } else { >>>>>>> // standard SIP message >>>>>>> // regular processing >>>>>>> process(msg); >>>>>>> emergency=FALSE; >>>>>>> } >>>>>>> >>>>>>> If (emergency == TRUE) { >>>>>>> // make sure that the emergency call does not get > >> dropped on the >>>>>>> floor >>>>>>> // skip authorization failures >>>>>>> // give the call a special treatment >>>>>>> lots-of-code-here(); >>>>>>> >>>>>>> // trigger all the QoS signaling you have in the >>> network to make >>>>>>> James happy >>>>>>> trigger-qos(); >>>>>>> >>>>>>> // query location >>>>>>> location=retrieve-location(); >>>>>>> >>>>>>> // determine next hop >>>>>>> next-hop=lost(location, serviceURN) >>>>>>> >>>>>>> // attach RPH marking to outgoing msg to make James and >>>>>> Keith happy >>>>>>> msg=add(msg, RPH); >>>>>>> >>>>>>> send(msg, next-hop); >>>>>>> } >>>>>>> >>>>>>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >>>>>>> // all the emergency related processing done already upfront >>>>>>> // hence I log something. >>>>>>> log(RPH_WAS_PRESENT_JUHU); >>>>>>> } else if ((rph-present(msg) == TRUE) && (emergency == >>> FALSE)) { >>>>>>> // this is not an emergency call // this is something >>> like GETS >>>>>>> result=special-authorization-procedure(user); >>>>>>> >>>>>>> if (result == AUTHORIZED) { >>>>>>> // do some priority & preemption thing here. >>>>>>> // trigger all the QoS you have >>>>>>> lots-of-code-here(); >>>>>>> } else { >>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // >>>>>>> don't need todo any RPH processing // this includes the case >>>>>>> where the call was an emergency call but the RPH >>>>>>> >>>>>>> // marking was not there. >>>>>>> nothing(); >>>>>>> } >>>>>>> >>>>>>> --------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>>> Behalf Of Hannes Tschofenig >>>>>>>> Sent: 06 February, 2009 15:07 >>>>>>>> To: 'Janet P Gunn' >>>>>>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >>>>>>> FI/Espoo) >>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >>>>>>>> >>>>>>>> Who would define something that could prevent DoS problems? >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> >>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>>>>>>> Sent: 06 February, 2009 14:11 >>>>>>>> To: Hannes Tschofenig >>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >>>>>>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >>>> 'James >>>>>>>> M. Polk' >>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >>> Meeting: Agenda (RPH) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> But there is nothing IN RFC4412 that specifically >>>>>> addresses how to >>>>>>>> prevent any particular namespace being used for DoS. Anyone/any >>>> UA >>>>>>>> can ATTEMPT to invoke priority treatment by attaching RPH. For >>>> all >>>>>>>> of the 4412 namespaces, as with the new proposed namespace, the >>>>>>>> mechanisms for preventing DoS are not specified in the >>>>>> document that >>>>>>>> defines the namespace. >>>>>>>> They are/will be specified elsewhere. >>>>>>>> >>>>>>>> Janet >>>>>>>> >>>>>>>> This is a PRIVATE message. If you are not the intended >>>>>> recipient, >>>>>>>> please delete without copying and kindly advise us by e-mail of >>>> the >>>>>>>> mistake in delivery. >>>>>>>> NOTE: Regardless of content, this e-mail shall not >>>>>> operate to bind >>>>>>>> CSC to any order or other contract unless pursuant to explicit >>>>>>>> written agreement or government initiative expressly permitting >>>> the >>>>>>>> use of e-mail for such purpose. >>>>>>>> >>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: >>>>>>>> >>>>>>>> > Hi James, >>>>>>>> > >>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF >>>>>> documents. What I >>>>>>>> would >>>>>>>> > like to point out is that there is more than just a >>>>>> header and >>>>>>>> values within >>>>>>>> > the header that have to be considered in order to >>>>>> make a judgement >>>>>>>> of what >>>>>>>> > is appropriate and what isn't. There is an >>>>>> architectural question >>>>>>>> and >>>>>>>> > whether the environment we are using the stuff is >>>>>> indeed providing > >>>>>>> the >>>>>>>> > properties you need for the solution to be >>> appropriate. >>>>>>>> > >>>>>>>> > Let me describe in more detail what I meant (and >>>>>> please correct me >>>>>>>> if I am >>>>>>>> > wrong). >>>>>>>> > >>>>>>>> > Getting priority for SIP requests when using a GETS >>>>>> alike scenario >>>>>>>> means >>>>>>>> > that the entity that issues the request is specially >>>>>> authorized >>>>>>>> since >>>>>>>> > otherwise you introduce a nice denial of >>> service attack. This >>>>>>>> authorization >>>>>>>> > is tied to the entity that makes the request. For >>>>>> example, the >>>>>>>> person is >>>>>>>> > working for the government and has special rights. >>>>>>>> James Bond as a (not so) >>>>>>>> > secret agent might have these rights. >>>>>>>> > >>>>>>>> > The emergency services case >>> (citizen-to-authority) is a bit >>>>>>>> different as >>>>>>>> > there aren't really special rights with respect to >>>>>> authorization >>>>>>>> tied to >>>>>>>> > individuals. Instead, the fact that something is an >>>>>> emergency is >>>>>>>> purely a >>>>>>>> > judgement of the human that dials a special number. >>>>>>>> To deal with fraud, we >>>>>>>> > discussed in the group on what we can actually do to >>>>>> ensure that >>>>>>>> end users >>>>>>>> > do not bypass security procedures (such as >>>>>> authorization checks, >>>>>>>> charging >>>>>>>> > and so on). Part of this investigation was >>> the publication of >>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also >>> describes this >>>>>>>> issue. >>>>>>>> > >>>>>>>> > So, imagine the implementation of a SIP proxy (and we >>>>>> implemented >>>>>>>> that >>>>>>>> > stuff) that receives a call that contains a Service >>>>>> URN. The code >>>>>>>> branches >>>>>>>> > into a special mode where everything is done >>> so that the call >>>>>>>> receives >>>>>>>> > appropriate treatment and does not get dropped on the >>>>>> floor. The >>>>>>>> way how the >>>>>>>> > Service URN is placed in the message ensures that the >>>>>> call cannot >>>>>>>> go to my >>>>>>>> > friend (instead of the PSAP) unless the end host ran >>>>>> LoST already. >>>>>>>> In the >>>>>>>> > latter case, we discussed this also on the list for a >>>>>> while and >>>>>>>> Richard even >>>>>>>> > wrote a draft about it in the context of the >>> location hiding >>>>>>>> topic, we said >>>>>>>> > that the proxy would have to run LoST if he >>> cares about a >>>>>>>> potential >>>>>>>> > fraudulent usage. >>>>>>>> > >>>>>>>> > So, what do we need todo in order to provide >>> secure RFC 4412 >>>>>>>> functionality >>>>>>>> > in our context? >>>>>>>> > >>>>>>>> > Do you think that the current text in >>>>>>>> > >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>>>>>> gency-rph-nam >>>>>>>> > espace-00.txt reflects any of the >>> above-described issues: >>>>>>>> > " >>>>>>>> > The Security considerations that apply to RFC 4412 >>>>>>>> [RFC4412] >>>>>>>> apply >>>>>>>> > here. This document introduces no new security >>>>>>>> issues relative >>>>>>>> to >>>>>>>> > RFC 4412. >>>>>>>> > " >>>>>>>> > >>>>>>>> > From various discussions in GEOPRIV I recall >>> that you are >>>>>>>> super-sensitive >>>>>>>> > regarding security and privacy. For some reasons you >>>>>> don't seem to >>>>>>>> have the >>>>>>>> > same concerns here. I would like to >>> understand your reasoning. >>>>>>>> > >>>>>>>> > Please also do me another favor: Don't always say >>>>>> that I don't >>>>>>>> understand >>>>>>>> > the subject. Even if that would be the case it isn't >>>>>> particular >>>>>>>> fair given >>>>>>>> > that different folks had to educate you on other >>>>>> topics in the >>>>>>>> past as well. >>>>>>>> > Additionally, if you listen to the audio recordings >>>>>> then you will > >>>>>>> notice >>>>>>>> > that Henning, Ted, and Jon do not seem to understand >>>>>> the issue >>>>>>>> either as >>>>>>>> > they have raised similar issues during the >>> F2F meetings. >>>>>>>> > >>>>>>>> > Ciao >>>>>>>> > Hannes >>>>>>>> > >>>>>>>> > >>>>>>>> > >Hannes - I believe it is you who do not understand >>>>>> RFC 4412 -- >>>>>>>> > >and many of us are trying to get that >>> through to you, but you >>>>>>>> > >don't seem to want to listen/read. >>>>>>>> > > >>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, >>>>>>>> > > >>>>>>>> > >One use is GETS. >>>>>>>> > > >>>>>>>> > >One use is MLPP. >>>>>>>> > > >>>>>>>> > >These examples are in RFC 4412 because there >>> were specific >>>>>>>> > >namespaces being created for the IANA section of >>>>>> that document. >>>>>>>> > > >>>>>>>> > >Reading the whole document, you will see >>> that RPH can be >>>>>>>> > >specified for other uses than GETS or MLPP >>> specifically. >>>>>>>> > > >>>>>>>> > >I knew when I wrote RFC 4412 that one day we >>> would specify a >>>>>>>> > >namespace for ECRIT (the "esnet" namespace >>> now) -- but I also >>>>>>>> > >knew it was premature for RFC 4412 to >>> incorporate that >>>>>>>> > >namespace, that a future doc to RFC 4412 >>> would have to be >>>>>>>> > >written to do this. Brian and I talked about >>> this at the >>>>>>>> > >original NENA meeting that created the IP WGs there >>>>>> (in August >>>>>>>> > >of 03). We both agreed we should wait until it was >>>>>>>> > >appropriate to the work in the IETF to >>> submit this document >>>>>>>> > >that is now >>>>>>>> > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>>>>>> > >gency-rph-namespace-00.txt >>>>>>>> > > >>>>>>>> > >Yet, you seem to want to use some additional >>> mechanism to >>>>>>>> > >indicate priority of a call in SIP. That >>> means you want to >>>>>>>> > >introduce a second way to accomplish this in SIP. >>>>>>>> Why do you >>>>>>>> > >want to promote a separate way to do something SIP >>>>>> has already >>>>>>>> > >defined? That will cause interoperability issues and >>>>>> we both know >>>>>>>> that. >>>>>>>> > > >>>>>>>> > >You've said to me (and others) that you >>> believe RPH is just >>>>>>>> > >another way to accomplish what sos or a URI can >>>>>> indicate - and >>>>>>>> > >you're wrong. Your way would be >>> _the_second_way_to_do_it, >>>>>>>> > >because SIP already considers RPH to be >>> *the*way* to priority >>>>>>>> > >mark SIP requests. >>>>>>>> > > >>>>>>>> > >If you don't believe me (no comment), then >>> why do you not >>>>>>>> > >believe the SIP WG chair (who knows more >>> about SIP than both >>>>>>>> > >of us) - who, on this thread, has again said >>> to you "RFC 4412 >>>>>>>> > >(RPH) is the SIP mechanism to priority mark >>> SIP requests"? >>>>>>>> > > >>>>>>>> > >Further, I believe it is inappropriate to >>> prohibit endpoints >>>>>>>> > >from being able to set the esnet namespace. >>> I absolutely >>>>>>>> > >believe it will not be needed most of the >>> time, but I believe >>>>>>>> > >if someone does find a valid use for >>> endpoints to mark >>>>>>>> > >priority in SIP, this ID - once it has >>> become an RFC -- will >>>>>>>> > >have to be obsoleted with a new RFC saying the exact >>>>>> opposite. >>>>>>>> > > >>>>>>>> > >(color me confused ... over and over again) >>>>>>>> > > >>>>>>>> > >James >>>>>>>> > > >>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >>>>>>>> > >>Keith, please understand that the usage of RFC 4412 >>>>>> for GETS and >>>>>>>> for >>>>>>>> > >>the type of emergency call we discuss here is >>>>>> different. Just >>>>>>>> looking >>>>>>>> > >>at the header and the name of the namespace is a bit > >>>>>>> > >artificial. I hope >>>>>>>> > >>you understand that. >>>>>>>> > >> >>>>>>>> > >> >-----Original Message----- >>>>>>>> > >> >From: DRAGE, Keith (Keith) >>>>>>>> [mailto:drage@alcatel-lucent.com] >>>>>>>> > >> >Sent: 05 February, 2009 14:55 >>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >>>>>>>> Polk'; 'Tschofenig, >>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>> Meeting: Agenda (my >>>>>>>> >>>>>>>> > >> >mistake) >>>>>>>> > >> > >>>>>>>> > >> >Which is exactly what RFC 4412 specifies for all >>>>>> namespaces. >>>>>>>> > >> > >>>>>>>> > >> >regards >>>>>>>> > >> > >>>>>>>> > >> >Keith >>>>>>>> > >> > >>>>>>>> > >> >> -----Original Message----- >>>>>>>> > >> >> From: ecrit-bounces@ietf.org >>>>>> [mailto:ecrit-bounces@ietf.org] >>>>>>>> > >> >On Behalf >>>>>>>> > >> >> Of Brian Rosen >>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >>> Polk'; 'Tschofenig, >>>>>>>> > >Hannes (NSN >>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' >>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>>> Meeting: Agenda (my >>>>>>>> > >> >> mistake) >>>>>>>> > >> >> >>>>>>>> > >> >> The value is that in some networks >>> where priority for >>>>>>>> > >> >emergency calls >>>>>>>> > >> >> is appropriate, and appropriate >>> policing of marking is >>>>>>>> > >implemented, >>>>>>>> > >> >> emergency calls will receive resource priority. >>>>>>>> > >> >> >>>>>>>> > >> >> Not all networks would need policing. Some >>>>>> will. Policing >>>>>>>> could >>>>>>>> > >> >> be to Route header/R-URI content, but other >>>>>> criteria are >>>>>>>> possible. >>>>>>>> > >> >> >>>>>>>> > >> >> Not all networks will need resource priority >>>>>> for emergency >>>>>>>> calls. >>>>>>>> > >> >> Fine, ignore this marking/namespace. >>>>>>>> > >> >> >>>>>>>> > >> >> Brian >>>>>>>> > >> >> > -----Original Message----- >>>>>>>> > >> >> > From: Hannes Tschofenig >>>>>>>> [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >>>>>> Tschofenig, Hannes >>>>>>>> (NSN - >>>>>>>> > >> >> > FI/Espoo); 'ECRIT' >>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>> Meeting: Agenda (my >>>>>>>> > >> >> > mistake) >>>>>>>> > >> >> > >>>>>>>> > >> >> > I don't even see the value in permitting the >>>>>> endpoint todo >>>>>>>> the >>>>>>>> > >> >> > RPH marking. >>>>>>>> > >> >> > In addition to the security concerns >>> there is also the >>>>>>>> > >> >problem that >>>>>>>> > >> >> > there are more options to implement without >>>>>> an additional >>>>>>>> value. >>>>>>>> > >> >> > >>>>>>>> > >> >> > >-----Original Message----- >>>>>>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 >>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >>>>>> 'Tschofenig, >>>>>>>> > >> >> Hannes (NSN - >>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' >>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >>> Interim Meeting: >>>>>>>> Agenda (my >>>>>>>> > >> >> > mistake) >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >Hannes >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >This matches my understanding >>> precisely. We wish to >>>>>>>> > >> >> permit endpoints >>>>>>>> > >> >> > >to mark. We do not require it, and >>> don't necessarily >>>>>>>> expect it >>>>>>>> > >> >> > >in many (even >>>>>>>> > >> >> > >most) cases. We don't wish to see the >>>>>> document prohibit >>>>>>>> it. >>>>>>>> > >> >> > >We all seem to agree it has value within the > >>>>> Emergency >>>>>>>> > >> >Services IP >>>>>>>> > >> >> > >Networks. >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >Brian >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >> -----Original Message----- >>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org >>>>>>>> [mailto:ecrit-bounces@ietf.org] >>>>>>>> > >> >> > >On Behalf >>>>>>>> > >> >> > >> Of James M. Polk >>>>>>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >>> Hannes (NSN - >>>>>>>> > >> >> FI/Espoo); 'ECRIT' >>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>>> Meeting: >>>>>>>> > >Agenda (my >>>>>>>> > >> >> > >> mistake) >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >>> Tschofenig wrote: >>>>>>>> > >> >> > >> > > James wrote: >>>>>>>> > >> >> > >> > >> you are the _lone_ voice not >>>>>> supporting this ID, >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> >Listening to the audio recording of past >>>>>> meetings I >>>>>>>> have to >>>>>>>> > >> >> > >say that >>>>>>>> > >> >> > >> >I >>>>>>>> > >> >> > >> was >>>>>>>> > >> >> > >> >not the only persons raising >>> concerns about the >>>>>>>> document. >>>>>>>> > >> >> > >> >That was probably the reason why you >>>>>> agreed to limit >>>>>>>> the >>>>>>>> > >> >> > >scope of the >>>>>>>> > >> >> > >> >document (which you didn't later do) to >>>>>> get folks to >>>>>>>> agree >>>>>>>> > >> >> > >to make it >>>>>>>> > >> >> > >> a WG >>>>>>>> > >> >> > >> >item. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> re-listen to the audio please >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> Ted's concerns were consistent with most >>>>>>>> (all?) other >>>>>>>> > >> >> concerns -- >>>>>>>> > >> >> > >> which were based on the premise of whether >>>>>> or not the >>>>>>>> > >> >> UAC should be >>>>>>>> > >> >> > >> trusted to initiate the marking on the >>>>>> INVITE. The >>>>>>>> most >>>>>>>> > >> >> > >> recent version has backed off this >>> to a "can" -- >>>>>>>> meaning not >>>>>>>> > >> >prohibited >>>>>>>> > >> >> > >> (i.e., no 2119 text). I also backed off >>>>>> the text in >>>>>>>> the >>>>>>>> > >> >> SP domain >>>>>>>> > >> >> > >> part to "can", such that there is >>> no 2119 text >>>>>>>> > >> >mandating or even >>>>>>>> > >> >> > >> recommending its usage there. I also do >>>>>> not prohibit >>>>>>>> its >>>>>>>> > >> >> > >use, based on >>>>>>>> > >> >> > >> local policy. Keith has come forward with >>>>>> the specific >>>>>>>> >>>>>>>> > >> >> > >> request that non-ESInet networks be >>>>>> allowed to mark and >>>>>>>> pay >>>>>>>> > >> >attention to >>>>>>>> > >> >> > >> this priority indication -- with IMS as >>>>>> the specific >>>>>>>> example >>>>>>>> > >> >> > >> he wishes to have this valid for. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> Where there is no disagreement, save for >>>>>> your recent >>>>>>>> > >> >> > >pushback - is in >>>>>>>> > >> >> > >> the ESInet, which is where Brian >>> has requested it's >>>>>>>> > >> >> > >definition in the >>>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >>>>>> chair within >>>>>>>> > >> >> NENA, and if >>>>>>>> > >> >> > >> he asks for it, are you going to say you >>>>>> know better >>>>>>>> than he? >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >Btw, I not disagreeing with the document >>>>>> as such. I >>>>>>>> > >> >just want to >>>>>>>> > >> >> > the >>>>>>>> > >> >> > >> scope >>>>>>>> > >> >> > >> >to change. The usage of RPH >>> within the emergency >>>>>>>> > >> >> services network >>>>>>>> > >> >> > is >>>>>>>> > >> >> > >> fine >>>>>>>> > >> >> > >> >for me. I may get convinced to start the > >>>>> RPH marking >>>>>>>> from >>>>>>>> > >> >> > >the the VSP >>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy about the >>>>>> end host >>>>>>>> doing >>>>>>>> > >> >> > >the marking. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> please read what I wrote above, and then >>>>>> re-read the >>>>>>>> > >> >most recent >>>>>>>> > >> >> > >> version of the ID. I don't have endpoints >>>>>> that SHOULD >>>>>>>> or >>>>>>>> > >> >> MUST mark >>>>>>>> > >> >> > >> anything wrt RPH. I also don't want to >>>>>> prohibit it, >>>>>>>> > >> >> because there >>>>>>>> > >> >> > >> might be cases (that I don't know >>> of) of valid uses >>>>>>>> > >> >> under certain >>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear >>>>>> that there are 3 >>>>>>>> > >> >> networking >>>>>>>> > >> >> > >> parts to consider >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> #1 - from the endpoint >>>>>>>> > >> >> > >> #2 - within the VSP >>>>>>>> > >> >> > >> #3 - within the ESInet >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> the most recent ID version has "can" for >>>>>> #s 1 and 2, >>>>>>>> and >>>>>>>> > >> >> > >2119 language >>>>>>>> > >> >> > >> offering those supporting this >>>>>> specification will have >>>>>>>> RPH >>>>>>>> > >> >> > >> adherence within #3 (the ESInet). >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> What other scope changes do you want, >>>>>> because I haven't >>>>>>>> > >> >> heard them. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> I only heard you claim in email during the >>>>>> last IETF >>>>>>>> and in >>>>>>>> > >> >> > >the ECRIT >>>>>>>> > >> >> > >> session that RPH should not be >>> used for priority >>>>>>>> marking >>>>>>>> > >> >> requests. >>>>>>>> > >> >> > >> This is something Keith (SIP WG >>> chair) voiced his >>>>>>>> opposition >>>>>>>> > >> >> > >> to your views regarding creating a second >>>>>> means for SIP >>>>>>>> to >>>>>>>> > >> >priority >>>>>>>> > >> >> > >> mark request "when SIP already has one >>>>>> interoperable >>>>>>>> way to >>>>>>>> > >> >> > >> accomplish this... it's call the RP header >>>>>> mechanism". >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >I don't see advantages -- only >>> disadvantages. >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> >Ciao >>>>>>>> > >> >> > >> >Hannes >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >>> _______________________________________________ >>>>>>>> > >> >> > >> Ecrit mailing list >>>>>>>> > >> >> > >> Ecrit@ietf.org >>>>>>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> > >> >> > > >>>>>>>> > >> >> >>>>>>>> > >> >> _______________________________________________ >>>>>>>> > >> >> Ecrit mailing list >>>>>>>> > >> >> Ecrit@ietf.org >>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> > >> >> >>>>>>>> > >> > >>>>>>>> > > >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > Ecrit mailing list >>>>>>>> > Ecrit@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> ------------------------------------------------------------------------------------------------ > > This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ------------------------------------------------------------------------------------------------ >> [mf2] >> >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822B73A6C99 for ; Fri, 6 Feb 2009 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EuuXmKTeZSl for ; Fri, 6 Feb 2009 13:45:31 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 984963A6C98 for ; Fri, 6 Feb 2009 13:45:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="244561666" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2009 21:45:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n16LjYiP012326; Fri, 6 Feb 2009 13:45:34 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n16LjYdk018704; Fri, 6 Feb 2009 21:45:34 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); Fri, 6 Feb 2009 13:45:34 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 13:45:33 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 15:45:31 -0600 To: "Winterbottom, James" , "Hannes Tschofenig" , "Brian Rosen" , "Henning Schulzrinne" From: "James M. Polk" In-Reply-To: References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 21:45:33.0083 (UTC) FILETIME=[3CAE26B0:01C988A4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=39306; t=1233956734; x=1234820734; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=rpZz1nwFoCX2w4go9/8q0n6vY+EknWVMTPU8wXBfK6s=; b=TMtJQZYIEbTZooafjPZGBq68X18bK/bjoCWTFZzwHyCVdNhxvPaC5eDBPA 83sFTyv07UNYUT62pZk3t4xvDKTnp7yZd63nqIxHbQwzOf26+NsybWpX0vlP Sn3d9XnR3O; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 21:45:34 -0000 At 02:01 PM 2/6/2009, Winterbottom, James wrote: >Hi All, > >I have followed thi thread with some interest and I struggling to >see a use case for the >providing RPH for emergency calls from the end-point. ok, let's address this concern only for a minute. If there is no use-case you can think of (for endpoints insertion of RP namespace esnet), does that mean this RFC to-be has to prevent (i.e., MUST NOT) endpoints from being allowed to insert esnet? That means, you feel and believe, you know about all customer requirements everywhere, doesn't it? I'm not kidding or being snide here. Remember, this is a Standards Track doc for implementers, allowing them the idea that some future specification MAY allow endpoints to insert the RP header from endpoints gives them the ability to adjust their code to that possibility. There is the (good?) chance that at least one customer (somewhere) of one or more vendors has this as a requirement _now_, but we haven't heard about it yet. Stating in this to-be RFC that endpoints are forbidden from inserting an RP header would prevent them from implementing/satisfying their customer requirement while still supporting this specification. Remember, this RFC to-be DOES NOT say anything about endpoints MUST or even SHOULD implement the "esnet" RP namespace in order to be compliant with this spec. It merely says MAY, which means "some future spec MAY recommend or mandate it". I agree with Brian that robust security considerations stating that endpoint implementations need to very careful about configuring this capability needs to be written, and I will commit to writing that text in the next rev of the doc. James >The reference-model call in ECRIT, for better or worse, is for all >calls to go back through a home-VSP. >We placed quite a lot of emphasis, largely for traffing reasons, for >the VSP to be able to verify that >a call is in fact an emergency call. This is done by the proxy >taking the inband location, doing a LoST >query with the provided URN, and verifying that the resulting >destination URI is the same as the destination >URI provide in the SIP INVITE. My understanding was that VSPs would >always do this check so they could >tell if they could bill for the call or not, and because the VSP can >be use that the call is an emergency call >it can apply any special priorities that may be applicable. This >obviates the need for RPH from the end-point >to the network. > >This leaves us with the argument of "it doesn't hurt to it", which >is not a good reason to write a specification. >It was intimated on the geopriv mailing list last year that great >pains had been taken to keep SIP with in the >MTU limits of UDP over Ethernet >(http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html). Assuming >that this is the case, perhaps there is harm in including >information that we know will be ignored. > >Cheers >James > > > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >Sent: Fri 2/6/2009 12:33 PM >To: 'Brian Rosen'; 'Henning Schulzrinne' >Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >Subject: Re: [Ecrit] RPH > >To the story short here is the code for the proxy: > >--------------------- > >IF emergency call was recognized THEN > execute emergency call specific procedures (priority queuing, >preemption, fetch location, determine routing, do funny QoS things & co) >ELSE > normal call handling procedures. > >--------------------- > >If you can make this differentiation between an emergency call and a regular >call then you can also do everything that is necessary for emergency call >handling. > >Brian + Keith: Please tell me that we cannot do the above with our currently >specified mechanisms. > >Ciao >Hannes > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: 06 February, 2009 17:49 > >To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >Subject: RE: [Ecrit] RPH > > > >I agree that not all networks will permit (or pay attention > >to) a priority request from an end device. > > > >No one has asked for that. > > > >The namespace request has several uses, one of which is within > >an emergency services IP network, one of which is between > >elements within a public network controlled by the operator, > >and one of which is an endpoint request for resource priority. > > > >Those of us requesting this work proceed are happy if the > >endpoint part is simply left as possible (MAY), and, speaking > >for myself, having the draft discuss the security implications > >of endpoint marking is reasonable. > > > >Having discussed this issue with an implementation team who > >worked on MLPP systems, I am confident I know what I'm talking > >about, but YMMV. The fact that you could, if you wanted to, > >give resource priority to a call you decided, however you > >decided, was an emergency call is an implementation decision, > >and not subject to standardization. > > > >RPH is the IETF standard way for one entity to request > >resource priority of another entity in a SIP system. We're > >asking for a namespace to use that within the domain of > >emergency calls. That is, I think, a VERY reasonable request. > > > >Brian > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Friday, February 06, 2009 10:33 AM > >> To: Hannes Tschofenig > >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >> Subject: Re: [Ecrit] RPH > >> > >> To chime in here: > >> > >> I don't think it's productive to simply state that 4412 > >doesn't worry > >> about authorization, so we shouldn't either (simplifying a bit). > >> Authorization was discussed repeatedly, and the general > >assumption was > >> that there were two conditions: Either the user invoking resource- > >> priority was well known and had a set of permissions that could be > >> checked in real time or there are ways to deal with abuse after the > >> fact in ways that deter abuse (the court-martial kind of thing in a > >> military context). > >> > >> The RFC 4412 security consideration (11.2) call this out in pretty > >> strong language: > >> > >> Prioritized access to network and end-system resources imposes > >> particularly stringent requirements on authentication and > >> authorization mechanisms, since access to prioritized > >resources may > >> impact overall system stability and performance and not > >just result > >> in theft of, say, a single phone call. > >> Thus, the question is whether we have such strong authentication in > >> emergency calling. In some cases, such as residential fixed line > >> deployments where ISP = VSP, we're probably pretty close, in others, > >> such as prepaid cell phones or hot spots or VSP-only providers, we > >> aren't. > >> > >> The other point that I think Hannes is making is that the > >information > >> is either redundant or dangerous. If a processing element recognizes > >> the call as being an emergency call, it can apply whatever treatment > >> it deems appropriate and doesn't need additional information. If it > >> doesn't or can't, using just the RPH can be rather dangerous unless > >> that element can be reasonably certain that there is strong > >> authentication and recourse. > >> > >> I don't buy the argument that somehow finding the RPH is faster than > >> just looking for the identifier. Thus, given that the information is > >> either redundant or dangerous, I fail to see the advantage. > >> > >> Henning > >> > >> > >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > >> > >> > Don't get hung up on the details. There are ways to optimize it. > >> > That was > >> > not the point of the code example. > >> > > >> > The problem that my pseudo code should have shown you is that you > >> > * don't gain anything with RPH marking for the emergency call case > >> > from the SIP UA towards the outbound proxy since the functionality > >> > is already provide otherwise. How often does the proxy need to get > >> > told that this is an emergency call todo whatever emergency call > >> > handling procedures are necessary? > >> > * you only introduce fraud problems (if you are not > >careful and you > >> > understand the security stuff well enough) > >> > > >> > If you can point me to people who implement the RPH emergency call > >> > case please do so. I would love to talk to them. > >> > > >> > Ciao > >> > Hannes > >> > > >> > PS: You need to parse incoming messages to some extend so that you > >> > know what it contains :-) Only looking for the emergency > >RPH header > >> > (and not for the Service URN/dial > >> > string) would exactly be the DoS/fraud attack I am worried about. > >> > That's the thing Henning was worried about (go and listen to the > >> > past meeting minutes). > >> > > >> > > >> >> Hannes > >> >> > >> >> You need to talk to people who really implement this kind > >of thing. > >> >> You are way off. > >> >> > >> >> When you implement a resource priority system, the point of doing > >> >> that is to look though the queue of work and pick out the > >ones with > >> >> priority, handling them first. You don't do all the parsing, you > >> >> don't do a lot of decision tree. > >> >> > >> >> Typically: > >> >> Check for DoS things, like too big messages, etc Do a quick scan > >> >> for the RPH message header If found: > >> >> Parse the message > >> >> Determine validity > >> >> Determine priority > >> >> Queue on the correct work queue > >> >> > >> >> The first two actions have to be very fast. Anyone who builds a > >> >> SIP thingie will tell you that parsing is one of the big cycle > >> >> consumers: if you have to parse every message BEFORE you > >determine > >> >> priority, you can't give much resource priority. > >> >> Once you get the whole message parsed, you might as well finish > >> >> working on it, because you've done so much of the work. > >> >> OTHOH, finding the end-of-message delimiter and doing a quick > >> >> string search for RPH is fast. If you are doing > >priority, you need > >> >> to keep all the priority processing pretty uniform, and pretty > >> >> simple, or you tend to spend too much time futzing around > >figuring > >> >> out what to do. You put all the priority related stuff together, > >> >> and use as much common code as possible. > >> >> > >> >> Brian > >> >> > >> >>> -----Original Message----- > >> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> On Behalf > >> >>> Of Hannes Tschofenig > >> >>> Sent: Friday, February 06, 2009 8:41 AM > >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' > >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >> >>> bounces@ietf.org > >> >>> Subject: [Ecrit] RPH > >> >>> > >> >>> Over lunch I was also thinking how an outbound proxy would > >> implement > >> >>> some of the emergency procedures. Here are some thoughts: > >> >>> > >> >>> --------------------------------------------------- > >> >>> > >> >>> // Process incoming message > >> >>> Parse(msg); > >> >>> > >> >>> // SIP INVITE without Service URN > >> >>> // legacy devices > >> >>> If (recognize-dialstring(msg)==TRUE) { // we got an emergency > >> >>> call going on emergency=TRUE; if (dialstring(msg) == 911) > >> >>> serviceURN=urn:service:sos; } else if > >> >>> (recognize-serviceURN(msg)==TRUE) { // oh. A updated > >device that > >> >>> has a service URN attached to the > >> call > >> >>> serviceURN=retrieve_ServiceURN(msg); > >> >>> emergency=TRUE; > >> >>> } else { > >> >>> // standard SIP message > >> >>> // regular processing > >> >>> process(msg); > >> >>> emergency=FALSE; > >> >>> } > >> >>> > >> >>> If (emergency == TRUE) { > >> >>> // make sure that the emergency call does not get > >dropped on the > >> >>> floor > >> >>> // skip authorization failures > >> >>> // give the call a special treatment > >> >>> lots-of-code-here(); > >> >>> > >> >>> // trigger all the QoS signaling you have in the > >network to make > >> >>> James happy > >> >>> trigger-qos(); > >> >>> > >> >>> // query location > >> >>> location=retrieve-location(); > >> >>> > >> >>> // determine next hop > >> >>> next-hop=lost(location, serviceURN) > >> >>> > >> >>> // attach RPH marking to outgoing msg to make James and > >> >> Keith happy > >> >>> msg=add(msg, RPH); > >> >>> > >> >>> send(msg, next-hop); > >> >>> } > >> >>> > >> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { > >> >>> // all the emergency related processing done already upfront > >> >>> // hence I log something. > >> >>> log(RPH_WAS_PRESENT_JUHU); > >> >>> } else if ((rph-present(msg) == TRUE) && (emergency == > >FALSE)) { > >> >>> // this is not an emergency call // this is something > >like GETS > >> >>> result=special-authorization-procedure(user); > >> >>> > >> >>> if (result == AUTHORIZED) { > >> >>> // do some priority & preemption thing here. > >> >>> // trigger all the QoS you have > >> >>> lots-of-code-here(); > >> >>> } else { > >> >>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // > >> >>> don't need todo any RPH processing // this includes the case > >> >>> where the call was an emergency call but the RPH > >> >>> > >> >>> // marking was not there. > >> >>> nothing(); > >> >>> } > >> >>> > >> >>> --------------------------------------------------- > >> >>> > >> >>> > >> >>> Ciao > >> >>> Hannes > >> >>> > >> >>>> -----Original Message----- > >> >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >>>> Behalf Of Hannes Tschofenig > >> >>>> Sent: 06 February, 2009 15:07 > >> >>>> To: 'Janet P Gunn' > >> >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > >> >>> FI/Espoo) > >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > >> >>>> > >> >>>> Who would define something that could prevent DoS problems? > >> >>>> > >> >>>> ________________________________ > >> >>>> > >> >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >> >>>> Sent: 06 February, 2009 14:11 > >> >>>> To: Hannes Tschofenig > >> >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >> >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); > >> 'James > >> >>>> M. Polk' > >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim > >Meeting: Agenda (RPH) > >> >>>> > >> >>>> > >> >>>> > >> >>>> But there is nothing IN RFC4412 that specifically > >> >> addresses how to > >> >>>> prevent any particular namespace being used for DoS. Anyone/any > >> UA > >> >>>> can ATTEMPT to invoke priority treatment by attaching RPH. For > >> all > >> >>>> of the 4412 namespaces, as with the new proposed namespace, the > >> >>>> mechanisms for preventing DoS are not specified in the > >> >> document that > >> >>>> defines the namespace. > >> >>>> They are/will be specified elsewhere. > >> >>>> > >> >>>> Janet > >> >>>> > >> >>>> This is a PRIVATE message. If you are not the intended > >> >> recipient, > >> >>>> please delete without copying and kindly advise us by e-mail of > >> the > >> >>>> mistake in delivery. > >> >>>> NOTE: Regardless of content, this e-mail shall not > >> >> operate to bind > >> >>>> CSC to any order or other contract unless pursuant to explicit > >> >>>> written agreement or government initiative expressly permitting > >> the > >> >>>> use of e-mail for such purpose. > >> >>>> > >> >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > >> >>>> > >> >>>> > Hi James, > >> >>>> > > >> >>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >> >> documents. What I > >> >>>> would > >> >>>> > like to point out is that there is more than just a > >> >> header and > >> >>>> values within > >> >>>> > the header that have to be considered in order to > >> >> make a judgement > >> >>>> of what > >> >>>> > is appropriate and what isn't. There is an > >> >> architectural question > >> >>>> and > >> >>>> > whether the environment we are using the stuff is > >> >> indeed providing > >> >>>> the > >> >>>> > properties you need for the solution to be > >appropriate. > >> >>>> > > >> >>>> > Let me describe in more detail what I meant (and > >> >> please correct me > >> >>>> if I am > >> >>>> > wrong). > >> >>>> > > >> >>>> > Getting priority for SIP requests when using a GETS > >> >> alike scenario > >> >>>> means > >> >>>> > that the entity that issues the request is specially > >> >> authorized > >> >>>> since > >> >>>> > otherwise you introduce a nice denial of > >service attack. This > >> >>>> authorization > >> >>>> > is tied to the entity that makes the request. For > >> >> example, the > >> >>>> person is > >> >>>> > working for the government and has special rights. > >> >>>> James Bond as a (not so) > >> >>>> > secret agent might have these rights. > >> >>>> > > >> >>>> > The emergency services case > >(citizen-to-authority) is a bit > >> >>>> different as > >> >>>> > there aren't really special rights with respect to > >> >> authorization > >> >>>> tied to > >> >>>> > individuals. Instead, the fact that something is an > >> >> emergency is > >> >>>> purely a > >> >>>> > judgement of the human that dials a special number. > >> >>>> To deal with fraud, we > >> >>>> > discussed in the group on what we can actually do to > >> >> ensure that > >> >>>> end users > >> >>>> > do not bypass security procedures (such as > >> >> authorization checks, > >> >>>> charging > >> >>>> > and so on). Part of this investigation was > >the publication of > >> >>>> > http://www.ietf.org/rfc/rfc5069.txt that also > >describes this > >> >>>> issue. > >> >>>> > > >> >>>> > So, imagine the implementation of a SIP proxy (and we > >> >> implemented > >> >>>> that > >> >>>> > stuff) that receives a call that contains a Service > >> >> URN. The code > >> >>>> branches > >> >>>> > into a special mode where everything is done > >so that the call > >> >>>> receives > >> >>>> > appropriate treatment and does not get dropped on the > >> >> floor. The > >> >>>> way how the > >> >>>> > Service URN is placed in the message ensures that the > >> >> call cannot > >> >>>> go to my > >> >>>> > friend (instead of the PSAP) unless the end host ran > >> >> LoST already. > >> >>>> In the > >> >>>> > latter case, we discussed this also on the list for a > >> >> while and > >> >>>> Richard even > >> >>>> > wrote a draft about it in the context of the > >location hiding > >> >>>> topic, we said > >> >>>> > that the proxy would have to run LoST if he > >cares about a > >> >>>> potential > >> >>>> > fraudulent usage. > >> >>>> > > >> >>>> > So, what do we need todo in order to provide > >secure RFC 4412 > >> >>>> functionality > >> >>>> > in our context? > >> >>>> > > >> >>>> > Do you think that the current text in > >> >>>> > > >> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >>>> gency-rph-nam > >> >>>> > espace-00.txt reflects any of the > >above-described issues: > >> >>>> > " > >> >>>> > The Security considerations that apply to RFC 4412 > >> >>>> [RFC4412] > >> >>>> apply > >> >>>> > here. This document introduces no new security > >> >>>> issues relative > >> >>>> to > >> >>>> > RFC 4412. > >> >>>> > " > >> >>>> > > >> >>>> > From various discussions in GEOPRIV I recall > >that you are > >> >>>> super-sensitive > >> >>>> > regarding security and privacy. For some reasons you > >> >> don't seem to > >> >>>> have the > >> >>>> > same concerns here. I would like to > >understand your reasoning. > >> >>>> > > >> >>>> > Please also do me another favor: Don't always say > >> >> that I don't > >> >>>> understand > >> >>>> > the subject. Even if that would be the case it isn't > >> >> particular > >> >>>> fair given > >> >>>> > that different folks had to educate you on other > >> >> topics in the > >> >>>> past as well. > >> >>>> > Additionally, if you listen to the audio recordings > >> >> then you will > >> >>>> notice > >> >>>> > that Henning, Ted, and Jon do not seem to understand > >> >> the issue > >> >>>> either as > >> >>>> > they have raised similar issues during the > >F2F meetings. > >> >>>> > > >> >>>> > Ciao > >> >>>> > Hannes > >> >>>> > > >> >>>> > > >> >>>> > >Hannes - I believe it is you who do not understand > >> >> RFC 4412 -- > >> >>>> > >and many of us are trying to get that > >through to you, but you > >> >>>> > >don't seem to want to listen/read. > >> >>>> > > > >> >>>> > >RFC 4412 is *for* priority marking SIP requests, > >> >>>> > > > >> >>>> > >One use is GETS. > >> >>>> > > > >> >>>> > >One use is MLPP. > >> >>>> > > > >> >>>> > >These examples are in RFC 4412 because there > >were specific > >> >>>> > >namespaces being created for the IANA section of > >> >> that document. > >> >>>> > > > >> >>>> > >Reading the whole document, you will see > >that RPH can be > >> >>>> > >specified for other uses than GETS or MLPP > >specifically. > >> >>>> > > > >> >>>> > >I knew when I wrote RFC 4412 that one day we > >would specify a > >> >>>> > >namespace for ECRIT (the "esnet" namespace > >now) -- but I also > >> >>>> > >knew it was premature for RFC 4412 to > >incorporate that > >> >>>> > >namespace, that a future doc to RFC 4412 > >would have to be > >> >>>> > >written to do this. Brian and I talked about > >this at the > >> >>>> > >original NENA meeting that created the IP WGs there > >> >> (in August > >> >>>> > >of 03). We both agreed we should wait until it was > >> >>>> > >appropriate to the work in the IETF to > >submit this document > >> >>>> > >that is now > >> >>>> > > >> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >>>> > >gency-rph-namespace-00.txt > >> >>>> > > > >> >>>> > >Yet, you seem to want to use some additional > >mechanism to > >> >>>> > >indicate priority of a call in SIP. That > >means you want to > >> >>>> > >introduce a second way to accomplish this in SIP. > >> >>>> Why do you > >> >>>> > >want to promote a separate way to do something SIP > >> >> has already > >> >>>> > >defined? That will cause interoperability issues and > >> >> we both know > >> >>>> that. > >> >>>> > > > >> >>>> > >You've said to me (and others) that you > >believe RPH is just > >> >>>> > >another way to accomplish what sos or a URI can > >> >> indicate - and > >> >>>> > >you're wrong. Your way would be > >_the_second_way_to_do_it, > >> >>>> > >because SIP already considers RPH to be > >*the*way* to priority > >> >>>> > >mark SIP requests. > >> >>>> > > > >> >>>> > >If you don't believe me (no comment), then > >why do you not > >> >>>> > >believe the SIP WG chair (who knows more > >about SIP than both > >> >>>> > >of us) - who, on this thread, has again said > >to you "RFC 4412 > >> >>>> > >(RPH) is the SIP mechanism to priority mark > >SIP requests"? > >> >>>> > > > >> >>>> > >Further, I believe it is inappropriate to > >prohibit endpoints > >> >>>> > >from being able to set the esnet namespace. > >I absolutely > >> >>>> > >believe it will not be needed most of the > >time, but I believe > >> >>>> > >if someone does find a valid use for > >endpoints to mark > >> >>>> > >priority in SIP, this ID - once it has > >become an RFC -- will > >> >>>> > >have to be obsoleted with a new RFC saying the exact > >> >> opposite. > >> >>>> > > > >> >>>> > >(color me confused ... over and over again) > >> >>>> > > > >> >>>> > >James > >> >>>> > > > >> >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >> >>>> > >>Keith, please understand that the usage of RFC 4412 > >> >> for GETS and > >> >>>> for > >> >>>> > >>the type of emergency call we discuss here is > >> >> different. Just > >> >>>> looking > >> >>>> > >>at the header and the name of the namespace is a bit > >> >>>> > >artificial. I hope > >> >>>> > >>you understand that. > >> >>>> > >> > >> >>>> > >> >-----Original Message----- > >> >>>> > >> >From: DRAGE, Keith (Keith) > >> >>>> [mailto:drage@alcatel-lucent.com] > >> >>>> > >> >Sent: 05 February, 2009 14:55 > >> >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >> >>>> Polk'; 'Tschofenig, > >> >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: Agenda (my > >> >>>> > >> >>>> > >> >mistake) > >> >>>> > >> > > >> >>>> > >> >Which is exactly what RFC 4412 specifies for all > >> >> namespaces. > >> >>>> > >> > > >> >>>> > >> >regards > >> >>>> > >> > > >> >>>> > >> >Keith > >> >>>> > >> > > >> >>>> > >> >> -----Original Message----- > >> >>>> > >> >> From: ecrit-bounces@ietf.org > >> >> [mailto:ecrit-bounces@ietf.org] > >> >>>> > >> >On Behalf > >> >>>> > >> >> Of Brian Rosen > >> >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. > >Polk'; 'Tschofenig, > >> >>>> > >Hannes (NSN > >> >>>> > >> >> - FI/Espoo)'; 'ECRIT' > >> >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: Agenda (my > >> >>>> > >> >> mistake) > >> >>>> > >> >> > >> >>>> > >> >> The value is that in some networks > >where priority for > >> >>>> > >> >emergency calls > >> >>>> > >> >> is appropriate, and appropriate > >policing of marking is > >> >>>> > >implemented, > >> >>>> > >> >> emergency calls will receive resource priority. > >> >>>> > >> >> > >> >>>> > >> >> Not all networks would need policing. Some > >> >> will. Policing > >> >>>> could > >> >>>> > >> >> be to Route header/R-URI content, but other > >> >> criteria are > >> >>>> possible. > >> >>>> > >> >> > >> >>>> > >> >> Not all networks will need resource priority > >> >> for emergency > >> >>>> calls. > >> >>>> > >> >> Fine, ignore this marking/namespace. > >> >>>> > >> >> > >> >>>> > >> >> Brian > >> >>>> > >> >> > -----Original Message----- > >> >>>> > >> >> > From: Hannes Tschofenig > >> >>>> [mailto:Hannes.Tschofenig@gmx.net] > >> >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >> >> Tschofenig, Hannes > >> >>>> (NSN - > >> >>>> > >> >> > FI/Espoo); 'ECRIT' > >> >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: Agenda (my > >> >>>> > >> >> > mistake) > >> >>>> > >> >> > > >> >>>> > >> >> > I don't even see the value in permitting the > >> >> endpoint todo > >> >>>> the > >> >>>> > >> >> > RPH marking. > >> >>>> > >> >> > In addition to the security concerns > >there is also the > >> >>>> > >> >problem that > >> >>>> > >> >> > there are more options to implement without > >> >> an additional > >> >>>> value. > >> >>>> > >> >> > > >> >>>> > >> >> > >-----Original Message----- > >> >>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >>>> > >> >> > >Sent: 05 February, 2009 00:03 > >> >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >> >> 'Tschofenig, > >> >>>> > >> >> Hannes (NSN - > >> >>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >> >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual > >Interim Meeting: > >> >>>> Agenda (my > >> >>>> > >> >> > mistake) > >> >>>> > >> >> > > > >> >>>> > >> >> > >Hannes > >> >>>> > >> >> > > > >> >>>> > >> >> > >This matches my understanding > >precisely. We wish to > >> >>>> > >> >> permit endpoints > >> >>>> > >> >> > >to mark. We do not require it, and > >don't necessarily > >> >>>> expect it > >> >>>> > >> >> > >in many (even > >> >>>> > >> >> > >most) cases. We don't wish to see the > >> >> document prohibit > >> >>>> it. > >> >>>> > >> >> > >We all seem to agree it has value within the > >> >> Emergency > >> >>>> > >> >Services IP > >> >>>> > >> >> > >Networks. > >> >>>> > >> >> > > > >> >>>> > >> >> > >Brian > >> >>>> > >> >> > > > >> >>>> > >> >> > >> -----Original Message----- > >> >>>> > >> >> > >> From: ecrit-bounces@ietf.org > >> >>>> [mailto:ecrit-bounces@ietf.org] > >> >>>> > >> >> > >On Behalf > >> >>>> > >> >> > >> Of James M. Polk > >> >>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, > >Hannes (NSN - > >> >>>> > >> >> FI/Espoo); 'ECRIT' > >> >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: > >> >>>> > >Agenda (my > >> >>>> > >> >> > >> mistake) > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes > >Tschofenig wrote: > >> >>>> > >> >> > >> > > James wrote: > >> >>>> > >> >> > >> > >> you are the _lone_ voice not > >> >> supporting this ID, > >> >>>> > >> >> > >> > > >> >>>> > >> >> > >> >Listening to the audio recording of past > >> >> meetings I > >> >>>> have to > >> >>>> > >> >> > >say that > >> >>>> > >> >> > >> >I > >> >>>> > >> >> > >> was > >> >>>> > >> >> > >> >not the only persons raising > >concerns about the > >> >>>> document. > >> >>>> > >> >> > >> >That was probably the reason why you > >> >> agreed to limit > >> >>>> the > >> >>>> > >> >> > >scope of the > >> >>>> > >> >> > >> >document (which you didn't later do) to > >> >> get folks to > >> >>>> agree > >> >>>> > >> >> > >to make it > >> >>>> > >> >> > >> a WG > >> >>>> > >> >> > >> >item. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> re-listen to the audio please > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> Ted's concerns were consistent with most > >> >>>> (all?) other > >> >>>> > >> >> concerns -- > >> >>>> > >> >> > >> which were based on the premise of whether > >> >> or not the > >> >>>> > >> >> UAC should be > >> >>>> > >> >> > >> trusted to initiate the marking on the > >> >> INVITE. The > >> >>>> most > >> >>>> > >> >> > >> recent version has backed off this > >to a "can" -- > >> >>>> meaning not > >> >>>> > >> >prohibited > >> >>>> > >> >> > >> (i.e., no 2119 text). I also backed off > >> >> the text in > >> >>>> the > >> >>>> > >> >> SP domain > >> >>>> > >> >> > >> part to "can", such that there is > >no 2119 text > >> >>>> > >> >mandating or even > >> >>>> > >> >> > >> recommending its usage there. I also do > >> >> not prohibit > >> >>>> its > >> >>>> > >> >> > >use, based on > >> >>>> > >> >> > >> local policy. Keith has come forward with > >> >> the specific > >> >>>> > >> >>>> > >> >> > >> request that non-ESInet networks be > >> >> allowed to mark and > >> >>>> pay > >> >>>> > >> >attention to > >> >>>> > >> >> > >> this priority indication -- with IMS as > >> >> the specific > >> >>>> example > >> >>>> > >> >> > >> he wishes to have this valid for. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> Where there is no disagreement, save for > >> >> your recent > >> >>>> > >> >> > >pushback - is in > >> >>>> > >> >> > >> the ESInet, which is where Brian > >has requested it's > >> >>>> > >> >> > >definition in the > >> >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >> >> chair within > >> >>>> > >> >> NENA, and if > >> >>>> > >> >> > >> he asks for it, are you going to say you > >> >> know better > >> >>>> than he? > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> >Btw, I not disagreeing with the document > >> >> as such. I > >> >>>> > >> >just want to > >> >>>> > >> >> > the > >> >>>> > >> >> > >> scope > >> >>>> > >> >> > >> >to change. The usage of RPH > >within the emergency > >> >>>> > >> >> services network > >> >>>> > >> >> > is > >> >>>> > >> >> > >> fine > >> >>>> > >> >> > >> >for me. I may get convinced to start the > >> >> RPH marking > >> >>>> from > >> >>>> > >> >> > >the the VSP > >> >>>> > >> >> > >> >towards the PSAP. I feel uneasy about the > >> >> end host > >> >>>> doing > >> >>>> > >> >> > >the marking. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> please read what I wrote above, and then > >> >> re-read the > >> >>>> > >> >most recent > >> >>>> > >> >> > >> version of the ID. I don't have endpoints > >> >> that SHOULD > >> >>>> or > >> >>>> > >> >> MUST mark > >> >>>> > >> >> > >> anything wrt RPH. I also don't want to > >> >> prohibit it, > >> >>>> > >> >> because there > >> >>>> > >> >> > >> might be cases (that I don't know > >of) of valid uses > >> >>>> > >> >> under certain > >> >>>> > >> >> > >> circumstances. Figure 1 is very clear > >> >> that there are 3 > >> >>>> > >> >> networking > >> >>>> > >> >> > >> parts to consider > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> #1 - from the endpoint > >> >>>> > >> >> > >> #2 - within the VSP > >> >>>> > >> >> > >> #3 - within the ESInet > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> the most recent ID version has "can" for > >> >> #s 1 and 2, > >> >>>> and > >> >>>> > >> >> > >2119 language > >> >>>> > >> >> > >> offering those supporting this > >> >> specification will have > >> >>>> RPH > >> >>>> > >> >> > >> adherence within #3 (the ESInet). > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> What other scope changes do you want, > >> >> because I haven't > >> >>>> > >> >> heard them. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> I only heard you claim in email during the > >> >> last IETF > >> >>>> and in > >> >>>> > >> >> > >the ECRIT > >> >>>> > >> >> > >> session that RPH should not be > >used for priority > >> >>>> marking > >> >>>> > >> >> requests. > >> >>>> > >> >> > >> This is something Keith (SIP WG > >chair) voiced his > >> >>>> opposition > >> >>>> > >> >> > >> to your views regarding creating a second > >> >> means for SIP > >> >>>> to > >> >>>> > >> >priority > >> >>>> > >> >> > >> mark request "when SIP already has one > >> >> interoperable > >> >>>> way to > >> >>>> > >> >> > >> accomplish this... it's call the RP header > >> >> mechanism". > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> >I don't see advantages -- only > >disadvantages. > >> >>>> > >> >> > >> > > >> >>>> > >> >> > >> >Ciao > >> >>>> > >> >> > >> >Hannes > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> > >_______________________________________________ > >> >>>> > >> >> > >> Ecrit mailing list > >> >>>> > >> >> > >> Ecrit@ietf.org > >> >>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >> > > > >> >>>> > >> >> > >> >>>> > >> >> _______________________________________________ > >> >>>> > >> >> Ecrit mailing list > >> >>>> > >> >> Ecrit@ietf.org > >> >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >> > >> >>>> > >> > > >> >>>> > > > >> >>>> > > >> >>>> > _______________________________________________ > >> >>>> > Ecrit mailing list > >> >>>> > Ecrit@ietf.org > >> >>>> > https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Ecrit mailing list > >> >>>> Ecrit@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >>> > >> >>> _______________________________________________ > >> >>> Ecrit mailing list > >> >>> Ecrit@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > >> > _______________________________________________ > >> > Ecrit mailing list > >> > Ecrit@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8B93A6BE7 for ; Fri, 6 Feb 2009 14:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrFIJHIDCMig for ; Fri, 6 Feb 2009 14:02:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7F8263A6B3A for ; Fri, 6 Feb 2009 14:02:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="244570757" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2009 22:02:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n16M2F8I020926; Fri, 6 Feb 2009 14:02:15 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n16M2CWr003346; Fri, 6 Feb 2009 22:02:15 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); Fri, 6 Feb 2009 14:02:05 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 14:02:04 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 16:02:03 -0600 To: "Hannes Tschofenig" From: "James M. Polk" In-Reply-To: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> <000701c9883c$59b095d0$49b5b70a@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 22:02:04.0218 (UTC) FILETIME=[8B7159A0:01C988A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15988; t=1233957735; x=1234821735; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20ECRIT=20Virtual=20Interim=20Meeting=3A= 20Agenda=20(RPH=20&=20GETS) |Sender:=20; bh=HJStnRQiVuDODg7u1VphD2K/NazdySUsYyry+cclws0=; b=kZXyEJwiuNDzcIa/WXUzyKJ0EXna7TmK+Rfw3695a/cEh/lubSTOEh2fqf KQAt5gaXkq+CTpTWZKDPXKLIx8zqRl1Rh5BWFVd0CpvaUz3HM8xsN7ppfxhy sFYu6A+Zkc; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:02:14 -0000 At 03:21 AM 2/6/2009, Hannes Tschofenig wrote: >Hi James, > >I have read RFC 4412 and also the GETS/MLPP IETF documents. What I would >like to point out is that there is more than just a header and values within >the header that have to be considered in order to make a judgement of what >is appropriate and what isn't. There is an architectural question and >whether the environment we are using the stuff is indeed providing the >properties you need for the solution to be appropriate. > >Let me describe in more detail what I meant (and please correct me if I am >wrong). > >Getting priority for SIP requests when using a GETS alike scenario means >that the entity that issues the request is specially authorized since >otherwise you introduce a nice denial of service attack. You are missing a step in GETS here. The endpoint, who sends the GETS set-up as an INVITE is not already authorized (not the device, not the user). In North America, there is a 10 digit GETS number that is dialed (that I won't give out right now on an open list) - and there literally is only 1 number available to dial for this service. Literally anyone can dial this number today in North America (no matter where the phone is - as long as it is in North America -- and I might be too limiting in that it is dialable from anywhere, because it is going to a North American destination). Once this number is dialed, it is answered by an authentication and authorization IVR. This IVR challenges each caller for their authentication passcode, and a password). Once this has been successfully entered, then call is NOW authorized to proceed towards its destination number - this step is only known to the authorizing system because the destination 10 digit number is NOT entered until after the authentication and authorization step has completed. The authorized caller is prompted with a new dial tone - in which they can enter any number on the planet and receive preferential treatment through as many carriers (in IP, it's SPs) that have implemented this GETS service (which is an SLA with the Department of Homeland Security now). Merely entering the GETS RP namespace is never intended, alone, to gain any preferential treatment -- other than towards this authentication & authorization IVR. I hope you can see that this is a completely separate type of service and implementation type than ECRIT based emergency calling will use. BTW - to your comment below about me not calling your name out when you are incorrect because I have been equally incorrect -- I'm not sure I've been spared as much as you think, given that many have called me out by name when they've felt I've been wrong over the years. >This authorization >is tied to the entity that makes the request. For example, the person is >working for the government and has special rights. James Bond as a (not so) >secret agent might have these rights. > >The emergency services case (citizen-to-authority) is a bit different as >there aren't really special rights with respect to authorization tied to >individuals. Instead, the fact that something is an emergency is purely a >judgement of the human that dials a special number. To deal with fraud, we >discussed in the group on what we can actually do to ensure that end users >do not bypass security procedures (such as authorization checks, charging >and so on). Part of this investigation was the publication of >http://www.ietf.org/rfc/rfc5069.txt that also describes this issue. > >So, imagine the implementation of a SIP proxy (and we implemented that >stuff) that receives a call that contains a Service URN. The code branches >into a special mode where everything is done so that the call receives >appropriate treatment and does not get dropped on the floor. The way how the >Service URN is placed in the message ensures that the call cannot go to my >friend (instead of the PSAP) unless the end host ran LoST already. In the >latter case, we discussed this also on the list for a while and Richard even >wrote a draft about it in the context of the location hiding topic, we said >that the proxy would have to run LoST if he cares about a potential >fraudulent usage. > >So, what do we need todo in order to provide secure RFC 4412 functionality >in our context? > >Do you think that the current text in >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-nam >espace-00.txt reflects any of the above-described issues: >" > The Security considerations that apply to RFC 4412 [RFC4412] apply > here. This document introduces no new security issues relative to > RFC 4412. >" > > From various discussions in GEOPRIV I recall that you are super-sensitive >regarding security and privacy. For some reasons you don't seem to have the >same concerns here. I would like to understand your reasoning. > >Please also do me another favor: Don't always say that I don't understand >the subject. Even if that would be the case it isn't particular fair given >that different folks had to educate you on other topics in the past as well. >Additionally, if you listen to the audio recordings then you will notice >that Henning, Ted, and Jon do not seem to understand the issue either as >they have raised similar issues during the F2F meetings. > >Ciao >Hannes > > > >Hannes - I believe it is you who do not understand RFC 4412 -- > >and many of us are trying to get that through to you, but you > >don't seem to want to listen/read. > > > >RFC 4412 is *for* priority marking SIP requests, > > > >One use is GETS. > > > >One use is MLPP. > > > >These examples are in RFC 4412 because there were specific > >namespaces being created for the IANA section of that document. > > > >Reading the whole document, you will see that RPH can be > >specified for other uses than GETS or MLPP specifically. > > > >I knew when I wrote RFC 4412 that one day we would specify a > >namespace for ECRIT (the "esnet" namespace now) -- but I also > >knew it was premature for RFC 4412 to incorporate that > >namespace, that a future doc to RFC 4412 would have to be > >written to do this. Brian and I talked about this at the > >original NENA meeting that created the IP WGs there (in August > >of 03). We both agreed we should wait until it was > >appropriate to the work in the IETF to submit this document > >that is now > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >gency-rph-namespace-00.txt > > > >Yet, you seem to want to use some additional mechanism to > >indicate priority of a call in SIP. That means you want to > >introduce a second way to accomplish this in SIP. Why do you > >want to promote a separate way to do something SIP has already > >defined? That will cause interoperability issues and we both know that. > > > >You've said to me (and others) that you believe RPH is just > >another way to accomplish what sos or a URI can indicate - and > >you're wrong. Your way would be _the_second_way_to_do_it, > >because SIP already considers RPH to be *the*way* to priority > >mark SIP requests. > > > >If you don't believe me (no comment), then why do you not > >believe the SIP WG chair (who knows more about SIP than both > >of us) - who, on this thread, has again said to you "RFC 4412 > >(RPH) is the SIP mechanism to priority mark SIP requests"? > > > >Further, I believe it is inappropriate to prohibit endpoints > >from being able to set the esnet namespace. I absolutely > >believe it will not be needed most of the time, but I believe > >if someone does find a valid use for endpoints to mark > >priority in SIP, this ID - once it has become an RFC -- will > >have to be obsoleted with a new RFC saying the exact opposite. > > > >(color me confused ... over and over again) > > > >James > > > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>Keith, please understand that the usage of RFC 4412 for GETS and for > >>the type of emergency call we discuss here is different. Just looking > >>at the header and the name of the namespace is a bit > >artificial. I hope > >>you understand that. > >> > >> >-----Original Message----- > >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> >Sent: 05 February, 2009 14:55 > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >mistake) > >> > > >> >Which is exactly what RFC 4412 specifies for all namespaces. > >> > > >> >regards > >> > > >> >Keith > >> > > >> >> -----Original Message----- > >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf > >> >> Of Brian Rosen > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >Hannes (NSN > >> >> - FI/Espoo)'; 'ECRIT' > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> mistake) > >> >> > >> >> The value is that in some networks where priority for > >> >emergency calls > >> >> is appropriate, and appropriate policing of marking is > >implemented, > >> >> emergency calls will receive resource priority. > >> >> > >> >> Not all networks would need policing. Some will. Policing could > >> >> be to Route header/R-URI content, but other criteria are possible. > >> >> > >> >> Not all networks will need resource priority for emergency calls. > >> >> Fine, ignore this marking/namespace. > >> >> > >> >> Brian > >> >> > -----Original Message----- > >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, Hannes (NSN - > >> >> > FI/Espoo); 'ECRIT' > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> > mistake) > >> >> > > >> >> > I don't even see the value in permitting the endpoint todo the > >> >> > RPH marking. > >> >> > In addition to the security concerns there is also the > >> >problem that > >> >> > there are more options to implement without an additional value. > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >> > >Sent: 05 February, 2009 00:03 > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> >> Hannes (NSN - > >> >> > >FI/Espoo)'; 'ECRIT' > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> > mistake) > >> >> > > > >> >> > >Hannes > >> >> > > > >> >> > >This matches my understanding precisely. We wish to > >> >> permit endpoints > >> >> > >to mark. We do not require it, and don't necessarily expect it > >> >> > >in many (even > >> >> > >most) cases. We don't wish to see the document prohibit it. > >> >> > >We all seem to agree it has value within the Emergency > >> >Services IP > >> >> > >Networks. > >> >> > > > >> >> > >Brian > >> >> > > > >> >> > >> -----Original Message----- > >> >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> > >On Behalf > >> >> > >> Of James M. Polk > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> >> FI/Espoo); 'ECRIT' > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (my > >> >> > >> mistake) > >> >> > >> > >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> >> > >> > > James wrote: > >> >> > >> > >> you are the _lone_ voice not supporting this ID, > >> >> > >> > > >> >> > >> >Listening to the audio recording of past meetings I have to > >> >> > >say that > >> >> > >> >I > >> >> > >> was > >> >> > >> >not the only persons raising concerns about the document. > >> >> > >> >That was probably the reason why you agreed to limit the > >> >> > >scope of the > >> >> > >> >document (which you didn't later do) to get folks to agree > >> >> > >to make it > >> >> > >> a WG > >> >> > >> >item. > >> >> > >> > >> >> > >> re-listen to the audio please > >> >> > >> > >> >> > >> Ted's concerns were consistent with most (all?) other > >> >> concerns -- > >> >> > >> which were based on the premise of whether or not the > >> >> UAC should be > >> >> > >> trusted to initiate the marking on the INVITE. The most > >> >> > >> recent version has backed off this to a "can" -- meaning not > >> >prohibited > >> >> > >> (i.e., no 2119 text). I also backed off the text in the > >> >> SP domain > >> >> > >> part to "can", such that there is no 2119 text > >> >mandating or even > >> >> > >> recommending its usage there. I also do not prohibit its > >> >> > >use, based on > >> >> > >> local policy. Keith has come forward with the specific > >> >> > >> request that non-ESInet networks be allowed to mark and pay > >> >attention to > >> >> > >> this priority indication -- with IMS as the specific example > >> >> > >> he wishes to have this valid for. > >> >> > >> > >> >> > >> Where there is no disagreement, save for your recent > >> >> > >pushback - is in > >> >> > >> the ESInet, which is where Brian has requested it's > >> >> > >definition in the > >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> >> NENA, and if > >> >> > >> he asks for it, are you going to say you know better than he? > >> >> > >> > >> >> > >> > >> >> > >> >Btw, I not disagreeing with the document as such. I > >> >just want to > >> >> > the > >> >> > >> scope > >> >> > >> >to change. The usage of RPH within the emergency > >> >> services network > >> >> > is > >> >> > >> fine > >> >> > >> >for me. I may get convinced to start the RPH marking from > >> >> > >the the VSP > >> >> > >> >towards the PSAP. I feel uneasy about the end host doing > >> >> > >the marking. > >> >> > >> > >> >> > >> please read what I wrote above, and then re-read the > >> >most recent > >> >> > >> version of the ID. I don't have endpoints that SHOULD or > >> >> MUST mark > >> >> > >> anything wrt RPH. I also don't want to prohibit it, > >> >> because there > >> >> > >> might be cases (that I don't know of) of valid uses > >> >> under certain > >> >> > >> circumstances. Figure 1 is very clear that there are 3 > >> >> networking > >> >> > >> parts to consider > >> >> > >> > >> >> > >> #1 - from the endpoint > >> >> > >> #2 - within the VSP > >> >> > >> #3 - within the ESInet > >> >> > >> > >> >> > >> the most recent ID version has "can" for #s 1 and 2, and > >> >> > >2119 language > >> >> > >> offering those supporting this specification will have RPH > >> >> > >> adherence within #3 (the ESInet). > >> >> > >> > >> >> > >> What other scope changes do you want, because I haven't > >> >> heard them. > >> >> > >> > >> >> > >> I only heard you claim in email during the last IETF and in > >> >> > >the ECRIT > >> >> > >> session that RPH should not be used for priority marking > >> >> requests. > >> >> > >> This is something Keith (SIP WG chair) voiced his opposition > >> >> > >> to your views regarding creating a second means for SIP to > >> >priority > >> >> > >> mark request "when SIP already has one interoperable way to > >> >> > >> accomplish this... it's call the RP header mechanism". > >> >> > >> > >> >> > >> >I don't see advantages -- only disadvantages. > >> >> > >> > > >> >> > >> >Ciao > >> >> > >> >Hannes > >> >> > >> > >> >> > >> _______________________________________________ > >> >> > >> Ecrit mailing list > >> >> > >> Ecrit@ietf.org > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > > > >> >> > >> >> _______________________________________________ > >> >> Ecrit mailing list > >> >> Ecrit@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC833A6BBF for ; Fri, 6 Feb 2009 14:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhiYMYsvNnLx for ; Fri, 6 Feb 2009 14:05:30 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id BFC4E3A680C for ; Fri, 6 Feb 2009 14:05:26 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16M5L8i018882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 17:05:22 -0500 (EST) Message-Id: From: Henning Schulzrinne To: "James M. Polk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 17:05:21 -0500 References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:05:31 -0000 James, we don't go through every possible SIP header that might be inserted into emergency requests. Yes, somebody could add RPH, but this applies to PAI and dozens of other SIP headers as well. So far, nobody has provided, in my opinion, a compelling use case that is worth documenting. "It could be useful somewhere for something" doesn't cut it. I have provided multiple reasons why I think that it is a bad idea for (normal) UAs to do so, none of which you address. I see no need to say "do not insert RPH", as it would have to be be a no-op for the reasons I mentioned. Henning On Feb 6, 2009, at 4:45 PM, James M. Polk wrote: > At 02:01 PM 2/6/2009, Winterbottom, James wrote: >> Hi All, >> >> I have followed thi thread with some interest and I struggling to >> see a use case for the >> providing RPH for emergency calls from the end-point. > > ok, let's address this concern only for a minute. > > If there is no use-case you can think of (for endpoints insertion of > RP namespace esnet), does that mean this RFC to-be has to prevent > (i.e., MUST NOT) endpoints from being allowed to insert esnet? That > means, you feel and believe, you know about all customer > requirements everywhere, doesn't it? > > I'm not kidding or being snide here. > > Remember, this is a Standards Track doc for implementers, allowing > them the idea that some future specification MAY allow endpoints to > insert the RP header from endpoints gives them the ability to adjust > their code to that possibility. There is the (good?) chance that at > least one customer (somewhere) of one or more vendors has this as a > requirement _now_, but we haven't heard about it yet. > > Stating in this to-be RFC that endpoints are forbidden from > inserting an RP header would prevent them from implementing/ > satisfying their customer requirement while still supporting this > specification. > > Remember, this RFC to-be DOES NOT say anything about endpoints MUST > or even SHOULD implement the "esnet" RP namespace in order to be > compliant with this spec. It merely says MAY, which means "some > future spec MAY recommend or mandate it". > > I agree with Brian that robust security considerations stating that > endpoint implementations need to very careful about configuring this > capability needs to be written, and I will commit to writing that > text in the next rev of the doc. > > James > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9ECC3A68C5 for ; Fri, 6 Feb 2009 14:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svcc3a577S2e for ; Fri, 6 Feb 2009 14:10:08 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BAAC13A6C98 for ; Fri, 6 Feb 2009 14:10:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="62595908" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2009 22:10:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n16MAAn1009610; Fri, 6 Feb 2009 14:10:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16MAAYm002873; Fri, 6 Feb 2009 22:10:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 14:10:10 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 14:10:09 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 16:10:08 -0600 To: Henning Schulzrinne , "Winterbottom, James" From: "James M. Polk" In-Reply-To: <28F08C20-0FCC-4E0D-953D-F6C9850BF9EF@cs.columbia.edu> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> <28F08C20-0FCC-4E0D-953D-F6C9850BF9EF@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 22:10:09.0545 (UTC) FILETIME=[ACB85F90:01C988A7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=38659; t=1233958210; x=1234822210; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=+SWbe6rJ2FfVHQVmJJlsblVAbZ6D6LBZwahNyO4OaaQ=; b=gPS3YlsvXA++rh51sJqhfjidCiCy47vcFCiX6Qh9kwm/WihTGYkJ2Ts7rM lA6xFjZ99XCraen5cxYfQLdOhAw9wTyKmzyvIeYolq8MveO+qX51Wzvl1909 86PLlU0YYr; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:10:13 -0000 At 03:05 PM 2/6/2009, Henning Schulzrinne wrote: >There's another problem with the "it doesn't hurt argument". Assume >for a moment we have a "UA MAY include RPH" wording. There are now two >cases: > >(1) All UAs implement it. > >(2) Only some UAs implement it. > >(1) seems unlikely for a MAY. If (2) occurs, we have the choice >between two undesirable outcomes: > >(a) some UAs that are otherwise compliant get worse service just >because they didn't include the RPH; am I reading this correctly - that unless all UAs implement this capability this should never be implemented by any UAs? This flies in the face of vendors solving for their customer's requirements. I will admit that at this time, I know of no Cisco customers that want this capability, so I'm not angling for any of our revenue here. I'm saying that I think I hear you saying this ID should say something like UAs are prevented from implementing the RP namespace esnet I'm fighting against that, because customers are always coming to every vendor with new requirements, some of them unique at the time. This prevention text would prevent a vendor from complying with this specification and still meet the customer's needs. I believe that this ID needs to retain the endpoints MAY insert esnet, and have appropriate security considerations text that highlights the concerns expressed here. Some future ID can then update this current RFC (to-be) within the 2119 rules of the use of MAY here. >OR > >(b) the proxy has to look for the service URN to give the call the >appropriate treatment, thus obviating any advantage of having the >header, yet incurring more complicated processing logic. > > >I have no objection to whatever markings people want to apply to calls >within an ESN - that's largely a private matter. > >Henning > >On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: > >>Hi All, >> >>I have followed thi thread with some interest and I struggling to >>see a use case for the >>providing RPH for emergency calls from the end-point. >> >>The reference-model call in ECRIT, for better or worse, is for all >>calls to go back through a home-VSP. >>We placed quite a lot of emphasis, largely for traffing reasons, for >>the VSP to be able to verify that >>a call is in fact an emergency call. This is done by the proxy >>taking the inband location, doing a LoST >>query with the provided URN, and verifying that the resulting >>destination URI is the same as the destination >>URI provide in the SIP INVITE. My understanding was that VSPs would >>always do this check so they could >>tell if they could bill for the call or not, and because the VSP can >>be use that the call is an emergency call >>it can apply any special priorities that may be applicable. This >>obviates the need for RPH from the end-point >>to the network. >> >>This leaves us with the argument of "it doesn't hurt to it", which >>is not a good reason to write a specification. >>It was intimated on the geopriv mailing list last year that great >>pains had been taken to keep SIP with in the >>MTU limits of UDP over Ethernet >>(http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html ). Assuming >>that this is the case, perhaps there is harm in including >>information that we know will be ignored. >> >>Cheers >>James >> >> >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >>Sent: Fri 2/6/2009 12:33 PM >>To: 'Brian Rosen'; 'Henning Schulzrinne' >>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >>Subject: Re: [Ecrit] RPH >> >>To the story short here is the code for the proxy: >> >>--------------------- >> >>IF emergency call was recognized THEN >> execute emergency call specific procedures (priority queuing, >>preemption, fetch location, determine routing, do funny QoS things & >>co) >>ELSE >> normal call handling procedures. >> >>--------------------- >> >>If you can make this differentiation between an emergency call and a >>regular >>call then you can also do everything that is necessary for emergency >>call >>handling. >> >>Brian + Keith: Please tell me that we cannot do the above with our >>currently >>specified mechanisms. >> >>Ciao >>Hannes >> >>>-----Original Message----- >>>From: Brian Rosen [mailto:br@brianrosen.net] >>>Sent: 06 February, 2009 17:49 >>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>Subject: RE: [Ecrit] RPH >>> >>>I agree that not all networks will permit (or pay attention >>>to) a priority request from an end device. >>> >>>No one has asked for that. >>> >>>The namespace request has several uses, one of which is within >>>an emergency services IP network, one of which is between >>>elements within a public network controlled by the operator, >>>and one of which is an endpoint request for resource priority. >>> >>>Those of us requesting this work proceed are happy if the >>>endpoint part is simply left as possible (MAY), and, speaking >>>for myself, having the draft discuss the security implications >>>of endpoint marking is reasonable. >>> >>>Having discussed this issue with an implementation team who >>>worked on MLPP systems, I am confident I know what I'm talking >>>about, but YMMV. The fact that you could, if you wanted to, >>>give resource priority to a call you decided, however you >>>decided, was an emergency call is an implementation decision, >>>and not subject to standardization. >>> >>>RPH is the IETF standard way for one entity to request >>>resource priority of another entity in a SIP system. We're >>>asking for a namespace to use that within the domain of >>>emergency calls. That is, I think, a VERY reasonable request. >>> >>>Brian >>> >>>>-----Original Message----- >>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>Sent: Friday, February 06, 2009 10:33 AM >>>>To: Hannes Tschofenig >>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >>>>Subject: Re: [Ecrit] RPH >>>> >>>>To chime in here: >>>> >>>>I don't think it's productive to simply state that 4412 >>>doesn't worry >>>>about authorization, so we shouldn't either (simplifying a bit). >>>>Authorization was discussed repeatedly, and the general >>>assumption was >>>>that there were two conditions: Either the user invoking resource- >>>>priority was well known and had a set of permissions that could be >>>>checked in real time or there are ways to deal with abuse after the >>>>fact in ways that deter abuse (the court-martial kind of thing in a >>>>military context). >>>> >>>>The RFC 4412 security consideration (11.2) call this out in pretty >>>>strong language: >>>> >>>> Prioritized access to network and end-system resources imposes >>>> particularly stringent requirements on authentication and >>>> authorization mechanisms, since access to prioritized >>>resources may >>>> impact overall system stability and performance and not >>>just result >>>> in theft of, say, a single phone call. >>>>Thus, the question is whether we have such strong authentication in >>>>emergency calling. In some cases, such as residential fixed line >>>>deployments where ISP = VSP, we're probably pretty close, in others, >>>>such as prepaid cell phones or hot spots or VSP-only providers, we >>>>aren't. >>>> >>>>The other point that I think Hannes is making is that the >>>information >>>>is either redundant or dangerous. If a processing element recognizes >>>>the call as being an emergency call, it can apply whatever treatment >>>>it deems appropriate and doesn't need additional information. If it >>>>doesn't or can't, using just the RPH can be rather dangerous unless >>>>that element can be reasonably certain that there is strong >>>>authentication and recourse. >>>> >>>>I don't buy the argument that somehow finding the RPH is faster than >>>>just looking for the identifier. Thus, given that the information is >>>>either redundant or dangerous, I fail to see the advantage. >>>> >>>>Henning >>>> >>>> >>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >>>> >>>>>Don't get hung up on the details. There are ways to optimize it. >>>>>That was >>>>>not the point of the code example. >>>>> >>>>>The problem that my pseudo code should have shown you is that you >>>>>* don't gain anything with RPH marking for the emergency call case >>>>>from the SIP UA towards the outbound proxy since the functionality >>>>>is already provide otherwise. How often does the proxy need to get >>>>>told that this is an emergency call todo whatever emergency call >>>>>handling procedures are necessary? >>>>>* you only introduce fraud problems (if you are not >>>careful and you >>>>>understand the security stuff well enough) >>>>> >>>>>If you can point me to people who implement the RPH emergency call >>>>>case please do so. I would love to talk to them. >>>>> >>>>>Ciao >>>>>Hannes >>>>> >>>>>PS: You need to parse incoming messages to some extend so that you >>>>>know what it contains :-) Only looking for the emergency >>>RPH header >>>>>(and not for the Service URN/dial >>>>>string) would exactly be the DoS/fraud attack I am worried about. >>>>>That's the thing Henning was worried about (go and listen to the >>>>>past meeting minutes). >>>>> >>>>> >>>>>>Hannes >>>>>> >>>>>>You need to talk to people who really implement this kind >>>of thing. >>>>>>You are way off. >>>>>> >>>>>>When you implement a resource priority system, the point of doing >>>>>>that is to look though the queue of work and pick out the >>>ones with >>>>>>priority, handling them first. You don't do all the parsing, you >>>>>>don't do a lot of decision tree. >>>>>> >>>>>>Typically: >>>>>>Check for DoS things, like too big messages, etc Do a quick scan >>>>>>for the RPH message header If found: >>>>>>Parse the message >>>>>>Determine validity >>>>>>Determine priority >>>>>>Queue on the correct work queue >>>>>> >>>>>>The first two actions have to be very fast. Anyone who builds a >>>>>>SIP thingie will tell you that parsing is one of the big cycle >>>>>>consumers: if you have to parse every message BEFORE you >>>determine >>>>>>priority, you can't give much resource priority. >>>>>>Once you get the whole message parsed, you might as well finish >>>>>>working on it, because you've done so much of the work. >>>>>>OTHOH, finding the end-of-message delimiter and doing a quick >>>>>>string search for RPH is fast. If you are doing >>>priority, you need >>>>>>to keep all the priority processing pretty uniform, and pretty >>>>>>simple, or you tend to spend too much time futzing around >>>figuring >>>>>>out what to do. You put all the priority related stuff together, >>>>>>and use as much common code as possible. >>>>>> >>>>>>Brian >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>On Behalf >>>>>>>Of Hannes Tschofenig >>>>>>>Sent: Friday, February 06, 2009 8:41 AM >>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn' >>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >>>>>>>bounces@ietf.org >>>>>>>Subject: [Ecrit] RPH >>>>>>> >>>>>>>Over lunch I was also thinking how an outbound proxy would >>>>implement >>>>>>>some of the emergency procedures. Here are some thoughts: >>>>>>> >>>>>>>--------------------------------------------------- >>>>>>> >>>>>>>// Process incoming message >>>>>>>Parse(msg); >>>>>>> >>>>>>>// SIP INVITE without Service URN >>>>>>>// legacy devices >>>>>>>If (recognize-dialstring(msg)==TRUE) { // we got an emergency >>>>>>>call going on emergency=TRUE; if (dialstring(msg) == 911) >>>>>>>serviceURN=urn:service:sos; } else if >>>>>>>(recognize-serviceURN(msg)==TRUE) { // oh. A updated >>>device that >>>>>>>has a service URN attached to the >>>>call >>>>>>>serviceURN=retrieve_ServiceURN(msg); >>>>>>>emergency=TRUE; >>>>>>>} else { >>>>>>>// standard SIP message >>>>>>>// regular processing >>>>>>>process(msg); >>>>>>>emergency=FALSE; >>>>>>>} >>>>>>> >>>>>>>If (emergency == TRUE) { >>>>>>> // make sure that the emergency call does not get >>>dropped on the >>>>>>>floor >>>>>>> // skip authorization failures >>>>>>> // give the call a special treatment >>>>>>> lots-of-code-here(); >>>>>>> >>>>>>> // trigger all the QoS signaling you have in the >>>network to make >>>>>>>James happy >>>>>>> trigger-qos(); >>>>>>> >>>>>>> // query location >>>>>>> location=retrieve-location(); >>>>>>> >>>>>>> // determine next hop >>>>>>> next-hop=lost(location, serviceURN) >>>>>>> >>>>>>> // attach RPH marking to outgoing msg to make James and >>>>>>Keith happy >>>>>>> msg=add(msg, RPH); >>>>>>> >>>>>>> send(msg, next-hop); >>>>>>>} >>>>>>> >>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >>>>>>> // all the emergency related processing done already upfront >>>>>>> // hence I log something. >>>>>>> log(RPH_WAS_PRESENT_JUHU); >>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency == >>>FALSE)) { >>>>>>>// this is not an emergency call // this is something >>>like GETS >>>>>>>result=special-authorization-procedure(user); >>>>>>> >>>>>>>if (result == AUTHORIZED) { >>>>>>> // do some priority & preemption thing here. >>>>>>> // trigger all the QoS you have >>>>>>> lots-of-code-here(); >>>>>>>} else { >>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // >>>>>>>don't need todo any RPH processing // this includes the case >>>>>>>where the call was an emergency call but the RPH >>>>>>> >>>>>>>// marking was not there. >>>>>>>nothing(); >>>>>>>} >>>>>>> >>>>>>>--------------------------------------------------- >>>>>>> >>>>>>> >>>>>>>Ciao >>>>>>>Hannes >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>>>Behalf Of Hannes Tschofenig >>>>>>>>Sent: 06 February, 2009 15:07 >>>>>>>>To: 'Janet P Gunn' >>>>>>>>Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >>>>>>>FI/Espoo) >>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) >>>>>>>> >>>>>>>>Who would define something that could prevent DoS problems? >>>>>>>> >>>>>>>>________________________________ >>>>>>>> >>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>>>>>>> Sent: 06 February, 2009 14:11 >>>>>>>> To: Hannes Tschofenig >>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >>>>>>>>ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >>>>'James >>>>>>>>M. Polk' >>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>Meeting: Agenda (RPH) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> But there is nothing IN RFC4412 that specifically >>>>>>addresses how to >>>>>>>>prevent any particular namespace being used for DoS. Anyone/any >>>>UA >>>>>>>>can ATTEMPT to invoke priority treatment by attaching RPH. For >>>>all >>>>>>>>of the 4412 namespaces, as with the new proposed namespace, the >>>>>>>>mechanisms for preventing DoS are not specified in the >>>>>>document that >>>>>>>>defines the namespace. >>>>>>>>They are/will be specified elsewhere. >>>>>>>> >>>>>>>> Janet >>>>>>>> >>>>>>>> This is a PRIVATE message. If you are not the intended >>>>>>recipient, >>>>>>>>please delete without copying and kindly advise us by e-mail of >>>>the >>>>>>>>mistake in delivery. >>>>>>>> NOTE: Regardless of content, this e-mail shall not >>>>>>operate to bind >>>>>>>>CSC to any order or other contract unless pursuant to explicit >>>>>>>>written agreement or government initiative expressly permitting >>>>the >>>>>>>>use of e-mail for such purpose. >>>>>>>> >>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: >>>>>>>> >>>>>>>> > Hi James, >>>>>>>> > >>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF >>>>>>documents. What I >>>>>>>>would >>>>>>>> > like to point out is that there is more than just a >>>>>>header and >>>>>>>>values within >>>>>>>> > the header that have to be considered in order to >>>>>>make a judgement >>>>>>>>of what >>>>>>>> > is appropriate and what isn't. There is an >>>>>>architectural question >>>>>>>>and >>>>>>>> > whether the environment we are using the stuff is >>>>>>indeed providing >>>>>>>>the >>>>>>>> > properties you need for the solution to be >>>appropriate. >>>>>>>> > >>>>>>>> > Let me describe in more detail what I meant (and >>>>>>please correct me >>>>>>>>if I am >>>>>>>> > wrong). >>>>>>>> > >>>>>>>> > Getting priority for SIP requests when using a GETS >>>>>>alike scenario >>>>>>>>means >>>>>>>> > that the entity that issues the request is specially >>>>>>authorized >>>>>>>>since >>>>>>>> > otherwise you introduce a nice denial of >>>service attack. This >>>>>>>>authorization >>>>>>>> > is tied to the entity that makes the request. For >>>>>>example, the >>>>>>>>person is >>>>>>>> > working for the government and has special rights. >>>>>>>>James Bond as a (not so) >>>>>>>> > secret agent might have these rights. >>>>>>>> > >>>>>>>> > The emergency services case >>>(citizen-to-authority) is a bit >>>>>>>>different as >>>>>>>> > there aren't really special rights with respect to >>>>>>authorization >>>>>>>>tied to >>>>>>>> > individuals. Instead, the fact that something is an >>>>>>emergency is >>>>>>>>purely a >>>>>>>> > judgement of the human that dials a special number. >>>>>>>>To deal with fraud, we >>>>>>>> > discussed in the group on what we can actually do to >>>>>>ensure that >>>>>>>>end users >>>>>>>> > do not bypass security procedures (such as >>>>>>authorization checks, >>>>>>>>charging >>>>>>>> > and so on). Part of this investigation was >>>the publication of >>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also >>>describes this >>>>>>>>issue. >>>>>>>> > >>>>>>>> > So, imagine the implementation of a SIP proxy (and we >>>>>>implemented >>>>>>>>that >>>>>>>> > stuff) that receives a call that contains a Service >>>>>>URN. The code >>>>>>>>branches >>>>>>>> > into a special mode where everything is done >>>so that the call >>>>>>>>receives >>>>>>>> > appropriate treatment and does not get dropped on the >>>>>>floor. The >>>>>>>>way how the >>>>>>>> > Service URN is placed in the message ensures that the >>>>>>call cannot >>>>>>>>go to my >>>>>>>> > friend (instead of the PSAP) unless the end host ran >>>>>>LoST already. >>>>>>>>In the >>>>>>>> > latter case, we discussed this also on the list for a >>>>>>while and >>>>>>>>Richard even >>>>>>>> > wrote a draft about it in the context of the >>>location hiding >>>>>>>>topic, we said >>>>>>>> > that the proxy would have to run LoST if he >>>cares about a >>>>>>>>potential >>>>>>>> > fraudulent usage. >>>>>>>> > >>>>>>>> > So, what do we need todo in order to provide >>>secure RFC 4412 >>>>>>>>functionality >>>>>>>> > in our context? >>>>>>>> > >>>>>>>> > Do you think that the current text in >>>>>>>> > >>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>>>>>>gency-rph-nam >>>>>>>> > espace-00.txt reflects any of the >>>above-described issues: >>>>>>>> > " >>>>>>>> > The Security considerations that apply to RFC 4412 >>>>>>>>[RFC4412] >>>>>>>>apply >>>>>>>> > here. This document introduces no new security >>>>>>>>issues relative >>>>>>>>to >>>>>>>> > RFC 4412. >>>>>>>> > " >>>>>>>> > >>>>>>>> > From various discussions in GEOPRIV I recall >>>that you are >>>>>>>>super-sensitive >>>>>>>> > regarding security and privacy. For some reasons you >>>>>>don't seem to >>>>>>>>have the >>>>>>>> > same concerns here. I would like to >>>understand your reasoning. >>>>>>>> > >>>>>>>> > Please also do me another favor: Don't always say >>>>>>that I don't >>>>>>>>understand >>>>>>>> > the subject. Even if that would be the case it isn't >>>>>>particular >>>>>>>>fair given >>>>>>>> > that different folks had to educate you on other >>>>>>topics in the >>>>>>>>past as well. >>>>>>>> > Additionally, if you listen to the audio recordings >>>>>>then you will >>>>>>>>notice >>>>>>>> > that Henning, Ted, and Jon do not seem to understand >>>>>>the issue >>>>>>>>either as >>>>>>>> > they have raised similar issues during the >>>F2F meetings. >>>>>>>> > >>>>>>>> > Ciao >>>>>>>> > Hannes >>>>>>>> > >>>>>>>> > >>>>>>>> > >Hannes - I believe it is you who do not understand >>>>>>RFC 4412 -- >>>>>>>> > >and many of us are trying to get that >>>through to you, but you >>>>>>>> > >don't seem to want to listen/read. >>>>>>>> > > >>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, >>>>>>>> > > >>>>>>>> > >One use is GETS. >>>>>>>> > > >>>>>>>> > >One use is MLPP. >>>>>>>> > > >>>>>>>> > >These examples are in RFC 4412 because there >>>were specific >>>>>>>> > >namespaces being created for the IANA section of >>>>>>that document. >>>>>>>> > > >>>>>>>> > >Reading the whole document, you will see >>>that RPH can be >>>>>>>> > >specified for other uses than GETS or MLPP >>>specifically. >>>>>>>> > > >>>>>>>> > >I knew when I wrote RFC 4412 that one day we >>>would specify a >>>>>>>> > >namespace for ECRIT (the "esnet" namespace >>>now) -- but I also >>>>>>>> > >knew it was premature for RFC 4412 to >>>incorporate that >>>>>>>> > >namespace, that a future doc to RFC 4412 >>>would have to be >>>>>>>> > >written to do this. Brian and I talked about >>>this at the >>>>>>>> > >original NENA meeting that created the IP WGs there >>>>>>(in August >>>>>>>> > >of 03). We both agreed we should wait until it was >>>>>>>> > >appropriate to the work in the IETF to >>>submit this document >>>>>>>> > >that is now >>>>>>>> > >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>>>>>> > >gency-rph-namespace-00.txt >>>>>>>> > > >>>>>>>> > >Yet, you seem to want to use some additional >>>mechanism to >>>>>>>> > >indicate priority of a call in SIP. That >>>means you want to >>>>>>>> > >introduce a second way to accomplish this in SIP. >>>>>>>>Why do you >>>>>>>> > >want to promote a separate way to do something SIP >>>>>>has already >>>>>>>> > >defined? That will cause interoperability issues and >>>>>>we both know >>>>>>>>that. >>>>>>>> > > >>>>>>>> > >You've said to me (and others) that you >>>believe RPH is just >>>>>>>> > >another way to accomplish what sos or a URI can >>>>>>indicate - and >>>>>>>> > >you're wrong. Your way would be >>>_the_second_way_to_do_it, >>>>>>>> > >because SIP already considers RPH to be >>>*the*way* to priority >>>>>>>> > >mark SIP requests. >>>>>>>> > > >>>>>>>> > >If you don't believe me (no comment), then >>>why do you not >>>>>>>> > >believe the SIP WG chair (who knows more >>>about SIP than both >>>>>>>> > >of us) - who, on this thread, has again said >>>to you "RFC 4412 >>>>>>>> > >(RPH) is the SIP mechanism to priority mark >>>SIP requests"? >>>>>>>> > > >>>>>>>> > >Further, I believe it is inappropriate to >>>prohibit endpoints >>>>>>>> > >from being able to set the esnet namespace. >>>I absolutely >>>>>>>> > >believe it will not be needed most of the >>>time, but I believe >>>>>>>> > >if someone does find a valid use for >>>endpoints to mark >>>>>>>> > >priority in SIP, this ID - once it has >>>become an RFC -- will >>>>>>>> > >have to be obsoleted with a new RFC saying the exact >>>>>>opposite. >>>>>>>> > > >>>>>>>> > >(color me confused ... over and over again) >>>>>>>> > > >>>>>>>> > >James >>>>>>>> > > >>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >>>>>>>> > >>Keith, please understand that the usage of RFC 4412 >>>>>>for GETS and >>>>>>>>for >>>>>>>> > >>the type of emergency call we discuss here is >>>>>>different. Just >>>>>>>>looking >>>>>>>> > >>at the header and the name of the namespace is a bit >>>>>>>> > >artificial. I hope >>>>>>>> > >>you understand that. >>>>>>>> > >> >>>>>>>> > >> >-----Original Message----- >>>>>>>> > >> >From: DRAGE, Keith (Keith) >>>>>>>>[mailto:drage@alcatel-lucent.com] >>>>>>>> > >> >Sent: 05 February, 2009 14:55 >>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >>>>>>>>Polk'; 'Tschofenig, >>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>>Meeting: Agenda (my >>>>>>>> >>>>>>>> > >> >mistake) >>>>>>>> > >> > >>>>>>>> > >> >Which is exactly what RFC 4412 specifies for all >>>>>>namespaces. >>>>>>>> > >> > >>>>>>>> > >> >regards >>>>>>>> > >> > >>>>>>>> > >> >Keith >>>>>>>> > >> > >>>>>>>> > >> >> -----Original Message----- >>>>>>>> > >> >> From: ecrit-bounces@ietf.org >>>>>>[mailto:ecrit-bounces@ietf.org] >>>>>>>> > >> >On Behalf >>>>>>>> > >> >> Of Brian Rosen >>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >>>Polk'; 'Tschofenig, >>>>>>>> > >Hannes (NSN >>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' >>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>>>Meeting: Agenda (my >>>>>>>> > >> >> mistake) >>>>>>>> > >> >> >>>>>>>> > >> >> The value is that in some networks >>>where priority for >>>>>>>> > >> >emergency calls >>>>>>>> > >> >> is appropriate, and appropriate >>>policing of marking is >>>>>>>> > >implemented, >>>>>>>> > >> >> emergency calls will receive resource priority. >>>>>>>> > >> >> >>>>>>>> > >> >> Not all networks would need policing. Some >>>>>>will. Policing >>>>>>>>could >>>>>>>> > >> >> be to Route header/R-URI content, but other >>>>>>criteria are >>>>>>>>possible. >>>>>>>> > >> >> >>>>>>>> > >> >> Not all networks will need resource priority >>>>>>for emergency >>>>>>>>calls. >>>>>>>> > >> >> Fine, ignore this marking/namespace. >>>>>>>> > >> >> >>>>>>>> > >> >> Brian >>>>>>>> > >> >> > -----Original Message----- >>>>>>>> > >> >> > From: Hannes Tschofenig >>>>>>>>[mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >>>>>>Tschofenig, Hannes >>>>>>>>(NSN - >>>>>>>> > >> >> > FI/Espoo); 'ECRIT' >>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>>Meeting: Agenda (my >>>>>>>> > >> >> > mistake) >>>>>>>> > >> >> > >>>>>>>> > >> >> > I don't even see the value in permitting the >>>>>>endpoint todo >>>>>>>>the >>>>>>>> > >> >> > RPH marking. >>>>>>>> > >> >> > In addition to the security concerns >>>there is also the >>>>>>>> > >> >problem that >>>>>>>> > >> >> > there are more options to implement without >>>>>>an additional >>>>>>>>value. >>>>>>>> > >> >> > >>>>>>>> > >> >> > >-----Original Message----- >>>>>>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 >>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >>>>>>'Tschofenig, >>>>>>>> > >> >> Hannes (NSN - >>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' >>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >>>Interim Meeting: >>>>>>>>Agenda (my >>>>>>>> > >> >> > mistake) >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >Hannes >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >This matches my understanding >>>precisely. We wish to >>>>>>>> > >> >> permit endpoints >>>>>>>> > >> >> > >to mark. We do not require it, and >>>don't necessarily >>>>>>>>expect it >>>>>>>> > >> >> > >in many (even >>>>>>>> > >> >> > >most) cases. We don't wish to see the >>>>>>document prohibit >>>>>>>>it. >>>>>>>> > >> >> > >We all seem to agree it has value within the >>>>>>Emergency >>>>>>>> > >> >Services IP >>>>>>>> > >> >> > >Networks. >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >Brian >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >> -----Original Message----- >>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org >>>>>>>>[mailto:ecrit-bounces@ietf.org] >>>>>>>> > >> >> > >On Behalf >>>>>>>> > >> >> > >> Of James M. Polk >>>>>>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >>>Hannes (NSN - >>>>>>>> > >> >> FI/Espoo); 'ECRIT' >>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>>>Meeting: >>>>>>>> > >Agenda (my >>>>>>>> > >> >> > >> mistake) >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >>>Tschofenig wrote: >>>>>>>> > >> >> > >> > > James wrote: >>>>>>>> > >> >> > >> > >> you are the _lone_ voice not >>>>>>supporting this ID, >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> >Listening to the audio recording of past >>>>>>meetings I >>>>>>>>have to >>>>>>>> > >> >> > >say that >>>>>>>> > >> >> > >> >I >>>>>>>> > >> >> > >> was >>>>>>>> > >> >> > >> >not the only persons raising >>>concerns about the >>>>>>>>document. >>>>>>>> > >> >> > >> >That was probably the reason why you >>>>>>agreed to limit >>>>>>>>the >>>>>>>> > >> >> > >scope of the >>>>>>>> > >> >> > >> >document (which you didn't later do) to >>>>>>get folks to >>>>>>>>agree >>>>>>>> > >> >> > >to make it >>>>>>>> > >> >> > >> a WG >>>>>>>> > >> >> > >> >item. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> re-listen to the audio please >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> Ted's concerns were consistent with most >>>>>>>>(all?) other >>>>>>>> > >> >> concerns -- >>>>>>>> > >> >> > >> which were based on the premise of whether >>>>>>or not the >>>>>>>> > >> >> UAC should be >>>>>>>> > >> >> > >> trusted to initiate the marking on the >>>>>>INVITE. The >>>>>>>>most >>>>>>>> > >> >> > >> recent version has backed off this >>>to a "can" -- >>>>>>>>meaning not >>>>>>>> > >> >prohibited >>>>>>>> > >> >> > >> (i.e., no 2119 text). I also backed off >>>>>>the text in >>>>>>>>the >>>>>>>> > >> >> SP domain >>>>>>>> > >> >> > >> part to "can", such that there is >>>no 2119 text >>>>>>>> > >> >mandating or even >>>>>>>> > >> >> > >> recommending its usage there. I also do >>>>>>not prohibit >>>>>>>>its >>>>>>>> > >> >> > >use, based on >>>>>>>> > >> >> > >> local policy. Keith has come forward with >>>>>>the specific >>>>>>>> >>>>>>>> > >> >> > >> request that non-ESInet networks be >>>>>>allowed to mark and >>>>>>>>pay >>>>>>>> > >> >attention to >>>>>>>> > >> >> > >> this priority indication -- with IMS as >>>>>>the specific >>>>>>>>example >>>>>>>> > >> >> > >> he wishes to have this valid for. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> Where there is no disagreement, save for >>>>>>your recent >>>>>>>> > >> >> > >pushback - is in >>>>>>>> > >> >> > >> the ESInet, which is where Brian >>>has requested it's >>>>>>>> > >> >> > >definition in the >>>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >>>>>>chair within >>>>>>>> > >> >> NENA, and if >>>>>>>> > >> >> > >> he asks for it, are you going to say you >>>>>>know better >>>>>>>>than he? >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >Btw, I not disagreeing with the document >>>>>>as such. I >>>>>>>> > >> >just want to >>>>>>>> > >> >> > the >>>>>>>> > >> >> > >> scope >>>>>>>> > >> >> > >> >to change. The usage of RPH >>>within the emergency >>>>>>>> > >> >> services network >>>>>>>> > >> >> > is >>>>>>>> > >> >> > >> fine >>>>>>>> > >> >> > >> >for me. I may get convinced to start the >>>>>>RPH marking >>>>>>>>from >>>>>>>> > >> >> > >the the VSP >>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy about the >>>>>>end host >>>>>>>>doing >>>>>>>> > >> >> > >the marking. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> please read what I wrote above, and then >>>>>>re-read the >>>>>>>> > >> >most recent >>>>>>>> > >> >> > >> version of the ID. I don't have endpoints >>>>>>that SHOULD >>>>>>>>or >>>>>>>> > >> >> MUST mark >>>>>>>> > >> >> > >> anything wrt RPH. I also don't want to >>>>>>prohibit it, >>>>>>>> > >> >> because there >>>>>>>> > >> >> > >> might be cases (that I don't know >>>of) of valid uses >>>>>>>> > >> >> under certain >>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear >>>>>>that there are 3 >>>>>>>> > >> >> networking >>>>>>>> > >> >> > >> parts to consider >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> #1 - from the endpoint >>>>>>>> > >> >> > >> #2 - within the VSP >>>>>>>> > >> >> > >> #3 - within the ESInet >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> the most recent ID version has "can" for >>>>>>#s 1 and 2, >>>>>>>>and >>>>>>>> > >> >> > >2119 language >>>>>>>> > >> >> > >> offering those supporting this >>>>>>specification will have >>>>>>>>RPH >>>>>>>> > >> >> > >> adherence within #3 (the ESInet). >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> What other scope changes do you want, >>>>>>because I haven't >>>>>>>> > >> >> heard them. >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> I only heard you claim in email during the >>>>>>last IETF >>>>>>>>and in >>>>>>>> > >> >> > >the ECRIT >>>>>>>> > >> >> > >> session that RPH should not be >>>used for priority >>>>>>>>marking >>>>>>>> > >> >> requests. >>>>>>>> > >> >> > >> This is something Keith (SIP WG >>>chair) voiced his >>>>>>>>opposition >>>>>>>> > >> >> > >> to your views regarding creating a second >>>>>>means for SIP >>>>>>>>to >>>>>>>> > >> >priority >>>>>>>> > >> >> > >> mark request "when SIP already has one >>>>>>interoperable >>>>>>>>way to >>>>>>>> > >> >> > >> accomplish this... it's call the RP header >>>>>>mechanism". >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >I don't see advantages -- only >>>disadvantages. >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> >Ciao >>>>>>>> > >> >> > >> >Hannes >>>>>>>> > >> >> > >> >>>>>>>> > >> >> > >> >>>_______________________________________________ >>>>>>>> > >> >> > >> Ecrit mailing list >>>>>>>> > >> >> > >> Ecrit@ietf.org >>>>>>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> > >> >> > > >>>>>>>> > >> >> >>>>>>>> > >> >> _______________________________________________ >>>>>>>> > >> >> Ecrit mailing list >>>>>>>> > >> >> Ecrit@ietf.org >>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> > >> >> >>>>>>>> > >> > >>>>>>>> > > >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > Ecrit mailing list >>>>>>>> > Ecrit@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Ecrit mailing list >>>>>>>>Ecrit@ietf.org >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Ecrit mailing list >>>>>>>Ecrit@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >> >> >>------------------------------------------------------------------------------------------------ >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>------------------------------------------------------------------------------------------------ >>[mf2] >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789B03A6C3B for ; Fri, 6 Feb 2009 14:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O18MdrwZwQ28 for ; Fri, 6 Feb 2009 14:14:50 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id E869A3A6B08 for ; Fri, 6 Feb 2009 14:14:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-129.messagelabs.com!1233958490!26260472!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 27894 invoked from network); 6 Feb 2009 22:14:50 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 22:14:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MEnI0006482; Fri, 6 Feb 2009 17:14:49 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MEl0r006470; Fri, 6 Feb 2009 17:14:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 6 Feb 2009 17:14:46 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RPH Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrgu From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:14:53 -0000 WW91IGNhbiBub3QgZGlzYWxsb3cgdGhpcyBmcm9tIGFuIFVFLiBUaGUgdHJ1c3QgcmVsYXRpb25z aGlwIHdpbGwgZGljdGF0ZSB3aGV0aGVyIGl0IGlzIGFjY2VwdGVkIG9yIG5vdA0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIDxlY3Jp dC1ib3VuY2VzQGlldGYub3JnPg0KVG86IEhlbm5pbmcgU2NodWx6cmlubmUgPGhnc0Bjcy5jb2x1 bWJpYS5lZHU+OyBXaW50ZXJib3R0b20sIEphbWVzIDxKYW1lcy5XaW50ZXJib3R0b21AYW5kcmV3 LmNvbT4NCkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSA8aGFubmVzLnRz Y2hvZmVuaWdAbnNuLmNvbT47IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NClNlbnQ6IEZyaSBGZWIg MDYgMTc6MTA6MDggMjAwOQ0KU3ViamVjdDogUmU6IFtFY3JpdF0gUlBIDQoNCkF0IDAzOjA1IFBN IDIvNi8yMDA5LCBIZW5uaW5nIFNjaHVsenJpbm5lIHdyb3RlOg0KPlRoZXJlJ3MgYW5vdGhlciBw cm9ibGVtIHdpdGggdGhlICJpdCBkb2Vzbid0IGh1cnQgYXJndW1lbnQiLiBBc3N1bWUNCj5mb3Ig YSBtb21lbnQgd2UgaGF2ZSBhICJVQSBNQVkgaW5jbHVkZSBSUEgiIHdvcmRpbmcuIFRoZXJlIGFy ZSBub3cgdHdvDQo+Y2FzZXM6DQo+DQo+KDEpIEFsbCBVQXMgaW1wbGVtZW50IGl0Lg0KPg0KPigy KSBPbmx5IHNvbWUgVUFzIGltcGxlbWVudCBpdC4NCj4NCj4oMSkgc2VlbXMgdW5saWtlbHkgZm9y IGEgTUFZLiBJZiAoMikgb2NjdXJzLCB3ZSBoYXZlIHRoZSBjaG9pY2UNCj5iZXR3ZWVuIHR3byB1 bmRlc2lyYWJsZSBvdXRjb21lczoNCj4NCj4oYSkgc29tZSBVQXMgdGhhdCBhcmUgb3RoZXJ3aXNl IGNvbXBsaWFudCBnZXQgd29yc2Ugc2VydmljZSBqdXN0DQo+YmVjYXVzZSB0aGV5IGRpZG4ndCBp bmNsdWRlIHRoZSBSUEg7DQoNCmFtIEkgcmVhZGluZyB0aGlzIGNvcnJlY3RseSAtIHRoYXQgdW5s ZXNzIGFsbCBVQXMgaW1wbGVtZW50IHRoaXMgDQpjYXBhYmlsaXR5IHRoaXMgc2hvdWxkIG5ldmVy IGJlIGltcGxlbWVudGVkIGJ5IGFueSBVQXM/DQoNClRoaXMgZmxpZXMgaW4gdGhlIGZhY2Ugb2Yg dmVuZG9ycyBzb2x2aW5nIGZvciB0aGVpciBjdXN0b21lcidzIHJlcXVpcmVtZW50cy4NCg0KSSB3 aWxsIGFkbWl0IHRoYXQgYXQgdGhpcyB0aW1lLCBJIGtub3cgb2Ygbm8gQ2lzY28gY3VzdG9tZXJz IHRoYXQgDQp3YW50IHRoaXMgY2FwYWJpbGl0eSwgc28gSSdtIG5vdCBhbmdsaW5nIGZvciBhbnkg b2Ygb3VyIHJldmVudWUgDQpoZXJlLiAgSSdtIHNheWluZyB0aGF0IEkgdGhpbmsgSSBoZWFyIHlv dSBzYXlpbmcgdGhpcyBJRCBzaG91bGQgc2F5IA0Kc29tZXRoaW5nIGxpa2UNCg0KICAgICAgICAg VUFzIGFyZSBwcmV2ZW50ZWQgZnJvbSBpbXBsZW1lbnRpbmcgdGhlIFJQIG5hbWVzcGFjZSBlc25l dA0KDQpJJ20gZmlnaHRpbmcgYWdhaW5zdCB0aGF0LCBiZWNhdXNlIGN1c3RvbWVycyBhcmUgYWx3 YXlzIGNvbWluZyB0byANCmV2ZXJ5IHZlbmRvciB3aXRoIG5ldyByZXF1aXJlbWVudHMsIHNvbWUg b2YgdGhlbSB1bmlxdWUgYXQgdGhlIA0KdGltZS4gIFRoaXMgcHJldmVudGlvbiB0ZXh0IHdvdWxk IHByZXZlbnQgYSB2ZW5kb3IgZnJvbSBjb21wbHlpbmcgDQp3aXRoIHRoaXMgc3BlY2lmaWNhdGlv biBhbmQgc3RpbGwgbWVldCB0aGUgY3VzdG9tZXIncyBuZWVkcy4NCg0KSSBiZWxpZXZlIHRoYXQg dGhpcyBJRCBuZWVkcyB0byByZXRhaW4gdGhlIGVuZHBvaW50cyBNQVkgaW5zZXJ0IA0KZXNuZXQs IGFuZCBoYXZlIGFwcHJvcHJpYXRlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgdGhhdCAN CmhpZ2hsaWdodHMgdGhlIGNvbmNlcm5zIGV4cHJlc3NlZCBoZXJlLg0KDQpTb21lIGZ1dHVyZSBJ RCBjYW4gdGhlbiB1cGRhdGUgdGhpcyBjdXJyZW50IFJGQyAodG8tYmUpIHdpdGhpbiB0aGUgDQoy MTE5IHJ1bGVzIG9mIHRoZSB1c2Ugb2YgTUFZIGhlcmUuDQoNCg0KPk9SDQo+DQo+KGIpIHRoZSBw cm94eSBoYXMgdG8gbG9vayBmb3IgdGhlIHNlcnZpY2UgVVJOIHRvIGdpdmUgdGhlIGNhbGwgdGhl DQo+YXBwcm9wcmlhdGUgdHJlYXRtZW50LCB0aHVzIG9idmlhdGluZyBhbnkgYWR2YW50YWdlIG9m IGhhdmluZyB0aGUNCj5oZWFkZXIsIHlldCBpbmN1cnJpbmcgbW9yZSBjb21wbGljYXRlZCBwcm9j ZXNzaW5nIGxvZ2ljLg0KPg0KPg0KPkkgaGF2ZSBubyBvYmplY3Rpb24gdG8gd2hhdGV2ZXIgbWFy a2luZ3MgcGVvcGxlIHdhbnQgdG8gYXBwbHkgdG8gY2FsbHMNCj53aXRoaW4gYW4gRVNOIC0gdGhh dCdzIGxhcmdlbHkgYSBwcml2YXRlIG1hdHRlci4NCj4NCj5IZW5uaW5nDQo+DQo+T24gRmViIDYs IDIwMDksIGF0IDM6MDEgUE0sIFdpbnRlcmJvdHRvbSwgSmFtZXMgd3JvdGU6DQo+DQo+PkhpIEFs bCwNCj4+DQo+PkkgaGF2ZSBmb2xsb3dlZCB0aGkgdGhyZWFkIHdpdGggc29tZSBpbnRlcmVzdCBh bmQgSSBzdHJ1Z2dsaW5nIHRvDQo+PnNlZSBhIHVzZSBjYXNlIGZvciB0aGUNCj4+cHJvdmlkaW5n IFJQSCBmb3IgZW1lcmdlbmN5IGNhbGxzIGZyb20gdGhlIGVuZC1wb2ludC4NCj4+DQo+PlRoZSBy ZWZlcmVuY2UtbW9kZWwgY2FsbCBpbiBFQ1JJVCwgZm9yIGJldHRlciBvciB3b3JzZSwgaXMgZm9y IGFsbA0KPj5jYWxscyB0byBnbyBiYWNrIHRocm91Z2ggYSBob21lLVZTUC4NCj4+V2UgcGxhY2Vk IHF1aXRlIGEgbG90IG9mIGVtcGhhc2lzLCBsYXJnZWx5IGZvciB0cmFmZmluZyByZWFzb25zLCBm b3INCj4+dGhlIFZTUCB0byBiZSBhYmxlIHRvIHZlcmlmeSB0aGF0DQo+PmEgY2FsbCBpcyBpbiBm YWN0IGFuIGVtZXJnZW5jeSBjYWxsLiBUaGlzIGlzIGRvbmUgYnkgdGhlIHByb3h5DQo+PnRha2lu ZyB0aGUgaW5iYW5kIGxvY2F0aW9uLCBkb2luZyBhIExvU1QNCj4+cXVlcnkgd2l0aCB0aGUgcHJv dmlkZWQgVVJOLCBhbmQgdmVyaWZ5aW5nIHRoYXQgdGhlIHJlc3VsdGluZw0KPj5kZXN0aW5hdGlv biBVUkkgaXMgdGhlIHNhbWUgYXMgdGhlIGRlc3RpbmF0aW9uDQo+PlVSSSBwcm92aWRlIGluIHRo ZSBTSVAgSU5WSVRFLiBNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IFZTUHMgd291bGQNCj4+YWx3 YXlzIGRvIHRoaXMgY2hlY2sgc28gdGhleSBjb3VsZA0KPj50ZWxsIGlmIHRoZXkgY291bGQgYmls bCBmb3IgdGhlIGNhbGwgb3Igbm90LCBhbmQgYmVjYXVzZSB0aGUgVlNQIGNhbg0KPj5iZSB1c2Ug dGhhdCB0aGUgY2FsbCBpcyBhbiBlbWVyZ2VuY3kgY2FsbA0KPj5pdCBjYW4gYXBwbHkgYW55IHNw ZWNpYWwgcHJpb3JpdGllcyB0aGF0IG1heSBiZSBhcHBsaWNhYmxlLiBUaGlzDQo+Pm9idmlhdGVz IHRoZSBuZWVkIGZvciBSUEggZnJvbSB0aGUgZW5kLXBvaW50DQo+PnRvIHRoZSBuZXR3b3JrLg0K Pj4NCj4+VGhpcyBsZWF2ZXMgdXMgd2l0aCB0aGUgYXJndW1lbnQgb2YgIml0IGRvZXNuJ3QgaHVy dCB0byBpdCIsIHdoaWNoDQo+PmlzIG5vdCBhIGdvb2QgcmVhc29uIHRvIHdyaXRlIGEgc3BlY2lm aWNhdGlvbi4NCj4+SXQgd2FzIGludGltYXRlZCBvbiB0aGUgZ2VvcHJpdiBtYWlsaW5nIGxpc3Qg bGFzdCB5ZWFyIHRoYXQgZ3JlYXQNCj4+cGFpbnMgaGFkIGJlZW4gdGFrZW4gdG8ga2VlcCBTSVAg d2l0aCBpbiB0aGUNCj4+TVRVIGxpbWl0cyBvZiBVRFAgb3ZlciBFdGhlcm5ldCANCj4+KGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9nZW9wcml2L2N1cnJlbnQvbXNnMDYxMjAu aHRtbCApLiBBc3N1bWluZw0KPj50aGF0IHRoaXMgaXMgdGhlIGNhc2UsIHBlcmhhcHMgdGhlcmUg aXMgaGFybSBpbiBpbmNsdWRpbmcNCj4+aW5mb3JtYXRpb24gdGhhdCB3ZSBrbm93IHdpbGwgYmUg aWdub3JlZC4NCj4+DQo+PkNoZWVycw0KPj5KYW1lcw0KPj4NCj4+DQo+Pg0KPj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBIYW5uZXMgVHNjaG9mZW5pZw0KPj5TZW50OiBGcmkgMi82LzIwMDkgMTI6MzMgUE0NCj4+ VG86ICdCcmlhbiBSb3Nlbic7ICdIZW5uaW5nIFNjaHVsenJpbm5lJw0KPj5DYzogVHNjaG9mZW5p ZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7ICdFQ1JJVCcNCj4+U3ViamVjdDogUmU6IFtFY3Jp dF0gUlBIDQo+Pg0KPj5UbyB0aGUgc3Rvcnkgc2hvcnQgaGVyZSBpcyB0aGUgY29kZSBmb3IgdGhl IHByb3h5Og0KPj4NCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj5JRiBlbWVyZ2VuY3kg Y2FsbCB3YXMgcmVjb2duaXplZCBUSEVODQo+PiAgICBleGVjdXRlIGVtZXJnZW5jeSBjYWxsIHNw ZWNpZmljIHByb2NlZHVyZXMgKHByaW9yaXR5IHF1ZXVpbmcsDQo+PnByZWVtcHRpb24sIGZldGNo IGxvY2F0aW9uLCBkZXRlcm1pbmUgcm91dGluZywgZG8gZnVubnkgUW9TIHRoaW5ncyAmDQo+PmNv KQ0KPj5FTFNFDQo+PiAgICBub3JtYWwgY2FsbCBoYW5kbGluZyBwcm9jZWR1cmVzLg0KPj4NCj4+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj5JZiB5b3UgY2FuIG1ha2UgdGhpcyBkaWZmZXJl bnRpYXRpb24gYmV0d2VlbiBhbiBlbWVyZ2VuY3kgY2FsbCBhbmQgYQ0KPj5yZWd1bGFyDQo+PmNh bGwgdGhlbiB5b3UgY2FuIGFsc28gZG8gZXZlcnl0aGluZyB0aGF0IGlzIG5lY2Vzc2FyeSBmb3Ig ZW1lcmdlbmN5DQo+PmNhbGwNCj4+aGFuZGxpbmcuDQo+Pg0KPj5CcmlhbiArIEtlaXRoOiBQbGVh c2UgdGVsbCBtZSB0aGF0IHdlIGNhbm5vdCBkbyB0aGUgYWJvdmUgd2l0aCBvdXINCj4+Y3VycmVu dGx5DQo+PnNwZWNpZmllZCBtZWNoYW5pc21zLg0KPj4NCj4+Q2lhbw0KPj5IYW5uZXMNCj4+DQo+ Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogQnJpYW4gUm9zZW4gW21haWx0 bzpickBicmlhbnJvc2VuLm5ldF0NCj4+PlNlbnQ6IDA2IEZlYnJ1YXJ5LCAyMDA5IDE3OjQ5DQo+ Pj5UbzogJ0hlbm5pbmcgU2NodWx6cmlubmUnOyAnSGFubmVzIFRzY2hvZmVuaWcnDQo+Pj5DYzog J1RzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pJzsgJ0VDUklUJw0KPj4+U3ViamVj dDogUkU6IFtFY3JpdF0gUlBIDQo+Pj4NCj4+PkkgYWdyZWUgdGhhdCBub3QgYWxsIG5ldHdvcmtz IHdpbGwgcGVybWl0IChvciBwYXkgYXR0ZW50aW9uDQo+Pj50bykgYSBwcmlvcml0eSByZXF1ZXN0 IGZyb20gYW4gZW5kIGRldmljZS4NCj4+Pg0KPj4+Tm8gb25lIGhhcyBhc2tlZCBmb3IgdGhhdC4N Cj4+Pg0KPj4+VGhlIG5hbWVzcGFjZSByZXF1ZXN0IGhhcyBzZXZlcmFsIHVzZXMsIG9uZSBvZiB3 aGljaCBpcyB3aXRoaW4NCj4+PmFuIGVtZXJnZW5jeSBzZXJ2aWNlcyBJUCBuZXR3b3JrLCBvbmUg b2Ygd2hpY2ggaXMgYmV0d2Vlbg0KPj4+ZWxlbWVudHMgd2l0aGluIGEgcHVibGljIG5ldHdvcmsg Y29udHJvbGxlZCBieSB0aGUgb3BlcmF0b3IsDQo+Pj5hbmQgb25lIG9mIHdoaWNoIGlzIGFuIGVu ZHBvaW50IHJlcXVlc3QgZm9yIHJlc291cmNlIHByaW9yaXR5Lg0KPj4+DQo+Pj5UaG9zZSBvZiB1 cyByZXF1ZXN0aW5nIHRoaXMgd29yayBwcm9jZWVkIGFyZSBoYXBweSBpZiB0aGUNCj4+PmVuZHBv aW50IHBhcnQgaXMgc2ltcGx5IGxlZnQgYXMgcG9zc2libGUgKE1BWSksIGFuZCwgc3BlYWtpbmcN Cj4+PmZvciBteXNlbGYsIGhhdmluZyB0aGUgZHJhZnQgZGlzY3VzcyB0aGUgc2VjdXJpdHkgaW1w bGljYXRpb25zDQo+Pj5vZiBlbmRwb2ludCBtYXJraW5nIGlzIHJlYXNvbmFibGUuDQo+Pj4NCj4+ PkhhdmluZyBkaXNjdXNzZWQgdGhpcyBpc3N1ZSB3aXRoIGFuIGltcGxlbWVudGF0aW9uIHRlYW0g d2hvDQo+Pj53b3JrZWQgb24gTUxQUCBzeXN0ZW1zLCBJIGFtIGNvbmZpZGVudCBJIGtub3cgd2hh dCBJJ20gdGFsa2luZw0KPj4+YWJvdXQsIGJ1dCBZTU1WLiAgVGhlIGZhY3QgdGhhdCB5b3UgY291 bGQsIGlmIHlvdSB3YW50ZWQgdG8sDQo+Pj5naXZlIHJlc291cmNlIHByaW9yaXR5IHRvIGEgY2Fs bCB5b3UgZGVjaWRlZCwgaG93ZXZlciB5b3UNCj4+PmRlY2lkZWQsIHdhcyBhbiBlbWVyZ2VuY3kg Y2FsbCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiwNCj4+PmFuZCBub3Qgc3ViamVjdCB0 byBzdGFuZGFyZGl6YXRpb24uDQo+Pj4NCj4+PlJQSCBpcyB0aGUgSUVURiBzdGFuZGFyZCB3YXkg Zm9yIG9uZSBlbnRpdHkgdG8gcmVxdWVzdA0KPj4+cmVzb3VyY2UgcHJpb3JpdHkgb2YgYW5vdGhl ciBlbnRpdHkgaW4gYSBTSVAgc3lzdGVtLiAgV2UncmUNCj4+PmFza2luZyBmb3IgYSBuYW1lc3Bh Y2UgdG8gdXNlIHRoYXQgd2l0aGluIHRoZSBkb21haW4gb2YNCj4+PmVtZXJnZW5jeSBjYWxscy4g IFRoYXQgaXMsIEkgdGhpbmssIGEgVkVSWSByZWFzb25hYmxlIHJlcXVlc3QuDQo+Pj4NCj4+PkJy aWFuDQo+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PkZyb206IEhlbm5p bmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1XQ0KPj4+PlNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMDYsIDIwMDkgMTA6MzMgQU0NCj4+Pj5UbzogSGFubmVzIFRzY2hvZmVu aWcNCj4+Pj5DYzogQnJpYW4gUm9zZW47IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNw b28pOyBFQ1JJVA0KPj4+PlN1YmplY3Q6IFJlOiBbRWNyaXRdIFJQSA0KPj4+Pg0KPj4+PlRvIGNo aW1lIGluIGhlcmU6DQo+Pj4+DQo+Pj4+SSBkb24ndCB0aGluayBpdCdzIHByb2R1Y3RpdmUgdG8g c2ltcGx5IHN0YXRlIHRoYXQgNDQxMg0KPj4+ZG9lc24ndCB3b3JyeQ0KPj4+PmFib3V0IGF1dGhv cml6YXRpb24sIHNvIHdlIHNob3VsZG4ndCBlaXRoZXIgKHNpbXBsaWZ5aW5nIGEgYml0KS4NCj4+ Pj5BdXRob3JpemF0aW9uIHdhcyBkaXNjdXNzZWQgcmVwZWF0ZWRseSwgYW5kIHRoZSBnZW5lcmFs DQo+Pj5hc3N1bXB0aW9uIHdhcw0KPj4+PnRoYXQgdGhlcmUgd2VyZSB0d28gY29uZGl0aW9uczog RWl0aGVyIHRoZSB1c2VyIGludm9raW5nIHJlc291cmNlLQ0KPj4+PnByaW9yaXR5IHdhcyB3ZWxs IGtub3duIGFuZCBoYWQgYSBzZXQgb2YgcGVybWlzc2lvbnMgdGhhdCBjb3VsZCBiZQ0KPj4+PmNo ZWNrZWQgaW4gcmVhbCB0aW1lIG9yIHRoZXJlIGFyZSB3YXlzIHRvIGRlYWwgd2l0aCBhYnVzZSBh ZnRlciB0aGUNCj4+Pj5mYWN0IGluIHdheXMgdGhhdCBkZXRlciBhYnVzZSAodGhlIGNvdXJ0LW1h cnRpYWwga2luZCBvZiB0aGluZyBpbiBhDQo+Pj4+bWlsaXRhcnkgY29udGV4dCkuDQo+Pj4+DQo+ Pj4+VGhlIFJGQyA0NDEyIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gKDExLjIpIGNhbGwgdGhpcyBv dXQgaW4gcHJldHR5DQo+Pj4+c3Ryb25nIGxhbmd1YWdlOg0KPj4+Pg0KPj4+PiAgUHJpb3JpdGl6 ZWQgYWNjZXNzIHRvIG5ldHdvcmsgYW5kIGVuZC1zeXN0ZW0gcmVzb3VyY2VzIGltcG9zZXMNCj4+ Pj4gICAgcGFydGljdWxhcmx5IHN0cmluZ2VudCByZXF1aXJlbWVudHMgb24gYXV0aGVudGljYXRp b24gYW5kDQo+Pj4+ICAgIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtcywgc2luY2UgYWNjZXNzIHRv IHByaW9yaXRpemVkDQo+Pj5yZXNvdXJjZXMgbWF5DQo+Pj4+ICAgIGltcGFjdCBvdmVyYWxsIHN5 c3RlbSBzdGFiaWxpdHkgYW5kIHBlcmZvcm1hbmNlIGFuZCBub3QNCj4+Pmp1c3QgcmVzdWx0DQo+ Pj4+ICAgIGluIHRoZWZ0IG9mLCBzYXksIGEgc2luZ2xlIHBob25lIGNhbGwuDQo+Pj4+VGh1cywg dGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2UgaGF2ZSBzdWNoIHN0cm9uZyBhdXRoZW50aWNhdGlv biBpbg0KPj4+PmVtZXJnZW5jeSBjYWxsaW5nLiBJbiBzb21lIGNhc2VzLCBzdWNoIGFzIHJlc2lk ZW50aWFsIGZpeGVkIGxpbmUNCj4+Pj5kZXBsb3ltZW50cyB3aGVyZSBJU1AgPSBWU1AsIHdlJ3Jl IHByb2JhYmx5IHByZXR0eSBjbG9zZSwgaW4gb3RoZXJzLA0KPj4+PnN1Y2ggYXMgcHJlcGFpZCBj ZWxsIHBob25lcyBvciBob3Qgc3BvdHMgb3IgVlNQLW9ubHkgcHJvdmlkZXJzLCB3ZQ0KPj4+PmFy ZW4ndC4NCj4+Pj4NCj4+Pj5UaGUgb3RoZXIgcG9pbnQgdGhhdCBJIHRoaW5rIEhhbm5lcyBpcyBt YWtpbmcgaXMgdGhhdCB0aGUNCj4+PmluZm9ybWF0aW9uDQo+Pj4+aXMgZWl0aGVyIHJlZHVuZGFu dCBvciBkYW5nZXJvdXMuIElmIGEgcHJvY2Vzc2luZyBlbGVtZW50IHJlY29nbml6ZXMNCj4+Pj50 aGUgY2FsbCBhcyBiZWluZyBhbiBlbWVyZ2VuY3kgY2FsbCwgaXQgY2FuIGFwcGx5IHdoYXRldmVy IHRyZWF0bWVudA0KPj4+Pml0IGRlZW1zIGFwcHJvcHJpYXRlIGFuZCBkb2Vzbid0IG5lZWQgYWRk aXRpb25hbCBpbmZvcm1hdGlvbi4gSWYgaXQNCj4+Pj5kb2Vzbid0IG9yIGNhbid0LCB1c2luZyBq dXN0IHRoZSBSUEggY2FuIGJlIHJhdGhlciBkYW5nZXJvdXMgdW5sZXNzDQo+Pj4+dGhhdCBlbGVt ZW50IGNhbiBiZSByZWFzb25hYmx5IGNlcnRhaW4gdGhhdCB0aGVyZSBpcyBzdHJvbmcNCj4+Pj5h dXRoZW50aWNhdGlvbiBhbmQgcmVjb3Vyc2UuDQo+Pj4+DQo+Pj4+SSBkb24ndCBidXkgdGhlIGFy Z3VtZW50IHRoYXQgc29tZWhvdyBmaW5kaW5nIHRoZSBSUEggaXMgZmFzdGVyIHRoYW4NCj4+Pj5q dXN0IGxvb2tpbmcgZm9yIHRoZSBpZGVudGlmaWVyLiBUaHVzLCBnaXZlbiB0aGF0IHRoZSBpbmZv cm1hdGlvbiBpcw0KPj4+PmVpdGhlciByZWR1bmRhbnQgb3IgZGFuZ2Vyb3VzLCBJIGZhaWwgdG8g c2VlIHRoZSBhZHZhbnRhZ2UuDQo+Pj4+DQo+Pj4+SGVubmluZw0KPj4+Pg0KPj4+Pg0KPj4+Pk9u IEZlYiA2LCAyMDA5LCBhdCAxMDoyMCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+ DQo+Pj4+PkRvbid0IGdldCBodW5nIHVwIG9uIHRoZSBkZXRhaWxzLiBUaGVyZSBhcmUgd2F5cyB0 byBvcHRpbWl6ZSBpdC4NCj4+Pj4+VGhhdCB3YXMNCj4+Pj4+bm90IHRoZSBwb2ludCBvZiB0aGUg Y29kZSBleGFtcGxlLg0KPj4+Pj4NCj4+Pj4+VGhlIHByb2JsZW0gdGhhdCBteSBwc2V1ZG8gY29k ZSBzaG91bGQgaGF2ZSBzaG93biB5b3UgaXMgdGhhdCB5b3UNCj4+Pj4+KiBkb24ndCBnYWluIGFu eXRoaW5nIHdpdGggUlBIIG1hcmtpbmcgZm9yIHRoZSBlbWVyZ2VuY3kgY2FsbCBjYXNlDQo+Pj4+ PmZyb20gdGhlIFNJUCBVQSB0b3dhcmRzIHRoZSBvdXRib3VuZCBwcm94eSBzaW5jZSB0aGUgZnVu Y3Rpb25hbGl0eQ0KPj4+Pj5pcyBhbHJlYWR5IHByb3ZpZGUgb3RoZXJ3aXNlLiBIb3cgb2Z0ZW4g ZG9lcyB0aGUgcHJveHkgbmVlZCB0byBnZXQNCj4+Pj4+dG9sZCB0aGF0IHRoaXMgaXMgYW4gZW1l cmdlbmN5IGNhbGwgdG9kbyB3aGF0ZXZlciBlbWVyZ2VuY3kgY2FsbA0KPj4+Pj5oYW5kbGluZyBw cm9jZWR1cmVzIGFyZSBuZWNlc3Nhcnk/DQo+Pj4+PiogeW91IG9ubHkgaW50cm9kdWNlIGZyYXVk IHByb2JsZW1zIChpZiB5b3UgYXJlIG5vdA0KPj4+Y2FyZWZ1bCBhbmQgeW91DQo+Pj4+PnVuZGVy c3RhbmQgdGhlIHNlY3VyaXR5IHN0dWZmIHdlbGwgZW5vdWdoKQ0KPj4+Pj4NCj4+Pj4+SWYgeW91 IGNhbiBwb2ludCBtZSB0byBwZW9wbGUgd2hvIGltcGxlbWVudCB0aGUgUlBIIGVtZXJnZW5jeSBj YWxsDQo+Pj4+PmNhc2UgcGxlYXNlIGRvIHNvLiBJIHdvdWxkIGxvdmUgdG8gdGFsayB0byB0aGVt Lg0KPj4+Pj4NCj4+Pj4+Q2lhbw0KPj4+Pj5IYW5uZXMNCj4+Pj4+DQo+Pj4+PlBTOiBZb3UgbmVl ZCB0byBwYXJzZSBpbmNvbWluZyBtZXNzYWdlcyB0byBzb21lIGV4dGVuZCBzbyB0aGF0IHlvdQ0K Pj4+Pj5rbm93IHdoYXQgaXQgY29udGFpbnMgOi0pIE9ubHkgbG9va2luZyBmb3IgdGhlIGVtZXJn ZW5jeQ0KPj4+UlBIIGhlYWRlcg0KPj4+Pj4oYW5kIG5vdCBmb3IgdGhlIFNlcnZpY2UgVVJOL2Rp YWwNCj4+Pj4+c3RyaW5nKSB3b3VsZCBleGFjdGx5IGJlIHRoZSBEb1MvZnJhdWQgYXR0YWNrIEkg YW0gd29ycmllZCBhYm91dC4NCj4+Pj4+VGhhdCdzIHRoZSB0aGluZyBIZW5uaW5nIHdhcyB3b3Jy aWVkIGFib3V0IChnbyBhbmQgbGlzdGVuIHRvIHRoZQ0KPj4+Pj5wYXN0IG1lZXRpbmcgbWludXRl cykuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+Pkhhbm5lcw0KPj4+Pj4+DQo+Pj4+Pj5Zb3UgbmVlZCB0 byB0YWxrIHRvIHBlb3BsZSB3aG8gcmVhbGx5IGltcGxlbWVudCB0aGlzIGtpbmQNCj4+Pm9mIHRo aW5nLg0KPj4+Pj4+WW91IGFyZSB3YXkgb2ZmLg0KPj4+Pj4+DQo+Pj4+Pj5XaGVuIHlvdSBpbXBs ZW1lbnQgYSByZXNvdXJjZSBwcmlvcml0eSBzeXN0ZW0sIHRoZSBwb2ludCBvZiBkb2luZw0KPj4+ Pj4+dGhhdCBpcyB0byBsb29rIHRob3VnaCB0aGUgcXVldWUgb2Ygd29yayBhbmQgcGljayBvdXQg dGhlDQo+Pj5vbmVzIHdpdGgNCj4+Pj4+PnByaW9yaXR5LCBoYW5kbGluZyB0aGVtIGZpcnN0LiAg WW91IGRvbid0IGRvIGFsbCB0aGUgcGFyc2luZywgeW91DQo+Pj4+Pj5kb24ndCBkbyBhIGxvdCBv ZiBkZWNpc2lvbiB0cmVlLg0KPj4+Pj4+DQo+Pj4+Pj5UeXBpY2FsbHk6DQo+Pj4+Pj5DaGVjayBm b3IgRG9TIHRoaW5ncywgbGlrZSB0b28gYmlnIG1lc3NhZ2VzLCBldGMgRG8gYSBxdWljayBzY2Fu DQo+Pj4+Pj5mb3IgdGhlIFJQSCBtZXNzYWdlIGhlYWRlciBJZiBmb3VuZDoNCj4+Pj4+PlBhcnNl IHRoZSBtZXNzYWdlDQo+Pj4+Pj5EZXRlcm1pbmUgdmFsaWRpdHkNCj4+Pj4+PkRldGVybWluZSBw cmlvcml0eQ0KPj4+Pj4+UXVldWUgb24gdGhlIGNvcnJlY3Qgd29yayBxdWV1ZQ0KPj4+Pj4+DQo+ Pj4+Pj5UaGUgZmlyc3QgdHdvIGFjdGlvbnMgaGF2ZSB0byBiZSB2ZXJ5IGZhc3QuICBBbnlvbmUg d2hvIGJ1aWxkcyBhDQo+Pj4+Pj5TSVAgdGhpbmdpZSB3aWxsIHRlbGwgeW91IHRoYXQgcGFyc2lu ZyBpcyBvbmUgb2YgdGhlIGJpZyBjeWNsZQ0KPj4+Pj4+Y29uc3VtZXJzOiBpZiB5b3UgaGF2ZSB0 byBwYXJzZSBldmVyeSBtZXNzYWdlIEJFRk9SRSB5b3UNCj4+PmRldGVybWluZQ0KPj4+Pj4+cHJp b3JpdHksIHlvdSBjYW4ndCBnaXZlIG11Y2ggcmVzb3VyY2UgcHJpb3JpdHkuDQo+Pj4+Pj5PbmNl IHlvdSBnZXQgdGhlIHdob2xlIG1lc3NhZ2UgcGFyc2VkLCB5b3UgbWlnaHQgYXMgd2VsbCBmaW5p c2gNCj4+Pj4+Pndvcmtpbmcgb24gaXQsIGJlY2F1c2UgeW91J3ZlIGRvbmUgc28gbXVjaCBvZiB0 aGUgd29yay4NCj4+Pj4+Pk9USE9ILCBmaW5kaW5nIHRoZSBlbmQtb2YtbWVzc2FnZSBkZWxpbWl0 ZXIgYW5kIGRvaW5nIGEgcXVpY2sNCj4+Pj4+PnN0cmluZyBzZWFyY2ggZm9yIFJQSCBpcyBmYXN0 LiAgSWYgeW91IGFyZSBkb2luZw0KPj4+cHJpb3JpdHksIHlvdSBuZWVkDQo+Pj4+Pj50byBrZWVw IGFsbCB0aGUgcHJpb3JpdHkgcHJvY2Vzc2luZyBwcmV0dHkgdW5pZm9ybSwgYW5kIHByZXR0eQ0K Pj4+Pj4+c2ltcGxlLCBvciB5b3UgdGVuZCB0byBzcGVuZCB0b28gbXVjaCB0aW1lIGZ1dHppbmcg YXJvdW5kDQo+Pj5maWd1cmluZw0KPj4+Pj4+b3V0IHdoYXQgdG8gZG8uICBZb3UgcHV0IGFsbCB0 aGUgcHJpb3JpdHkgcmVsYXRlZCBzdHVmZiB0b2dldGhlciwNCj4+Pj4+PmFuZCB1c2UgYXMgbXVj aCBjb21tb24gY29kZSBhcyBwb3NzaWJsZS4NCj4+Pj4+Pg0KPj4+Pj4+QnJpYW4NCj4+Pj4+Pg0K Pj4+Pj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+RnJvbTogZWNyaXQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4+Pj5PbiBC ZWhhbGYNCj4+Pj4+Pj5PZiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+PlNlbnQ6IEZyaWRheSwg RmVicnVhcnkgMDYsIDIwMDkgODo0MSBBTQ0KPj4+Pj4+PlRvOiAnSGFubmVzIFRzY2hvZmVuaWcn OyAnSmFuZXQgUCBHdW5uJw0KPj4+Pj4+PkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJ L0VzcG9vKTsgJ0VDUklUJzsgZWNyaXQtDQo+Pj4+Pj4+Ym91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+ PlN1YmplY3Q6IFtFY3JpdF0gUlBIDQo+Pj4+Pj4+DQo+Pj4+Pj4+T3ZlciBsdW5jaCBJIHdhcyBh bHNvIHRoaW5raW5nIGhvdyBhbiBvdXRib3VuZCBwcm94eSB3b3VsZA0KPj4+PmltcGxlbWVudA0K Pj4+Pj4+PnNvbWUgb2YgdGhlIGVtZXJnZW5jeSBwcm9jZWR1cmVzLiBIZXJlIGFyZSBzb21lIHRo b3VnaHRzOg0KPj4+Pj4+Pg0KPj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pi8vIFByb2Nlc3MgaW5jb21pbmcg bWVzc2FnZQ0KPj4+Pj4+PlBhcnNlKG1zZyk7DQo+Pj4+Pj4+DQo+Pj4+Pj4+Ly8gU0lQIElOVklU RSB3aXRob3V0IFNlcnZpY2UgVVJODQo+Pj4+Pj4+Ly8gbGVnYWN5IGRldmljZXMNCj4+Pj4+Pj5J ZiAocmVjb2duaXplLWRpYWxzdHJpbmcobXNnKT09VFJVRSkgeyAgLy8gd2UgZ290IGFuIGVtZXJn ZW5jeQ0KPj4+Pj4+PmNhbGwgZ29pbmcgb24gIGVtZXJnZW5jeT1UUlVFOyAgaWYgKGRpYWxzdHJp bmcobXNnKSA9PSA5MTEpDQo+Pj4+Pj4+c2VydmljZVVSTj11cm46c2VydmljZTpzb3M7IH0gZWxz ZSBpZg0KPj4+Pj4+PihyZWNvZ25pemUtc2VydmljZVVSTihtc2cpPT1UUlVFKSB7ICAvLyBvaC4g QSB1cGRhdGVkDQo+Pj5kZXZpY2UgdGhhdA0KPj4+Pj4+PmhhcyBhIHNlcnZpY2UgVVJOIGF0dGFj aGVkIHRvIHRoZQ0KPj4+PmNhbGwNCj4+Pj4+Pj5zZXJ2aWNlVVJOPXJldHJpZXZlX1NlcnZpY2VV Uk4obXNnKTsNCj4+Pj4+Pj5lbWVyZ2VuY3k9VFJVRTsNCj4+Pj4+Pj59IGVsc2Ugew0KPj4+Pj4+ Pi8vIHN0YW5kYXJkIFNJUCBtZXNzYWdlDQo+Pj4+Pj4+Ly8gcmVndWxhciBwcm9jZXNzaW5nDQo+ Pj4+Pj4+cHJvY2Vzcyhtc2cpOw0KPj4+Pj4+PmVtZXJnZW5jeT1GQUxTRTsNCj4+Pj4+Pj59DQo+ Pj4+Pj4+DQo+Pj4+Pj4+SWYgKGVtZXJnZW5jeSA9PSBUUlVFKSB7DQo+Pj4+Pj4+ICAvLyBtYWtl IHN1cmUgdGhhdCB0aGUgZW1lcmdlbmN5IGNhbGwgZG9lcyBub3QgZ2V0DQo+Pj5kcm9wcGVkIG9u IHRoZQ0KPj4+Pj4+PmZsb29yDQo+Pj4+Pj4+ICAvLyBza2lwIGF1dGhvcml6YXRpb24gZmFpbHVy ZXMNCj4+Pj4+Pj4gIC8vIGdpdmUgdGhlIGNhbGwgYSBzcGVjaWFsIHRyZWF0bWVudA0KPj4+Pj4+ PiAgbG90cy1vZi1jb2RlLWhlcmUoKTsNCj4+Pj4+Pj4NCj4+Pj4+Pj4gIC8vIHRyaWdnZXIgYWxs IHRoZSBRb1Mgc2lnbmFsaW5nIHlvdSBoYXZlIGluIHRoZQ0KPj4+bmV0d29yayB0byBtYWtlDQo+ Pj4+Pj4+SmFtZXMgaGFwcHkNCj4+Pj4+Pj4gIHRyaWdnZXItcW9zKCk7DQo+Pj4+Pj4+DQo+Pj4+ Pj4+ICAvLyBxdWVyeSBsb2NhdGlvbg0KPj4+Pj4+PiAgbG9jYXRpb249cmV0cmlldmUtbG9jYXRp b24oKTsNCj4+Pj4+Pj4NCj4+Pj4+Pj4gIC8vIGRldGVybWluZSBuZXh0IGhvcA0KPj4+Pj4+PiAg bmV4dC1ob3A9bG9zdChsb2NhdGlvbiwgc2VydmljZVVSTikNCj4+Pj4+Pj4NCj4+Pj4+Pj4gIC8v IGF0dGFjaCBSUEggbWFya2luZyB0byBvdXRnb2luZyBtc2cgdG8gbWFrZSBKYW1lcyBhbmQNCj4+ Pj4+PktlaXRoIGhhcHB5DQo+Pj4+Pj4+ICBtc2c9YWRkKG1zZywgUlBIKTsNCj4+Pj4+Pj4NCj4+ Pj4+Pj4gIHNlbmQobXNnLCBuZXh0LWhvcCk7DQo+Pj4+Pj4+fQ0KPj4+Pj4+Pg0KPj4+Pj4+Pklm ICgocnBoLXByZXNlbnQobXNnKSA9PSBUUlVFKSAmJiAoZW1lcmdlbmN5ID09IFRSVUUpKSB7DQo+ Pj4+Pj4+ICAvLyBhbGwgdGhlIGVtZXJnZW5jeSByZWxhdGVkIHByb2Nlc3NpbmcgZG9uZSBhbHJl YWR5IHVwZnJvbnQNCj4+Pj4+Pj4gIC8vIGhlbmNlIEkgbG9nIHNvbWV0aGluZy4NCj4+Pj4+Pj4g IGxvZyhSUEhfV0FTX1BSRVNFTlRfSlVIVSk7DQo+Pj4+Pj4+fSBlbHNlIGlmICgocnBoLXByZXNl bnQobXNnKSA9PSBUUlVFKSAmJiAoZW1lcmdlbmN5ID09DQo+Pj5GQUxTRSkpIHsNCj4+Pj4+Pj4v LyB0aGlzIGlzIG5vdCBhbiBlbWVyZ2VuY3kgY2FsbCAgLy8gdGhpcyBpcyBzb21ldGhpbmcNCj4+ Pmxpa2UgR0VUUw0KPj4+Pj4+PnJlc3VsdD1zcGVjaWFsLWF1dGhvcml6YXRpb24tcHJvY2VkdXJl KHVzZXIpOw0KPj4+Pj4+Pg0KPj4+Pj4+PmlmIChyZXN1bHQgPT0gQVVUSE9SSVpFRCkgew0KPj4+ Pj4+PiAgIC8vIGRvIHNvbWUgcHJpb3JpdHkgJiBwcmVlbXB0aW9uIHRoaW5nIGhlcmUuDQo+Pj4+ Pj4+ICAgLy8gdHJpZ2dlciBhbGwgdGhlIFFvUyB5b3UgaGF2ZQ0KPj4+Pj4+PiAgIGxvdHMtb2Yt Y29kZS1oZXJlKCk7DQo+Pj4+Pj4+fSBlbHNlIHsNCj4+Pj4+Pj4gICBsb2coIk5PVCBBVVRIT1JJ WkVEOyBkb24ndCBEb1MgbXkgbmV0d29yayIpOyAgfSB9IGVsc2UgeyAgLy8NCj4+Pj4+Pj5kb24n dCBuZWVkIHRvZG8gYW55IFJQSCBwcm9jZXNzaW5nICAvLyB0aGlzIGluY2x1ZGVzIHRoZSBjYXNl DQo+Pj4+Pj4+d2hlcmUgdGhlIGNhbGwgd2FzIGFuIGVtZXJnZW5jeSBjYWxsIGJ1dCB0aGUgUlBI DQo+Pj4+Pj4+DQo+Pj4+Pj4+Ly8gbWFya2luZyB3YXMgbm90IHRoZXJlLg0KPj4+Pj4+Pm5vdGhp bmcoKTsNCj4+Pj4+Pj59DQo+Pj4+Pj4+DQo+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+Q2lh bw0KPj4+Pj4+Pkhhbm5lcw0KPj4+Pj4+Pg0KPj4+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4+Pj4+Pj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+Pj4+QmVoYWxmIE9mIEhhbm5lcyBUc2Nob2Zlbmln DQo+Pj4+Pj4+PlNlbnQ6IDA2IEZlYnJ1YXJ5LCAyMDA5IDE1OjA3DQo+Pj4+Pj4+PlRvOiAnSmFu ZXQgUCBHdW5uJw0KPj4+Pj4+Pj5DYzogJ0VDUklUJzsgZWNyaXQtYm91bmNlc0BpZXRmLm9yZzsg VHNjaG9mZW5pZyxIYW5uZXMgKE5TTiAtDQo+Pj4+Pj4+RkkvRXNwb28pDQo+Pj4+Pj4+PlN1Ympl Y3Q6IFJlOiBbRWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nOiBBZ2VuZGEgKFJQ SCkNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PldobyB3b3VsZCBkZWZpbmUgc29tZXRoaW5nIHRoYXQgY291 bGQgcHJldmVudCBEb1MgcHJvYmxlbXM/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgRnJvbTogSmFu ZXQgUCBHdW5uIFttYWlsdG86amd1bm42QGNzYy5jb21dDQo+Pj4+Pj4+PiAgICAgICAgIFNlbnQ6 IDA2IEZlYnJ1YXJ5LCAyMDA5IDE0OjExDQo+Pj4+Pj4+PiAgICAgICAgIFRvOiBIYW5uZXMgVHNj aG9mZW5pZw0KPj4+Pj4+Pj4gICAgICAgICBDYzogJ0JyaWFuIFJvc2VuJzsgJ0RSQUdFLCBLZWl0 aCAoS2VpdGgpJzsgJ0VDUklUJzsNCj4+Pj4+Pj4+ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzsgVHNj aG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7DQo+Pj4+J0phbWVzDQo+Pj4+Pj4+Pk0u IFBvbGsnDQo+Pj4+Pj4+PiAgICAgICAgIFN1YmplY3Q6IFJlOiBbRWNyaXRdIEVDUklUIFZpcnR1 YWwgSW50ZXJpbQ0KPj4+TWVldGluZzogQWdlbmRhIChSUEgpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgIEJ1dCB0aGVyZSBpcyBub3RoaW5nIElOIFJGQzQ0 MTIgdGhhdCBzcGVjaWZpY2FsbHkNCj4+Pj4+PmFkZHJlc3NlcyBob3cgdG8NCj4+Pj4+Pj4+cHJl dmVudCBhbnkgcGFydGljdWxhciBuYW1lc3BhY2UgYmVpbmcgdXNlZCBmb3IgRG9TLiAgQW55b25l L2FueQ0KPj4+PlVBDQo+Pj4+Pj4+PmNhbiBBVFRFTVBUIHRvIGludm9rZSBwcmlvcml0eSB0cmVh dG1lbnQgYnkgYXR0YWNoaW5nIFJQSC4gIEZvcg0KPj4+PmFsbA0KPj4+Pj4+Pj5vZiB0aGUgNDQx MiBuYW1lc3BhY2VzLCBhcyB3aXRoIHRoZSBuZXcgcHJvcG9zZWQgbmFtZXNwYWNlLCB0aGUNCj4+ Pj4+Pj4+bWVjaGFuaXNtcyBmb3IgcHJldmVudGluZyBEb1MgYXJlIG5vdCBzcGVjaWZpZWQgaW4g dGhlDQo+Pj4+Pj5kb2N1bWVudCB0aGF0DQo+Pj4+Pj4+PmRlZmluZXMgdGhlIG5hbWVzcGFjZS4N Cj4+Pj4+Pj4+VGhleSBhcmUvd2lsbCBiZSBzcGVjaWZpZWQgZWxzZXdoZXJlLg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+ICAgICAgICAgSmFuZXQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgIFRoaXMg aXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4+Pj4+ cmVjaXBpZW50LA0KPj4+Pj4+Pj5wbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2lu ZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YNCj4+Pj50aGUNCj4+Pj4+Pj4+bWlzdGFrZSBpbiBk ZWxpdmVyeS4NCj4+Pj4+Pj4+ICAgICAgICAgTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0 aGlzIGUtbWFpbCBzaGFsbCBub3QNCj4+Pj4+Pm9wZXJhdGUgdG8gYmluZA0KPj4+Pj4+Pj5DU0Mg dG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNp dA0KPj4+Pj4+Pj53cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhw cmVzc2x5IHBlcm1pdHRpbmcNCj4+Pj50aGUNCj4+Pj4+Pj4+dXNlIG9mIGUtbWFpbCBmb3Igc3Vj aCBwdXJwb3NlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgZWNyaXQtYm91bmNlc0BpZXRm Lm9yZyB3cm90ZSBvbiAwMi8wNi8yMDA5IDA0OjIxOjUxIEFNOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ ICAgICAgICAgPiBIaSBKYW1lcywNCj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4gICAgICAg ICA+IEkgaGF2ZSByZWFkIFJGQyA0NDEyIGFuZCBhbHNvIHRoZSBHRVRTL01MUFAgSUVURg0KPj4+ Pj4+ZG9jdW1lbnRzLiBXaGF0IEkNCj4+Pj4+Pj4+d291bGQNCj4+Pj4+Pj4+ICAgICAgICAgPiBs aWtlIHRvIHBvaW50IG91dCBpcyB0aGF0IHRoZXJlIGlzIG1vcmUgdGhhbiBqdXN0IGENCj4+Pj4+ PmhlYWRlciBhbmQNCj4+Pj4+Pj4+dmFsdWVzIHdpdGhpbg0KPj4+Pj4+Pj4gICAgICAgICA+IHRo ZSBoZWFkZXIgdGhhdCBoYXZlIHRvIGJlIGNvbnNpZGVyZWQgaW4gb3JkZXIgdG8NCj4+Pj4+Pm1h a2UgYSBqdWRnZW1lbnQNCj4+Pj4+Pj4+b2Ygd2hhdA0KPj4+Pj4+Pj4gICAgICAgICA+IGlzIGFw cHJvcHJpYXRlIGFuZCB3aGF0IGlzbid0LiBUaGVyZSBpcyBhbg0KPj4+Pj4+YXJjaGl0ZWN0dXJh bCBxdWVzdGlvbg0KPj4+Pj4+Pj5hbmQNCj4+Pj4+Pj4+ICAgICAgICAgPiB3aGV0aGVyIHRoZSBl bnZpcm9ubWVudCB3ZSBhcmUgdXNpbmcgdGhlIHN0dWZmIGlzDQo+Pj4+Pj5pbmRlZWQgcHJvdmlk aW5nDQo+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+IHByb3BlcnRpZXMgeW91IG5lZWQg Zm9yIHRoZSBzb2x1dGlvbiB0byBiZQ0KPj4+YXBwcm9wcmlhdGUuDQo+Pj4+Pj4+PiAgICAgICAg ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiBMZXQgbWUgZGVzY3JpYmUgaW4gbW9yZSBkZXRhaWwgd2hh dCBJIG1lYW50IChhbmQNCj4+Pj4+PnBsZWFzZSBjb3JyZWN0IG1lDQo+Pj4+Pj4+PmlmIEkgYW0N Cj4+Pj4+Pj4+ICAgICAgICAgPiB3cm9uZykuDQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+ ICAgICAgICAgPiBHZXR0aW5nIHByaW9yaXR5IGZvciBTSVAgcmVxdWVzdHMgd2hlbiB1c2luZyBh IEdFVFMNCj4+Pj4+PmFsaWtlIHNjZW5hcmlvDQo+Pj4+Pj4+Pm1lYW5zDQo+Pj4+Pj4+PiAgICAg ICAgID4gdGhhdCB0aGUgZW50aXR5IHRoYXQgaXNzdWVzIHRoZSByZXF1ZXN0IGlzIHNwZWNpYWxs eQ0KPj4+Pj4+YXV0aG9yaXplZA0KPj4+Pj4+Pj5zaW5jZQ0KPj4+Pj4+Pj4gICAgICAgICA+IG90 aGVyd2lzZSB5b3UgaW50cm9kdWNlIGEgbmljZSBkZW5pYWwgb2YNCj4+PnNlcnZpY2UgYXR0YWNr LiBUaGlzDQo+Pj4+Pj4+PmF1dGhvcml6YXRpb24NCj4+Pj4+Pj4+ICAgICAgICAgPiBpcyB0aWVk IHRvIHRoZSBlbnRpdHkgdGhhdCBtYWtlcyB0aGUgcmVxdWVzdC4gRm9yDQo+Pj4+Pj5leGFtcGxl LCB0aGUNCj4+Pj4+Pj4+cGVyc29uIGlzDQo+Pj4+Pj4+PiAgICAgICAgID4gd29ya2luZyBmb3Ig dGhlIGdvdmVybm1lbnQgYW5kIGhhcyBzcGVjaWFsIHJpZ2h0cy4NCj4+Pj4+Pj4+SmFtZXMgQm9u ZCBhcyBhIChub3Qgc28pDQo+Pj4+Pj4+PiAgICAgICAgID4gc2VjcmV0IGFnZW50IG1pZ2h0IGhh dmUgdGhlc2UgcmlnaHRzLg0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+PiAgICAgICAgID4g VGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyBjYXNlDQo+Pj4oY2l0aXplbi10by1hdXRob3JpdHkpIGlz IGEgYml0DQo+Pj4+Pj4+PmRpZmZlcmVudCBhcw0KPj4+Pj4+Pj4gICAgICAgICA+IHRoZXJlIGFy ZW4ndCByZWFsbHkgc3BlY2lhbCByaWdodHMgd2l0aCByZXNwZWN0IHRvDQo+Pj4+Pj5hdXRob3Jp emF0aW9uDQo+Pj4+Pj4+PnRpZWQgdG8NCj4+Pj4+Pj4+ICAgICAgICAgPiBpbmRpdmlkdWFscy4g SW5zdGVhZCwgdGhlIGZhY3QgdGhhdCBzb21ldGhpbmcgaXMgYW4NCj4+Pj4+PmVtZXJnZW5jeSBp cw0KPj4+Pj4+Pj5wdXJlbHkgYQ0KPj4+Pj4+Pj4gICAgICAgICA+IGp1ZGdlbWVudCBvZiB0aGUg aHVtYW4gdGhhdCBkaWFscyBhIHNwZWNpYWwgbnVtYmVyLg0KPj4+Pj4+Pj5UbyBkZWFsIHdpdGgg ZnJhdWQsIHdlDQo+Pj4+Pj4+PiAgICAgICAgID4gZGlzY3Vzc2VkIGluIHRoZSBncm91cCBvbiB3 aGF0IHdlIGNhbiBhY3R1YWxseSBkbyB0bw0KPj4+Pj4+ZW5zdXJlIHRoYXQNCj4+Pj4+Pj4+ZW5k IHVzZXJzDQo+Pj4+Pj4+PiAgICAgICAgID4gZG8gbm90IGJ5cGFzcyBzZWN1cml0eSBwcm9jZWR1 cmVzIChzdWNoIGFzDQo+Pj4+Pj5hdXRob3JpemF0aW9uIGNoZWNrcywNCj4+Pj4+Pj4+Y2hhcmdp bmcNCj4+Pj4+Pj4+ICAgICAgICAgPiBhbmQgc28gb24pLiBQYXJ0IG9mIHRoaXMgaW52ZXN0aWdh dGlvbiB3YXMNCj4+PnRoZSBwdWJsaWNhdGlvbiBvZg0KPj4+Pj4+Pj4gICAgICAgICA+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzUwNjkudHh0IHRoYXQgYWxzbw0KPj4+ZGVzY3JpYmVzIHRo aXMNCj4+Pj4+Pj4+aXNzdWUuDQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+ICAgICAgICAg PiBTbywgaW1hZ2luZSB0aGUgaW1wbGVtZW50YXRpb24gb2YgYSBTSVAgcHJveHkgKGFuZCB3ZQ0K Pj4+Pj4+aW1wbGVtZW50ZWQNCj4+Pj4+Pj4+dGhhdA0KPj4+Pj4+Pj4gICAgICAgICA+IHN0dWZm KSB0aGF0IHJlY2VpdmVzIGEgY2FsbCB0aGF0IGNvbnRhaW5zIGEgU2VydmljZQ0KPj4+Pj4+VVJO LiBUaGUgY29kZQ0KPj4+Pj4+Pj5icmFuY2hlcw0KPj4+Pj4+Pj4gICAgICAgICA+IGludG8gYSBz cGVjaWFsIG1vZGUgd2hlcmUgZXZlcnl0aGluZyBpcyBkb25lDQo+Pj5zbyB0aGF0IHRoZSBjYWxs DQo+Pj4+Pj4+PnJlY2VpdmVzDQo+Pj4+Pj4+PiAgICAgICAgID4gYXBwcm9wcmlhdGUgdHJlYXRt ZW50IGFuZCBkb2VzIG5vdCBnZXQgZHJvcHBlZCBvbiB0aGUNCj4+Pj4+PmZsb29yLiBUaGUNCj4+ Pj4+Pj4+d2F5IGhvdyB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiBTZXJ2aWNlIFVSTiBpcyBwbGFj ZWQgaW4gdGhlIG1lc3NhZ2UgZW5zdXJlcyB0aGF0IHRoZQ0KPj4+Pj4+Y2FsbCBjYW5ub3QNCj4+ Pj4+Pj4+Z28gdG8gbXkNCj4+Pj4+Pj4+ICAgICAgICAgPiBmcmllbmQgKGluc3RlYWQgb2YgdGhl IFBTQVApIHVubGVzcyB0aGUgZW5kIGhvc3QgcmFuDQo+Pj4+Pj5Mb1NUIGFscmVhZHkuDQo+Pj4+ Pj4+PkluIHRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+IGxhdHRlciBjYXNlLCB3ZSBkaXNjdXNzZWQg dGhpcyBhbHNvIG9uIHRoZSBsaXN0IGZvciBhDQo+Pj4+Pj53aGlsZSBhbmQNCj4+Pj4+Pj4+Umlj aGFyZCBldmVuDQo+Pj4+Pj4+PiAgICAgICAgID4gd3JvdGUgYSBkcmFmdCBhYm91dCBpdCBpbiB0 aGUgY29udGV4dCBvZiB0aGUNCj4+PmxvY2F0aW9uIGhpZGluZw0KPj4+Pj4+Pj50b3BpYywgd2Ug c2FpZA0KPj4+Pj4+Pj4gICAgICAgICA+IHRoYXQgdGhlIHByb3h5IHdvdWxkIGhhdmUgdG8gcnVu IExvU1QgaWYgaGUNCj4+PmNhcmVzIGFib3V0IGENCj4+Pj4+Pj4+cG90ZW50aWFsDQo+Pj4+Pj4+ PiAgICAgICAgID4gZnJhdWR1bGVudCB1c2FnZS4NCj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+ Pj4gICAgICAgICA+IFNvLCB3aGF0IGRvIHdlIG5lZWQgdG9kbyBpbiBvcmRlciB0byBwcm92aWRl DQo+Pj5zZWN1cmUgUkZDIDQ0MTINCj4+Pj4+Pj4+ZnVuY3Rpb25hbGl0eQ0KPj4+Pj4+Pj4gICAg ICAgICA+IGluIG91ciBjb250ZXh0Pw0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+PiAgICAg ICAgID4gRG8geW91IHRoaW5rIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCBpbg0KPj4+Pj4+Pj4gICAg ICAgICA+DQo+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtZWNyaXQtbG9jYWwtZW1lcg0KPj4+Pj4+Pj5nZW5jeS1ycGgtbmFtDQo+Pj4+Pj4+PiAg ICAgICAgID4gZXNwYWNlLTAwLnR4dCByZWZsZWN0cyBhbnkgb2YgdGhlDQo+Pj5hYm92ZS1kZXNj cmliZWQgaXNzdWVzOg0KPj4+Pj4+Pj4gICAgICAgICA+ICINCj4+Pj4+Pj4+ICAgICAgICAgPiAg ICBUaGUgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhhdCBhcHBseSB0byBSRkMgNDQxMg0KPj4+ Pj4+Pj5bUkZDNDQxMl0NCj4+Pj4+Pj4+YXBwbHkNCj4+Pj4+Pj4+ICAgICAgICAgPiAgICBoZXJl LiAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5vIG5ldyBzZWN1cml0eQ0KPj4+Pj4+Pj5pc3N1 ZXMgcmVsYXRpdmUNCj4+Pj4+Pj4+dG8NCj4+Pj4+Pj4+ICAgICAgICAgPiAgICBSRkMgNDQxMi4N Cj4+Pj4+Pj4+ICAgICAgICAgPiAiDQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+ICAgICAg ICAgPiBGcm9tIHZhcmlvdXMgZGlzY3Vzc2lvbnMgaW4gR0VPUFJJViBJIHJlY2FsbA0KPj4+dGhh dCB5b3UgYXJlDQo+Pj4+Pj4+PnN1cGVyLXNlbnNpdGl2ZQ0KPj4+Pj4+Pj4gICAgICAgICA+IHJl Z2FyZGluZyBzZWN1cml0eSBhbmQgcHJpdmFjeS4gRm9yIHNvbWUgcmVhc29ucyB5b3UNCj4+Pj4+ PmRvbid0IHNlZW0gdG8NCj4+Pj4+Pj4+aGF2ZSB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiBzYW1l IGNvbmNlcm5zIGhlcmUuIEkgd291bGQgbGlrZSB0bw0KPj4+dW5kZXJzdGFuZCB5b3VyIHJlYXNv bmluZy4NCj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4gICAgICAgICA+IFBsZWFzZSBhbHNv IGRvIG1lIGFub3RoZXIgZmF2b3I6IERvbid0IGFsd2F5cyBzYXkNCj4+Pj4+PnRoYXQgSSBkb24n dA0KPj4+Pj4+Pj51bmRlcnN0YW5kDQo+Pj4+Pj4+PiAgICAgICAgID4gdGhlIHN1YmplY3QuIEV2 ZW4gaWYgdGhhdCB3b3VsZCBiZSB0aGUgY2FzZSBpdCBpc24ndA0KPj4+Pj4+cGFydGljdWxhcg0K Pj4+Pj4+Pj5mYWlyIGdpdmVuDQo+Pj4+Pj4+PiAgICAgICAgID4gdGhhdCBkaWZmZXJlbnQgZm9s a3MgaGFkIHRvIGVkdWNhdGUgeW91IG9uIG90aGVyDQo+Pj4+Pj50b3BpY3MgaW4gdGhlDQo+Pj4+ Pj4+PnBhc3QgYXMgd2VsbC4NCj4+Pj4+Pj4+ICAgICAgICAgPiBBZGRpdGlvbmFsbHksIGlmIHlv dSBsaXN0ZW4gdG8gdGhlIGF1ZGlvIHJlY29yZGluZ3MNCj4+Pj4+PnRoZW4geW91IHdpbGwNCj4+ Pj4+Pj4+bm90aWNlDQo+Pj4+Pj4+PiAgICAgICAgID4gdGhhdCBIZW5uaW5nLCBUZWQsIGFuZCBK b24gZG8gbm90IHNlZW0gdG8gdW5kZXJzdGFuZA0KPj4+Pj4+dGhlIGlzc3VlDQo+Pj4+Pj4+PmVp dGhlciBhcw0KPj4+Pj4+Pj4gICAgICAgICA+IHRoZXkgaGF2ZSByYWlzZWQgc2ltaWxhciBpc3N1 ZXMgZHVyaW5nIHRoZQ0KPj4+RjJGIG1lZXRpbmdzLg0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+ Pj4+PiAgICAgICAgID4gQ2lhbw0KPj4+Pj4+Pj4gICAgICAgICA+IEhhbm5lcw0KPj4+Pj4+Pj4g ICAgICAgICA+DQo+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+SGFubmVz IC0gSSBiZWxpZXZlIGl0IGlzIHlvdSB3aG8gZG8gbm90IHVuZGVyc3RhbmQNCj4+Pj4+PlJGQyA0 NDEyIC0tDQo+Pj4+Pj4+PiAgICAgICAgID4gPmFuZCBtYW55IG9mIHVzIGFyZSB0cnlpbmcgdG8g Z2V0IHRoYXQNCj4+PnRocm91Z2ggdG8geW91LCBidXQgeW91DQo+Pj4+Pj4+PiAgICAgICAgID4g PmRvbid0IHNlZW0gdG8gd2FudCB0byBsaXN0ZW4vcmVhZC4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+ DQo+Pj4+Pj4+PiAgICAgICAgID4gPlJGQyA0NDEyIGlzICpmb3IqIHByaW9yaXR5IG1hcmtpbmcg U0lQIHJlcXVlc3RzLA0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+ T25lIHVzZSBpcyBHRVRTLg0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAg PiA+T25lIHVzZSBpcyBNTFBQLg0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAg ICAgPiA+VGhlc2UgZXhhbXBsZXMgYXJlIGluIFJGQyA0NDEyIGJlY2F1c2UgdGhlcmUNCj4+Pndl cmUgc3BlY2lmaWMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+bmFtZXNwYWNlcyBiZWluZyBjcmVhdGVk IGZvciB0aGUgSUFOQSBzZWN0aW9uIG9mDQo+Pj4+Pj50aGF0IGRvY3VtZW50Lg0KPj4+Pj4+Pj4g ICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+UmVhZGluZyB0aGUgd2hvbGUgZG9jdW1l bnQsIHlvdSB3aWxsIHNlZQ0KPj4+dGhhdCBSUEggY2FuIGJlDQo+Pj4+Pj4+PiAgICAgICAgID4g PnNwZWNpZmllZCBmb3Igb3RoZXIgdXNlcyB0aGFuIEdFVFMgb3IgTUxQUA0KPj4+c3BlY2lmaWNh bGx5Lg0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+SSBrbmV3IHdo ZW4gSSB3cm90ZSBSRkMgNDQxMiB0aGF0IG9uZSBkYXkgd2UNCj4+PndvdWxkIHNwZWNpZnkgYQ0K Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3BhY2UgZm9yIEVDUklUICh0aGUgImVzbmV0IiBuYW1l c3BhY2UNCj4+Pm5vdykgLS0gYnV0IEkgYWxzbw0KPj4+Pj4+Pj4gICAgICAgICA+ID5rbmV3IGl0 IHdhcyBwcmVtYXR1cmUgZm9yIFJGQyA0NDEyIHRvDQo+Pj5pbmNvcnBvcmF0ZSB0aGF0DQo+Pj4+ Pj4+PiAgICAgICAgID4gPm5hbWVzcGFjZSwgdGhhdCBhIGZ1dHVyZSBkb2MgdG8gUkZDIDQ0MTIN Cj4+PndvdWxkIGhhdmUgdG8gYmUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+d3JpdHRlbiB0byBkbyB0 aGlzLiBCcmlhbiBhbmQgSSB0YWxrZWQgYWJvdXQNCj4+PnRoaXMgYXQgdGhlDQo+Pj4+Pj4+PiAg ICAgICAgID4gPm9yaWdpbmFsIE5FTkEgbWVldGluZyB0aGF0IGNyZWF0ZWQgdGhlIElQIFdHcyB0 aGVyZQ0KPj4+Pj4+KGluIEF1Z3VzdA0KPj4+Pj4+Pj4gICAgICAgICA+ID5vZiAwMykuICBXZSBi b3RoIGFncmVlZCB3ZSBzaG91bGQgd2FpdCB1bnRpbCBpdCB3YXMNCj4+Pj4+Pj4+ICAgICAgICAg PiA+YXBwcm9wcmlhdGUgdG8gdGhlIHdvcmsgaW4gdGhlIElFVEYgdG8NCj4+PnN1Ym1pdCB0aGlz IGRvY3VtZW50DQo+Pj4+Pj4+PiAgICAgICAgID4gPnRoYXQgaXMgbm93DQo+Pj4+Pj4+PiAgICAg ICAgID4NCj4+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtZWNyaXQtbG9jYWwtZW1lcg0KPj4+Pj4+Pj4gICAgICAgICA+ID5nZW5jeS1ycGgtbmFt ZXNwYWNlLTAwLnR4dA0KPj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+ WWV0LCB5b3Ugc2VlbSB0byB3YW50IHRvIHVzZSBzb21lIGFkZGl0aW9uYWwNCj4+Pm1lY2hhbmlz bSB0bw0KPj4+Pj4+Pj4gICAgICAgICA+ID5pbmRpY2F0ZSBwcmlvcml0eSBvZiBhIGNhbGwgaW4g U0lQLiAgVGhhdA0KPj4+bWVhbnMgeW91IHdhbnQgdG8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+aW50 cm9kdWNlIGEgc2Vjb25kIHdheSB0byBhY2NvbXBsaXNoIHRoaXMgaW4gU0lQLg0KPj4+Pj4+Pj5X aHkgZG8geW91DQo+Pj4+Pj4+PiAgICAgICAgID4gPndhbnQgdG8gcHJvbW90ZSBhIHNlcGFyYXRl IHdheSB0byBkbyBzb21ldGhpbmcgU0lQDQo+Pj4+Pj5oYXMgYWxyZWFkeQ0KPj4+Pj4+Pj4gICAg ICAgICA+ID5kZWZpbmVkPyBUaGF0IHdpbGwgY2F1c2UgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMg YW5kDQo+Pj4+Pj53ZSBib3RoIGtub3cNCj4+Pj4+Pj4+dGhhdC4NCj4+Pj4+Pj4+ICAgICAgICAg PiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPllvdSd2ZSBzYWlkIHRvIG1lIChhbmQgb3RoZXJzKSB0 aGF0IHlvdQ0KPj4+YmVsaWV2ZSBSUEggaXMganVzdA0KPj4+Pj4+Pj4gICAgICAgICA+ID5hbm90 aGVyIHdheSB0byBhY2NvbXBsaXNoIHdoYXQgc29zIG9yIGEgVVJJIGNhbg0KPj4+Pj4+aW5kaWNh dGUgLSBhbmQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+eW91J3JlIHdyb25nLiAgWW91ciB3YXkgd291 bGQgYmUNCj4+Pl90aGVfc2Vjb25kX3dheV90b19kb19pdCwNCj4+Pj4+Pj4+ICAgICAgICAgPiA+ YmVjYXVzZSBTSVAgYWxyZWFkeSBjb25zaWRlcnMgUlBIIHRvIGJlDQo+Pj4qdGhlKndheSogdG8g cHJpb3JpdHkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+bWFyayBTSVAgcmVxdWVzdHMuDQo+Pj4+Pj4+ PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID5JZiB5b3UgZG9uJ3QgYmVsaWV2ZSBt ZSAobm8gY29tbWVudCksIHRoZW4NCj4+PndoeSBkbyB5b3Ugbm90DQo+Pj4+Pj4+PiAgICAgICAg ID4gPmJlbGlldmUgdGhlIFNJUCBXRyBjaGFpciAod2hvIGtub3dzIG1vcmUNCj4+PmFib3V0IFNJ UCB0aGFuIGJvdGgNCj4+Pj4+Pj4+ICAgICAgICAgPiA+b2YgdXMpIC0gd2hvLCBvbiB0aGlzIHRo cmVhZCwgaGFzIGFnYWluIHNhaWQNCj4+PnRvIHlvdSAiUkZDIDQ0MTINCj4+Pj4+Pj4+ICAgICAg ICAgPiA+KFJQSCkgaXMgdGhlIFNJUCBtZWNoYW5pc20gdG8gcHJpb3JpdHkgbWFyaw0KPj4+U0lQ IHJlcXVlc3RzIj8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPkZ1 cnRoZXIsIEkgYmVsaWV2ZSBpdCBpcyBpbmFwcHJvcHJpYXRlIHRvDQo+Pj5wcm9oaWJpdCBlbmRw b2ludHMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+ZnJvbSBiZWluZyBhYmxlIHRvIHNldCB0aGUgZXNu ZXQgbmFtZXNwYWNlLg0KPj4+SSBhYnNvbHV0ZWx5DQo+Pj4+Pj4+PiAgICAgICAgID4gPmJlbGll dmUgaXQgd2lsbCBub3QgYmUgbmVlZGVkIG1vc3Qgb2YgdGhlDQo+Pj50aW1lLCBidXQgSSBiZWxp ZXZlDQo+Pj4+Pj4+PiAgICAgICAgID4gPmlmIHNvbWVvbmUgZG9lcyBmaW5kIGEgdmFsaWQgdXNl IGZvcg0KPj4+ZW5kcG9pbnRzIHRvIG1hcmsNCj4+Pj4+Pj4+ICAgICAgICAgPiA+cHJpb3JpdHkg aW4gU0lQLCB0aGlzIElEIC0gb25jZSBpdCBoYXMNCj4+PmJlY29tZSBhbiBSRkMgLS0gd2lsbA0K Pj4+Pj4+Pj4gICAgICAgICA+ID5oYXZlIHRvIGJlIG9ic29sZXRlZCB3aXRoIGEgbmV3IFJGQyBz YXlpbmcgdGhlIGV4YWN0DQo+Pj4+Pj5vcHBvc2l0ZS4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+ Pj4+Pj4+PiAgICAgICAgID4gPihjb2xvciBtZSBjb25mdXNlZCAuLi4gb3ZlciBhbmQgb3ZlciBh Z2FpbikNCj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPkphbWVzDQo+ Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID5BdCAwMTowNSBQTSAyLzUv MjAwOSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+Pj4+PiAgICAgICAgID4gPj5LZWl0 aCwgcGxlYXNlIHVuZGVyc3RhbmQgdGhhdCB0aGUgdXNhZ2Ugb2YgUkZDIDQ0MTINCj4+Pj4+PmZv ciBHRVRTIGFuZA0KPj4+Pj4+Pj5mb3INCj4+Pj4+Pj4+ICAgICAgICAgPiA+PnRoZSB0eXBlIG9m IGVtZXJnZW5jeSBjYWxsIHdlIGRpc2N1c3MgaGVyZSBpcw0KPj4+Pj4+ZGlmZmVyZW50LiBKdXN0 DQo+Pj4+Pj4+Pmxvb2tpbmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PmF0IHRoZSBoZWFkZXIgYW5k IHRoZSBuYW1lIG9mIHRoZSBuYW1lc3BhY2UgaXMgYSBiaXQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+ YXJ0aWZpY2lhbC4gSSBob3BlDQo+Pj4+Pj4+PiAgICAgICAgID4gPj55b3UgdW5kZXJzdGFuZCB0 aGF0Lg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPkZyb206IERSQUdF LCBLZWl0aCAoS2VpdGgpDQo+Pj4+Pj4+PlttYWlsdG86ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29t XQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TZW50OiAwNSBGZWJydWFyeSwgMjAwOSAxNDo1NQ0K Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5UbzogQnJpYW4gUm9zZW47ICdIYW5uZXMgVHNjaG9mZW5p Zyc7ICdKYW1lcyBNLg0KPj4+Pj4+Pj5Qb2xrJzsgJ1RzY2hvZmVuaWcsDQo+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPkhhbm5lcyAoTlNOIC0gRkkvRXNwb28pJzsgJ0VDUklUJw0KPj4+Pj4+Pj4gICAg ICAgICA+ID4+ID5TdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsIEludGVyaW0NCj4+ Pj4+Pj4+TWVldGluZzogQWdlbmRhIChteQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+ PiA+bWlzdGFrZSkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAgID4g Pj4gPldoaWNoIGlzIGV4YWN0bHkgd2hhdCBSRkMgNDQxMiBzcGVjaWZpZXMgZm9yIGFsbA0KPj4+ Pj4+bmFtZXNwYWNlcy4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPnJlZ2FyZHMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPktlaXRoDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4g Pj4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+W21haWx0bzplY3JpdC1ib3Vu Y2VzQGlldGYub3JnXQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5PbiBCZWhhbGYNCj4+Pj4+Pj4+ ICAgICAgICAgPiA+PiA+PiBPZiBCcmlhbiBSb3Nlbg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIwMDkgMTA6MTkgUE0NCj4+Pj4+Pj4+ICAg ICAgICAgPiA+PiA+PiBUbzogJ0hhbm5lcyBUc2Nob2ZlbmlnJzsgJ0phbWVzIE0uDQo+Pj5Qb2xr JzsgJ1RzY2hvZmVuaWcsDQo+Pj4+Pj4+PiAgICAgICAgID4gPkhhbm5lcyAoTlNODQo+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gLSBGSS9Fc3BvbyknOyAnRUNSSVQnDQo+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gU3ViamVjdDogUmU6IFtFY3JpdF0gRUNSSVQgVmlydHVhbCBJbnRlcmltDQo+Pj4+ Pj4+Pk1lZXRpbmc6IEFnZW5kYSAobXkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBtaXN0YWtl KQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gVGhl IHZhbHVlIGlzIHRoYXQgaW4gc29tZSBuZXR3b3Jrcw0KPj4+d2hlcmUgcHJpb3JpdHkgZm9yDQo+ Pj4+Pj4+PiAgICAgICAgID4gPj4gPmVtZXJnZW5jeSBjYWxscw0KPj4+Pj4+Pj4gICAgICAgICA+ ID4+ID4+IGlzIGFwcHJvcHJpYXRlLCBhbmQgYXBwcm9wcmlhdGUNCj4+PnBvbGljaW5nIG9mIG1h cmtpbmcgaXMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+aW1wbGVtZW50ZWQsDQo+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gZW1lcmdlbmN5IGNhbGxzIHdpbGwgcmVjZWl2ZSByZXNvdXJjZSBwcmlvcml0 eS4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IE5v dCBhbGwgbmV0d29ya3Mgd291bGQgbmVlZCBwb2xpY2luZy4gIFNvbWUNCj4+Pj4+PndpbGwuICBQ b2xpY2luZw0KPj4+Pj4+Pj5jb3VsZA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGJlIHRvIFJv dXRlIGhlYWRlci9SLVVSSSBjb250ZW50LCBidXQgb3RoZXINCj4+Pj4+PmNyaXRlcmlhIGFyZQ0K Pj4+Pj4+Pj5wb3NzaWJsZS4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+IE5vdCBhbGwgbmV0d29ya3Mgd2lsbCBuZWVkIHJlc291cmNlIHByaW9yaXR5 DQo+Pj4+Pj5mb3IgZW1lcmdlbmN5DQo+Pj4+Pj4+PmNhbGxzLg0KPj4+Pj4+Pj4gICAgICAgICA+ ID4+ID4+IEZpbmUsIGlnbm9yZSB0aGlzIG1hcmtpbmcvbmFtZXNwYWNlLg0KPj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gQnJpYW4NCj4+Pj4+Pj4+ICAg ICAgICAgPiA+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+Pj5bbWFpbHRvOkhh bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXRdDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBTZW50 OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDA5IDU6MDkgUE0NCj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+PiA+IFRvOiAnQnJpYW4gUm9zZW4nOyAnSmFtZXMgTS4gUG9sayc7DQo+Pj4+Pj5Uc2No b2ZlbmlnLCBIYW5uZXMNCj4+Pj4+Pj4+KE5TTiAtDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4g PiBGSS9Fc3Bvbyk7ICdFQ1JJVCcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+IFN1YmplY3Q6 IFJFOiBbRWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbQ0KPj4+Pj4+Pj5NZWV0aW5nOiBBZ2Vu ZGEgKG15DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBtaXN0YWtlKQ0KPj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+IEkgZG9uJ3QgZXZlbiBz ZWUgdGhlIHZhbHVlIGluIHBlcm1pdHRpbmcgdGhlDQo+Pj4+Pj5lbmRwb2ludCB0b2RvDQo+Pj4+ Pj4+PnRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gUlBIIG1hcmtpbmcuDQo+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gPiBJbiBhZGRpdGlvbiB0byB0aGUgc2VjdXJpdHkgY29uY2VybnMN Cj4+PnRoZXJlIGlzIGFsc28gdGhlDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPnByb2JsZW0gdGhh dA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gdGhlcmUgYXJlIG1vcmUgb3B0aW9ucyB0byBp bXBsZW1lbnQgd2l0aG91dA0KPj4+Pj4+YW4gYWRkaXRpb25hbA0KPj4+Pj4+Pj52YWx1ZS4NCj4+ Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5Gcm9t OiBCcmlhbiBSb3NlbiBbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XQ0KPj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPlNlbnQ6IDA1IEZlYnJ1YXJ5LCAyMDA5IDAwOjAzDQo+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gPiA+VG86ICdKYW1lcyBNLiBQb2xrJzsgJ0hhbm5lcyBUc2Nob2ZlbmlnJzsN Cj4+Pj4+PidUc2Nob2ZlbmlnLA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEhhbm5lcyAoTlNO IC0NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5GSS9Fc3BvbyknOyAnRUNSSVQnDQo+Pj4+ Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+U3ViamVjdDogUkU6IFtFY3JpdF0gRUNSSVQgVmlydHVh bA0KPj4+SW50ZXJpbSBNZWV0aW5nOg0KPj4+Pj4+Pj5BZ2VuZGEgKG15DQo+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gPiBtaXN0YWtlKQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPg0KPj4+ Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkhhbm5lcw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ ID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPlRoaXMgbWF0Y2hlcyBteSB1bmRlcnN0 YW5kaW5nDQo+Pj5wcmVjaXNlbHkuICBXZSB3aXNoIHRvDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4g Pj4gcGVybWl0IGVuZHBvaW50cw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRvIG1hcmsu IFdlIGRvIG5vdCByZXF1aXJlIGl0LCBhbmQNCj4+PmRvbid0IG5lY2Vzc2FyaWx5DQo+Pj4+Pj4+ PmV4cGVjdCBpdA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPmluIG1hbnkgKGV2ZW4NCj4+ Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5tb3N0KSBjYXNlcy4gIFdlIGRvbid0IHdpc2ggdG8g c2VlIHRoZQ0KPj4+Pj4+ZG9jdW1lbnQgcHJvaGliaXQNCj4+Pj4+Pj4+aXQuDQo+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+V2UgYWxsIHNlZW0gdG8gYWdyZWUgaXQgaGFzIHZhbHVlIHdpdGhp biB0aGUNCj4+Pj4+PkVtZXJnZW5jeQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TZXJ2aWNlcyBJ UA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPk5ldHdvcmtzLg0KPj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkJyaWFuDQo+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gPiA+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gRnJv bTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+Pj5bbWFpbHRvOmVjcml0LWJvdW5jZXNA aWV0Zi5vcmddDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+T24gQmVoYWxmDQo+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gPiA+PiBPZiBKYW1lcyBNLiBQb2xrDQo+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA0LCAyMDA5IDQ6MDEgUE0N Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZzsgVHNj aG9mZW5pZywNCj4+Pkhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBGSS9F c3Bvbyk7ICdFQ1JJVCcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFN1YmplY3Q6IFJl OiBbRWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbQ0KPj4+Pj4+Pj5NZWV0aW5nOg0KPj4+Pj4+ Pj4gICAgICAgICA+ID5BZ2VuZGEgKG15DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBt aXN0YWtlKQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+PiA+ID4+IEF0IDAyOjM3IFBNIDIvNC8yMDA5LCBIYW5uZXMNCj4+PlRzY2hvZmVuaWcg d3JvdGU6DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+ID4gSmFtZXMgd3JvdGU6DQo+ Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+ID4+IHlvdSBhcmUgdGhlIF9sb25lXyB2b2lj ZSBub3QNCj4+Pj4+PnN1cHBvcnRpbmcgdGhpcyBJRCwNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiA+ID4+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5MaXN0ZW5pbmcgdG8gdGhl IGF1ZGlvIHJlY29yZGluZyBvZiBwYXN0DQo+Pj4+Pj5tZWV0aW5ncyBJDQo+Pj4+Pj4+PmhhdmUg dG8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5zYXkgdGhhdA0KPj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPj4gPkkNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHdhcw0KPj4+ Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPm5vdCB0aGUgb25seSBwZXJzb25zIHJhaXNpbmcN Cj4+PmNvbmNlcm5zIGFib3V0IHRoZQ0KPj4+Pj4+Pj5kb2N1bWVudC4NCj4+Pj4+Pj4+ICAgICAg ICAgPiA+PiA+PiA+ID4+ID5UaGF0IHdhcyBwcm9iYWJseSB0aGUgcmVhc29uIHdoeSB5b3UNCj4+ Pj4+PmFncmVlZCB0byBsaW1pdA0KPj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiA+ID5zY29wZSBvZiB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5kb2N1bWVu dCAod2hpY2ggeW91IGRpZG4ndCBsYXRlciBkbykgdG8NCj4+Pj4+PmdldCBmb2xrcyB0bw0KPj4+ Pj4+Pj5hZ3JlZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRvIG1ha2UgaXQNCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IGEgV0cNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ ID4+ID5pdGVtLg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+ICAgICAg ICAgPiA+PiA+PiA+ID4+IHJlLWxpc3RlbiB0byB0aGUgYXVkaW8gcGxlYXNlDQo+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gVGVkJ3Mg Y29uY2VybnMgd2VyZSBjb25zaXN0ZW50IHdpdGggbW9zdA0KPj4+Pj4+Pj4oYWxsPykgb3RoZXIN Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBjb25jZXJucyAtLQ0KPj4+Pj4+Pj4gICAgICAgICA+ ID4+ID4+ID4gPj4gd2hpY2ggd2VyZSBiYXNlZCBvbiB0aGUgcHJlbWlzZSBvZiB3aGV0aGVyDQo+ Pj4+Pj5vciBub3QgdGhlDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gVUFDIHNob3VsZCBiZQ0K Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gdHJ1c3RlZCB0byBpbml0aWF0ZSB0aGUgbWFy a2luZyBvbiB0aGUNCj4+Pj4+PklOVklURS4gIFRoZQ0KPj4+Pj4+Pj5tb3N0DQo+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+PiByZWNlbnQgdmVyc2lvbiBoYXMgYmFja2VkIG9mZiB0aGlzDQo+ Pj50byBhICJjYW4iIC0tDQo+Pj4+Pj4+Pm1lYW5pbmcgbm90DQo+Pj4+Pj4+PiAgICAgICAgID4g Pj4gPnByb2hpYml0ZWQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IChpLmUuLCBubyAy MTE5IHRleHQpLiAgSSBhbHNvIGJhY2tlZCBvZmYNCj4+Pj4+PnRoZSB0ZXh0IGluDQo+Pj4+Pj4+ PnRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFNQIGRvbWFpbg0KPj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPj4gcGFydCB0byAiY2FuIiwgc3VjaCB0aGF0IHRoZXJlIGlzDQo+Pj5ubyAy MTE5IHRleHQNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+bWFuZGF0aW5nIG9yIGV2ZW4NCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHJlY29tbWVuZGluZyBpdHMgdXNhZ2UgdGhlcmUuIEkg YWxzbyBkbw0KPj4+Pj4+bm90IHByb2hpYml0DQo+Pj4+Pj4+Pml0cw0KPj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPnVzZSwgYmFzZWQgb24NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ IGxvY2FsIHBvbGljeS4gIEtlaXRoIGhhcyBjb21lIGZvcndhcmQgd2l0aA0KPj4+Pj4+dGhlIHNw ZWNpZmljDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gcmVxdWVzdCB0 aGF0IG5vbi1FU0luZXQgbmV0d29ya3MgYmUNCj4+Pj4+PmFsbG93ZWQgdG8gbWFyayBhbmQNCj4+ Pj4+Pj4+cGF5DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPmF0dGVudGlvbiB0bw0KPj4+Pj4+Pj4g ICAgICAgICA+ID4+ID4+ID4gPj4gdGhpcyBwcmlvcml0eSBpbmRpY2F0aW9uIC0tIHdpdGggSU1T IGFzDQo+Pj4+Pj50aGUgc3BlY2lmaWMNCj4+Pj4+Pj4+ZXhhbXBsZQ0KPj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPj4gaGUgd2lzaGVzIHRvIGhhdmUgdGhpcyB2YWxpZCBmb3IuDQo+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gV2hl cmUgdGhlcmUgaXMgbm8gZGlzYWdyZWVtZW50LCBzYXZlIGZvcg0KPj4+Pj4+eW91ciByZWNlbnQN Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5wdXNoYmFjayAtIGlzIGluDQo+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+PiB0aGUgRVNJbmV0LCB3aGljaCBpcyB3aGVyZSBCcmlhbg0KPj4+ aGFzIHJlcXVlc3RlZCBpdCdzDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+ZGVmaW5pdGlv biBpbiB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IElFVEYgb24gYmVoYWxmIG9m IE5FTkEuICBIZSdzIHRoZSBpMyBXRw0KPj4+Pj4+Y2hhaXIgd2l0aGluDQo+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gTkVOQSwgYW5kIGlmDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBo ZSBhc2tzIGZvciBpdCwgYXJlIHlvdSBnb2luZyB0byBzYXkgeW91DQo+Pj4+Pj5rbm93IGJldHRl cg0KPj4+Pj4+Pj50aGFuIGhlPw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+ QnR3LCBJIG5vdCBkaXNhZ3JlZWluZyB3aXRoIHRoZSBkb2N1bWVudA0KPj4+Pj4+YXMgc3VjaC4g SQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID5qdXN0IHdhbnQgdG8NCj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+PiA+IHRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gc2NvcGUNCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50byBjaGFuZ2UuIFRoZSB1c2FnZSBvZiBSUEgNCj4+ PndpdGhpbiB0aGUgZW1lcmdlbmN5DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gc2VydmljZXMg bmV0d29yaw0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gaXMNCj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+PiA+ID4+IGZpbmUNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5mb3IgbWUu IEkgbWF5IGdldCBjb252aW5jZWQgdG8gc3RhcnQgdGhlDQo+Pj4+Pj5SUEggbWFya2luZw0KPj4+ Pj4+Pj5mcm9tDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+dGhlIHRoZSBWU1ANCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50b3dhcmRzIHRoZSBQU0FQLiBJIGZlZWwgdW5lYXN5 IGFib3V0IHRoZQ0KPj4+Pj4+ZW5kIGhvc3QNCj4+Pj4+Pj4+ZG9pbmcNCj4+Pj4+Pj4+ICAgICAg ICAgPiA+PiA+PiA+ID50aGUgbWFya2luZy4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBwbGVhc2UgcmVhZCB3aGF0IEkgd3JvdGUg YWJvdmUsIGFuZCB0aGVuDQo+Pj4+Pj5yZS1yZWFkIHRoZQ0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ ID5tb3N0IHJlY2VudA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gdmVyc2lvbiBvZiB0 aGUgSUQuIEkgZG9uJ3QgaGF2ZSBlbmRwb2ludHMNCj4+Pj4+PnRoYXQgU0hPVUxEDQo+Pj4+Pj4+ Pm9yDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gTVVTVCBtYXJrDQo+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+PiBhbnl0aGluZyB3cnQgUlBILiAgSSBhbHNvIGRvbid0IHdhbnQgdG8NCj4+ Pj4+PnByb2hpYml0IGl0LA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGJlY2F1c2UgdGhlcmUN Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IG1pZ2h0IGJlIGNhc2VzICh0aGF0IEkgZG9u J3Qga25vdw0KPj4+b2YpIG9mIHZhbGlkIHVzZXMNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiB1 bmRlciBjZXJ0YWluDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBjaXJjdW1zdGFuY2Vz LiAgRmlndXJlIDEgaXMgdmVyeSBjbGVhcg0KPj4+Pj4+dGhhdCB0aGVyZSBhcmUgMw0KPj4+Pj4+ Pj4gICAgICAgICA+ID4+ID4+IG5ldHdvcmtpbmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ ID4+IHBhcnRzIHRvIGNvbnNpZGVyDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+ Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gIzEgLSBmcm9tIHRoZSBlbmRwb2ludA0KPj4+Pj4+ Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gIzIgLSB3aXRoaW4gdGhlIFZTUA0KPj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+ID4gPj4gIzMgLSB3aXRoaW4gdGhlIEVTSW5ldA0KPj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRoZSBtb3N0IHJl Y2VudCBJRCB2ZXJzaW9uIGhhcyAiY2FuIiBmb3INCj4+Pj4+PiNzIDEgYW5kIDIsDQo+Pj4+Pj4+ PmFuZA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPjIxMTkgbGFuZ3VhZ2UNCj4+Pj4+Pj4+ ICAgICAgICAgPiA+PiA+PiA+ID4+IG9mZmVyaW5nIHRob3NlIHN1cHBvcnRpbmcgdGhpcw0KPj4+ Pj4+c3BlY2lmaWNhdGlvbiB3aWxsIGhhdmUNCj4+Pj4+Pj4+UlBIDQo+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+PiBhZGhlcmVuY2Ugd2l0aGluICMzICh0aGUgRVNJbmV0KS4NCj4+Pj4+Pj4+ ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBXaGF0 IG90aGVyIHNjb3BlIGNoYW5nZXMgZG8geW91IHdhbnQsDQo+Pj4+Pj5iZWNhdXNlIEkgaGF2ZW4n dA0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGhlYXJkIHRoZW0uDQo+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gSSBvbmx5IGhlYXJk IHlvdSBjbGFpbSBpbiBlbWFpbCBkdXJpbmcgdGhlDQo+Pj4+Pj5sYXN0IElFVEYNCj4+Pj4+Pj4+ YW5kIGluDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+dGhlIEVDUklUDQo+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+PiBzZXNzaW9uIHRoYXQgUlBIIHNob3VsZCBub3QgYmUNCj4+PnVz ZWQgZm9yIHByaW9yaXR5DQo+Pj4+Pj4+Pm1hcmtpbmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiByZXF1ZXN0cy4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFRoaXMgaXMgc29tZXRo aW5nIEtlaXRoIChTSVAgV0cNCj4+PmNoYWlyKSB2b2ljZWQgaGlzDQo+Pj4+Pj4+Pm9wcG9zaXRp b24NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRvIHlvdXIgdmlld3MgcmVnYXJkaW5n IGNyZWF0aW5nIGEgc2Vjb25kDQo+Pj4+Pj5tZWFucyBmb3IgU0lQDQo+Pj4+Pj4+PnRvDQo+Pj4+ Pj4+PiAgICAgICAgID4gPj4gPnByaW9yaXR5DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+ PiBtYXJrIHJlcXVlc3QgIndoZW4gU0lQIGFscmVhZHkgaGFzIG9uZQ0KPj4+Pj4+aW50ZXJvcGVy YWJsZQ0KPj4+Pj4+Pj53YXkgdG8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IGFjY29t cGxpc2ggdGhpcy4uLiBpdCdzIGNhbGwgdGhlIFJQIGhlYWRlcg0KPj4+Pj4+bWVjaGFuaXNtIi4N Cj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4g PiA+PiA+SSBkb24ndCBzZWUgYWR2YW50YWdlcyAtLSBvbmx5DQo+Pj5kaXNhZHZhbnRhZ2VzLg0K Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPg0KPj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ ID4gPj4gPkNpYW8NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5IYW5uZXMNCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0K Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+ID4gPj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+ Pj4gICAgICAgICA+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4+ Pj4+PiAgICAgICAgID4gPj4gPj4NCj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+DQo+Pj4+Pj4+PiAg ICAgICAgID4gPg0KPj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+PiAgICAgICAgID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+ICAgICAg ICAgPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+ICAgICAgICAgPiBFY3JpdEBpZXRmLm9y Zw0KPj4+Pj4+Pj4gICAgICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+RWNyaXQgbWFp bGluZyBsaXN0DQo+Pj4+Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pj4+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+Pj4NCj4+Pj4+Pj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PkVjcml0IG1haWxp bmcgbGlzdA0KPj4+Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pj4+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4+Pj4NCj4+Pj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+RWNyaXQgbWFpbGluZyBsaXN0DQo+ Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PkVjcml0IG1haWxpbmcgbGlzdA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pg0KPj4NCj4+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PlRoaXMgbWVzc2FnZSBpcyBmb3Ig dGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KPj5jb250YWluIHByaXZpbGVn ZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4NCj4+SWYg eW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0K Pj5pbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQg dXNlIG9mDQo+PnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PlttZjJdDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+RWNyaXQgbWFpbGluZyBsaXN0DQo+RWNy aXRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3Jp dCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0DQo= Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B817E3A6C96 for ; Fri, 6 Feb 2009 14:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLq5RyjmWx7d for ; Fri, 6 Feb 2009 14:15:55 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 11D583A6C7E for ; Fri, 6 Feb 2009 14:15:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="139068387" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Feb 2009 22:15:57 +0000 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 n16MFv1d032344; Fri, 6 Feb 2009 14:15:57 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16MFv4g007916; Fri, 6 Feb 2009 22:15:57 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); Fri, 6 Feb 2009 14:15:57 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 14:15:55 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 16:15:54 -0600 To: Ted Hardie , Henning Schulzrinne , "Winterbottom, James" From: "James M. Polk" In-Reply-To: References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> <28F08C20-0FCC-4E0D-953D-F6C9850BF9EF@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 22:15:55.0650 (UTC) FILETIME=[7B03CE20:01C988A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=42153; t=1233958557; x=1234822557; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=4VQ8OUddTb6yBmOu+DftaoHXTyqQG77tPLVgt6ioGxE=; b=eMSc8S4QnYgck7hFjDAu/xDzzsyfo45+6m0IAQoTskU7AMAJ9SrzJamd62 V1rjWdI3l8S8cFpRtTSDUcQQI6kueecdOHtI21zRK0ATWh9ls7SNEezEZSXc bVRO9QHGGx; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:15:58 -0000 At 03:27 PM 2/6/2009, Ted Hardie wrote: >At 1:05 PM -0800 2/6/09, Henning Schulzrinne wrote: > >There's another problem with the "it doesn't hurt argument". Assume > >for a moment we have a "UA MAY include RPH" wording. There are now two > >cases: > >Is it ever a protocol error for a SIP entity to include RPH? no - no error exists for this. The SIP rule about headers comes from RFC 3261 (SIP base spec) that non-understood headers are ignored. >Or is it always the expectation that it generally might be included, >and may be roundly >ignored? I'm not sure "it generally might be included"... unless you are in a network that mandates its inclusion, for now, such as US military networks. >If the latter is true, then the key thing is for those interested in >having this >work in a specific context to publish the namespace they will use in that >context. Others in similar contexts may adopt that, if they like. But >the UA/general SIP handling isn't different here just because it is an >emergency call. It's only different in contexts where that RPH namespace >is in use, and only because of an agreement to do so; presumably the >interested >party could assign RPH values to non-emergency calls too sure >, so it isn't a tight linkage between emergency-special handling. > >I'm just trying to figure out whether we're introducing a new situation >in which the call processing for emergency calls is different. We've >agreed previously to try to minimize those. If the call processing here >is the standard RPH processing (which seems to be "your mileage may >vary"), then we probably don't even need to call it out. I'm not sure I understand your "then we probably don't even need to call it out"... Does this mean you are advocating preventing UAs from including it in the text, or saying UA are allowed to, but there are potentially serious concerns you (mr customer) need to consider if you are thinking of including this header? >Possibly confused, > Ted > > > > >(1) All UAs implement it. > > > >(2) Only some UAs implement it. > > > >(1) seems unlikely for a MAY. If (2) occurs, we have the choice > >between two undesirable outcomes: > > > >(a) some UAs that are otherwise compliant get worse service just > >because they didn't include the RPH; > > > >OR > > > >(b) the proxy has to look for the service URN to give the call the > >appropriate treatment, thus obviating any advantage of having the > >header, yet incurring more complicated processing logic. > > > > > >I have no objection to whatever markings people want to apply to calls > >within an ESN - that's largely a private matter. > > > >Henning > > > >On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: > > > >> Hi All, > >> > >> I have followed thi thread with some interest and I struggling to > >> see a use case for the > >> providing RPH for emergency calls from the end-point. > >> > >> The reference-model call in ECRIT, for better or worse, is for all > >> calls to go back through a home-VSP. > >> We placed quite a lot of emphasis, largely for traffing reasons, for > >> the VSP to be able to verify that > >> a call is in fact an emergency call. This is done by the proxy > >> taking the inband location, doing a LoST > >> query with the provided URN, and verifying that the resulting > >> destination URI is the same as the destination > >> URI provide in the SIP INVITE. My understanding was that VSPs would > >> always do this check so they could > >> tell if they could bill for the call or not, and because the VSP can > >> be use that the call is an emergency call > >> it can apply any special priorities that may be applicable. This > >> obviates the need for RPH from the end-point > >> to the network. > >> > >> This leaves us with the argument of "it doesn't hurt to it", which > >> is not a good reason to write a specification. > >> It was intimated on the geopriv mailing list last year that great > >> pains had been taken to keep SIP with in the > >> MTU limits of UDP over Ethernet > (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120.html > >> ). Assuming > >> that this is the case, perhaps there is harm in including > >> information that we know will be ignored. > >> > >> Cheers > >> James > >> > >> > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > >> Sent: Fri 2/6/2009 12:33 PM > >> To: 'Brian Rosen'; 'Henning Schulzrinne' > >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > >> Subject: Re: [Ecrit] RPH > >> > >> To the story short here is the code for the proxy: > >> > >> --------------------- > >> > >> IF emergency call was recognized THEN > >> execute emergency call specific procedures (priority queuing, > > > preemption, fetch location, determine routing, do funny QoS things & > >> co) > >> ELSE > >> normal call handling procedures. > >> > >> --------------------- > >> > >> If you can make this differentiation between an emergency call and a > >> regular > >> call then you can also do everything that is necessary for emergency > >> call > >> handling. > >> > >> Brian + Keith: Please tell me that we cannot do the above with our > >> currently > >> specified mechanisms. > >> > >> Ciao > >> Hannes > >> > >>> -----Original Message----- > >>> From: Brian Rosen [mailto:br@brianrosen.net] > >>> Sent: 06 February, 2009 17:49 > >>> To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > >>> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>> Subject: RE: [Ecrit] RPH > >>> > >>> I agree that not all networks will permit (or pay attention > >>> to) a priority request from an end device. > >>> > >>> No one has asked for that. > >>> > >>> The namespace request has several uses, one of which is within > >>> an emergency services IP network, one of which is between > >>> elements within a public network controlled by the operator, > >>> and one of which is an endpoint request for resource priority. > >>> > >>> Those of us requesting this work proceed are happy if the > >>> endpoint part is simply left as possible (MAY), and, speaking > >>> for myself, having the draft discuss the security implications > >>> of endpoint marking is reasonable. > >>> > >>> Having discussed this issue with an implementation team who > >>> worked on MLPP systems, I am confident I know what I'm talking > >>> about, but YMMV. The fact that you could, if you wanted to, > >>> give resource priority to a call you decided, however you > >>> decided, was an emergency call is an implementation decision, > >>> and not subject to standardization. > >>> > >>> RPH is the IETF standard way for one entity to request > >>> resource priority of another entity in a SIP system. We're > >>> asking for a namespace to use that within the domain of > >>> emergency calls. That is, I think, a VERY reasonable request. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>> Sent: Friday, February 06, 2009 10:33 AM > >>>> To: Hannes Tschofenig > >>>> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >>>> Subject: Re: [Ecrit] RPH > >>>> > >>>> To chime in here: > >>>> > >>>> I don't think it's productive to simply state that 4412 > >>> doesn't worry > >>>> about authorization, so we shouldn't either (simplifying a bit). > >>>> Authorization was discussed repeatedly, and the general > >>> assumption was > >>>> that there were two conditions: Either the user invoking resource- > >>>> priority was well known and had a set of permissions that could be > >>>> checked in real time or there are ways to deal with abuse after the > >>>> fact in ways that deter abuse (the court-martial kind of thing in a > >>>> military context). > >>>> > >>>> The RFC 4412 security consideration (11.2) call this out in pretty > >>>> strong language: > >>>> > >>>> Prioritized access to network and end-system resources imposes > >>>> particularly stringent requirements on authentication and > >>>> authorization mechanisms, since access to prioritized > >>> resources may > >>>> impact overall system stability and performance and not > >>> just result > >>>> in theft of, say, a single phone call. > >>>> Thus, the question is whether we have such strong authentication in > >>>> emergency calling. In some cases, such as residential fixed line > >>>> deployments where ISP = VSP, we're probably pretty close, in others, > >>>> such as prepaid cell phones or hot spots or VSP-only providers, we > >>>> aren't. > >>>> > >>>> The other point that I think Hannes is making is that the > >>> information > >>>> is either redundant or dangerous. If a processing element recognizes > >>>> the call as being an emergency call, it can apply whatever treatment > >>>> it deems appropriate and doesn't need additional information. If it > >>>> doesn't or can't, using just the RPH can be rather dangerous unless > >>>> that element can be reasonably certain that there is strong > >>>> authentication and recourse. > >>>> > >>>> I don't buy the argument that somehow finding the RPH is faster than > >>>> just looking for the identifier. Thus, given that the information is > > >>> either redundant or dangerous, I fail to see the advantage. > >>>> > >>>> Henning > >>>> > >>>> > >>>> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > >>>> > >>>>> Don't get hung up on the details. There are ways to optimize it. > >>>>> That was > >>>>> not the point of the code example. > >>>>> > >>>>> The problem that my pseudo code should have shown you is that you > >>>>> * don't gain anything with RPH marking for the emergency call case > >>>>> from the SIP UA towards the outbound proxy since the functionality > >>>>> is already provide otherwise. How often does the proxy need to get > >>>>> told that this is an emergency call todo whatever emergency call > >>>>> handling procedures are necessary? > >>>>> * you only introduce fraud problems (if you are not > >>> careful and you > >>>>> understand the security stuff well enough) > >>>>> > >>>>> If you can point me to people who implement the RPH emergency call > >>>>> case please do so. I would love to talk to them. > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>> PS: You need to parse incoming messages to some extend so that you > >>>>> know what it contains :-) Only looking for the emergency > >>> RPH header > >>>>> (and not for the Service URN/dial > >>>>> string) would exactly be the DoS/fraud attack I am worried about. > >>>>> That's the thing Henning was worried about (go and listen to the > >>>>> past meeting minutes). > >>>>> > >>>>> > >>>>>> Hannes > >>>>>> > >>>>>> You need to talk to people who really implement this kind > >>> of thing. > >>>>>> You are way off. > >>>>>> > >>>>>> When you implement a resource priority system, the point of doing > >>>>>> that is to look though the queue of work and pick out the > >>> ones with > >>>>>> priority, handling them first. You don't do all the parsing, you > >>>>>> don't do a lot of decision tree. > >>>>>> > >>>>>> Typically: > >>>>>> Check for DoS things, like too big messages, etc Do a quick scan > >>>>>> for the RPH message header If found: > >>>>>> Parse the message > >>>>>> Determine validity > >>>>>> Determine priority > >>>>>> Queue on the correct work queue > >>>>>> > >>>>>> The first two actions have to be very fast. Anyone who builds a > >>>>>> SIP thingie will tell you that parsing is one of the big cycle > >>>>>> consumers: if you have to parse every message BEFORE you > >>> determine > >>>>>> priority, you can't give much resource priority. > >>>>>> Once you get the whole message parsed, you might as well finish > >>>>>> working on it, because you've done so much of the work. > >>>>>> OTHOH, finding the end-of-message delimiter and doing a quick > >>>>>> string search for RPH is fast. If you are doing > >>> priority, you need > >>>>>> to keep all the priority processing pretty uniform, and pretty > >>>>>> simple, or you tend to spend too much time futzing around > >>> figuring > >>>>>> out what to do. You put all the priority related stuff together, > >>>>>> and use as much common code as possible. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>>>>> On Behalf > >>>>>>> Of Hannes Tschofenig > >>>>>>> Sent: Friday, February 06, 2009 8:41 AM > >>>>>>> To: 'Hannes Tschofenig'; 'Janet P Gunn' > >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >>>>>>> bounces@ietf.org > >>>>>>> Subject: [Ecrit] RPH > >>>>>>> > >>>>>>> Over lunch I was also thinking how an outbound proxy would > >>>> implement > >>>>>>> some of the emergency procedures. Here are some thoughts: > >>>>>>> > >>>>>>> --------------------------------------------------- > >>>>>>> > >>>>>>> // Process incoming message > >>>>>>> Parse(msg); > >>>>>>> > >>>>>>> // SIP INVITE without Service URN > >>>>>>> // legacy devices > >>>>>>> If (recognize-dialstring(msg)==TRUE) { // we got an emergency > >>>>>>> call going on emergency=TRUE; if (dialstring(msg) == 911) > >>>>>>> serviceURN=urn:service:sos; } else if > >>>>>>> (recognize-serviceURN(msg)==TRUE) { // oh. A updated > >>> device that > >>>>>>> has a service URN attached to the > >>>> call > >>>>>>> serviceURN=retrieve_ServiceURN(msg); > >>>>>>> emergency=TRUE; > >>>>>>> } else { > >>>>>>> // standard SIP message > >>>>>>> // regular processing > >>>>>>> process(msg); > >>>>>>> emergency=FALSE; > >>>>>>> } > >>>>>>> > >>>>>>> If (emergency == TRUE) { > >>>>>>> // make sure that the emergency call does not get > > >> dropped on the > >>>>>>> floor > >>>>>>> // skip authorization failures > >>>>>>> // give the call a special treatment > >>>>>>> lots-of-code-here(); > >>>>>>> > >>>>>>> // trigger all the QoS signaling you have in the > >>> network to make > >>>>>>> James happy > >>>>>>> trigger-qos(); > >>>>>>> > >>>>>>> // query location > >>>>>>> location=retrieve-location(); > >>>>>>> > >>>>>>> // determine next hop > >>>>>>> next-hop=lost(location, serviceURN) > >>>>>>> > >>>>>>> // attach RPH marking to outgoing msg to make James and > >>>>>> Keith happy > >>>>>>> msg=add(msg, RPH); > >>>>>>> > >>>>>>> send(msg, next-hop); > >>>>>>> } > >>>>>>> > >>>>>>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { > >>>>>>> // all the emergency related processing done already upfront > >>>>>>> // hence I log something. > >>>>>>> log(RPH_WAS_PRESENT_JUHU); > >>>>>>> } else if ((rph-present(msg) == TRUE) && (emergency == > >>> FALSE)) { > >>>>>>> // this is not an emergency call // this is something > >>> like GETS > >>>>>>> result=special-authorization-procedure(user); > >>>>>>> > >>>>>>> if (result == AUTHORIZED) { > >>>>>>> // do some priority & preemption thing here. > >>>>>>> // trigger all the QoS you have > >>>>>>> lots-of-code-here(); > >>>>>>> } else { > >>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // > >>>>>>> don't need todo any RPH processing // this includes the case > >>>>>>> where the call was an emergency call but the RPH > >>>>>>> > >>>>>>> // marking was not there. > >>>>>>> nothing(); > >>>>>>> } > >>>>>>> > >>>>>>> --------------------------------------------------- > >>>>>>> > >>>>>>> > >>>>>>> Ciao > >>>>>>> Hannes > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>>>>>> Behalf Of Hannes Tschofenig > >>>>>>>> Sent: 06 February, 2009 15:07 > >>>>>>>> To: 'Janet P Gunn' > >>>>>>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > >>>>>>> FI/Espoo) > >>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH) > >>>>>>>> > >>>>>>>> Who would define something that could prevent DoS problems? > >>>>>>>> > >>>>>>>> ________________________________ > >>>>>>>> > >>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >>>>>>>> Sent: 06 February, 2009 14:11 > >>>>>>>> To: Hannes Tschofenig > >>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >>>>>>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); > >>>> 'James > >>>>>>>> M. Polk' > >>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>> Meeting: Agenda (RPH) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> But there is nothing IN RFC4412 that specifically > >>>>>> addresses how to > >>>>>>>> prevent any particular namespace being used for DoS. Anyone/any > >>>> UA > >>>>>>>> can ATTEMPT to invoke priority treatment by attaching RPH. For > >>>> all > >>>>>>>> of the 4412 namespaces, as with the new proposed namespace, the > >>>>>>>> mechanisms for preventing DoS are not specified in the > >>>>>> document that > >>>>>>>> defines the namespace. > >>>>>>>> They are/will be specified elsewhere. > >>>>>>>> > >>>>>>>> Janet > >>>>>>>> > >>>>>>>> This is a PRIVATE message. If you are not the intended > >>>>>> recipient, > >>>>>>>> please delete without copying and kindly advise us by e-mail of > >>>> the > >>>>>>>> mistake in delivery. > >>>>>>>> NOTE: Regardless of content, this e-mail shall not > >>>>>> operate to bind > >>>>>>>> CSC to any order or other contract unless pursuant to explicit > >>>>>>>> written agreement or government initiative expressly permitting > >>>> the > >>>>>>>> use of e-mail for such purpose. > >>>>>>>> > >>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > >>>>>>>> > >>>>>>>> > Hi James, > >>>>>>>> > > >>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >>>>>> documents. What I > >>>>>>>> would > >>>>>>>> > like to point out is that there is more than just a > >>>>>> header and > >>>>>>>> values within > >>>>>>>> > the header that have to be considered in order to > >>>>>> make a judgement > >>>>>>>> of what > >>>>>>>> > is appropriate and what isn't. There is an > >>>>>> architectural question > >>>>>>>> and > >>>>>>>> > whether the environment we are using the stuff is > >>>>>> indeed providing > > >>>>>>> the > >>>>>>>> > properties you need for the solution to be > >>> appropriate. > >>>>>>>> > > >>>>>>>> > Let me describe in more detail what I meant (and > >>>>>> please correct me > >>>>>>>> if I am > >>>>>>>> > wrong). > >>>>>>>> > > >>>>>>>> > Getting priority for SIP requests when using a GETS > >>>>>> alike scenario > >>>>>>>> means > >>>>>>>> > that the entity that issues the request is specially > >>>>>> authorized > >>>>>>>> since > >>>>>>>> > otherwise you introduce a nice denial of > >>> service attack. This > >>>>>>>> authorization > >>>>>>>> > is tied to the entity that makes the request. For > >>>>>> example, the > >>>>>>>> person is > >>>>>>>> > working for the government and has special rights. > >>>>>>>> James Bond as a (not so) > >>>>>>>> > secret agent might have these rights. > >>>>>>>> > > >>>>>>>> > The emergency services case > >>> (citizen-to-authority) is a bit > >>>>>>>> different as > >>>>>>>> > there aren't really special rights with respect to > >>>>>> authorization > >>>>>>>> tied to > >>>>>>>> > individuals. Instead, the fact that something is an > >>>>>> emergency is > >>>>>>>> purely a > >>>>>>>> > judgement of the human that dials a special number. > >>>>>>>> To deal with fraud, we > >>>>>>>> > discussed in the group on what we can actually do to > >>>>>> ensure that > >>>>>>>> end users > >>>>>>>> > do not bypass security procedures (such as > >>>>>> authorization checks, > >>>>>>>> charging > >>>>>>>> > and so on). Part of this investigation was > >>> the publication of > >>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also > >>> describes this > >>>>>>>> issue. > >>>>>>>> > > >>>>>>>> > So, imagine the implementation of a SIP proxy (and we > >>>>>> implemented > >>>>>>>> that > >>>>>>>> > stuff) that receives a call that contains a Service > >>>>>> URN. The code > >>>>>>>> branches > >>>>>>>> > into a special mode where everything is done > >>> so that the call > >>>>>>>> receives > >>>>>>>> > appropriate treatment and does not get dropped on the > >>>>>> floor. The > >>>>>>>> way how the > >>>>>>>> > Service URN is placed in the message ensures that the > >>>>>> call cannot > >>>>>>>> go to my > >>>>>>>> > friend (instead of the PSAP) unless the end host ran > >>>>>> LoST already. > >>>>>>>> In the > >>>>>>>> > latter case, we discussed this also on the list for a > >>>>>> while and > >>>>>>>> Richard even > >>>>>>>> > wrote a draft about it in the context of the > >>> location hiding > >>>>>>>> topic, we said > >>>>>>>> > that the proxy would have to run LoST if he > >>> cares about a > >>>>>>>> potential > >>>>>>>> > fraudulent usage. > >>>>>>>> > > >>>>>>>> > So, what do we need todo in order to provide > >>> secure RFC 4412 > >>>>>>>> functionality > >>>>>>>> > in our context? > >>>>>>>> > > >>>>>>>> > Do you think that the current text in > >>>>>>>> > > >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >>>>>>>> gency-rph-nam > >>>>>>>> > espace-00.txt reflects any of the > >>> above-described issues: > >>>>>>>> > " > >>>>>>>> > The Security considerations that apply to RFC 4412 > >>>>>>>> [RFC4412] > >>>>>>>> apply > >>>>>>>> > here. This document introduces no new security > >>>>>>>> issues relative > >>>>>>>> to > >>>>>>>> > RFC 4412. > >>>>>>>> > " > >>>>>>>> > > >>>>>>>> > From various discussions in GEOPRIV I recall > >>> that you are > >>>>>>>> super-sensitive > >>>>>>>> > regarding security and privacy. For some reasons you > >>>>>> don't seem to > >>>>>>>> have the > >>>>>>>> > same concerns here. I would like to > >>> understand your reasoning. > >>>>>>>> > > >>>>>>>> > Please also do me another favor: Don't always say > >>>>>> that I don't > >>>>>>>> understand > >>>>>>>> > the subject. Even if that would be the case it isn't > >>>>>> particular > >>>>>>>> fair given > >>>>>>>> > that different folks had to educate you on other > >>>>>> topics in the > >>>>>>>> past as well. > >>>>>>>> > Additionally, if you listen to the audio recordings > >>>>>> then you will > > >>>>>>> notice > >>>>>>>> > that Henning, Ted, and Jon do not seem to understand > >>>>>> the issue > >>>>>>>> either as > >>>>>>>> > they have raised similar issues during the > >>> F2F meetings. > >>>>>>>> > > >>>>>>>> > Ciao > >>>>>>>> > Hannes > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > >Hannes - I believe it is you who do not understand > >>>>>> RFC 4412 -- > >>>>>>>> > >and many of us are trying to get that > >>> through to you, but you > >>>>>>>> > >don't seem to want to listen/read. > >>>>>>>> > > > >>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, > >>>>>>>> > > > >>>>>>>> > >One use is GETS. > >>>>>>>> > > > >>>>>>>> > >One use is MLPP. > >>>>>>>> > > > >>>>>>>> > >These examples are in RFC 4412 because there > >>> were specific > >>>>>>>> > >namespaces being created for the IANA section of > >>>>>> that document. > >>>>>>>> > > > >>>>>>>> > >Reading the whole document, you will see > >>> that RPH can be > >>>>>>>> > >specified for other uses than GETS or MLPP > >>> specifically. > >>>>>>>> > > > >>>>>>>> > >I knew when I wrote RFC 4412 that one day we > >>> would specify a > >>>>>>>> > >namespace for ECRIT (the "esnet" namespace > >>> now) -- but I also > >>>>>>>> > >knew it was premature for RFC 4412 to > >>> incorporate that > >>>>>>>> > >namespace, that a future doc to RFC 4412 > >>> would have to be > >>>>>>>> > >written to do this. Brian and I talked about > >>> this at the > >>>>>>>> > >original NENA meeting that created the IP WGs there > >>>>>> (in August > >>>>>>>> > >of 03). We both agreed we should wait until it was > >>>>>>>> > >appropriate to the work in the IETF to > >>> submit this document > >>>>>>>> > >that is now > >>>>>>>> > > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >>>>>>>> > >gency-rph-namespace-00.txt > >>>>>>>> > > > >>>>>>>> > >Yet, you seem to want to use some additional > >>> mechanism to > >>>>>>>> > >indicate priority of a call in SIP. That > >>> means you want to > >>>>>>>> > >introduce a second way to accomplish this in SIP. > >>>>>>>> Why do you > >>>>>>>> > >want to promote a separate way to do something SIP > >>>>>> has already > >>>>>>>> > >defined? That will cause interoperability issues and > >>>>>> we both know > >>>>>>>> that. > >>>>>>>> > > > >>>>>>>> > >You've said to me (and others) that you > >>> believe RPH is just > >>>>>>>> > >another way to accomplish what sos or a URI can > >>>>>> indicate - and > >>>>>>>> > >you're wrong. Your way would be > >>> _the_second_way_to_do_it, > >>>>>>>> > >because SIP already considers RPH to be > >>> *the*way* to priority > >>>>>>>> > >mark SIP requests. > >>>>>>>> > > > >>>>>>>> > >If you don't believe me (no comment), then > >>> why do you not > >>>>>>>> > >believe the SIP WG chair (who knows more > >>> about SIP than both > >>>>>>>> > >of us) - who, on this thread, has again said > >>> to you "RFC 4412 > >>>>>>>> > >(RPH) is the SIP mechanism to priority mark > >>> SIP requests"? > >>>>>>>> > > > >>>>>>>> > >Further, I believe it is inappropriate to > >>> prohibit endpoints > >>>>>>>> > >from being able to set the esnet namespace. > >>> I absolutely > >>>>>>>> > >believe it will not be needed most of the > >>> time, but I believe > >>>>>>>> > >if someone does find a valid use for > >>> endpoints to mark > >>>>>>>> > >priority in SIP, this ID - once it has > >>> become an RFC -- will > >>>>>>>> > >have to be obsoleted with a new RFC saying the exact > >>>>>> opposite. > >>>>>>>> > > > >>>>>>>> > >(color me confused ... over and over again) > >>>>>>>> > > > >>>>>>>> > >James > >>>>>>>> > > > >>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>>>>>>> > >>Keith, please understand that the usage of RFC 4412 > >>>>>> for GETS and > >>>>>>>> for > >>>>>>>> > >>the type of emergency call we discuss here is > >>>>>> different. Just > >>>>>>>> looking > >>>>>>>> > >>at the header and the name of the namespace is a bit > > >>>>>>> > >artificial. I hope > >>>>>>>> > >>you understand that. > >>>>>>>> > >> > >>>>>>>> > >> >-----Original Message----- > >>>>>>>> > >> >From: DRAGE, Keith (Keith) > >>>>>>>> [mailto:drage@alcatel-lucent.com] > >>>>>>>> > >> >Sent: 05 February, 2009 14:55 > >>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >>>>>>>> Polk'; 'Tschofenig, > >>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>>>>>> Meeting: Agenda (my > >>>>>>>> > >>>>>>>> > >> >mistake) > >>>>>>>> > >> > > >>>>>>>> > >> >Which is exactly what RFC 4412 specifies for all > >>>>>> namespaces. > >>>>>>>> > >> > > >>>>>>>> > >> >regards > >>>>>>>> > >> > > >>>>>>>> > >> >Keith > >>>>>>>> > >> > > >>>>>>>> > >> >> -----Original Message----- > >>>>>>>> > >> >> From: ecrit-bounces@ietf.org > >>>>>> [mailto:ecrit-bounces@ietf.org] > >>>>>>>> > >> >On Behalf > >>>>>>>> > >> >> Of Brian Rosen > >>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. > >>> Polk'; 'Tschofenig, > >>>>>>>> > >Hannes (NSN > >>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' > >>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>>>>>> Meeting: Agenda (my > >>>>>>>> > >> >> mistake) > >>>>>>>> > >> >> > >>>>>>>> > >> >> The value is that in some networks > >>> where priority for > >>>>>>>> > >> >emergency calls > >>>>>>>> > >> >> is appropriate, and appropriate > >>> policing of marking is > >>>>>>>> > >implemented, > >>>>>>>> > >> >> emergency calls will receive resource priority. > >>>>>>>> > >> >> > >>>>>>>> > >> >> Not all networks would need policing. Some > >>>>>> will. Policing > >>>>>>>> could > >>>>>>>> > >> >> be to Route header/R-URI content, but other > >>>>>> criteria are > >>>>>>>> possible. > >>>>>>>> > >> >> > >>>>>>>> > >> >> Not all networks will need resource priority > >>>>>> for emergency > >>>>>>>> calls. > >>>>>>>> > >> >> Fine, ignore this marking/namespace. > >>>>>>>> > >> >> > >>>>>>>> > >> >> Brian > >>>>>>>> > >> >> > -----Original Message----- > >>>>>>>> > >> >> > From: Hannes Tschofenig > >>>>>>>> [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >>>>>> Tschofenig, Hannes > >>>>>>>> (NSN - > >>>>>>>> > >> >> > FI/Espoo); 'ECRIT' > >>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>>>>>> Meeting: Agenda (my > >>>>>>>> > >> >> > mistake) > >>>>>>>> > >> >> > > >>>>>>>> > >> >> > I don't even see the value in permitting the > >>>>>> endpoint todo > >>>>>>>> the > >>>>>>>> > >> >> > RPH marking. > >>>>>>>> > >> >> > In addition to the security concerns > >>> there is also the > >>>>>>>> > >> >problem that > >>>>>>>> > >> >> > there are more options to implement without > >>>>>> an additional > >>>>>>>> value. > >>>>>>>> > >> >> > > >>>>>>>> > >> >> > >-----Original Message----- > >>>>>>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 > >>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >>>>>> 'Tschofenig, > >>>>>>>> > >> >> Hannes (NSN - > >>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual > >>> Interim Meeting: > >>>>>>>> Agenda (my > >>>>>>>> > >> >> > mistake) > >>>>>>>> > >> >> > > > >>>>>>>> > >> >> > >Hannes > >>>>>>>> > >> >> > > > >>>>>>>> > >> >> > >This matches my understanding > >>> precisely. We wish to > >>>>>>>> > >> >> permit endpoints > >>>>>>>> > >> >> > >to mark. We do not require it, and > >>> don't necessarily > >>>>>>>> expect it > >>>>>>>> > >> >> > >in many (even > >>>>>>>> > >> >> > >most) cases. We don't wish to see the > >>>>>> document prohibit > >>>>>>>> it. > >>>>>>>> > >> >> > >We all seem to agree it has value within the > > >>>>> Emergency > >>>>>>>> > >> >Services IP > >>>>>>>> > >> >> > >Networks. > >>>>>>>> > >> >> > > > >>>>>>>> > >> >> > >Brian > >>>>>>>> > >> >> > > > >>>>>>>> > >> >> > >> -----Original Message----- > >>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org > >>>>>>>> [mailto:ecrit-bounces@ietf.org] > >>>>>>>> > >> >> > >On Behalf > >>>>>>>> > >> >> > >> Of James M. Polk > >>>>>>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, > >>> Hannes (NSN - > >>>>>>>> > >> >> FI/Espoo); 'ECRIT' > >>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>>>>>> Meeting: > >>>>>>>> > >Agenda (my > >>>>>>>> > >> >> > >> mistake) > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes > >>> Tschofenig wrote: > >>>>>>>> > >> >> > >> > > James wrote: > >>>>>>>> > >> >> > >> > >> you are the _lone_ voice not > >>>>>> supporting this ID, > >>>>>>>> > >> >> > >> > > >>>>>>>> > >> >> > >> >Listening to the audio recording of past > >>>>>> meetings I > >>>>>>>> have to > >>>>>>>> > >> >> > >say that > >>>>>>>> > >> >> > >> >I > >>>>>>>> > >> >> > >> was > >>>>>>>> > >> >> > >> >not the only persons raising > >>> concerns about the > >>>>>>>> document. > >>>>>>>> > >> >> > >> >That was probably the reason why you > >>>>>> agreed to limit > >>>>>>>> the > >>>>>>>> > >> >> > >scope of the > >>>>>>>> > >> >> > >> >document (which you didn't later do) to > >>>>>> get folks to > >>>>>>>> agree > >>>>>>>> > >> >> > >to make it > >>>>>>>> > >> >> > >> a WG > >>>>>>>> > >> >> > >> >item. > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> re-listen to the audio please > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> Ted's concerns were consistent with most > >>>>>>>> (all?) other > >>>>>>>> > >> >> concerns -- > >>>>>>>> > >> >> > >> which were based on the premise of whether > >>>>>> or not the > >>>>>>>> > >> >> UAC should be > >>>>>>>> > >> >> > >> trusted to initiate the marking on the > >>>>>> INVITE. The > >>>>>>>> most > >>>>>>>> > >> >> > >> recent version has backed off this > >>> to a "can" -- > >>>>>>>> meaning not > >>>>>>>> > >> >prohibited > >>>>>>>> > >> >> > >> (i.e., no 2119 text). I also backed off > >>>>>> the text in > >>>>>>>> the > >>>>>>>> > >> >> SP domain > >>>>>>>> > >> >> > >> part to "can", such that there is > >>> no 2119 text > >>>>>>>> > >> >mandating or even > >>>>>>>> > >> >> > >> recommending its usage there. I also do > >>>>>> not prohibit > >>>>>>>> its > >>>>>>>> > >> >> > >use, based on > >>>>>>>> > >> >> > >> local policy. Keith has come forward with > >>>>>> the specific > >>>>>>>> > >>>>>>>> > >> >> > >> request that non-ESInet networks be > >>>>>> allowed to mark and > >>>>>>>> pay > >>>>>>>> > >> >attention to > >>>>>>>> > >> >> > >> this priority indication -- with IMS as > >>>>>> the specific > >>>>>>>> example > >>>>>>>> > >> >> > >> he wishes to have this valid for. > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> Where there is no disagreement, save for > >>>>>> your recent > >>>>>>>> > >> >> > >pushback - is in > >>>>>>>> > >> >> > >> the ESInet, which is where Brian > >>> has requested it's > >>>>>>>> > >> >> > >definition in the > >>>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >>>>>> chair within > >>>>>>>> > >> >> NENA, and if > >>>>>>>> > >> >> > >> he asks for it, are you going to say you > >>>>>> know better > >>>>>>>> than he? > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> >Btw, I not disagreeing with the document > >>>>>> as such. I > >>>>>>>> > >> >just want to > >>>>>>>> > >> >> > the > >>>>>>>> > >> >> > >> scope > >>>>>>>> > >> >> > >> >to change. The usage of RPH > >>> within the emergency > >>>>>>>> > >> >> services network > >>>>>>>> > >> >> > is > >>>>>>>> > >> >> > >> fine > >>>>>>>> > >> >> > >> >for me. I may get convinced to start the > > >>>>> RPH marking > >>>>>>>> from > >>>>>>>> > >> >> > >the the VSP > >>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy about the > >>>>>> end host > >>>>>>>> doing > >>>>>>>> > >> >> > >the marking. > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> please read what I wrote above, and then > >>>>>> re-read the > >>>>>>>> > >> >most recent > >>>>>>>> > >> >> > >> version of the ID. I don't have endpoints > >>>>>> that SHOULD > >>>>>>>> or > >>>>>>>> > >> >> MUST mark > >>>>>>>> > >> >> > >> anything wrt RPH. I also don't want to > >>>>>> prohibit it, > >>>>>>>> > >> >> because there > >>>>>>>> > >> >> > >> might be cases (that I don't know > >>> of) of valid uses > >>>>>>>> > >> >> under certain > >>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear > >>>>>> that there are 3 > >>>>>>>> > >> >> networking > >>>>>>>> > >> >> > >> parts to consider > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> #1 - from the endpoint > >>>>>>>> > >> >> > >> #2 - within the VSP > >>>>>>>> > >> >> > >> #3 - within the ESInet > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> the most recent ID version has "can" for > >>>>>> #s 1 and 2, > >>>>>>>> and > >>>>>>>> > >> >> > >2119 language > >>>>>>>> > >> >> > >> offering those supporting this > >>>>>> specification will have > >>>>>>>> RPH > >>>>>>>> > >> >> > >> adherence within #3 (the ESInet). > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> What other scope changes do you want, > >>>>>> because I haven't > >>>>>>>> > >> >> heard them. > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> I only heard you claim in email during the > >>>>>> last IETF > >>>>>>>> and in > >>>>>>>> > >> >> > >the ECRIT > >>>>>>>> > >> >> > >> session that RPH should not be > >>> used for priority > >>>>>>>> marking > >>>>>>>> > >> >> requests. > >>>>>>>> > >> >> > >> This is something Keith (SIP WG > >>> chair) voiced his > >>>>>>>> opposition > >>>>>>>> > >> >> > >> to your views regarding creating a second > >>>>>> means for SIP > >>>>>>>> to > >>>>>>>> > >> >priority > >>>>>>>> > >> >> > >> mark request "when SIP already has one > >>>>>> interoperable > >>>>>>>> way to > >>>>>>>> > >> >> > >> accomplish this... it's call the RP header > >>>>>> mechanism". > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> >I don't see advantages -- only > >>> disadvantages. > >>>>>>>> > >> >> > >> > > >>>>>>>> > >> >> > >> >Ciao > >>>>>>>> > >> >> > >> >Hannes > >>>>>>>> > >> >> > >> > >>>>>>>> > >> >> > >> > >>> _______________________________________________ > >>>>>>>> > >> >> > >> Ecrit mailing list > >>>>>>>> > >> >> > >> Ecrit@ietf.org > >>>>>>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >> >> > > > >>>>>>>> > >> >> > >>>>>>>> > >> >> _______________________________________________ > >>>>>>>> > >> >> Ecrit mailing list > >>>>>>>> > >> >> Ecrit@ietf.org > >>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >> >> > >>>>>>>> > >> > > >>>>>>>> > > > >>>>>>>> > > >>>>>>>> > _______________________________________________ > >>>>>>>> > Ecrit mailing list > >>>>>>>> > Ecrit@ietf.org > >>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Ecrit mailing list > >>>>>>>> Ecrit@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>> > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> > >> > ------------------------------------------------------------------------------------------------ > > > This message is for the designated recipient only and may > >> contain privileged, proprietary, or otherwise private information. > >> If you have received it in error, please notify the sender > >> immediately and delete the original. Any unauthorized use of > >> this email is prohibited. > >> > ------------------------------------------------------------------------------------------------ > >> [mf2] > >> > >> > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D412C3A6CA0 for ; Fri, 6 Feb 2009 14:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCdbxiVUtq5i for ; Fri, 6 Feb 2009 14:21:10 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E40683A6C9C for ; Fri, 6 Feb 2009 14:21:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="129615356" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2009 22:21:12 +0000 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 n16MLCpo008721; Fri, 6 Feb 2009 14:21:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16MLCoK012896; Fri, 6 Feb 2009 22:21:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 14:21:12 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 14:21:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 16:21:10 -0600 To: Henning Schulzrinne From: "James M. Polk" In-Reply-To: References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 22:21:11.0666 (UTC) FILETIME=[37600520:01C988A9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3230; t=1233958872; x=1234822872; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=gDKMJQFH4ymODMEF0eYbQNqUAJqTmIWtI+bK2Ph8Hvk=; b=T27xVXRYqQ1/pDjxcProqxZ2f5WsJOiWhGTLAOESNhPmoaBmV1YA1RYThu sDFog4wN50lQzWPyoVfKMD1Da6G5fQWA9jOhuZ2YRgENgaWR0ZSUQUcRlxWc 0tgXoSE5fU; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:21:10 -0000 At 04:05 PM 2/6/2009, Henning Schulzrinne wrote: >James, > >we don't go through every possible SIP header that might be inserted >into emergency requests. Yes, somebody could add RPH, but this applies >to PAI and dozens of other SIP headers as well. So far, nobody has >provided, in my opinion, a compelling use case that is worth >documenting. "It could be useful somewhere for something" doesn't cut >it. I have provided multiple reasons why I think that it is a bad idea >for (normal) UAs to do so, none of which you address. >I see no need to say "do not insert RPH", this is the only thing - right now - that I'm afraid one of us believes should be the case. I'm glad you are not joining that position. I really do not want to highlight the idea fo UAs inserting esnet, but I believe sometime down the road - some customer will come up with a valid reason for this, and I don't want to state in text that it is prevented from being inserted (and yet have the vendor who wants to sell to that customer also want that vendor to adhere to this spec as well). I'm just advocating we not have the text prevent its inclusion. As I've said, I will beef up the security considerations section wrt UA insertion of esnet - unless others object to this... >as it would have to be be a no-op for the >reasons I mentioned. > >Henning > >On Feb 6, 2009, at 4:45 PM, James M. Polk wrote: > >>At 02:01 PM 2/6/2009, Winterbottom, James wrote: >>>Hi All, >>> >>>I have followed thi thread with some interest and I struggling to >>>see a use case for the >>>providing RPH for emergency calls from the end-point. >> >>ok, let's address this concern only for a minute. >> >>If there is no use-case you can think of (for endpoints insertion of >>RP namespace esnet), does that mean this RFC to-be has to prevent >>(i.e., MUST NOT) endpoints from being allowed to insert esnet? That >>means, you feel and believe, you know about all customer >>requirements everywhere, doesn't it? >> >>I'm not kidding or being snide here. >> >>Remember, this is a Standards Track doc for implementers, allowing >>them the idea that some future specification MAY allow endpoints to >>insert the RP header from endpoints gives them the ability to adjust >>their code to that possibility. There is the (good?) chance that at >>least one customer (somewhere) of one or more vendors has this as a >>requirement _now_, but we haven't heard about it yet. >> >>Stating in this to-be RFC that endpoints are forbidden from >>inserting an RP header would prevent them from implementing/ >>satisfying their customer requirement while still supporting this >>specification. >> >>Remember, this RFC to-be DOES NOT say anything about endpoints MUST >>or even SHOULD implement the "esnet" RP namespace in order to be >>compliant with this spec. It merely says MAY, which means "some >>future spec MAY recommend or mandate it". >> >>I agree with Brian that robust security considerations stating that >>endpoint implementations need to very careful about configuring this >>capability needs to be written, and I will commit to writing that >>text in the next rev of the doc. >> >>James Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814C83A6CA4 for ; Fri, 6 Feb 2009 14:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFEzMb5o-bYO for ; Fri, 6 Feb 2009 14:29:28 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9635A3A6A1D for ; Fri, 6 Feb 2009 14:29:28 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16MT97P024659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 17:29:09 -0500 (EST) Message-Id: <7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> From: Henning Schulzrinne To: "James M. Polk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 17:29:09 -0500 References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:29:32 -0000 To restate: I will object to any text mentioning use of ESNET in UAs. It's useless (since under-specified), likely to be harmful to reliable network operation and just causes confusion. The text should describe when it is useful (within a "closed" ESNET, presumably) and what conditions need to be met in order to ensure reliable and secure usage. That something might be useful somewhere else is always true, in any specification, but we don't add a "This document does not prevent the use of this mechanism somewhere else." in documents. Henning On Feb 6, 2009, at 5:21 PM, James M. Polk wrote: > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote: >> James, >> >> we don't go through every possible SIP header that might be inserted >> into emergency requests. Yes, somebody could add RPH, but this >> applies >> to PAI and dozens of other SIP headers as well. So far, nobody has >> provided, in my opinion, a compelling use case that is worth >> documenting. "It could be useful somewhere for something" doesn't cut >> it. I have provided multiple reasons why I think that it is a bad >> idea >> for (normal) UAs to do so, none of which you address. > > >> I see no need to say "do not insert RPH", > > this is the only thing - right now - that I'm afraid one of us > believes should be the case. I'm glad you are not joining that > position. I really do not want to highlight the idea fo UAs > inserting esnet, but I believe sometime down the road - some > customer will come up with a valid reason for this, and I don't want > to state in text that it is prevented from being inserted (and yet > have the vendor who wants to sell to that customer also want that > vendor to adhere to this spec as well). > > I'm just advocating we not have the text prevent its inclusion. > > As I've said, I will beef up the security considerations section wrt > UA insertion of esnet - unless others object to this... Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200E93A684F for ; Fri, 6 Feb 2009 14:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG11DK55MXLU for ; Fri, 6 Feb 2009 14:37:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EAB173A6967 for ; Fri, 6 Feb 2009 14:37:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="244588395" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2009 22:37:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n16MbRlp001407; Fri, 6 Feb 2009 14:37:30 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n16MbRAF004496; Fri, 6 Feb 2009 22:37:27 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); Fri, 6 Feb 2009 14:37:27 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 14:37:27 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 16:37:26 -0600 To: Henning Schulzrinne From: "James M. Polk" In-Reply-To: <7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> <7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 22:37:27.0173 (UTC) FILETIME=[7CD29350:01C988AB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2610; t=1233959850; x=1234823850; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=s7EWmWmtvCfr1fmgTZwa3KlESx3jlf0u5HZpgYXbRhU=; b=ja0pWf51mye33lkFsJv9ImHKs/HkHSzxGkwc2ucjq83OOtxtNQJNzSVVFv tAH5PeFrAMrdWvy5oyvdqeIlF9NZ2Tb6YXs3cpBgYTCwsW4Ut8V6trQVG7pF GqQPifsZEInoX5/BGrJ/8EFqAInHAWnltwxGd6QIzX1kk9NKyL7is=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:37:29 -0000 Henning I agree with your statement "This document does not prevent the use of this mechanism somewhere else." in documents. I just want to avoid having to write in (something like) 'UAs are prevented from including RP namespace esnet" That was pretty much suggested by one person on the list. Is this agreeable? Taking this statement further "I will object to any text mentioning use of ESNET in UAs." Does that mean you do _not_ want UA insertion of esnet to be added to the security considerations section? James At 04:29 PM 2/6/2009, Henning Schulzrinne wrote: >To restate: I will object to any text mentioning use of ESNET in UAs. >It's useless (since under-specified), likely to be harmful to reliable >network operation and just causes confusion. The text should describe >when it is useful (within a "closed" ESNET, presumably) and what >conditions need to be met in order to ensure reliable and secure >usage. That something might be useful somewhere else is always true, >in any specification, but we don't add a "This document does not >prevent the use of this mechanism somewhere else." in documents. > >Henning > >On Feb 6, 2009, at 5:21 PM, James M. Polk wrote: > >>At 04:05 PM 2/6/2009, Henning Schulzrinne wrote: >>>James, >>> >>>we don't go through every possible SIP header that might be inserted >>>into emergency requests. Yes, somebody could add RPH, but this >>>applies >>>to PAI and dozens of other SIP headers as well. So far, nobody has >>>provided, in my opinion, a compelling use case that is worth >>>documenting. "It could be useful somewhere for something" doesn't cut >>>it. I have provided multiple reasons why I think that it is a bad >>>idea >>>for (normal) UAs to do so, none of which you address. >> >> >>>I see no need to say "do not insert RPH", >> >>this is the only thing - right now - that I'm afraid one of us >>believes should be the case. I'm glad you are not joining that >>position. I really do not want to highlight the idea fo UAs >>inserting esnet, but I believe sometime down the road - some >>customer will come up with a valid reason for this, and I don't want >>to state in text that it is prevented from being inserted (and yet >>have the vendor who wants to sell to that customer also want that >>vendor to adhere to this spec as well). >> >>I'm just advocating we not have the text prevent its inclusion. >> >>As I've said, I will beef up the security considerations section wrt >>UA insertion of esnet - unless others object to this... Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254B23A6C9F for ; Fri, 6 Feb 2009 14:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxwuUsWEcKCQ for ; Fri, 6 Feb 2009 14:46:08 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D76523A6C98 for ; Fri, 6 Feb 2009 14:46:07 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 22:46:08 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp049) with SMTP; 06 Feb 2009 23:46:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/DRYgNT4XDoU/ax14u2Rvc0GOhUtsphtHzAwIQZv sah5oNO/obM/zn From: "Hannes Tschofenig" To: "'James M. Polk'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> <000701c9883c$59b095d0$49b5b70a@nsnintra.net> Date: Sat, 7 Feb 2009 00:46:53 +0200 Message-ID: <000001c988ac$d0261940$0201a8c0@nsnintra.net> 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.3350 Thread-Index: AcmIppJ3db5pt/4hRciq0u3Zrgn8DQABfvUg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:46:10 -0000 Good that you agree that GETS usage of RPH and the one we discuss in ECRIT is different. So far, some folks have been saying "what works for GETS works for the ECRIT case as well". I argued that the environment is different and hence just referencing RFC 4412 isn't good enough. >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: 07 February, 2009 00:02 >To: Hannes Tschofenig >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, Hannes >(NSN - FI/Espoo); 'ECRIT' >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) > >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote: >>Hi James, >> >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I >>would like to point out is that there is more than just a header and >>values within the header that have to be considered in order >to make a >>judgement of what is appropriate and what isn't. There is an >>architectural question and whether the environment we are using the >>stuff is indeed providing the properties you need for the >solution to be appropriate. >> >>Let me describe in more detail what I meant (and please >correct me if I >>am wrong). >> >>Getting priority for SIP requests when using a GETS alike scenario >>means that the entity that issues the request is specially authorized >>since otherwise you introduce a nice denial of service attack. > >You are missing a step in GETS here. The endpoint, who sends >the GETS set-up as an INVITE is not already authorized (not >the device, not the user). In North America, there is a 10 >digit GETS number that is dialed (that I won't give out right >now on an open list) - and there literally is only 1 number >available to dial for this service. Literally anyone can dial >this number today in North America (no matter where the phone >is - as long as it is in North America -- and I might be too >limiting in that it is dialable from anywhere, because it is >going to a North American destination). > >Once this number is dialed, it is answered by an >authentication and authorization IVR. This IVR challenges >each caller for their authentication passcode, and a >password). Once this has been successfully entered, then call >is NOW authorized to proceed towards its destination number - >this step is only known to the authorizing system because the >destination 10 digit number is NOT entered until after the >authentication and authorization step has completed. > >The authorized caller is prompted with a new dial tone - in >which they can enter any number on the planet and receive >preferential treatment through as many carriers (in IP, it's >SPs) that have implemented this GETS service (which is an SLA >with the Department of Homeland Security now). > >Merely entering the GETS RP namespace is never intended, >alone, to gain any preferential treatment -- other than >towards this authentication & authorization IVR. > >I hope you can see that this is a completely separate type of >service and implementation type than ECRIT based emergency >calling will use. > >BTW - to your comment below about me not calling your name out >when you are incorrect because I have been equally incorrect >-- I'm not sure I've been spared as much as you think, given >that many have called me out by name when they've felt I've >been wrong over the years. > >>This authorization >>is tied to the entity that makes the request. For example, the person >>is working for the government and has special rights. James Bond as a >>(not so) secret agent might have these rights. >> >>The emergency services case (citizen-to-authority) is a bit different >>as there aren't really special rights with respect to authorization >>tied to individuals. Instead, the fact that something is an emergency >>is purely a judgement of the human that dials a special >number. To deal >>with fraud, we discussed in the group on what we can actually do to >>ensure that end users do not bypass security procedures (such as >>authorization checks, charging and so on). Part of this investigation >>was the publication of http://www.ietf.org/rfc/rfc5069.txt >that also describes this issue. >> >>So, imagine the implementation of a SIP proxy (and we implemented that >>stuff) that receives a call that contains a Service URN. The code >>branches into a special mode where everything is done so that >the call >>receives appropriate treatment and does not get dropped on the floor. >>The way how the Service URN is placed in the message ensures that the >>call cannot go to my friend (instead of the PSAP) unless the end host >>ran LoST already. In the latter case, we discussed this also on the >>list for a while and Richard even wrote a draft about it in >the context >>of the location hiding topic, we said that the proxy would >have to run >>LoST if he cares about a potential fraudulent usage. >> >>So, what do we need todo in order to provide secure RFC 4412 >>functionality in our context? >> >>Do you think that the current text in >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme >rgency-rp >>h-nam espace-00.txt reflects any of the above-described issues: >>" >> The Security considerations that apply to RFC 4412 [RFC4412] apply >> here. This document introduces no new security issues relative to >> RFC 4412. >>" >> >> From various discussions in GEOPRIV I recall that you are >>super-sensitive regarding security and privacy. For some reasons you >>don't seem to have the same concerns here. I would like to >understand your reasoning. >> >>Please also do me another favor: Don't always say that I don't >>understand the subject. Even if that would be the case it isn't >>particular fair given that different folks had to educate you >on other topics in the past as well. >>Additionally, if you listen to the audio recordings then you will >>notice that Henning, Ted, and Jon do not seem to understand the issue >>either as they have raised similar issues during the F2F meetings. >> >>Ciao >>Hannes >> >> >> >Hannes - I believe it is you who do not understand RFC 4412 -- and >> >many of us are trying to get that through to you, but you >don't seem >> >to want to listen/read. >> > >> >RFC 4412 is *for* priority marking SIP requests, >> > >> >One use is GETS. >> > >> >One use is MLPP. >> > >> >These examples are in RFC 4412 because there were specific >namespaces >> >being created for the IANA section of that document. >> > >> >Reading the whole document, you will see that RPH can be specified >> >for other uses than GETS or MLPP specifically. >> > >> >I knew when I wrote RFC 4412 that one day we would specify a >> >namespace for ECRIT (the "esnet" namespace now) -- but I >also knew it >> >was premature for RFC 4412 to incorporate that namespace, that a >> >future doc to RFC 4412 would have to be written to do this. >Brian and >> >I talked about this at the original NENA meeting that >created the IP >> >WGs there (in August of 03). We both agreed we should wait >until it >> >was appropriate to the work in the IETF to submit this >document that >> >is now >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >gency-rph-namespace-00.txt >> > >> >Yet, you seem to want to use some additional mechanism to indicate >> >priority of a call in SIP. That means you want to >introduce a second >> >way to accomplish this in SIP. Why do you want to promote >a separate >> >way to do something SIP has already defined? That will cause >> >interoperability issues and we both know that. >> > >> >You've said to me (and others) that you believe RPH is just another >> >way to accomplish what sos or a URI can indicate - and >you're wrong. >> >Your way would be _the_second_way_to_do_it, because SIP already >> >considers RPH to be *the*way* to priority mark SIP requests. >> > >> >If you don't believe me (no comment), then why do you not >believe the >> >SIP WG chair (who knows more about SIP than both of us) - who, on >> >this thread, has again said to you "RFC 4412 >> >(RPH) is the SIP mechanism to priority mark SIP requests"? >> > >> >Further, I believe it is inappropriate to prohibit endpoints from >> >being able to set the esnet namespace. I absolutely >believe it will >> >not be needed most of the time, but I believe if someone >does find a >> >valid use for endpoints to mark priority in SIP, this ID - once it >> >has become an RFC -- will have to be obsoleted with a new >RFC saying >> >the exact opposite. >> > >> >(color me confused ... over and over again) >> > >> >James >> > >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >> >>Keith, please understand that the usage of RFC 4412 for >GETS and for >> >>the type of emergency call we discuss here is different. Just >> >>looking at the header and the name of the namespace is a bit >> >artificial. I hope >> >>you understand that. >> >> >> >> >-----Original Message----- >> >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> >> >Sent: 05 February, 2009 14:55 >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> >mistake) >> >> > >> >> >Which is exactly what RFC 4412 specifies for all namespaces. >> >> > >> >> >regards >> >> > >> >> >Keith >> >> > >> >> >> -----Original Message----- >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >> >On Behalf >> >> >> Of Brian Rosen >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >> >Hannes (NSN >> >> >> - FI/Espoo)'; 'ECRIT' >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> >> mistake) >> >> >> >> >> >> The value is that in some networks where priority for >> >> >emergency calls >> >> >> is appropriate, and appropriate policing of marking is >> >implemented, >> >> >> emergency calls will receive resource priority. >> >> >> >> >> >> Not all networks would need policing. Some will. Policing >> >> >> could be to Route header/R-URI content, but other >criteria are possible. >> >> >> >> >> >> Not all networks will need resource priority for >emergency calls. >> >> >> Fine, ignore this marking/namespace. >> >> >> >> >> >> Brian >> >> >> > -----Original Message----- >> >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, >Hannes (NSN - >> >> >> > FI/Espoo); 'ECRIT' >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: >Agenda (my >> >> >> > mistake) >> >> >> > >> >> >> > I don't even see the value in permitting the >endpoint todo the >> >> >> > RPH marking. >> >> >> > In addition to the security concerns there is also the >> >> >problem that >> >> >> > there are more options to implement without an >additional value. >> >> >> > >> >> >> > >-----Original Message----- >> >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> >> >> > >Sent: 05 February, 2009 00:03 >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, >> >> >> Hannes (NSN - >> >> >> > >FI/Espoo)'; 'ECRIT' >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda >> >> >> > >(my >> >> >> > mistake) >> >> >> > > >> >> >> > >Hannes >> >> >> > > >> >> >> > >This matches my understanding precisely. We wish to >> >> >> permit endpoints >> >> >> > >to mark. We do not require it, and don't necessarily expect >> >> >> > >it in many (even >> >> >> > >most) cases. We don't wish to see the document prohibit it. >> >> >> > >We all seem to agree it has value within the Emergency >> >> >Services IP >> >> >> > >Networks. >> >> >> > > >> >> >> > >Brian >> >> >> > > >> >> >> > >> -----Original Message----- >> >> >> > >> From: ecrit-bounces@ietf.org >> >> >> > >> [mailto:ecrit-bounces@ietf.org] >> >> >> > >On Behalf >> >> >> > >> Of James M. Polk >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - >> >> >> FI/Espoo); 'ECRIT' >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >> >Agenda (my >> >> >> > >> mistake) >> >> >> > >> >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >> >> >> > >> > > James wrote: >> >> >> > >> > >> you are the _lone_ voice not supporting this ID, >> >> >> > >> > >> >> >> > >> >Listening to the audio recording of past meetings I have >> >> >> > >> >to >> >> >> > >say that >> >> >> > >> >I >> >> >> > >> was >> >> >> > >> >not the only persons raising concerns about the document. >> >> >> > >> >That was probably the reason why you agreed to limit the >> >> >> > >scope of the >> >> >> > >> >document (which you didn't later do) to get >folks to agree >> >> >> > >to make it >> >> >> > >> a WG >> >> >> > >> >item. >> >> >> > >> >> >> >> > >> re-listen to the audio please >> >> >> > >> >> >> >> > >> Ted's concerns were consistent with most (all?) other >> >> >> concerns -- >> >> >> > >> which were based on the premise of whether or not the >> >> >> UAC should be >> >> >> > >> trusted to initiate the marking on the INVITE. The most >> >> >> > >> recent version has backed off this to a "can" -- meaning >> >> >> > >> not >> >> >prohibited >> >> >> > >> (i.e., no 2119 text). I also backed off the text in the >> >> >> SP domain >> >> >> > >> part to "can", such that there is no 2119 text >> >> >mandating or even >> >> >> > >> recommending its usage there. I also do not prohibit its >> >> >> > >use, based on >> >> >> > >> local policy. Keith has come forward with the specific >> >> >> > >> request that non-ESInet networks be allowed to >mark and pay >> >> >attention to >> >> >> > >> this priority indication -- with IMS as the specific >> >> >> > >> example he wishes to have this valid for. >> >> >> > >> >> >> >> > >> Where there is no disagreement, save for your recent >> >> >> > >pushback - is in >> >> >> > >> the ESInet, which is where Brian has requested it's >> >> >> > >definition in the >> >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within >> >> >> NENA, and if >> >> >> > >> he asks for it, are you going to say you know >better than he? >> >> >> > >> >> >> >> > >> >> >> >> > >> >Btw, I not disagreeing with the document as such. I >> >> >just want to >> >> >> > the >> >> >> > >> scope >> >> >> > >> >to change. The usage of RPH within the emergency >> >> >> services network >> >> >> > is >> >> >> > >> fine >> >> >> > >> >for me. I may get convinced to start the RPH marking from >> >> >> > >the the VSP >> >> >> > >> >towards the PSAP. I feel uneasy about the end host doing >> >> >> > >the marking. >> >> >> > >> >> >> >> > >> please read what I wrote above, and then re-read the >> >> >most recent >> >> >> > >> version of the ID. I don't have endpoints that SHOULD or >> >> >> MUST mark >> >> >> > >> anything wrt RPH. I also don't want to prohibit it, >> >> >> because there >> >> >> > >> might be cases (that I don't know of) of valid uses >> >> >> under certain >> >> >> > >> circumstances. Figure 1 is very clear that there are 3 >> >> >> networking >> >> >> > >> parts to consider >> >> >> > >> >> >> >> > >> #1 - from the endpoint >> >> >> > >> #2 - within the VSP >> >> >> > >> #3 - within the ESInet >> >> >> > >> >> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and >> >> >> > >2119 language >> >> >> > >> offering those supporting this specification will >have RPH >> >> >> > >> adherence within #3 (the ESInet). >> >> >> > >> >> >> >> > >> What other scope changes do you want, because I haven't >> >> >> heard them. >> >> >> > >> >> >> >> > >> I only heard you claim in email during the last >IETF and in >> >> >> > >the ECRIT >> >> >> > >> session that RPH should not be used for priority marking >> >> >> requests. >> >> >> > >> This is something Keith (SIP WG chair) voiced his >> >> >> > >> opposition to your views regarding creating a >second means >> >> >> > >> for SIP to >> >> >priority >> >> >> > >> mark request "when SIP already has one >interoperable way to >> >> >> > >> accomplish this... it's call the RP header mechanism". >> >> >> > >> >> >> >> > >> >I don't see advantages -- only disadvantages. >> >> >> > >> > >> >> >> > >> >Ciao >> >> >> > >> >Hannes >> >> >> > >> >> >> >> > >> _______________________________________________ >> >> >> > >> Ecrit mailing list >> >> >> > >> Ecrit@ietf.org >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > > >> >> >> >> >> >> _______________________________________________ >> >> >> Ecrit mailing list >> >> >> Ecrit@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> >> > >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77BA3A6B3A for ; Fri, 6 Feb 2009 14:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjaAam+Afx+x for ; Fri, 6 Feb 2009 14:50:27 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 09B643A6C34 for ; Fri, 6 Feb 2009 14:50:26 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-167.messagelabs.com!1233960628!17371104!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 18821 invoked from network); 6 Feb 2009 22:50:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 22:50:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MoR4o025051; Fri, 6 Feb 2009 17:50:27 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16MoPPh025023; Fri, 6 Feb 2009 17:50:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 6 Feb 2009 17:50:24 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01238F63@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RPH Thread-Index: AcmIqmlw2KPubKXZS3KfgX/Sk5WgMgAAuLjt From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:50:28 -0000 V2hhdCBuZXR3b3JrIGhhdmUgeW91IGV2ZXIgZW5naW5lZXJlZD8NCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyA8ZWNyaXQtYm91bmNl c0BpZXRmLm9yZz4NClRvOiBKYW1lcyBNLiBQb2xrIDxqbXBvbGtAY2lzY28uY29tPg0KQ2M6IEVD UklUIDxlY3JpdEBpZXRmLm9yZz4NClNlbnQ6IEZyaSBGZWIgMDYgMTc6Mjk6MDkgMjAwOQ0KU3Vi amVjdDogUmU6IFtFY3JpdF0gUlBIDQoNClRvIHJlc3RhdGU6IEkgd2lsbCBvYmplY3QgdG8gYW55 IHRleHQgbWVudGlvbmluZyB1c2Ugb2YgRVNORVQgaW4gVUFzLiAgDQpJdCdzIHVzZWxlc3MgKHNp bmNlIHVuZGVyLXNwZWNpZmllZCksIGxpa2VseSB0byBiZSBoYXJtZnVsIHRvIHJlbGlhYmxlICAN Cm5ldHdvcmsgb3BlcmF0aW9uIGFuZCBqdXN0IGNhdXNlcyBjb25mdXNpb24uIFRoZSB0ZXh0IHNo b3VsZCBkZXNjcmliZSAgDQp3aGVuIGl0IGlzIHVzZWZ1bCAod2l0aGluIGEgImNsb3NlZCIgRVNO RVQsIHByZXN1bWFibHkpIGFuZCB3aGF0ICANCmNvbmRpdGlvbnMgbmVlZCB0byBiZSBtZXQgaW4g b3JkZXIgdG8gZW5zdXJlIHJlbGlhYmxlIGFuZCBzZWN1cmUgIA0KdXNhZ2UuIFRoYXQgc29tZXRo aW5nIG1pZ2h0IGJlIHVzZWZ1bCBzb21ld2hlcmUgZWxzZSBpcyBhbHdheXMgdHJ1ZSwgIA0KaW4g YW55IHNwZWNpZmljYXRpb24sIGJ1dCB3ZSBkb24ndCBhZGQgYSAiVGhpcyBkb2N1bWVudCBkb2Vz IG5vdCAgDQpwcmV2ZW50IHRoZSB1c2Ugb2YgdGhpcyBtZWNoYW5pc20gc29tZXdoZXJlIGVsc2Uu IiBpbiBkb2N1bWVudHMuDQoNCkhlbm5pbmcNCg0KT24gRmViIDYsIDIwMDksIGF0IDU6MjEgUE0s IEphbWVzIE0uIFBvbGsgd3JvdGU6DQoNCj4gQXQgMDQ6MDUgUE0gMi82LzIwMDksIEhlbm5pbmcg U2NodWx6cmlubmUgd3JvdGU6DQo+PiBKYW1lcywNCj4+DQo+PiB3ZSBkb24ndCBnbyB0aHJvdWdo IGV2ZXJ5IHBvc3NpYmxlIFNJUCBoZWFkZXIgdGhhdCBtaWdodCBiZSBpbnNlcnRlZA0KPj4gaW50 byBlbWVyZ2VuY3kgcmVxdWVzdHMuIFllcywgc29tZWJvZHkgY291bGQgYWRkIFJQSCwgYnV0IHRo aXMgIA0KPj4gYXBwbGllcw0KPj4gdG8gUEFJIGFuZCBkb3plbnMgb2Ygb3RoZXIgU0lQIGhlYWRl cnMgYXMgd2VsbC4gU28gZmFyLCBub2JvZHkgaGFzDQo+PiBwcm92aWRlZCwgaW4gbXkgb3Bpbmlv biwgYSBjb21wZWxsaW5nIHVzZSBjYXNlIHRoYXQgaXMgd29ydGgNCj4+IGRvY3VtZW50aW5nLiAi SXQgY291bGQgYmUgdXNlZnVsIHNvbWV3aGVyZSBmb3Igc29tZXRoaW5nIiBkb2Vzbid0IGN1dA0K Pj4gaXQuIEkgaGF2ZSBwcm92aWRlZCBtdWx0aXBsZSByZWFzb25zIHdoeSBJIHRoaW5rIHRoYXQg aXQgaXMgYSBiYWQgIA0KPj4gaWRlYQ0KPj4gZm9yIChub3JtYWwpIFVBcyB0byBkbyBzbywgbm9u ZSBvZiB3aGljaCB5b3UgYWRkcmVzcy4NCj4NCj4NCj4+IEkgc2VlIG5vIG5lZWQgdG8gIHNheSAi ZG8gbm90IGluc2VydCBSUEgiLA0KPg0KPiB0aGlzIGlzIHRoZSBvbmx5IHRoaW5nIC0gcmlnaHQg bm93IC0gdGhhdCBJJ20gYWZyYWlkIG9uZSBvZiB1cyAgDQo+IGJlbGlldmVzIHNob3VsZCBiZSB0 aGUgY2FzZS4gSSdtIGdsYWQgeW91IGFyZSBub3Qgam9pbmluZyB0aGF0ICANCj4gcG9zaXRpb24u ICBJIHJlYWxseSBkbyBub3Qgd2FudCB0byBoaWdobGlnaHQgdGhlIGlkZWEgZm8gVUFzICANCj4g aW5zZXJ0aW5nIGVzbmV0LCBidXQgSSBiZWxpZXZlIHNvbWV0aW1lIGRvd24gdGhlIHJvYWQgLSBz b21lICANCj4gY3VzdG9tZXIgd2lsbCBjb21lIHVwIHdpdGggYSB2YWxpZCByZWFzb24gZm9yIHRo aXMsIGFuZCBJIGRvbid0IHdhbnQgIA0KPiB0byBzdGF0ZSBpbiB0ZXh0IHRoYXQgaXQgaXMgcHJl dmVudGVkIGZyb20gYmVpbmcgaW5zZXJ0ZWQgKGFuZCB5ZXQgIA0KPiBoYXZlIHRoZSB2ZW5kb3Ig d2hvIHdhbnRzIHRvIHNlbGwgdG8gdGhhdCBjdXN0b21lciBhbHNvIHdhbnQgdGhhdCAgDQo+IHZl bmRvciB0byBhZGhlcmUgdG8gdGhpcyBzcGVjIGFzIHdlbGwpLg0KPg0KPiBJJ20ganVzdCBhZHZv Y2F0aW5nIHdlIG5vdCBoYXZlIHRoZSB0ZXh0IHByZXZlbnQgaXRzIGluY2x1c2lvbi4NCj4NCj4g QXMgSSd2ZSBzYWlkLCBJIHdpbGwgYmVlZiB1cCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiB3cnQgIA0KPiBVQSBpbnNlcnRpb24gb2YgZXNuZXQgLSB1bmxlc3Mgb3RoZXJzIG9i amVjdCB0byB0aGlzLi4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo= Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0C93A6C9F for ; Fri, 6 Feb 2009 14:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNNbnRZRmDAB for ; Fri, 6 Feb 2009 14:51:21 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BC8083A6C46 for ; Fri, 6 Feb 2009 14:51:20 -0800 (PST) Received: (qmail invoked by alias); 06 Feb 2009 22:51:22 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp001) with SMTP; 06 Feb 2009 23:51:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8D0ZhUfv8O7X9+2FOX+sFzfkPgCsBjSSYbGb7+j WGWMJBGWk+TyVm From: "Hannes Tschofenig" To: "'DOLLY, MARTIN C, ATTLABS'" , , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> Date: Sat, 7 Feb 2009 00:52:07 +0200 Message-ID: <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:51:24 -0000 Hi Martin, I am arguing that if the UE does mark the call with the ECRIT RPH (I call it that way to differentiate it from RFC 4412 RPH usage, which is very different) then it should be ignored. Processing it will not help in any way (as I described in my pseudo code snippet). Incorrectly processing it (which is a possibility when the implementer does not understand the security implications -- they will not get it from the current version of the draft) will lead to security problems (fraud & DoS potential). While you cannot prevent someone from sending you, there is certainly the chance to document what the receiver should do with it. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of DOLLY, MARTIN C, ATTLABS >Sent: 07 February, 2009 00:15 >To: jmpolk@cisco.com; hgs@cs.columbia.edu; >James.Winterbottom@andrew.com >Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org >Subject: Re: [Ecrit] RPH > >You can not disallow this from an UE. The trust relationship >will dictate whether it is accepted or not > >----- Original Message ----- >From: ecrit-bounces@ietf.org >To: Henning Schulzrinne ; Winterbottom, >James >Cc: Tschofenig, Hannes (NSN - FI/Espoo) >; ECRIT >Sent: Fri Feb 06 17:10:08 2009 >Subject: Re: [Ecrit] RPH > >At 03:05 PM 2/6/2009, Henning Schulzrinne wrote: >>There's another problem with the "it doesn't hurt argument". >Assume for >>a moment we have a "UA MAY include RPH" wording. There are now two >>cases: >> >>(1) All UAs implement it. >> >>(2) Only some UAs implement it. >> >>(1) seems unlikely for a MAY. If (2) occurs, we have the >choice between >>two undesirable outcomes: >> >>(a) some UAs that are otherwise compliant get worse service just >>because they didn't include the RPH; > >am I reading this correctly - that unless all UAs implement >this capability this should never be implemented by any UAs? > >This flies in the face of vendors solving for their customer's >requirements. > >I will admit that at this time, I know of no Cisco customers >that want this capability, so I'm not angling for any of our >revenue here. I'm saying that I think I hear you saying this >ID should say something like > > UAs are prevented from implementing the RP namespace esnet > >I'm fighting against that, because customers are always coming >to every vendor with new requirements, some of them unique at >the time. This prevention text would prevent a vendor from >complying with this specification and still meet the customer's needs. > >I believe that this ID needs to retain the endpoints MAY >insert esnet, and have appropriate security considerations >text that highlights the concerns expressed here. > >Some future ID can then update this current RFC (to-be) within the >2119 rules of the use of MAY here. > > >>OR >> >>(b) the proxy has to look for the service URN to give the call the >>appropriate treatment, thus obviating any advantage of having the >>header, yet incurring more complicated processing logic. >> >> >>I have no objection to whatever markings people want to apply to calls >>within an ESN - that's largely a private matter. >> >>Henning >> >>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: >> >>>Hi All, >>> >>>I have followed thi thread with some interest and I struggling to >>>see a use case for the >>>providing RPH for emergency calls from the end-point. >>> >>>The reference-model call in ECRIT, for better or worse, is for all >>>calls to go back through a home-VSP. >>>We placed quite a lot of emphasis, largely for traffing reasons, for >>>the VSP to be able to verify that >>>a call is in fact an emergency call. This is done by the proxy >>>taking the inband location, doing a LoST >>>query with the provided URN, and verifying that the resulting >>>destination URI is the same as the destination >>>URI provide in the SIP INVITE. My understanding was that VSPs would >>>always do this check so they could >>>tell if they could bill for the call or not, and because the VSP can >>>be use that the call is an emergency call >>>it can apply any special priorities that may be applicable. This >>>obviates the need for RPH from the end-point >>>to the network. >>> >>>This leaves us with the argument of "it doesn't hurt to it", which >>>is not a good reason to write a specification. >>>It was intimated on the geopriv mailing list last year that great >>>pains had been taken to keep SIP with in the >>>MTU limits of UDP over Ethernet >>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612 >0.html ). Assuming >>>that this is the case, perhaps there is harm in including >>>information that we know will be ignored. >>> >>>Cheers >>>James >>> >>> >>> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >>>Sent: Fri 2/6/2009 12:33 PM >>>To: 'Brian Rosen'; 'Henning Schulzrinne' >>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >>>Subject: Re: [Ecrit] RPH >>> >>>To the story short here is the code for the proxy: >>> >>>--------------------- >>> >>>IF emergency call was recognized THEN >>> execute emergency call specific procedures (priority queuing, >>>preemption, fetch location, determine routing, do funny QoS things & >>>co) >>>ELSE >>> normal call handling procedures. >>> >>>--------------------- >>> >>>If you can make this differentiation between an emergency call and a >>>regular >>>call then you can also do everything that is necessary for emergency >>>call >>>handling. >>> >>>Brian + Keith: Please tell me that we cannot do the above with our >>>currently >>>specified mechanisms. >>> >>>Ciao >>>Hannes >>> >>>>-----Original Message----- >>>>From: Brian Rosen [mailto:br@brianrosen.net] >>>>Sent: 06 February, 2009 17:49 >>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>>Subject: RE: [Ecrit] RPH >>>> >>>>I agree that not all networks will permit (or pay attention >>>>to) a priority request from an end device. >>>> >>>>No one has asked for that. >>>> >>>>The namespace request has several uses, one of which is within >>>>an emergency services IP network, one of which is between >>>>elements within a public network controlled by the operator, >>>>and one of which is an endpoint request for resource priority. >>>> >>>>Those of us requesting this work proceed are happy if the >>>>endpoint part is simply left as possible (MAY), and, speaking >>>>for myself, having the draft discuss the security implications >>>>of endpoint marking is reasonable. >>>> >>>>Having discussed this issue with an implementation team who >>>>worked on MLPP systems, I am confident I know what I'm talking >>>>about, but YMMV. The fact that you could, if you wanted to, >>>>give resource priority to a call you decided, however you >>>>decided, was an emergency call is an implementation decision, >>>>and not subject to standardization. >>>> >>>>RPH is the IETF standard way for one entity to request >>>>resource priority of another entity in a SIP system. We're >>>>asking for a namespace to use that within the domain of >>>>emergency calls. That is, I think, a VERY reasonable request. >>>> >>>>Brian >>>> >>>>>-----Original Message----- >>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>Sent: Friday, February 06, 2009 10:33 AM >>>>>To: Hannes Tschofenig >>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >>>>>Subject: Re: [Ecrit] RPH >>>>> >>>>>To chime in here: >>>>> >>>>>I don't think it's productive to simply state that 4412 >>>>doesn't worry >>>>>about authorization, so we shouldn't either (simplifying a bit). >>>>>Authorization was discussed repeatedly, and the general >>>>assumption was >>>>>that there were two conditions: Either the user invoking resource- >>>>>priority was well known and had a set of permissions that could be >>>>>checked in real time or there are ways to deal with abuse after the >>>>>fact in ways that deter abuse (the court-martial kind of thing in a >>>>>military context). >>>>> >>>>>The RFC 4412 security consideration (11.2) call this out in pretty >>>>>strong language: >>>>> >>>>> Prioritized access to network and end-system resources imposes >>>>> particularly stringent requirements on authentication and >>>>> authorization mechanisms, since access to prioritized >>>>resources may >>>>> impact overall system stability and performance and not >>>>just result >>>>> in theft of, say, a single phone call. >>>>>Thus, the question is whether we have such strong authentication in >>>>>emergency calling. In some cases, such as residential fixed line >>>>>deployments where ISP = VSP, we're probably pretty close, >in others, >>>>>such as prepaid cell phones or hot spots or VSP-only providers, we >>>>>aren't. >>>>> >>>>>The other point that I think Hannes is making is that the >>>>information >>>>>is either redundant or dangerous. If a processing element >recognizes >>>>>the call as being an emergency call, it can apply whatever >treatment >>>>>it deems appropriate and doesn't need additional information. If it >>>>>doesn't or can't, using just the RPH can be rather dangerous unless >>>>>that element can be reasonably certain that there is strong >>>>>authentication and recourse. >>>>> >>>>>I don't buy the argument that somehow finding the RPH is >faster than >>>>>just looking for the identifier. Thus, given that the >information is >>>>>either redundant or dangerous, I fail to see the advantage. >>>>> >>>>>Henning >>>>> >>>>> >>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >>>>> >>>>>>Don't get hung up on the details. There are ways to optimize it. >>>>>>That was >>>>>>not the point of the code example. >>>>>> >>>>>>The problem that my pseudo code should have shown you is that you >>>>>>* don't gain anything with RPH marking for the emergency call case >>>>>>from the SIP UA towards the outbound proxy since the functionality >>>>>>is already provide otherwise. How often does the proxy need to get >>>>>>told that this is an emergency call todo whatever emergency call >>>>>>handling procedures are necessary? >>>>>>* you only introduce fraud problems (if you are not >>>>careful and you >>>>>>understand the security stuff well enough) >>>>>> >>>>>>If you can point me to people who implement the RPH emergency call >>>>>>case please do so. I would love to talk to them. >>>>>> >>>>>>Ciao >>>>>>Hannes >>>>>> >>>>>>PS: You need to parse incoming messages to some extend so that you >>>>>>know what it contains :-) Only looking for the emergency >>>>RPH header >>>>>>(and not for the Service URN/dial >>>>>>string) would exactly be the DoS/fraud attack I am worried about. >>>>>>That's the thing Henning was worried about (go and listen to the >>>>>>past meeting minutes). >>>>>> >>>>>> >>>>>>>Hannes >>>>>>> >>>>>>>You need to talk to people who really implement this kind >>>>of thing. >>>>>>>You are way off. >>>>>>> >>>>>>>When you implement a resource priority system, the point of doing >>>>>>>that is to look though the queue of work and pick out the >>>>ones with >>>>>>>priority, handling them first. You don't do all the parsing, you >>>>>>>don't do a lot of decision tree. >>>>>>> >>>>>>>Typically: >>>>>>>Check for DoS things, like too big messages, etc Do a quick scan >>>>>>>for the RPH message header If found: >>>>>>>Parse the message >>>>>>>Determine validity >>>>>>>Determine priority >>>>>>>Queue on the correct work queue >>>>>>> >>>>>>>The first two actions have to be very fast. Anyone who builds a >>>>>>>SIP thingie will tell you that parsing is one of the big cycle >>>>>>>consumers: if you have to parse every message BEFORE you >>>>determine >>>>>>>priority, you can't give much resource priority. >>>>>>>Once you get the whole message parsed, you might as well finish >>>>>>>working on it, because you've done so much of the work. >>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick >>>>>>>string search for RPH is fast. If you are doing >>>>priority, you need >>>>>>>to keep all the priority processing pretty uniform, and pretty >>>>>>>simple, or you tend to spend too much time futzing around >>>>figuring >>>>>>>out what to do. You put all the priority related stuff together, >>>>>>>and use as much common code as possible. >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>On Behalf >>>>>>>>Of Hannes Tschofenig >>>>>>>>Sent: Friday, February 06, 2009 8:41 AM >>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn' >>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >>>>>>>>bounces@ietf.org >>>>>>>>Subject: [Ecrit] RPH >>>>>>>> >>>>>>>>Over lunch I was also thinking how an outbound proxy would >>>>>implement >>>>>>>>some of the emergency procedures. Here are some thoughts: >>>>>>>> >>>>>>>>--------------------------------------------------- >>>>>>>> >>>>>>>>// Process incoming message >>>>>>>>Parse(msg); >>>>>>>> >>>>>>>>// SIP INVITE without Service URN >>>>>>>>// legacy devices >>>>>>>>If (recognize-dialstring(msg)==TRUE) { // we got an emergency >>>>>>>>call going on emergency=TRUE; if (dialstring(msg) == 911) >>>>>>>>serviceURN=urn:service:sos; } else if >>>>>>>>(recognize-serviceURN(msg)==TRUE) { // oh. A updated >>>>device that >>>>>>>>has a service URN attached to the >>>>>call >>>>>>>>serviceURN=retrieve_ServiceURN(msg); >>>>>>>>emergency=TRUE; >>>>>>>>} else { >>>>>>>>// standard SIP message >>>>>>>>// regular processing >>>>>>>>process(msg); >>>>>>>>emergency=FALSE; >>>>>>>>} >>>>>>>> >>>>>>>>If (emergency == TRUE) { >>>>>>>> // make sure that the emergency call does not get >>>>dropped on the >>>>>>>>floor >>>>>>>> // skip authorization failures >>>>>>>> // give the call a special treatment >>>>>>>> lots-of-code-here(); >>>>>>>> >>>>>>>> // trigger all the QoS signaling you have in the >>>>network to make >>>>>>>>James happy >>>>>>>> trigger-qos(); >>>>>>>> >>>>>>>> // query location >>>>>>>> location=retrieve-location(); >>>>>>>> >>>>>>>> // determine next hop >>>>>>>> next-hop=lost(location, serviceURN) >>>>>>>> >>>>>>>> // attach RPH marking to outgoing msg to make James and >>>>>>>Keith happy >>>>>>>> msg=add(msg, RPH); >>>>>>>> >>>>>>>> send(msg, next-hop); >>>>>>>>} >>>>>>>> >>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >>>>>>>> // all the emergency related processing done already upfront >>>>>>>> // hence I log something. >>>>>>>> log(RPH_WAS_PRESENT_JUHU); >>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency == >>>>FALSE)) { >>>>>>>>// this is not an emergency call // this is something >>>>like GETS >>>>>>>>result=special-authorization-procedure(user); >>>>>>>> >>>>>>>>if (result == AUTHORIZED) { >>>>>>>> // do some priority & preemption thing here. >>>>>>>> // trigger all the QoS you have >>>>>>>> lots-of-code-here(); >>>>>>>>} else { >>>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // >>>>>>>>don't need todo any RPH processing // this includes the case >>>>>>>>where the call was an emergency call but the RPH >>>>>>>> >>>>>>>>// marking was not there. >>>>>>>>nothing(); >>>>>>>>} >>>>>>>> >>>>>>>>--------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>>Ciao >>>>>>>>Hannes >>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>>>>Behalf Of Hannes Tschofenig >>>>>>>>>Sent: 06 February, 2009 15:07 >>>>>>>>>To: 'Janet P Gunn' >>>>>>>>>Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >>>>>>>>FI/Espoo) >>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >Agenda (RPH) >>>>>>>>> >>>>>>>>>Who would define something that could prevent DoS problems? >>>>>>>>> >>>>>>>>>________________________________ >>>>>>>>> >>>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>>>>>>>> Sent: 06 February, 2009 14:11 >>>>>>>>> To: Hannes Tschofenig >>>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >>>>>>>>>ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >>>>>'James >>>>>>>>>M. Polk' >>>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>Meeting: Agenda (RPH) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> But there is nothing IN RFC4412 that specifically >>>>>>>addresses how to >>>>>>>>>prevent any particular namespace being used for DoS. >Anyone/any >>>>>UA >>>>>>>>>can ATTEMPT to invoke priority treatment by attaching RPH. For >>>>>all >>>>>>>>>of the 4412 namespaces, as with the new proposed namespace, the >>>>>>>>>mechanisms for preventing DoS are not specified in the >>>>>>>document that >>>>>>>>>defines the namespace. >>>>>>>>>They are/will be specified elsewhere. >>>>>>>>> >>>>>>>>> Janet >>>>>>>>> >>>>>>>>> This is a PRIVATE message. If you are not the intended >>>>>>>recipient, >>>>>>>>>please delete without copying and kindly advise us by e-mail of >>>>>the >>>>>>>>>mistake in delivery. >>>>>>>>> NOTE: Regardless of content, this e-mail shall not >>>>>>>operate to bind >>>>>>>>>CSC to any order or other contract unless pursuant to explicit >>>>>>>>>written agreement or government initiative expressly permitting >>>>>the >>>>>>>>>use of e-mail for such purpose. >>>>>>>>> >>>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 >04:21:51 AM: >>>>>>>>> >>>>>>>>> > Hi James, >>>>>>>>> > >>>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF >>>>>>>documents. What I >>>>>>>>>would >>>>>>>>> > like to point out is that there is more than just a >>>>>>>header and >>>>>>>>>values within >>>>>>>>> > the header that have to be considered in order to >>>>>>>make a judgement >>>>>>>>>of what >>>>>>>>> > is appropriate and what isn't. There is an >>>>>>>architectural question >>>>>>>>>and >>>>>>>>> > whether the environment we are using the stuff is >>>>>>>indeed providing >>>>>>>>>the >>>>>>>>> > properties you need for the solution to be >>>>appropriate. >>>>>>>>> > >>>>>>>>> > Let me describe in more detail what I meant (and >>>>>>>please correct me >>>>>>>>>if I am >>>>>>>>> > wrong). >>>>>>>>> > >>>>>>>>> > Getting priority for SIP requests when using a GETS >>>>>>>alike scenario >>>>>>>>>means >>>>>>>>> > that the entity that issues the request is specially >>>>>>>authorized >>>>>>>>>since >>>>>>>>> > otherwise you introduce a nice denial of >>>>service attack. This >>>>>>>>>authorization >>>>>>>>> > is tied to the entity that makes the request. For >>>>>>>example, the >>>>>>>>>person is >>>>>>>>> > working for the government and has special rights. >>>>>>>>>James Bond as a (not so) >>>>>>>>> > secret agent might have these rights. >>>>>>>>> > >>>>>>>>> > The emergency services case >>>>(citizen-to-authority) is a bit >>>>>>>>>different as >>>>>>>>> > there aren't really special rights with respect to >>>>>>>authorization >>>>>>>>>tied to >>>>>>>>> > individuals. Instead, the fact that something is an >>>>>>>emergency is >>>>>>>>>purely a >>>>>>>>> > judgement of the human that dials a special number. >>>>>>>>>To deal with fraud, we >>>>>>>>> > discussed in the group on what we can actually do to >>>>>>>ensure that >>>>>>>>>end users >>>>>>>>> > do not bypass security procedures (such as >>>>>>>authorization checks, >>>>>>>>>charging >>>>>>>>> > and so on). Part of this investigation was >>>>the publication of >>>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also >>>>describes this >>>>>>>>>issue. >>>>>>>>> > >>>>>>>>> > So, imagine the implementation of a SIP >proxy (and we >>>>>>>implemented >>>>>>>>>that >>>>>>>>> > stuff) that receives a call that contains a Service >>>>>>>URN. The code >>>>>>>>>branches >>>>>>>>> > into a special mode where everything is done >>>>so that the call >>>>>>>>>receives >>>>>>>>> > appropriate treatment and does not get >dropped on the >>>>>>>floor. The >>>>>>>>>way how the >>>>>>>>> > Service URN is placed in the message >ensures that the >>>>>>>call cannot >>>>>>>>>go to my >>>>>>>>> > friend (instead of the PSAP) unless the end host ran >>>>>>>LoST already. >>>>>>>>>In the >>>>>>>>> > latter case, we discussed this also on the >list for a >>>>>>>while and >>>>>>>>>Richard even >>>>>>>>> > wrote a draft about it in the context of the >>>>location hiding >>>>>>>>>topic, we said >>>>>>>>> > that the proxy would have to run LoST if he >>>>cares about a >>>>>>>>>potential >>>>>>>>> > fraudulent usage. >>>>>>>>> > >>>>>>>>> > So, what do we need todo in order to provide >>>>secure RFC 4412 >>>>>>>>>functionality >>>>>>>>> > in our context? >>>>>>>>> > >>>>>>>>> > Do you think that the current text in >>>>>>>>> > >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >>>>>>>>>gency-rph-nam >>>>>>>>> > espace-00.txt reflects any of the >>>>above-described issues: >>>>>>>>> > " >>>>>>>>> > The Security considerations that apply >to RFC 4412 >>>>>>>>>[RFC4412] >>>>>>>>>apply >>>>>>>>> > here. This document introduces no new security >>>>>>>>>issues relative >>>>>>>>>to >>>>>>>>> > RFC 4412. >>>>>>>>> > " >>>>>>>>> > >>>>>>>>> > From various discussions in GEOPRIV I recall >>>>that you are >>>>>>>>>super-sensitive >>>>>>>>> > regarding security and privacy. For some reasons you >>>>>>>don't seem to >>>>>>>>>have the >>>>>>>>> > same concerns here. I would like to >>>>understand your reasoning. >>>>>>>>> > >>>>>>>>> > Please also do me another favor: Don't always say >>>>>>>that I don't >>>>>>>>>understand >>>>>>>>> > the subject. Even if that would be the case it isn't >>>>>>>particular >>>>>>>>>fair given >>>>>>>>> > that different folks had to educate you on other >>>>>>>topics in the >>>>>>>>>past as well. >>>>>>>>> > Additionally, if you listen to the audio recordings >>>>>>>then you will >>>>>>>>>notice >>>>>>>>> > that Henning, Ted, and Jon do not seem to understand >>>>>>>the issue >>>>>>>>>either as >>>>>>>>> > they have raised similar issues during the >>>>F2F meetings. >>>>>>>>> > >>>>>>>>> > Ciao >>>>>>>>> > Hannes >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >Hannes - I believe it is you who do not understand >>>>>>>RFC 4412 -- >>>>>>>>> > >and many of us are trying to get that >>>>through to you, but you >>>>>>>>> > >don't seem to want to listen/read. >>>>>>>>> > > >>>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, >>>>>>>>> > > >>>>>>>>> > >One use is GETS. >>>>>>>>> > > >>>>>>>>> > >One use is MLPP. >>>>>>>>> > > >>>>>>>>> > >These examples are in RFC 4412 because there >>>>were specific >>>>>>>>> > >namespaces being created for the IANA section of >>>>>>>that document. >>>>>>>>> > > >>>>>>>>> > >Reading the whole document, you will see >>>>that RPH can be >>>>>>>>> > >specified for other uses than GETS or MLPP >>>>specifically. >>>>>>>>> > > >>>>>>>>> > >I knew when I wrote RFC 4412 that one day we >>>>would specify a >>>>>>>>> > >namespace for ECRIT (the "esnet" namespace >>>>now) -- but I also >>>>>>>>> > >knew it was premature for RFC 4412 to >>>>incorporate that >>>>>>>>> > >namespace, that a future doc to RFC 4412 >>>>would have to be >>>>>>>>> > >written to do this. Brian and I talked about >>>>this at the >>>>>>>>> > >original NENA meeting that created the IP WGs there >>>>>>>(in August >>>>>>>>> > >of 03). We both agreed we should wait until it was >>>>>>>>> > >appropriate to the work in the IETF to >>>>submit this document >>>>>>>>> > >that is now >>>>>>>>> > >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l >ocal-emer >>>>>>>>> > >gency-rph-namespace-00.txt >>>>>>>>> > > >>>>>>>>> > >Yet, you seem to want to use some additional >>>>mechanism to >>>>>>>>> > >indicate priority of a call in SIP. That >>>>means you want to >>>>>>>>> > >introduce a second way to accomplish this in SIP. >>>>>>>>>Why do you >>>>>>>>> > >want to promote a separate way to do something SIP >>>>>>>has already >>>>>>>>> > >defined? That will cause interoperability >issues and >>>>>>>we both know >>>>>>>>>that. >>>>>>>>> > > >>>>>>>>> > >You've said to me (and others) that you >>>>believe RPH is just >>>>>>>>> > >another way to accomplish what sos or a URI can >>>>>>>indicate - and >>>>>>>>> > >you're wrong. Your way would be >>>>_the_second_way_to_do_it, >>>>>>>>> > >because SIP already considers RPH to be >>>>*the*way* to priority >>>>>>>>> > >mark SIP requests. >>>>>>>>> > > >>>>>>>>> > >If you don't believe me (no comment), then >>>>why do you not >>>>>>>>> > >believe the SIP WG chair (who knows more >>>>about SIP than both >>>>>>>>> > >of us) - who, on this thread, has again said >>>>to you "RFC 4412 >>>>>>>>> > >(RPH) is the SIP mechanism to priority mark >>>>SIP requests"? >>>>>>>>> > > >>>>>>>>> > >Further, I believe it is inappropriate to >>>>prohibit endpoints >>>>>>>>> > >from being able to set the esnet namespace. >>>>I absolutely >>>>>>>>> > >believe it will not be needed most of the >>>>time, but I believe >>>>>>>>> > >if someone does find a valid use for >>>>endpoints to mark >>>>>>>>> > >priority in SIP, this ID - once it has >>>>become an RFC -- will >>>>>>>>> > >have to be obsoleted with a new RFC saying >the exact >>>>>>>opposite. >>>>>>>>> > > >>>>>>>>> > >(color me confused ... over and over again) >>>>>>>>> > > >>>>>>>>> > >James >>>>>>>>> > > >>>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >>>>>>>>> > >>Keith, please understand that the usage >of RFC 4412 >>>>>>>for GETS and >>>>>>>>>for >>>>>>>>> > >>the type of emergency call we discuss here is >>>>>>>different. Just >>>>>>>>>looking >>>>>>>>> > >>at the header and the name of the >namespace is a bit >>>>>>>>> > >artificial. I hope >>>>>>>>> > >>you understand that. >>>>>>>>> > >> >>>>>>>>> > >> >-----Original Message----- >>>>>>>>> > >> >From: DRAGE, Keith (Keith) >>>>>>>>>[mailto:drage@alcatel-lucent.com] >>>>>>>>> > >> >Sent: 05 February, 2009 14:55 >>>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >>>>>>>>>Polk'; 'Tschofenig, >>>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>>>Meeting: Agenda (my >>>>>>>>> >>>>>>>>> > >> >mistake) >>>>>>>>> > >> > >>>>>>>>> > >> >Which is exactly what RFC 4412 specifies for all >>>>>>>namespaces. >>>>>>>>> > >> > >>>>>>>>> > >> >regards >>>>>>>>> > >> > >>>>>>>>> > >> >Keith >>>>>>>>> > >> > >>>>>>>>> > >> >> -----Original Message----- >>>>>>>>> > >> >> From: ecrit-bounces@ietf.org >>>>>>>[mailto:ecrit-bounces@ietf.org] >>>>>>>>> > >> >On Behalf >>>>>>>>> > >> >> Of Brian Rosen >>>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >>>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >>>>Polk'; 'Tschofenig, >>>>>>>>> > >Hannes (NSN >>>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' >>>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>>>>Meeting: Agenda (my >>>>>>>>> > >> >> mistake) >>>>>>>>> > >> >> >>>>>>>>> > >> >> The value is that in some networks >>>>where priority for >>>>>>>>> > >> >emergency calls >>>>>>>>> > >> >> is appropriate, and appropriate >>>>policing of marking is >>>>>>>>> > >implemented, >>>>>>>>> > >> >> emergency calls will receive resource >priority. >>>>>>>>> > >> >> >>>>>>>>> > >> >> Not all networks would need policing. Some >>>>>>>will. Policing >>>>>>>>>could >>>>>>>>> > >> >> be to Route header/R-URI content, but other >>>>>>>criteria are >>>>>>>>>possible. >>>>>>>>> > >> >> >>>>>>>>> > >> >> Not all networks will need resource priority >>>>>>>for emergency >>>>>>>>>calls. >>>>>>>>> > >> >> Fine, ignore this marking/namespace. >>>>>>>>> > >> >> >>>>>>>>> > >> >> Brian >>>>>>>>> > >> >> > -----Original Message----- >>>>>>>>> > >> >> > From: Hannes Tschofenig >>>>>>>>>[mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >>>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >>>>>>>Tschofenig, Hannes >>>>>>>>>(NSN - >>>>>>>>> > >> >> > FI/Espoo); 'ECRIT' >>>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>>>Meeting: Agenda (my >>>>>>>>> > >> >> > mistake) >>>>>>>>> > >> >> > >>>>>>>>> > >> >> > I don't even see the value in permitting the >>>>>>>endpoint todo >>>>>>>>>the >>>>>>>>> > >> >> > RPH marking. >>>>>>>>> > >> >> > In addition to the security concerns >>>>there is also the >>>>>>>>> > >> >problem that >>>>>>>>> > >> >> > there are more options to implement without >>>>>>>an additional >>>>>>>>>value. >>>>>>>>> > >> >> > >>>>>>>>> > >> >> > >-----Original Message----- >>>>>>>>> > >> >> > >From: Brian Rosen >[mailto:br@brianrosen.net] >>>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 >>>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >>>>>>>'Tschofenig, >>>>>>>>> > >> >> Hannes (NSN - >>>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' >>>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >>>>Interim Meeting: >>>>>>>>>Agenda (my >>>>>>>>> > >> >> > mistake) >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > >Hannes >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > >This matches my understanding >>>>precisely. We wish to >>>>>>>>> > >> >> permit endpoints >>>>>>>>> > >> >> > >to mark. We do not require it, and >>>>don't necessarily >>>>>>>>>expect it >>>>>>>>> > >> >> > >in many (even >>>>>>>>> > >> >> > >most) cases. We don't wish to see the >>>>>>>document prohibit >>>>>>>>>it. >>>>>>>>> > >> >> > >We all seem to agree it has value >within the >>>>>>>Emergency >>>>>>>>> > >> >Services IP >>>>>>>>> > >> >> > >Networks. >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > >Brian >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > >> -----Original Message----- >>>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org >>>>>>>>>[mailto:ecrit-bounces@ietf.org] >>>>>>>>> > >> >> > >On Behalf >>>>>>>>> > >> >> > >> Of James M. Polk >>>>>>>>> > >> >> > >> Sent: Wednesday, February 04, >2009 4:01 PM >>>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >>>>Hannes (NSN - >>>>>>>>> > >> >> FI/Espoo); 'ECRIT' >>>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT >Virtual Interim >>>>>>>>>Meeting: >>>>>>>>> > >Agenda (my >>>>>>>>> > >> >> > >> mistake) >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >>>>Tschofenig wrote: >>>>>>>>> > >> >> > >> > > James wrote: >>>>>>>>> > >> >> > >> > >> you are the _lone_ voice not >>>>>>>supporting this ID, >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> >Listening to the audio recording of past >>>>>>>meetings I >>>>>>>>>have to >>>>>>>>> > >> >> > >say that >>>>>>>>> > >> >> > >> >I >>>>>>>>> > >> >> > >> was >>>>>>>>> > >> >> > >> >not the only persons raising >>>>concerns about the >>>>>>>>>document. >>>>>>>>> > >> >> > >> >That was probably the reason why you >>>>>>>agreed to limit >>>>>>>>>the >>>>>>>>> > >> >> > >scope of the >>>>>>>>> > >> >> > >> >document (which you didn't later do) to >>>>>>>get folks to >>>>>>>>>agree >>>>>>>>> > >> >> > >to make it >>>>>>>>> > >> >> > >> a WG >>>>>>>>> > >> >> > >> >item. >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> re-listen to the audio please >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> Ted's concerns were consistent with most >>>>>>>>>(all?) other >>>>>>>>> > >> >> concerns -- >>>>>>>>> > >> >> > >> which were based on the premise >of whether >>>>>>>or not the >>>>>>>>> > >> >> UAC should be >>>>>>>>> > >> >> > >> trusted to initiate the marking on the >>>>>>>INVITE. The >>>>>>>>>most >>>>>>>>> > >> >> > >> recent version has backed off this >>>>to a "can" -- >>>>>>>>>meaning not >>>>>>>>> > >> >prohibited >>>>>>>>> > >> >> > >> (i.e., no 2119 text). I also backed off >>>>>>>the text in >>>>>>>>>the >>>>>>>>> > >> >> SP domain >>>>>>>>> > >> >> > >> part to "can", such that there is >>>>no 2119 text >>>>>>>>> > >> >mandating or even >>>>>>>>> > >> >> > >> recommending its usage there. I also do >>>>>>>not prohibit >>>>>>>>>its >>>>>>>>> > >> >> > >use, based on >>>>>>>>> > >> >> > >> local policy. Keith has come >forward with >>>>>>>the specific >>>>>>>>> >>>>>>>>> > >> >> > >> request that non-ESInet networks be >>>>>>>allowed to mark and >>>>>>>>>pay >>>>>>>>> > >> >attention to >>>>>>>>> > >> >> > >> this priority indication -- with IMS as >>>>>>>the specific >>>>>>>>>example >>>>>>>>> > >> >> > >> he wishes to have this valid for. >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> Where there is no disagreement, save for >>>>>>>your recent >>>>>>>>> > >> >> > >pushback - is in >>>>>>>>> > >> >> > >> the ESInet, which is where Brian >>>>has requested it's >>>>>>>>> > >> >> > >definition in the >>>>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >>>>>>>chair within >>>>>>>>> > >> >> NENA, and if >>>>>>>>> > >> >> > >> he asks for it, are you going to say you >>>>>>>know better >>>>>>>>>than he? >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> >Btw, I not disagreeing with the document >>>>>>>as such. I >>>>>>>>> > >> >just want to >>>>>>>>> > >> >> > the >>>>>>>>> > >> >> > >> scope >>>>>>>>> > >> >> > >> >to change. The usage of RPH >>>>within the emergency >>>>>>>>> > >> >> services network >>>>>>>>> > >> >> > is >>>>>>>>> > >> >> > >> fine >>>>>>>>> > >> >> > >> >for me. I may get convinced to start the >>>>>>>RPH marking >>>>>>>>>from >>>>>>>>> > >> >> > >the the VSP >>>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy >about the >>>>>>>end host >>>>>>>>>doing >>>>>>>>> > >> >> > >the marking. >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> please read what I wrote above, and then >>>>>>>re-read the >>>>>>>>> > >> >most recent >>>>>>>>> > >> >> > >> version of the ID. I don't have endpoints >>>>>>>that SHOULD >>>>>>>>>or >>>>>>>>> > >> >> MUST mark >>>>>>>>> > >> >> > >> anything wrt RPH. I also don't want to >>>>>>>prohibit it, >>>>>>>>> > >> >> because there >>>>>>>>> > >> >> > >> might be cases (that I don't know >>>>of) of valid uses >>>>>>>>> > >> >> under certain >>>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear >>>>>>>that there are 3 >>>>>>>>> > >> >> networking >>>>>>>>> > >> >> > >> parts to consider >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> #1 - from the endpoint >>>>>>>>> > >> >> > >> #2 - within the VSP >>>>>>>>> > >> >> > >> #3 - within the ESInet >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> the most recent ID version has "can" for >>>>>>>#s 1 and 2, >>>>>>>>>and >>>>>>>>> > >> >> > >2119 language >>>>>>>>> > >> >> > >> offering those supporting this >>>>>>>specification will have >>>>>>>>>RPH >>>>>>>>> > >> >> > >> adherence within #3 (the ESInet). >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> What other scope changes do you want, >>>>>>>because I haven't >>>>>>>>> > >> >> heard them. >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> I only heard you claim in email >during the >>>>>>>last IETF >>>>>>>>>and in >>>>>>>>> > >> >> > >the ECRIT >>>>>>>>> > >> >> > >> session that RPH should not be >>>>used for priority >>>>>>>>>marking >>>>>>>>> > >> >> requests. >>>>>>>>> > >> >> > >> This is something Keith (SIP WG >>>>chair) voiced his >>>>>>>>>opposition >>>>>>>>> > >> >> > >> to your views regarding creating a second >>>>>>>means for SIP >>>>>>>>>to >>>>>>>>> > >> >priority >>>>>>>>> > >> >> > >> mark request "when SIP already has one >>>>>>>interoperable >>>>>>>>>way to >>>>>>>>> > >> >> > >> accomplish this... it's call the >RP header >>>>>>>mechanism". >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> >I don't see advantages -- only >>>>disadvantages. >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> >Ciao >>>>>>>>> > >> >> > >> >Hannes >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >> >>>>_______________________________________________ >>>>>>>>> > >> >> > >> Ecrit mailing list >>>>>>>>> > >> >> > >> Ecrit@ietf.org >>>>>>>>> > >> >> > >> >https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> >>>>>>>>> > >> >> >_______________________________________________ >>>>>>>>> > >> >> Ecrit mailing list >>>>>>>>> > >> >> Ecrit@ietf.org >>>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>> > >> >> >>>>>>>>> > >> > >>>>>>>>> > > >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > Ecrit mailing list >>>>>>>>> > Ecrit@ietf.org >>>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>Ecrit mailing list >>>>>>>>>Ecrit@ietf.org >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Ecrit mailing list >>>>>>>>Ecrit@ietf.org >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>>------------------------------------------------------------- >----------------------------------- >>>This message is for the designated recipient only and may >>>contain privileged, proprietary, or otherwise private information. >>>If you have received it in error, please notify the sender >>>immediately and delete the original. Any unauthorized use of >>>this email is prohibited. >>>------------------------------------------------------------- >----------------------------------- >>>[mf2] >>> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF253A684F for ; Fri, 6 Feb 2009 14:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKNdebCUjVAy for ; Fri, 6 Feb 2009 14:52:34 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 324F13A6A00 for ; Fri, 6 Feb 2009 14:52:34 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n16MqX45011568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Feb 2009 17:52:34 -0500 (EST) Message-Id: <4FF8360F-264C-4FA1-BDA8-E34F71877032@cs.columbia.edu> From: Henning Schulzrinne To: "James M. Polk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 17:52:33 -0500 References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> <7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:52:35 -0000 Discussing the use of RPH for UAs is out of scope for the document. I have no objection to adding a sentence to that effect, e.g., to the security consideration section. On Feb 6, 2009, at 5:37 PM, James M. Polk wrote: > Henning > > I agree with your statement > > "This document does not prevent the use of this > mechanism somewhere else." in documents. > > I just want to avoid having to write in (something like) > > 'UAs are prevented from including RP namespace esnet" > > That was pretty much suggested by one person on the list. > > Is this agreeable? > > Taking this statement further > > "I will object to any text mentioning use of ESNET in UAs." > > Does that mean you do _not_ want UA insertion of esnet to be added > to the security considerations section? > > James Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33553A6B3A for ; Fri, 6 Feb 2009 15:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.323 X-Spam-Level: X-Spam-Status: No, score=-5.323 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnppHVt0PORS for ; Fri, 6 Feb 2009 15:09:23 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3EB703A680C for ; Fri, 6 Feb 2009 15:09:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,394,1231113600"; d="scan'208";a="29450600" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Feb 2009 23:09:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n16N9OrJ006137; Fri, 6 Feb 2009 15:09:24 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n16N9N5J024398; Fri, 6 Feb 2009 23:09:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 15:09:23 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 15:09:22 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 17:09:21 -0600 To: "Hannes Tschofenig" From: "James M. Polk" In-Reply-To: <000001c988ac$d0261940$0201a8c0@nsnintra.net> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <000001c988ac$d0261940$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 23:09:23.0038 (UTC) FILETIME=[F2C45FE0:01C988AF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18894; t=1233961764; x=1234825764; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20ECRIT=20Virtual=20Interim=20Meeting=3A= 20Agenda=20(RPH=20&=20GETS) |Sender:=20; bh=hcGzh0hf19CApJw78ipSA3a8nzBvP7p57WYNf/LRZms=; b=iRHc/VvWi19kRbG56t1/YyuJDs64hX2WPmXZX8Gt+TYoIqCr8ZrBYToS74 yshpNTDT8PutIs8AecvHwcHghKEbJu/opPy0M89as72qtowPei+iPnDYflNR G8YVP9hVq8; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 23:09:25 -0000 At 04:46 PM 2/6/2009, Hannes Tschofenig wrote: >Good that you agree that GETS usage of RPH and the one we discuss in ECRIT >is different. >So far, some folks have been saying "what works for GETS works for the ECRIT >case as well". I don't know who "those people" are but they are wrong. Now, did you mean "what works for MLPP works for the ECRIT case as well"? This is closer to the truth, but since we do not have any plans (that I know of) to allow preemption when calling sos -- the last P in MLPP doesn't apply at this time. >I argued that the environment is different and hence just referencing RFC >4412 isn't good enough. I agree that the environment (for GETS and for MLPP when compared to ECRIT) is different, but the header is just a header. It's how one uses it in any environment that creates the security considerations. The same authentication and authorization considerations text applies to all 3 environments, and this new ID only identifies a namespace to be used within local emergency calling. I fully expect there will need to be a BCP or Framework type doc written providing more guidelines (or NENA will write it), once we have implementation experience to write such a doc -- but we do not at this time. > >-----Original Message----- > >From: James M. Polk [mailto:jmpolk@cisco.com] > >Sent: 07 February, 2009 00:02 > >To: Hannes Tschofenig > >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, Hannes > >(NSN - FI/Espoo); 'ECRIT' > >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) > > > >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote: > >>Hi James, > >> > >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I > >>would like to point out is that there is more than just a header and > >>values within the header that have to be considered in order > >to make a > >>judgement of what is appropriate and what isn't. There is an > >>architectural question and whether the environment we are using the > >>stuff is indeed providing the properties you need for the > >solution to be appropriate. > >> > >>Let me describe in more detail what I meant (and please > >correct me if I > >>am wrong). > >> > >>Getting priority for SIP requests when using a GETS alike scenario > >>means that the entity that issues the request is specially authorized > >>since otherwise you introduce a nice denial of service attack. > > > >You are missing a step in GETS here. The endpoint, who sends > >the GETS set-up as an INVITE is not already authorized (not > >the device, not the user). In North America, there is a 10 > >digit GETS number that is dialed (that I won't give out right > >now on an open list) - and there literally is only 1 number > >available to dial for this service. Literally anyone can dial > >this number today in North America (no matter where the phone > >is - as long as it is in North America -- and I might be too > >limiting in that it is dialable from anywhere, because it is > >going to a North American destination). > > > >Once this number is dialed, it is answered by an > >authentication and authorization IVR. This IVR challenges > >each caller for their authentication passcode, and a > >password). Once this has been successfully entered, then call > >is NOW authorized to proceed towards its destination number - > >this step is only known to the authorizing system because the > >destination 10 digit number is NOT entered until after the > >authentication and authorization step has completed. > > > >The authorized caller is prompted with a new dial tone - in > >which they can enter any number on the planet and receive > >preferential treatment through as many carriers (in IP, it's > >SPs) that have implemented this GETS service (which is an SLA > >with the Department of Homeland Security now). > > > >Merely entering the GETS RP namespace is never intended, > >alone, to gain any preferential treatment -- other than > >towards this authentication & authorization IVR. > > > >I hope you can see that this is a completely separate type of > >service and implementation type than ECRIT based emergency > >calling will use. > > > >BTW - to your comment below about me not calling your name out > >when you are incorrect because I have been equally incorrect > >-- I'm not sure I've been spared as much as you think, given > >that many have called me out by name when they've felt I've > >been wrong over the years. > > > >>This authorization > >>is tied to the entity that makes the request. For example, the person > >>is working for the government and has special rights. James Bond as a > >>(not so) secret agent might have these rights. > >> > >>The emergency services case (citizen-to-authority) is a bit different > >>as there aren't really special rights with respect to authorization > >>tied to individuals. Instead, the fact that something is an emergency > >>is purely a judgement of the human that dials a special > >number. To deal > >>with fraud, we discussed in the group on what we can actually do to > >>ensure that end users do not bypass security procedures (such as > >>authorization checks, charging and so on). Part of this investigation > >>was the publication of http://www.ietf.org/rfc/rfc5069.txt > >that also describes this issue. > >> > >>So, imagine the implementation of a SIP proxy (and we implemented that > >>stuff) that receives a call that contains a Service URN. The code > >>branches into a special mode where everything is done so that > >the call > >>receives appropriate treatment and does not get dropped on the floor. > >>The way how the Service URN is placed in the message ensures that the > >>call cannot go to my friend (instead of the PSAP) unless the end host > >>ran LoST already. In the latter case, we discussed this also on the > >>list for a while and Richard even wrote a draft about it in > >the context > >>of the location hiding topic, we said that the proxy would > >have to run > >>LoST if he cares about a potential fraudulent usage. > >> > >>So, what do we need todo in order to provide secure RFC 4412 > >>functionality in our context? > >> > >>Do you think that the current text in > >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme > >rgency-rp > >>h-nam espace-00.txt reflects any of the above-described issues: > >>" > >> The Security considerations that apply to RFC 4412 [RFC4412] apply > >> here. This document introduces no new security issues relative to > >> RFC 4412. > >>" > >> > >> From various discussions in GEOPRIV I recall that you are > >>super-sensitive regarding security and privacy. For some reasons you > >>don't seem to have the same concerns here. I would like to > >understand your reasoning. > >> > >>Please also do me another favor: Don't always say that I don't > >>understand the subject. Even if that would be the case it isn't > >>particular fair given that different folks had to educate you > >on other topics in the past as well. > >>Additionally, if you listen to the audio recordings then you will > >>notice that Henning, Ted, and Jon do not seem to understand the issue > >>either as they have raised similar issues during the F2F meetings. > >> > >>Ciao > >>Hannes > >> > >> > >> >Hannes - I believe it is you who do not understand RFC 4412 -- and > >> >many of us are trying to get that through to you, but you > >don't seem > >> >to want to listen/read. > >> > > >> >RFC 4412 is *for* priority marking SIP requests, > >> > > >> >One use is GETS. > >> > > >> >One use is MLPP. > >> > > >> >These examples are in RFC 4412 because there were specific > >namespaces > >> >being created for the IANA section of that document. > >> > > >> >Reading the whole document, you will see that RPH can be specified > >> >for other uses than GETS or MLPP specifically. > >> > > >> >I knew when I wrote RFC 4412 that one day we would specify a > >> >namespace for ECRIT (the "esnet" namespace now) -- but I > >also knew it > >> >was premature for RFC 4412 to incorporate that namespace, that a > >> >future doc to RFC 4412 would have to be written to do this. > >Brian and > >> >I talked about this at the original NENA meeting that > >created the IP > >> >WGs there (in August of 03). We both agreed we should wait > >until it > >> >was appropriate to the work in the IETF to submit this > >document that > >> >is now > >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >gency-rph-namespace-00.txt > >> > > >> >Yet, you seem to want to use some additional mechanism to indicate > >> >priority of a call in SIP. That means you want to > >introduce a second > >> >way to accomplish this in SIP. Why do you want to promote > >a separate > >> >way to do something SIP has already defined? That will cause > >> >interoperability issues and we both know that. > >> > > >> >You've said to me (and others) that you believe RPH is just another > >> >way to accomplish what sos or a URI can indicate - and > >you're wrong. > >> >Your way would be _the_second_way_to_do_it, because SIP already > >> >considers RPH to be *the*way* to priority mark SIP requests. > >> > > >> >If you don't believe me (no comment), then why do you not > >believe the > >> >SIP WG chair (who knows more about SIP than both of us) - who, on > >> >this thread, has again said to you "RFC 4412 > >> >(RPH) is the SIP mechanism to priority mark SIP requests"? > >> > > >> >Further, I believe it is inappropriate to prohibit endpoints from > >> >being able to set the esnet namespace. I absolutely > >believe it will > >> >not be needed most of the time, but I believe if someone > >does find a > >> >valid use for endpoints to mark priority in SIP, this ID - once it > >> >has become an RFC -- will have to be obsoleted with a new > >RFC saying > >> >the exact opposite. > >> > > >> >(color me confused ... over and over again) > >> > > >> >James > >> > > >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >> >>Keith, please understand that the usage of RFC 4412 for > >GETS and for > >> >>the type of emergency call we discuss here is different. Just > >> >>looking at the header and the name of the namespace is a bit > >> >artificial. I hope > >> >>you understand that. > >> >> > >> >> >-----Original Message----- > >> >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> >> >Sent: 05 February, 2009 14:55 > >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; > >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> >mistake) > >> >> > > >> >> >Which is exactly what RFC 4412 specifies for all namespaces. > >> >> > > >> >> >regards > >> >> > > >> >> >Keith > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> >On Behalf > >> >> >> Of Brian Rosen > >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >> >Hannes (NSN > >> >> >> - FI/Espoo)'; 'ECRIT' > >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> >> mistake) > >> >> >> > >> >> >> The value is that in some networks where priority for > >> >> >emergency calls > >> >> >> is appropriate, and appropriate policing of marking is > >> >implemented, > >> >> >> emergency calls will receive resource priority. > >> >> >> > >> >> >> Not all networks would need policing. Some will. Policing > >> >> >> could be to Route header/R-URI content, but other > >criteria are possible. > >> >> >> > >> >> >> Not all networks will need resource priority for > >emergency calls. > >> >> >> Fine, ignore this marking/namespace. > >> >> >> > >> >> >> Brian > >> >> >> > -----Original Message----- > >> >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, > >Hannes (NSN - > >> >> >> > FI/Espoo); 'ECRIT' > >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (my > >> >> >> > mistake) > >> >> >> > > >> >> >> > I don't even see the value in permitting the > >endpoint todo the > >> >> >> > RPH marking. > >> >> >> > In addition to the security concerns there is also the > >> >> >problem that > >> >> >> > there are more options to implement without an > >additional value. > >> >> >> > > >> >> >> > >-----Original Message----- > >> >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >> >> > >Sent: 05 February, 2009 00:03 > >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> >> >> Hannes (NSN - > >> >> >> > >FI/Espoo)'; 'ECRIT' > >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda > >> >> >> > >(my > >> >> >> > mistake) > >> >> >> > > > >> >> >> > >Hannes > >> >> >> > > > >> >> >> > >This matches my understanding precisely. We wish to > >> >> >> permit endpoints > >> >> >> > >to mark. We do not require it, and don't necessarily expect > >> >> >> > >it in many (even > >> >> >> > >most) cases. We don't wish to see the document prohibit it. > >> >> >> > >We all seem to agree it has value within the Emergency > >> >> >Services IP > >> >> >> > >Networks. > >> >> >> > > > >> >> >> > >Brian > >> >> >> > > > >> >> >> > >> -----Original Message----- > >> >> >> > >> From: ecrit-bounces@ietf.org > >> >> >> > >> [mailto:ecrit-bounces@ietf.org] > >> >> >> > >On Behalf > >> >> >> > >> Of James M. Polk > >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> >> >> FI/Espoo); 'ECRIT' > >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >> >Agenda (my > >> >> >> > >> mistake) > >> >> >> > >> > >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> >> >> > >> > > James wrote: > >> >> >> > >> > >> you are the _lone_ voice not supporting this ID, > >> >> >> > >> > > >> >> >> > >> >Listening to the audio recording of past meetings I have > >> >> >> > >> >to > >> >> >> > >say that > >> >> >> > >> >I > >> >> >> > >> was > >> >> >> > >> >not the only persons raising concerns about the document. > >> >> >> > >> >That was probably the reason why you agreed to limit the > >> >> >> > >scope of the > >> >> >> > >> >document (which you didn't later do) to get > >folks to agree > >> >> >> > >to make it > >> >> >> > >> a WG > >> >> >> > >> >item. > >> >> >> > >> > >> >> >> > >> re-listen to the audio please > >> >> >> > >> > >> >> >> > >> Ted's concerns were consistent with most (all?) other > >> >> >> concerns -- > >> >> >> > >> which were based on the premise of whether or not the > >> >> >> UAC should be > >> >> >> > >> trusted to initiate the marking on the INVITE. The most > >> >> >> > >> recent version has backed off this to a "can" -- meaning > >> >> >> > >> not > >> >> >prohibited > >> >> >> > >> (i.e., no 2119 text). I also backed off the text in the > >> >> >> SP domain > >> >> >> > >> part to "can", such that there is no 2119 text > >> >> >mandating or even > >> >> >> > >> recommending its usage there. I also do not prohibit its > >> >> >> > >use, based on > >> >> >> > >> local policy. Keith has come forward with the specific > >> >> >> > >> request that non-ESInet networks be allowed to > >mark and pay > >> >> >attention to > >> >> >> > >> this priority indication -- with IMS as the specific > >> >> >> > >> example he wishes to have this valid for. > >> >> >> > >> > >> >> >> > >> Where there is no disagreement, save for your recent > >> >> >> > >pushback - is in > >> >> >> > >> the ESInet, which is where Brian has requested it's > >> >> >> > >definition in the > >> >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> >> >> NENA, and if > >> >> >> > >> he asks for it, are you going to say you know > >better than he? > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> >Btw, I not disagreeing with the document as such. I > >> >> >just want to > >> >> >> > the > >> >> >> > >> scope > >> >> >> > >> >to change. The usage of RPH within the emergency > >> >> >> services network > >> >> >> > is > >> >> >> > >> fine > >> >> >> > >> >for me. I may get convinced to start the RPH marking from > >> >> >> > >the the VSP > >> >> >> > >> >towards the PSAP. I feel uneasy about the end host doing > >> >> >> > >the marking. > >> >> >> > >> > >> >> >> > >> please read what I wrote above, and then re-read the > >> >> >most recent > >> >> >> > >> version of the ID. I don't have endpoints that SHOULD or > >> >> >> MUST mark > >> >> >> > >> anything wrt RPH. I also don't want to prohibit it, > >> >> >> because there > >> >> >> > >> might be cases (that I don't know of) of valid uses > >> >> >> under certain > >> >> >> > >> circumstances. Figure 1 is very clear that there are 3 > >> >> >> networking > >> >> >> > >> parts to consider > >> >> >> > >> > >> >> >> > >> #1 - from the endpoint > >> >> >> > >> #2 - within the VSP > >> >> >> > >> #3 - within the ESInet > >> >> >> > >> > >> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and > >> >> >> > >2119 language > >> >> >> > >> offering those supporting this specification will > >have RPH > >> >> >> > >> adherence within #3 (the ESInet). > >> >> >> > >> > >> >> >> > >> What other scope changes do you want, because I haven't > >> >> >> heard them. > >> >> >> > >> > >> >> >> > >> I only heard you claim in email during the last > >IETF and in > >> >> >> > >the ECRIT > >> >> >> > >> session that RPH should not be used for priority marking > >> >> >> requests. > >> >> >> > >> This is something Keith (SIP WG chair) voiced his > >> >> >> > >> opposition to your views regarding creating a > >second means > >> >> >> > >> for SIP to > >> >> >priority > >> >> >> > >> mark request "when SIP already has one > >interoperable way to > >> >> >> > >> accomplish this... it's call the RP header mechanism". > >> >> >> > >> > >> >> >> > >> >I don't see advantages -- only disadvantages. > >> >> >> > >> > > >> >> >> > >> >Ciao > >> >> >> > >> >Hannes > >> >> >> > >> > >> >> >> > >> _______________________________________________ > >> >> >> > >> Ecrit mailing list > >> >> >> > >> Ecrit@ietf.org > >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> > > > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Ecrit mailing list > >> >> >> Ecrit@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> > >> >> > > >> > > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814203A6B9F for ; Fri, 6 Feb 2009 15:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1IAsJn0Vxdu for ; Fri, 6 Feb 2009 15:33:00 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D53D03A6C23 for ; Fri, 6 Feb 2009 15:32:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,394,1231113600"; d="scan'208";a="62628621" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2009 23:32:20 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n16NWKGH030143; Fri, 6 Feb 2009 15:32:20 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n16NWKjQ015487; Fri, 6 Feb 2009 23:32:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 15:32:20 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.19.48]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 15:32:19 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Feb 2009 17:32:02 -0600 To: "Hannes Tschofenig" , "'DOLLY, MARTIN C, ATTLABS'" , , From: "James M. Polk" In-Reply-To: <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2009 23:32:19.0335 (UTC) FILETIME=[271AA170:01C988B3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=46657; t=1233963140; x=1234827140; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20RPH |Sender:=20; bh=RQZYazNduFE5QNH7ls9TWYzbZBuFImDIJwQ6CrXLrNo=; b=G7PQp9ct1/tjPA3Pv5kb6K/vYISzw9zZNXN4OmRChVQEWWf7gVYyilAjXS b5Xn9absW4SBrawRLInft9gA7tQe2etSEzupYWLhMAgjazgBzFHvD8Vc5Jfd QikPdXAIiX; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 23:33:03 -0000 At 04:52 PM 2/6/2009, Hannes Tschofenig wrote: >Hi Martin, > >I am arguing that if the UE does mark the call with the ECRIT RPH (I call it >that way to differentiate it from RFC 4412 RPH usage, which is very >different this statement doesn't make any sense -- just when I thought we were close to a common understanding... RFC 4412 defines a new header - Resource-Priority in SIP. This header has an identified set of header-values. With these values is a namespace, which dictate which type of usage is expected a particular namespace is used. RFC 4412 allows other documents to create new RP header-values (i.e., new namespaces with associated priority-values). Have I yet said anything that is inconsistent with usage within ECRIT? I don't think so. Along comes a new ID that defines a new RP namespaces in SIP for ECRIT, called "esnet". This new namespace is needed because the 5 header-values defined in RFC 4412 do not match the usage for the ECRIT effort, therefore a new one needs to be created. RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create 5 IANA registered namespaces (and associated priority-values). Consider draft-ietf-ecrit-local-emergency-rph-namespace-00 to be an extension to RFC 4412, because there was no reason why the esnet namespace (and associated priority-values) could not have been included in 4412; none whatsoever. The only reason why this -00 ID is not an UPDATE to RFC 4412 is that no new behavior is introduced. If there was, thenit would have to be listed as an UPDATE to 4412. This means that is is not defining anything new about the behavior of the RP header, therefore what's in this new ID (other than the definition of the new namespace) is the SAME as that in 4412 -- therefore it is inappropriate to consider one to be 4412 centric and the other to be ECRIT centric. May I recommend in the future we just refer to this -00 effort as the "esnet" RP namespace, please? >) then it should be ignored. This is basic SIP rules -- i.e., if a header is not understood, it is to be ignored. >Processing it will not help in any way (as I described in my pseudo code >snippet). I can't believe this will be true in every network, so this should not be repeated. Perhaps based on the networks you know about, it will be ignored. >Incorrectly processing it (which is a possibility when the >implementer does not understand the security implications -- they will not >get it from the current version of the draft) will lead to security problems >(fraud & DoS potential). this can be said about a lot of different headers in SIP too... PAI is but one example. Identity is another. >While you cannot prevent someone from sending you, there is certainly the >chance to document what the receiver should do with it. I believe that is a local policy decision -- i.e., it is a configuration issue -- which is not within the scope of the IETF. I believe, based on Henning's answer to my last question to him, that the security considerations section ought to have text saying what an implementer ought to be concerned about when this esnet namespace is received from a UA. As Martin said -- ultimately it's all about trust relationships -- and a domain might trust the endpoints within its domain to send the right RP namespace. It also might have a viable means to verify the namespace as well. This is certainly true between SIP servers where the recipient knows the upstream entity is another server within the same network. James >Ciao >Hannes > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of DOLLY, MARTIN C, ATTLABS > >Sent: 07 February, 2009 00:15 > >To: jmpolk@cisco.com; hgs@cs.columbia.edu; > >James.Winterbottom@andrew.com > >Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org > >Subject: Re: [Ecrit] RPH > > > >You can not disallow this from an UE. The trust relationship > >will dictate whether it is accepted or not > > > >----- Original Message ----- > >From: ecrit-bounces@ietf.org > >To: Henning Schulzrinne ; Winterbottom, > >James > >Cc: Tschofenig, Hannes (NSN - FI/Espoo) > >; ECRIT > >Sent: Fri Feb 06 17:10:08 2009 > >Subject: Re: [Ecrit] RPH > > > >At 03:05 PM 2/6/2009, Henning Schulzrinne wrote: > >>There's another problem with the "it doesn't hurt argument". > >Assume for > >>a moment we have a "UA MAY include RPH" wording. There are now two > >>cases: > >> > >>(1) All UAs implement it. > >> > >>(2) Only some UAs implement it. > >> > >>(1) seems unlikely for a MAY. If (2) occurs, we have the > >choice between > >>two undesirable outcomes: > >> > >>(a) some UAs that are otherwise compliant get worse service just > >>because they didn't include the RPH; > > > >am I reading this correctly - that unless all UAs implement > >this capability this should never be implemented by any UAs? > > > >This flies in the face of vendors solving for their customer's > >requirements. > > > >I will admit that at this time, I know of no Cisco customers > >that want this capability, so I'm not angling for any of our > >revenue here. I'm saying that I think I hear you saying this > >ID should say something like > > > > UAs are prevented from implementing the RP namespace esnet > > > >I'm fighting against that, because customers are always coming > >to every vendor with new requirements, some of them unique at > >the time. This prevention text would prevent a vendor from > >complying with this specification and still meet the customer's needs. > > > >I believe that this ID needs to retain the endpoints MAY > >insert esnet, and have appropriate security considerations > >text that highlights the concerns expressed here. > > > >Some future ID can then update this current RFC (to-be) within the > >2119 rules of the use of MAY here. > > > > > >>OR > >> > >>(b) the proxy has to look for the service URN to give the call the > >>appropriate treatment, thus obviating any advantage of having the > >>header, yet incurring more complicated processing logic. > >> > >> > >>I have no objection to whatever markings people want to apply to calls > >>within an ESN - that's largely a private matter. > >> > >>Henning > >> > >>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: > >> > >>>Hi All, > >>> > >>>I have followed thi thread with some interest and I struggling to > >>>see a use case for the > >>>providing RPH for emergency calls from the end-point. > >>> > >>>The reference-model call in ECRIT, for better or worse, is for all > >>>calls to go back through a home-VSP. > >>>We placed quite a lot of emphasis, largely for traffing reasons, for > >>>the VSP to be able to verify that > >>>a call is in fact an emergency call. This is done by the proxy > >>>taking the inband location, doing a LoST > >>>query with the provided URN, and verifying that the resulting > >>>destination URI is the same as the destination > >>>URI provide in the SIP INVITE. My understanding was that VSPs would > >>>always do this check so they could > >>>tell if they could bill for the call or not, and because the VSP can > >>>be use that the call is an emergency call > >>>it can apply any special priorities that may be applicable. This > >>>obviates the need for RPH from the end-point > >>>to the network. > >>> > >>>This leaves us with the argument of "it doesn't hurt to it", which > >>>is not a good reason to write a specification. > >>>It was intimated on the geopriv mailing list last year that great > >>>pains had been taken to keep SIP with in the > >>>MTU limits of UDP over Ethernet > >>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612 > >0.html ). Assuming > >>>that this is the case, perhaps there is harm in including > >>>information that we know will be ignored. > >>> > >>>Cheers > >>>James > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > >>>Sent: Fri 2/6/2009 12:33 PM > >>>To: 'Brian Rosen'; 'Henning Schulzrinne' > >>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > >>>Subject: Re: [Ecrit] RPH > >>> > >>>To the story short here is the code for the proxy: > >>> > >>>--------------------- > >>> > >>>IF emergency call was recognized THEN > >>> execute emergency call specific procedures (priority queuing, > >>>preemption, fetch location, determine routing, do funny QoS things & > >>>co) > >>>ELSE > >>> normal call handling procedures. > >>> > >>>--------------------- > >>> > >>>If you can make this differentiation between an emergency call and a > >>>regular > >>>call then you can also do everything that is necessary for emergency > >>>call > >>>handling. > >>> > >>>Brian + Keith: Please tell me that we cannot do the above with our > >>>currently > >>>specified mechanisms. > >>> > >>>Ciao > >>>Hannes > >>> > >>>>-----Original Message----- > >>>>From: Brian Rosen [mailto:br@brianrosen.net] > >>>>Sent: 06 February, 2009 17:49 > >>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > >>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>>>Subject: RE: [Ecrit] RPH > >>>> > >>>>I agree that not all networks will permit (or pay attention > >>>>to) a priority request from an end device. > >>>> > >>>>No one has asked for that. > >>>> > >>>>The namespace request has several uses, one of which is within > >>>>an emergency services IP network, one of which is between > >>>>elements within a public network controlled by the operator, > >>>>and one of which is an endpoint request for resource priority. > >>>> > >>>>Those of us requesting this work proceed are happy if the > >>>>endpoint part is simply left as possible (MAY), and, speaking > >>>>for myself, having the draft discuss the security implications > >>>>of endpoint marking is reasonable. > >>>> > >>>>Having discussed this issue with an implementation team who > >>>>worked on MLPP systems, I am confident I know what I'm talking > >>>>about, but YMMV. The fact that you could, if you wanted to, > >>>>give resource priority to a call you decided, however you > >>>>decided, was an emergency call is an implementation decision, > >>>>and not subject to standardization. > >>>> > >>>>RPH is the IETF standard way for one entity to request > >>>>resource priority of another entity in a SIP system. We're > >>>>asking for a namespace to use that within the domain of > >>>>emergency calls. That is, I think, a VERY reasonable request. > >>>> > >>>>Brian > >>>> > >>>>>-----Original Message----- > >>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>Sent: Friday, February 06, 2009 10:33 AM > >>>>>To: Hannes Tschofenig > >>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >>>>>Subject: Re: [Ecrit] RPH > >>>>> > >>>>>To chime in here: > >>>>> > >>>>>I don't think it's productive to simply state that 4412 > >>>>doesn't worry > >>>>>about authorization, so we shouldn't either (simplifying a bit). > >>>>>Authorization was discussed repeatedly, and the general > >>>>assumption was > >>>>>that there were two conditions: Either the user invoking resource- > >>>>>priority was well known and had a set of permissions that could be > >>>>>checked in real time or there are ways to deal with abuse after the > >>>>>fact in ways that deter abuse (the court-martial kind of thing in a > >>>>>military context). > >>>>> > >>>>>The RFC 4412 security consideration (11.2) call this out in pretty > >>>>>strong language: > >>>>> > >>>>> Prioritized access to network and end-system resources imposes > >>>>> particularly stringent requirements on authentication and > >>>>> authorization mechanisms, since access to prioritized > >>>>resources may > >>>>> impact overall system stability and performance and not > >>>>just result > >>>>> in theft of, say, a single phone call. > >>>>>Thus, the question is whether we have such strong authentication in > >>>>>emergency calling. In some cases, such as residential fixed line > >>>>>deployments where ISP = VSP, we're probably pretty close, > >in others, > >>>>>such as prepaid cell phones or hot spots or VSP-only providers, we > >>>>>aren't. > >>>>> > >>>>>The other point that I think Hannes is making is that the > >>>>information > >>>>>is either redundant or dangerous. If a processing element > >recognizes > >>>>>the call as being an emergency call, it can apply whatever > >treatment > >>>>>it deems appropriate and doesn't need additional information. If it > >>>>>doesn't or can't, using just the RPH can be rather dangerous unless > >>>>>that element can be reasonably certain that there is strong > >>>>>authentication and recourse. > >>>>> > >>>>>I don't buy the argument that somehow finding the RPH is > >faster than > >>>>>just looking for the identifier. Thus, given that the > >information is > >>>>>either redundant or dangerous, I fail to see the advantage. > >>>>> > >>>>>Henning > >>>>> > >>>>> > >>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > >>>>> > >>>>>>Don't get hung up on the details. There are ways to optimize it. > >>>>>>That was > >>>>>>not the point of the code example. > >>>>>> > >>>>>>The problem that my pseudo code should have shown you is that you > >>>>>>* don't gain anything with RPH marking for the emergency call case > >>>>>>from the SIP UA towards the outbound proxy since the functionality > >>>>>>is already provide otherwise. How often does the proxy need to get > >>>>>>told that this is an emergency call todo whatever emergency call > >>>>>>handling procedures are necessary? > >>>>>>* you only introduce fraud problems (if you are not > >>>>careful and you > >>>>>>understand the security stuff well enough) > >>>>>> > >>>>>>If you can point me to people who implement the RPH emergency call > >>>>>>case please do so. I would love to talk to them. > >>>>>> > >>>>>>Ciao > >>>>>>Hannes > >>>>>> > >>>>>>PS: You need to parse incoming messages to some extend so that you > >>>>>>know what it contains :-) Only looking for the emergency > >>>>RPH header > >>>>>>(and not for the Service URN/dial > >>>>>>string) would exactly be the DoS/fraud attack I am worried about. > >>>>>>That's the thing Henning was worried about (go and listen to the > >>>>>>past meeting minutes). > >>>>>> > >>>>>> > >>>>>>>Hannes > >>>>>>> > >>>>>>>You need to talk to people who really implement this kind > >>>>of thing. > >>>>>>>You are way off. > >>>>>>> > >>>>>>>When you implement a resource priority system, the point of doing > >>>>>>>that is to look though the queue of work and pick out the > >>>>ones with > >>>>>>>priority, handling them first. You don't do all the parsing, you > >>>>>>>don't do a lot of decision tree. > >>>>>>> > >>>>>>>Typically: > >>>>>>>Check for DoS things, like too big messages, etc Do a quick scan > >>>>>>>for the RPH message header If found: > >>>>>>>Parse the message > >>>>>>>Determine validity > >>>>>>>Determine priority > >>>>>>>Queue on the correct work queue > >>>>>>> > >>>>>>>The first two actions have to be very fast. Anyone who builds a > >>>>>>>SIP thingie will tell you that parsing is one of the big cycle > >>>>>>>consumers: if you have to parse every message BEFORE you > >>>>determine > >>>>>>>priority, you can't give much resource priority. > >>>>>>>Once you get the whole message parsed, you might as well finish > >>>>>>>working on it, because you've done so much of the work. > >>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick > >>>>>>>string search for RPH is fast. If you are doing > >>>>priority, you need > >>>>>>>to keep all the priority processing pretty uniform, and pretty > >>>>>>>simple, or you tend to spend too much time futzing around > >>>>figuring > >>>>>>>out what to do. You put all the priority related stuff together, > >>>>>>>and use as much common code as possible. > >>>>>>> > >>>>>>>Brian > >>>>>>> > >>>>>>>>-----Original Message----- > >>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>>>>>>On Behalf > >>>>>>>>Of Hannes Tschofenig > >>>>>>>>Sent: Friday, February 06, 2009 8:41 AM > >>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn' > >>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >>>>>>>>bounces@ietf.org > >>>>>>>>Subject: [Ecrit] RPH > >>>>>>>> > >>>>>>>>Over lunch I was also thinking how an outbound proxy would > >>>>>implement > >>>>>>>>some of the emergency procedures. Here are some thoughts: > >>>>>>>> > >>>>>>>>--------------------------------------------------- > >>>>>>>> > >>>>>>>>// Process incoming message > >>>>>>>>Parse(msg); > >>>>>>>> > >>>>>>>>// SIP INVITE without Service URN > >>>>>>>>// legacy devices > >>>>>>>>If (recognize-dialstring(msg)==TRUE) { // we got an emergency > >>>>>>>>call going on emergency=TRUE; if (dialstring(msg) == 911) > >>>>>>>>serviceURN=urn:service:sos; } else if > >>>>>>>>(recognize-serviceURN(msg)==TRUE) { // oh. A updated > >>>>device that > >>>>>>>>has a service URN attached to the > >>>>>call > >>>>>>>>serviceURN=retrieve_ServiceURN(msg); > >>>>>>>>emergency=TRUE; > >>>>>>>>} else { > >>>>>>>>// standard SIP message > >>>>>>>>// regular processing > >>>>>>>>process(msg); > >>>>>>>>emergency=FALSE; > >>>>>>>>} > >>>>>>>> > >>>>>>>>If (emergency == TRUE) { > >>>>>>>> // make sure that the emergency call does not get > >>>>dropped on the > >>>>>>>>floor > >>>>>>>> // skip authorization failures > >>>>>>>> // give the call a special treatment > >>>>>>>> lots-of-code-here(); > >>>>>>>> > >>>>>>>> // trigger all the QoS signaling you have in the > >>>>network to make > >>>>>>>>James happy > >>>>>>>> trigger-qos(); > >>>>>>>> > >>>>>>>> // query location > >>>>>>>> location=retrieve-location(); > >>>>>>>> > >>>>>>>> // determine next hop > >>>>>>>> next-hop=lost(location, serviceURN) > >>>>>>>> > >>>>>>>> // attach RPH marking to outgoing msg to make James and > >>>>>>>Keith happy > >>>>>>>> msg=add(msg, RPH); > >>>>>>>> > >>>>>>>> send(msg, next-hop); > >>>>>>>>} > >>>>>>>> > >>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { > >>>>>>>> // all the emergency related processing done already upfront > >>>>>>>> // hence I log something. > >>>>>>>> log(RPH_WAS_PRESENT_JUHU); > >>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency == > >>>>FALSE)) { > >>>>>>>>// this is not an emergency call // this is something > >>>>like GETS > >>>>>>>>result=special-authorization-procedure(user); > >>>>>>>> > >>>>>>>>if (result == AUTHORIZED) { > >>>>>>>> // do some priority & preemption thing here. > >>>>>>>> // trigger all the QoS you have > >>>>>>>> lots-of-code-here(); > >>>>>>>>} else { > >>>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } else { // > >>>>>>>>don't need todo any RPH processing // this includes the case > >>>>>>>>where the call was an emergency call but the RPH > >>>>>>>> > >>>>>>>>// marking was not there. > >>>>>>>>nothing(); > >>>>>>>>} > >>>>>>>> > >>>>>>>>--------------------------------------------------- > >>>>>>>> > >>>>>>>> > >>>>>>>>Ciao > >>>>>>>>Hannes > >>>>>>>> > >>>>>>>>>-----Original Message----- > >>>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>>>>>>>Behalf Of Hannes Tschofenig > >>>>>>>>>Sent: 06 February, 2009 15:07 > >>>>>>>>>To: 'Janet P Gunn' > >>>>>>>>>Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > >>>>>>>>FI/Espoo) > >>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (RPH) > >>>>>>>>> > >>>>>>>>>Who would define something that could prevent DoS problems? > >>>>>>>>> > >>>>>>>>>________________________________ > >>>>>>>>> > >>>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >>>>>>>>> Sent: 06 February, 2009 14:11 > >>>>>>>>> To: Hannes Tschofenig > >>>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >>>>>>>>>ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); > >>>>>'James > >>>>>>>>>M. Polk' > >>>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>>Meeting: Agenda (RPH) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> But there is nothing IN RFC4412 that specifically > >>>>>>>addresses how to > >>>>>>>>>prevent any particular namespace being used for DoS. > >Anyone/any > >>>>>UA > >>>>>>>>>can ATTEMPT to invoke priority treatment by attaching RPH. For > >>>>>all > >>>>>>>>>of the 4412 namespaces, as with the new proposed namespace, the > >>>>>>>>>mechanisms for preventing DoS are not specified in the > >>>>>>>document that > >>>>>>>>>defines the namespace. > >>>>>>>>>They are/will be specified elsewhere. > >>>>>>>>> > >>>>>>>>> Janet > >>>>>>>>> > >>>>>>>>> This is a PRIVATE message. If you are not the intended > >>>>>>>recipient, > >>>>>>>>>please delete without copying and kindly advise us by e-mail of > >>>>>the > >>>>>>>>>mistake in delivery. > >>>>>>>>> NOTE: Regardless of content, this e-mail shall not > >>>>>>>operate to bind > >>>>>>>>>CSC to any order or other contract unless pursuant to explicit > >>>>>>>>>written agreement or government initiative expressly permitting > >>>>>the > >>>>>>>>>use of e-mail for such purpose. > >>>>>>>>> > >>>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 > >04:21:51 AM: > >>>>>>>>> > >>>>>>>>> > Hi James, > >>>>>>>>> > > >>>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >>>>>>>documents. What I > >>>>>>>>>would > >>>>>>>>> > like to point out is that there is more than just a > >>>>>>>header and > >>>>>>>>>values within > >>>>>>>>> > the header that have to be considered in order to > >>>>>>>make a judgement > >>>>>>>>>of what > >>>>>>>>> > is appropriate and what isn't. There is an > >>>>>>>architectural question > >>>>>>>>>and > >>>>>>>>> > whether the environment we are using the stuff is > >>>>>>>indeed providing > >>>>>>>>>the > >>>>>>>>> > properties you need for the solution to be > >>>>appropriate. > >>>>>>>>> > > >>>>>>>>> > Let me describe in more detail what I meant (and > >>>>>>>please correct me > >>>>>>>>>if I am > >>>>>>>>> > wrong). > >>>>>>>>> > > >>>>>>>>> > Getting priority for SIP requests when using a GETS > >>>>>>>alike scenario > >>>>>>>>>means > >>>>>>>>> > that the entity that issues the request is specially > >>>>>>>authorized > >>>>>>>>>since > >>>>>>>>> > otherwise you introduce a nice denial of > >>>>service attack. This > >>>>>>>>>authorization > >>>>>>>>> > is tied to the entity that makes the request. For > >>>>>>>example, the > >>>>>>>>>person is > >>>>>>>>> > working for the government and has special rights. > >>>>>>>>>James Bond as a (not so) > >>>>>>>>> > secret agent might have these rights. > >>>>>>>>> > > >>>>>>>>> > The emergency services case > >>>>(citizen-to-authority) is a bit > >>>>>>>>>different as > >>>>>>>>> > there aren't really special rights with respect to > >>>>>>>authorization > >>>>>>>>>tied to > >>>>>>>>> > individuals. Instead, the fact that something is an > >>>>>>>emergency is > >>>>>>>>>purely a > >>>>>>>>> > judgement of the human that dials a special number. > >>>>>>>>>To deal with fraud, we > >>>>>>>>> > discussed in the group on what we can actually do to > >>>>>>>ensure that > >>>>>>>>>end users > >>>>>>>>> > do not bypass security procedures (such as > >>>>>>>authorization checks, > >>>>>>>>>charging > >>>>>>>>> > and so on). Part of this investigation was > >>>>the publication of > >>>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also > >>>>describes this > >>>>>>>>>issue. > >>>>>>>>> > > >>>>>>>>> > So, imagine the implementation of a SIP > >proxy (and we > >>>>>>>implemented > >>>>>>>>>that > >>>>>>>>> > stuff) that receives a call that contains a Service > >>>>>>>URN. The code > >>>>>>>>>branches > >>>>>>>>> > into a special mode where everything is done > >>>>so that the call > >>>>>>>>>receives > >>>>>>>>> > appropriate treatment and does not get > >dropped on the > >>>>>>>floor. The > >>>>>>>>>way how the > >>>>>>>>> > Service URN is placed in the message > >ensures that the > >>>>>>>call cannot > >>>>>>>>>go to my > >>>>>>>>> > friend (instead of the PSAP) unless the end host ran > >>>>>>>LoST already. > >>>>>>>>>In the > >>>>>>>>> > latter case, we discussed this also on the > >list for a > >>>>>>>while and > >>>>>>>>>Richard even > >>>>>>>>> > wrote a draft about it in the context of the > >>>>location hiding > >>>>>>>>>topic, we said > >>>>>>>>> > that the proxy would have to run LoST if he > >>>>cares about a > >>>>>>>>>potential > >>>>>>>>> > fraudulent usage. > >>>>>>>>> > > >>>>>>>>> > So, what do we need todo in order to provide > >>>>secure RFC 4412 > >>>>>>>>>functionality > >>>>>>>>> > in our context? > >>>>>>>>> > > >>>>>>>>> > Do you think that the current text in > >>>>>>>>> > > >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >>>>>>>>>gency-rph-nam > >>>>>>>>> > espace-00.txt reflects any of the > >>>>above-described issues: > >>>>>>>>> > " > >>>>>>>>> > The Security considerations that apply > >to RFC 4412 > >>>>>>>>>[RFC4412] > >>>>>>>>>apply > >>>>>>>>> > here. This document introduces no new security > >>>>>>>>>issues relative > >>>>>>>>>to > >>>>>>>>> > RFC 4412. > >>>>>>>>> > " > >>>>>>>>> > > >>>>>>>>> > From various discussions in GEOPRIV I recall > >>>>that you are > >>>>>>>>>super-sensitive > >>>>>>>>> > regarding security and privacy. For some reasons you > >>>>>>>don't seem to > >>>>>>>>>have the > >>>>>>>>> > same concerns here. I would like to > >>>>understand your reasoning. > >>>>>>>>> > > >>>>>>>>> > Please also do me another favor: Don't always say > >>>>>>>that I don't > >>>>>>>>>understand > >>>>>>>>> > the subject. Even if that would be the case it isn't > >>>>>>>particular > >>>>>>>>>fair given > >>>>>>>>> > that different folks had to educate you on other > >>>>>>>topics in the > >>>>>>>>>past as well. > >>>>>>>>> > Additionally, if you listen to the audio recordings > >>>>>>>then you will > >>>>>>>>>notice > >>>>>>>>> > that Henning, Ted, and Jon do not seem to understand > >>>>>>>the issue > >>>>>>>>>either as > >>>>>>>>> > they have raised similar issues during the > >>>>F2F meetings. > >>>>>>>>> > > >>>>>>>>> > Ciao > >>>>>>>>> > Hannes > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > >Hannes - I believe it is you who do not understand > >>>>>>>RFC 4412 -- > >>>>>>>>> > >and many of us are trying to get that > >>>>through to you, but you > >>>>>>>>> > >don't seem to want to listen/read. > >>>>>>>>> > > > >>>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, > >>>>>>>>> > > > >>>>>>>>> > >One use is GETS. > >>>>>>>>> > > > >>>>>>>>> > >One use is MLPP. > >>>>>>>>> > > > >>>>>>>>> > >These examples are in RFC 4412 because there > >>>>were specific > >>>>>>>>> > >namespaces being created for the IANA section of > >>>>>>>that document. > >>>>>>>>> > > > >>>>>>>>> > >Reading the whole document, you will see > >>>>that RPH can be > >>>>>>>>> > >specified for other uses than GETS or MLPP > >>>>specifically. > >>>>>>>>> > > > >>>>>>>>> > >I knew when I wrote RFC 4412 that one day we > >>>>would specify a > >>>>>>>>> > >namespace for ECRIT (the "esnet" namespace > >>>>now) -- but I also > >>>>>>>>> > >knew it was premature for RFC 4412 to > >>>>incorporate that > >>>>>>>>> > >namespace, that a future doc to RFC 4412 > >>>>would have to be > >>>>>>>>> > >written to do this. Brian and I talked about > >>>>this at the > >>>>>>>>> > >original NENA meeting that created the IP WGs there > >>>>>>>(in August > >>>>>>>>> > >of 03). We both agreed we should wait until it was > >>>>>>>>> > >appropriate to the work in the IETF to > >>>>submit this document > >>>>>>>>> > >that is now > >>>>>>>>> > > >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l > >ocal-emer > >>>>>>>>> > >gency-rph-namespace-00.txt > >>>>>>>>> > > > >>>>>>>>> > >Yet, you seem to want to use some additional > >>>>mechanism to > >>>>>>>>> > >indicate priority of a call in SIP. That > >>>>means you want to > >>>>>>>>> > >introduce a second way to accomplish this in SIP. > >>>>>>>>>Why do you > >>>>>>>>> > >want to promote a separate way to do something SIP > >>>>>>>has already > >>>>>>>>> > >defined? That will cause interoperability > >issues and > >>>>>>>we both know > >>>>>>>>>that. > >>>>>>>>> > > > >>>>>>>>> > >You've said to me (and others) that you > >>>>believe RPH is just > >>>>>>>>> > >another way to accomplish what sos or a URI can > >>>>>>>indicate - and > >>>>>>>>> > >you're wrong. Your way would be > >>>>_the_second_way_to_do_it, > >>>>>>>>> > >because SIP already considers RPH to be > >>>>*the*way* to priority > >>>>>>>>> > >mark SIP requests. > >>>>>>>>> > > > >>>>>>>>> > >If you don't believe me (no comment), then > >>>>why do you not > >>>>>>>>> > >believe the SIP WG chair (who knows more > >>>>about SIP than both > >>>>>>>>> > >of us) - who, on this thread, has again said > >>>>to you "RFC 4412 > >>>>>>>>> > >(RPH) is the SIP mechanism to priority mark > >>>>SIP requests"? > >>>>>>>>> > > > >>>>>>>>> > >Further, I believe it is inappropriate to > >>>>prohibit endpoints > >>>>>>>>> > >from being able to set the esnet namespace. > >>>>I absolutely > >>>>>>>>> > >believe it will not be needed most of the > >>>>time, but I believe > >>>>>>>>> > >if someone does find a valid use for > >>>>endpoints to mark > >>>>>>>>> > >priority in SIP, this ID - once it has > >>>>become an RFC -- will > >>>>>>>>> > >have to be obsoleted with a new RFC saying > >the exact > >>>>>>>opposite. > >>>>>>>>> > > > >>>>>>>>> > >(color me confused ... over and over again) > >>>>>>>>> > > > >>>>>>>>> > >James > >>>>>>>>> > > > >>>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>>>>>>>> > >>Keith, please understand that the usage > >of RFC 4412 > >>>>>>>for GETS and > >>>>>>>>>for > >>>>>>>>> > >>the type of emergency call we discuss here is > >>>>>>>different. Just > >>>>>>>>>looking > >>>>>>>>> > >>at the header and the name of the > >namespace is a bit > >>>>>>>>> > >artificial. I hope > >>>>>>>>> > >>you understand that. > >>>>>>>>> > >> > >>>>>>>>> > >> >-----Original Message----- > >>>>>>>>> > >> >From: DRAGE, Keith (Keith) > >>>>>>>>>[mailto:drage@alcatel-lucent.com] > >>>>>>>>> > >> >Sent: 05 February, 2009 14:55 > >>>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >>>>>>>>>Polk'; 'Tschofenig, > >>>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>>>>>>>Meeting: Agenda (my > >>>>>>>>> > >>>>>>>>> > >> >mistake) > >>>>>>>>> > >> > > >>>>>>>>> > >> >Which is exactly what RFC 4412 specifies for all > >>>>>>>namespaces. > >>>>>>>>> > >> > > >>>>>>>>> > >> >regards > >>>>>>>>> > >> > > >>>>>>>>> > >> >Keith > >>>>>>>>> > >> > > >>>>>>>>> > >> >> -----Original Message----- > >>>>>>>>> > >> >> From: ecrit-bounces@ietf.org > >>>>>>>[mailto:ecrit-bounces@ietf.org] > >>>>>>>>> > >> >On Behalf > >>>>>>>>> > >> >> Of Brian Rosen > >>>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >>>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. > >>>>Polk'; 'Tschofenig, > >>>>>>>>> > >Hannes (NSN > >>>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' > >>>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>>>>>>>Meeting: Agenda (my > >>>>>>>>> > >> >> mistake) > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> The value is that in some networks > >>>>where priority for > >>>>>>>>> > >> >emergency calls > >>>>>>>>> > >> >> is appropriate, and appropriate > >>>>policing of marking is > >>>>>>>>> > >implemented, > >>>>>>>>> > >> >> emergency calls will receive resource > >priority. > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> Not all networks would need policing. Some > >>>>>>>will. Policing > >>>>>>>>>could > >>>>>>>>> > >> >> be to Route header/R-URI content, but other > >>>>>>>criteria are > >>>>>>>>>possible. > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> Not all networks will need resource priority > >>>>>>>for emergency > >>>>>>>>>calls. > >>>>>>>>> > >> >> Fine, ignore this marking/namespace. > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> Brian > >>>>>>>>> > >> >> > -----Original Message----- > >>>>>>>>> > >> >> > From: Hannes Tschofenig > >>>>>>>>>[mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >>>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >>>>>>>Tschofenig, Hannes > >>>>>>>>>(NSN - > >>>>>>>>> > >> >> > FI/Espoo); 'ECRIT' > >>>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>>>>>>>Meeting: Agenda (my > >>>>>>>>> > >> >> > mistake) > >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > I don't even see the value in permitting the > >>>>>>>endpoint todo > >>>>>>>>>the > >>>>>>>>> > >> >> > RPH marking. > >>>>>>>>> > >> >> > In addition to the security concerns > >>>>there is also the > >>>>>>>>> > >> >problem that > >>>>>>>>> > >> >> > there are more options to implement without > >>>>>>>an additional > >>>>>>>>>value. > >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > >-----Original Message----- > >>>>>>>>> > >> >> > >From: Brian Rosen > >[mailto:br@brianrosen.net] > >>>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 > >>>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >>>>>>>'Tschofenig, > >>>>>>>>> > >> >> Hannes (NSN - > >>>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >>>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual > >>>>Interim Meeting: > >>>>>>>>>Agenda (my > >>>>>>>>> > >> >> > mistake) > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >Hannes > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >This matches my understanding > >>>>precisely. We wish to > >>>>>>>>> > >> >> permit endpoints > >>>>>>>>> > >> >> > >to mark. We do not require it, and > >>>>don't necessarily > >>>>>>>>>expect it > >>>>>>>>> > >> >> > >in many (even > >>>>>>>>> > >> >> > >most) cases. We don't wish to see the > >>>>>>>document prohibit > >>>>>>>>>it. > >>>>>>>>> > >> >> > >We all seem to agree it has value > >within the > >>>>>>>Emergency > >>>>>>>>> > >> >Services IP > >>>>>>>>> > >> >> > >Networks. > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >Brian > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >> -----Original Message----- > >>>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org > >>>>>>>>>[mailto:ecrit-bounces@ietf.org] > >>>>>>>>> > >> >> > >On Behalf > >>>>>>>>> > >> >> > >> Of James M. Polk > >>>>>>>>> > >> >> > >> Sent: Wednesday, February 04, > >2009 4:01 PM > >>>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, > >>>>Hannes (NSN - > >>>>>>>>> > >> >> FI/Espoo); 'ECRIT' > >>>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT > >Virtual Interim > >>>>>>>>>Meeting: > >>>>>>>>> > >Agenda (my > >>>>>>>>> > >> >> > >> mistake) > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes > >>>>Tschofenig wrote: > >>>>>>>>> > >> >> > >> > > James wrote: > >>>>>>>>> > >> >> > >> > >> you are the _lone_ voice not > >>>>>>>supporting this ID, > >>>>>>>>> > >> >> > >> > > >>>>>>>>> > >> >> > >> >Listening to the audio recording of past > >>>>>>>meetings I > >>>>>>>>>have to > >>>>>>>>> > >> >> > >say that > >>>>>>>>> > >> >> > >> >I > >>>>>>>>> > >> >> > >> was > >>>>>>>>> > >> >> > >> >not the only persons raising > >>>>concerns about the > >>>>>>>>>document. > >>>>>>>>> > >> >> > >> >That was probably the reason why you > >>>>>>>agreed to limit > >>>>>>>>>the > >>>>>>>>> > >> >> > >scope of the > >>>>>>>>> > >> >> > >> >document (which you didn't later do) to > >>>>>>>get folks to > >>>>>>>>>agree > >>>>>>>>> > >> >> > >to make it > >>>>>>>>> > >> >> > >> a WG > >>>>>>>>> > >> >> > >> >item. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> re-listen to the audio please > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> Ted's concerns were consistent with most > >>>>>>>>>(all?) other > >>>>>>>>> > >> >> concerns -- > >>>>>>>>> > >> >> > >> which were based on the premise > >of whether > >>>>>>>or not the > >>>>>>>>> > >> >> UAC should be > >>>>>>>>> > >> >> > >> trusted to initiate the marking on the > >>>>>>>INVITE. The > >>>>>>>>>most > >>>>>>>>> > >> >> > >> recent version has backed off this > >>>>to a "can" -- > >>>>>>>>>meaning not > >>>>>>>>> > >> >prohibited > >>>>>>>>> > >> >> > >> (i.e., no 2119 text). I also backed off > >>>>>>>the text in > >>>>>>>>>the > >>>>>>>>> > >> >> SP domain > >>>>>>>>> > >> >> > >> part to "can", such that there is > >>>>no 2119 text > >>>>>>>>> > >> >mandating or even > >>>>>>>>> > >> >> > >> recommending its usage there. I also do > >>>>>>>not prohibit > >>>>>>>>>its > >>>>>>>>> > >> >> > >use, based on > >>>>>>>>> > >> >> > >> local policy. Keith has come > >forward with > >>>>>>>the specific > >>>>>>>>> > >>>>>>>>> > >> >> > >> request that non-ESInet networks be > >>>>>>>allowed to mark and > >>>>>>>>>pay > >>>>>>>>> > >> >attention to > >>>>>>>>> > >> >> > >> this priority indication -- with IMS as > >>>>>>>the specific > >>>>>>>>>example > >>>>>>>>> > >> >> > >> he wishes to have this valid for. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> Where there is no disagreement, save for > >>>>>>>your recent > >>>>>>>>> > >> >> > >pushback - is in > >>>>>>>>> > >> >> > >> the ESInet, which is where Brian > >>>>has requested it's > >>>>>>>>> > >> >> > >definition in the > >>>>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >>>>>>>chair within > >>>>>>>>> > >> >> NENA, and if > >>>>>>>>> > >> >> > >> he asks for it, are you going to say you > >>>>>>>know better > >>>>>>>>>than he? > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> >Btw, I not disagreeing with the document > >>>>>>>as such. I > >>>>>>>>> > >> >just want to > >>>>>>>>> > >> >> > the > >>>>>>>>> > >> >> > >> scope > >>>>>>>>> > >> >> > >> >to change. The usage of RPH > >>>>within the emergency > >>>>>>>>> > >> >> services network > >>>>>>>>> > >> >> > is > >>>>>>>>> > >> >> > >> fine > >>>>>>>>> > >> >> > >> >for me. I may get convinced to start the > >>>>>>>RPH marking > >>>>>>>>>from > >>>>>>>>> > >> >> > >the the VSP > >>>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy > >about the > >>>>>>>end host > >>>>>>>>>doing > >>>>>>>>> > >> >> > >the marking. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> please read what I wrote above, and then > >>>>>>>re-read the > >>>>>>>>> > >> >most recent > >>>>>>>>> > >> >> > >> version of the ID. I don't have endpoints > >>>>>>>that SHOULD > >>>>>>>>>or > >>>>>>>>> > >> >> MUST mark > >>>>>>>>> > >> >> > >> anything wrt RPH. I also don't want to > >>>>>>>prohibit it, > >>>>>>>>> > >> >> because there > >>>>>>>>> > >> >> > >> might be cases (that I don't know > >>>>of) of valid uses > >>>>>>>>> > >> >> under certain > >>>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear > >>>>>>>that there are 3 > >>>>>>>>> > >> >> networking > >>>>>>>>> > >> >> > >> parts to consider > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> #1 - from the endpoint > >>>>>>>>> > >> >> > >> #2 - within the VSP > >>>>>>>>> > >> >> > >> #3 - within the ESInet > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> the most recent ID version has "can" for > >>>>>>>#s 1 and 2, > >>>>>>>>>and > >>>>>>>>> > >> >> > >2119 language > >>>>>>>>> > >> >> > >> offering those supporting this > >>>>>>>specification will have > >>>>>>>>>RPH > >>>>>>>>> > >> >> > >> adherence within #3 (the ESInet). > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> What other scope changes do you want, > >>>>>>>because I haven't > >>>>>>>>> > >> >> heard them. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> I only heard you claim in email > >during the > >>>>>>>last IETF > >>>>>>>>>and in > >>>>>>>>> > >> >> > >the ECRIT > >>>>>>>>> > >> >> > >> session that RPH should not be > >>>>used for priority > >>>>>>>>>marking > >>>>>>>>> > >> >> requests. > >>>>>>>>> > >> >> > >> This is something Keith (SIP WG > >>>>chair) voiced his > >>>>>>>>>opposition > >>>>>>>>> > >> >> > >> to your views regarding creating a second > >>>>>>>means for SIP > >>>>>>>>>to > >>>>>>>>> > >> >priority > >>>>>>>>> > >> >> > >> mark request "when SIP already has one > >>>>>>>interoperable > >>>>>>>>>way to > >>>>>>>>> > >> >> > >> accomplish this... it's call the > >RP header > >>>>>>>mechanism". > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> >I don't see advantages -- only > >>>>disadvantages. > >>>>>>>>> > >> >> > >> > > >>>>>>>>> > >> >> > >> >Ciao > >>>>>>>>> > >> >> > >> >Hannes > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> > >>>>_______________________________________________ > >>>>>>>>> > >> >> > >> Ecrit mailing list > >>>>>>>>> > >> >> > >> Ecrit@ietf.org > >>>>>>>>> > >> >> > >> > >https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> > >_______________________________________________ > >>>>>>>>> > >> >> Ecrit mailing list > >>>>>>>>> > >> >> Ecrit@ietf.org > >>>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >> >> > >>>>>>>>> > >> > > >>>>>>>>> > > > >>>>>>>>> > > >>>>>>>>> > _______________________________________________ > >>>>>>>>> > Ecrit mailing list > >>>>>>>>> > Ecrit@ietf.org > >>>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>_______________________________________________ > >>>>>>>>>Ecrit mailing list > >>>>>>>>>Ecrit@ietf.org > >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>>_______________________________________________ > >>>>>>>>Ecrit mailing list > >>>>>>>>Ecrit@ietf.org > >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Ecrit mailing list > >>>>>>Ecrit@ietf.org > >>>>>>https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >>>------------------------------------------------------------- > >----------------------------------- > >>>This message is for the designated recipient only and may > >>>contain privileged, proprietary, or otherwise private information. > >>>If you have received it in error, please notify the sender > >>>immediately and delete the original. Any unauthorized use of > >>>this email is prohibited. > >>>------------------------------------------------------------- > >----------------------------------- > >>>[mf2] > >>> > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EE03A6B9F for ; Fri, 6 Feb 2009 15:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v0fvhosYWtW for ; Fri, 6 Feb 2009 15:39:03 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id B784B3A682D for ; Fri, 6 Feb 2009 15:39:02 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-161.messagelabs.com!1233963543!19296858!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 30221 invoked from network); 6 Feb 2009 23:39:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-161.messagelabs.com with AES256-SHA encrypted SMTP; 6 Feb 2009 23:39:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16Nd3kE012820; Fri, 6 Feb 2009 18:39:03 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n16Nd1bs012805; Fri, 6 Feb 2009 18:39:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 6 Feb 2009 18:39:00 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01238F65@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RPH Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAAc6YOQ== From: "DOLLY, MARTIN C, ATTLABS" To: , , , Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 23:39:06 -0000 V3JvbmcsIGV2ZXJ5dGhpbmcgaXMgYmFzZWQgb24gc2VjdXJpdHkgcG9saWNpZXMNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5U c2Nob2ZlbmlnQGdteC5uZXQ+DQpUbzogRE9MTFksIE1BUlRJTiBDLCBBVFRMQUJTOyBqbXBvbGtA Y2lzY28uY29tIDxqbXBvbGtAY2lzY28uY29tPjsgaGdzQGNzLmNvbHVtYmlhLmVkdSA8aGdzQGNz LmNvbHVtYmlhLmVkdT47IEphbWVzLldpbnRlcmJvdHRvbUBhbmRyZXcuY29tIDxKYW1lcy5XaW50 ZXJib3R0b21AYW5kcmV3LmNvbT4NCkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0Vz cG9vKSA8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT47IGVjcml0QGlldGYub3JnIDxlY3JpdEBp ZXRmLm9yZz4NClNlbnQ6IEZyaSBGZWIgMDYgMTc6NTI6MDcgMjAwOQ0KU3ViamVjdDogUkU6IFtF Y3JpdF0gUlBIDQoNCkhpIE1hcnRpbiwgDQoNCkkgYW0gYXJndWluZyB0aGF0IGlmIHRoZSBVRSBk b2VzIG1hcmsgdGhlIGNhbGwgd2l0aCB0aGUgRUNSSVQgUlBIIChJIGNhbGwgaXQNCnRoYXQgd2F5 IHRvIGRpZmZlcmVudGlhdGUgaXQgZnJvbSBSRkMgNDQxMiBSUEggdXNhZ2UsIHdoaWNoIGlzIHZl cnkNCmRpZmZlcmVudCkgdGhlbiBpdCBzaG91bGQgYmUgaWdub3JlZC4gDQpQcm9jZXNzaW5nIGl0 IHdpbGwgbm90IGhlbHAgaW4gYW55IHdheSAoYXMgSSBkZXNjcmliZWQgaW4gbXkgcHNldWRvIGNv ZGUNCnNuaXBwZXQpLiBJbmNvcnJlY3RseSBwcm9jZXNzaW5nIGl0ICh3aGljaCBpcyBhIHBvc3Np YmlsaXR5IHdoZW4gdGhlDQppbXBsZW1lbnRlciBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBzZWN1 cml0eSBpbXBsaWNhdGlvbnMgLS0gdGhleSB3aWxsIG5vdA0KZ2V0IGl0IGZyb20gdGhlIGN1cnJl bnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQpIHdpbGwgbGVhZCB0byBzZWN1cml0eSBwcm9ibGVtcw0K KGZyYXVkICYgRG9TIHBvdGVudGlhbCkuIA0KDQpXaGlsZSB5b3UgY2Fubm90IHByZXZlbnQgc29t ZW9uZSBmcm9tIHNlbmRpbmcgeW91LCB0aGVyZSBpcyBjZXJ0YWlubHkgdGhlDQpjaGFuY2UgdG8g ZG9jdW1lbnQgd2hhdCB0aGUgcmVjZWl2ZXIgc2hvdWxkIGRvIHdpdGggaXQuDQoNCkNpYW8NCkhh bm5lcyANCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogZWNyaXQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIA0KPk9uIEJlaGFsZiBP ZiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlMNCj5TZW50OiAwNyBGZWJydWFyeSwgMjAwOSAwMDox NQ0KPlRvOiBqbXBvbGtAY2lzY28uY29tOyBoZ3NAY3MuY29sdW1iaWEuZWR1OyANCj5KYW1lcy5X aW50ZXJib3R0b21AYW5kcmV3LmNvbQ0KPkNjOiBoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29tOyBl Y3JpdEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbRWNyaXRdIFJQSA0KPg0KPllvdSBjYW4gbm90 IGRpc2FsbG93IHRoaXMgZnJvbSBhbiBVRS4gVGhlIHRydXN0IHJlbGF0aW9uc2hpcCANCj53aWxs IGRpY3RhdGUgd2hldGhlciBpdCBpcyBhY2NlcHRlZCBvciBub3QNCj4NCj4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQo+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyA8ZWNyaXQtYm91 bmNlc0BpZXRmLm9yZz4NCj5UbzogSGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVtYmlh LmVkdT47IFdpbnRlcmJvdHRvbSwgDQo+SmFtZXMgPEphbWVzLldpbnRlcmJvdHRvbUBhbmRyZXcu Y29tPg0KPkNjOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSANCj48aGFubmVz LnRzY2hvZmVuaWdAbnNuLmNvbT47IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NCj5TZW50OiBGcmkg RmViIDA2IDE3OjEwOjA4IDIwMDkNCj5TdWJqZWN0OiBSZTogW0Vjcml0XSBSUEgNCj4NCj5BdCAw MzowNSBQTSAyLzYvMjAwOSwgSGVubmluZyBTY2h1bHpyaW5uZSB3cm90ZToNCj4+VGhlcmUncyBh bm90aGVyIHByb2JsZW0gd2l0aCB0aGUgIml0IGRvZXNuJ3QgaHVydCBhcmd1bWVudCIuIA0KPkFz c3VtZSBmb3IgDQo+PmEgbW9tZW50IHdlIGhhdmUgYSAiVUEgTUFZIGluY2x1ZGUgUlBIIiB3b3Jk aW5nLiBUaGVyZSBhcmUgbm93IHR3bw0KPj5jYXNlczoNCj4+DQo+PigxKSBBbGwgVUFzIGltcGxl bWVudCBpdC4NCj4+DQo+PigyKSBPbmx5IHNvbWUgVUFzIGltcGxlbWVudCBpdC4NCj4+DQo+Pigx KSBzZWVtcyB1bmxpa2VseSBmb3IgYSBNQVkuIElmICgyKSBvY2N1cnMsIHdlIGhhdmUgdGhlIA0K PmNob2ljZSBiZXR3ZWVuIA0KPj50d28gdW5kZXNpcmFibGUgb3V0Y29tZXM6DQo+Pg0KPj4oYSkg c29tZSBVQXMgdGhhdCBhcmUgb3RoZXJ3aXNlIGNvbXBsaWFudCBnZXQgd29yc2Ugc2VydmljZSBq dXN0IA0KPj5iZWNhdXNlIHRoZXkgZGlkbid0IGluY2x1ZGUgdGhlIFJQSDsNCj4NCj5hbSBJIHJl YWRpbmcgdGhpcyBjb3JyZWN0bHkgLSB0aGF0IHVubGVzcyBhbGwgVUFzIGltcGxlbWVudCANCj50 aGlzIGNhcGFiaWxpdHkgdGhpcyBzaG91bGQgbmV2ZXIgYmUgaW1wbGVtZW50ZWQgYnkgYW55IFVB cz8NCj4NCj5UaGlzIGZsaWVzIGluIHRoZSBmYWNlIG9mIHZlbmRvcnMgc29sdmluZyBmb3IgdGhl aXIgY3VzdG9tZXIncyANCj5yZXF1aXJlbWVudHMuDQo+DQo+SSB3aWxsIGFkbWl0IHRoYXQgYXQg dGhpcyB0aW1lLCBJIGtub3cgb2Ygbm8gQ2lzY28gY3VzdG9tZXJzIA0KPnRoYXQgd2FudCB0aGlz IGNhcGFiaWxpdHksIHNvIEknbSBub3QgYW5nbGluZyBmb3IgYW55IG9mIG91ciANCj5yZXZlbnVl IGhlcmUuICBJJ20gc2F5aW5nIHRoYXQgSSB0aGluayBJIGhlYXIgeW91IHNheWluZyB0aGlzIA0K PklEIHNob3VsZCBzYXkgc29tZXRoaW5nIGxpa2UNCj4NCj4gICAgICAgICBVQXMgYXJlIHByZXZl bnRlZCBmcm9tIGltcGxlbWVudGluZyB0aGUgUlAgbmFtZXNwYWNlIGVzbmV0DQo+DQo+SSdtIGZp Z2h0aW5nIGFnYWluc3QgdGhhdCwgYmVjYXVzZSBjdXN0b21lcnMgYXJlIGFsd2F5cyBjb21pbmcg DQo+dG8gZXZlcnkgdmVuZG9yIHdpdGggbmV3IHJlcXVpcmVtZW50cywgc29tZSBvZiB0aGVtIHVu aXF1ZSBhdCANCj50aGUgdGltZS4gIFRoaXMgcHJldmVudGlvbiB0ZXh0IHdvdWxkIHByZXZlbnQg YSB2ZW5kb3IgZnJvbSANCj5jb21wbHlpbmcgd2l0aCB0aGlzIHNwZWNpZmljYXRpb24gYW5kIHN0 aWxsIG1lZXQgdGhlIGN1c3RvbWVyJ3MgbmVlZHMuDQo+DQo+SSBiZWxpZXZlIHRoYXQgdGhpcyBJ RCBuZWVkcyB0byByZXRhaW4gdGhlIGVuZHBvaW50cyBNQVkgDQo+aW5zZXJ0IGVzbmV0LCBhbmQg aGF2ZSBhcHByb3ByaWF0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyANCj50ZXh0IHRoYXQgaGln aGxpZ2h0cyB0aGUgY29uY2VybnMgZXhwcmVzc2VkIGhlcmUuDQo+DQo+U29tZSBmdXR1cmUgSUQg Y2FuIHRoZW4gdXBkYXRlIHRoaXMgY3VycmVudCBSRkMgKHRvLWJlKSB3aXRoaW4gdGhlDQo+MjEx OSBydWxlcyBvZiB0aGUgdXNlIG9mIE1BWSBoZXJlLg0KPg0KPg0KPj5PUg0KPj4NCj4+KGIpIHRo ZSBwcm94eSBoYXMgdG8gbG9vayBmb3IgdGhlIHNlcnZpY2UgVVJOIHRvIGdpdmUgdGhlIGNhbGwg dGhlDQo+PmFwcHJvcHJpYXRlIHRyZWF0bWVudCwgdGh1cyBvYnZpYXRpbmcgYW55IGFkdmFudGFn ZSBvZiBoYXZpbmcgdGhlDQo+PmhlYWRlciwgeWV0IGluY3VycmluZyBtb3JlIGNvbXBsaWNhdGVk IHByb2Nlc3NpbmcgbG9naWMuDQo+Pg0KPj4NCj4+SSBoYXZlIG5vIG9iamVjdGlvbiB0byB3aGF0 ZXZlciBtYXJraW5ncyBwZW9wbGUgd2FudCB0byBhcHBseSB0byBjYWxscw0KPj53aXRoaW4gYW4g RVNOIC0gdGhhdCdzIGxhcmdlbHkgYSBwcml2YXRlIG1hdHRlci4NCj4+DQo+Pkhlbm5pbmcNCj4+ DQo+Pk9uIEZlYiA2LCAyMDA5LCBhdCAzOjAxIFBNLCBXaW50ZXJib3R0b20sIEphbWVzIHdyb3Rl Og0KPj4NCj4+PkhpIEFsbCwNCj4+Pg0KPj4+SSBoYXZlIGZvbGxvd2VkIHRoaSB0aHJlYWQgd2l0 aCBzb21lIGludGVyZXN0IGFuZCBJIHN0cnVnZ2xpbmcgdG8NCj4+PnNlZSBhIHVzZSBjYXNlIGZv ciB0aGUNCj4+PnByb3ZpZGluZyBSUEggZm9yIGVtZXJnZW5jeSBjYWxscyBmcm9tIHRoZSBlbmQt cG9pbnQuDQo+Pj4NCj4+PlRoZSByZWZlcmVuY2UtbW9kZWwgY2FsbCBpbiBFQ1JJVCwgZm9yIGJl dHRlciBvciB3b3JzZSwgaXMgZm9yIGFsbA0KPj4+Y2FsbHMgdG8gZ28gYmFjayB0aHJvdWdoIGEg aG9tZS1WU1AuDQo+Pj5XZSBwbGFjZWQgcXVpdGUgYSBsb3Qgb2YgZW1waGFzaXMsIGxhcmdlbHkg Zm9yIHRyYWZmaW5nIHJlYXNvbnMsIGZvcg0KPj4+dGhlIFZTUCB0byBiZSBhYmxlIHRvIHZlcmlm eSB0aGF0DQo+Pj5hIGNhbGwgaXMgaW4gZmFjdCBhbiBlbWVyZ2VuY3kgY2FsbC4gVGhpcyBpcyBk b25lIGJ5IHRoZSBwcm94eQ0KPj4+dGFraW5nIHRoZSBpbmJhbmQgbG9jYXRpb24sIGRvaW5nIGEg TG9TVA0KPj4+cXVlcnkgd2l0aCB0aGUgcHJvdmlkZWQgVVJOLCBhbmQgdmVyaWZ5aW5nIHRoYXQg dGhlIHJlc3VsdGluZw0KPj4+ZGVzdGluYXRpb24gVVJJIGlzIHRoZSBzYW1lIGFzIHRoZSBkZXN0 aW5hdGlvbg0KPj4+VVJJIHByb3ZpZGUgaW4gdGhlIFNJUCBJTlZJVEUuIE15IHVuZGVyc3RhbmRp bmcgd2FzIHRoYXQgVlNQcyB3b3VsZA0KPj4+YWx3YXlzIGRvIHRoaXMgY2hlY2sgc28gdGhleSBj b3VsZA0KPj4+dGVsbCBpZiB0aGV5IGNvdWxkIGJpbGwgZm9yIHRoZSBjYWxsIG9yIG5vdCwgYW5k IGJlY2F1c2UgdGhlIFZTUCBjYW4NCj4+PmJlIHVzZSB0aGF0IHRoZSBjYWxsIGlzIGFuIGVtZXJn ZW5jeSBjYWxsDQo+Pj5pdCBjYW4gYXBwbHkgYW55IHNwZWNpYWwgcHJpb3JpdGllcyB0aGF0IG1h eSBiZSBhcHBsaWNhYmxlLiBUaGlzDQo+Pj5vYnZpYXRlcyB0aGUgbmVlZCBmb3IgUlBIIGZyb20g dGhlIGVuZC1wb2ludA0KPj4+dG8gdGhlIG5ldHdvcmsuDQo+Pj4NCj4+PlRoaXMgbGVhdmVzIHVz IHdpdGggdGhlIGFyZ3VtZW50IG9mICJpdCBkb2Vzbid0IGh1cnQgdG8gaXQiLCB3aGljaA0KPj4+ aXMgbm90IGEgZ29vZCByZWFzb24gdG8gd3JpdGUgYSBzcGVjaWZpY2F0aW9uLg0KPj4+SXQgd2Fz IGludGltYXRlZCBvbiB0aGUgZ2VvcHJpdiBtYWlsaW5nIGxpc3QgbGFzdCB5ZWFyIHRoYXQgZ3Jl YXQNCj4+PnBhaW5zIGhhZCBiZWVuIHRha2VuIHRvIGtlZXAgU0lQIHdpdGggaW4gdGhlDQo+Pj5N VFUgbGltaXRzIG9mIFVEUCBvdmVyIEV0aGVybmV0IA0KPj4+KGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9nZW9wcml2L2N1cnJlbnQvbXNnMDYxMg0KPjAuaHRtbCApLiBBc3N1 bWluZw0KPj4+dGhhdCB0aGlzIGlzIHRoZSBjYXNlLCBwZXJoYXBzIHRoZXJlIGlzIGhhcm0gaW4g aW5jbHVkaW5nDQo+Pj5pbmZvcm1hdGlvbiB0aGF0IHdlIGtub3cgd2lsbCBiZSBpZ25vcmVkLg0K Pj4+DQo+Pj5DaGVlcnMNCj4+PkphbWVzDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgSGFubmVzIFRzY2hvZmVuaWcNCj4+PlNlbnQ6IEZyaSAyLzYvMjAwOSAxMjozMyBQTQ0KPj4+ VG86ICdCcmlhbiBSb3Nlbic7ICdIZW5uaW5nIFNjaHVsenJpbm5lJw0KPj4+Q2M6IFRzY2hvZmVu aWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pOyAnRUNSSVQnDQo+Pj5TdWJqZWN0OiBSZTogW0Vj cml0XSBSUEgNCj4+Pg0KPj4+VG8gdGhlIHN0b3J5IHNob3J0IGhlcmUgaXMgdGhlIGNvZGUgZm9y IHRoZSBwcm94eToNCj4+Pg0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PklGIGVt ZXJnZW5jeSBjYWxsIHdhcyByZWNvZ25pemVkIFRIRU4NCj4+PiAgICBleGVjdXRlIGVtZXJnZW5j eSBjYWxsIHNwZWNpZmljIHByb2NlZHVyZXMgKHByaW9yaXR5IHF1ZXVpbmcsDQo+Pj5wcmVlbXB0 aW9uLCBmZXRjaCBsb2NhdGlvbiwgZGV0ZXJtaW5lIHJvdXRpbmcsIGRvIGZ1bm55IFFvUyB0aGlu Z3MgJg0KPj4+Y28pDQo+Pj5FTFNFDQo+Pj4gICAgbm9ybWFsIGNhbGwgaGFuZGxpbmcgcHJvY2Vk dXJlcy4NCj4+Pg0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PklmIHlvdSBjYW4g bWFrZSB0aGlzIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIGFuIGVtZXJnZW5jeSBjYWxsIGFuZCBh DQo+Pj5yZWd1bGFyDQo+Pj5jYWxsIHRoZW4geW91IGNhbiBhbHNvIGRvIGV2ZXJ5dGhpbmcgdGhh dCBpcyBuZWNlc3NhcnkgZm9yIGVtZXJnZW5jeQ0KPj4+Y2FsbA0KPj4+aGFuZGxpbmcuDQo+Pj4N Cj4+PkJyaWFuICsgS2VpdGg6IFBsZWFzZSB0ZWxsIG1lIHRoYXQgd2UgY2Fubm90IGRvIHRoZSBh Ym92ZSB3aXRoIG91cg0KPj4+Y3VycmVudGx5DQo+Pj5zcGVjaWZpZWQgbWVjaGFuaXNtcy4NCj4+ Pg0KPj4+Q2lhbw0KPj4+SGFubmVzDQo+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+PkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXRdDQo+Pj4+ U2VudDogMDYgRmVicnVhcnksIDIwMDkgMTc6NDkNCj4+Pj5UbzogJ0hlbm5pbmcgU2NodWx6cmlu bmUnOyAnSGFubmVzIFRzY2hvZmVuaWcnDQo+Pj4+Q2M6ICdUc2Nob2ZlbmlnLCBIYW5uZXMgKE5T TiAtIEZJL0VzcG9vKSc7ICdFQ1JJVCcNCj4+Pj5TdWJqZWN0OiBSRTogW0Vjcml0XSBSUEgNCj4+ Pj4NCj4+Pj5JIGFncmVlIHRoYXQgbm90IGFsbCBuZXR3b3JrcyB3aWxsIHBlcm1pdCAob3IgcGF5 IGF0dGVudGlvbg0KPj4+PnRvKSBhIHByaW9yaXR5IHJlcXVlc3QgZnJvbSBhbiBlbmQgZGV2aWNl Lg0KPj4+Pg0KPj4+Pk5vIG9uZSBoYXMgYXNrZWQgZm9yIHRoYXQuDQo+Pj4+DQo+Pj4+VGhlIG5h bWVzcGFjZSByZXF1ZXN0IGhhcyBzZXZlcmFsIHVzZXMsIG9uZSBvZiB3aGljaCBpcyB3aXRoaW4N Cj4+Pj5hbiBlbWVyZ2VuY3kgc2VydmljZXMgSVAgbmV0d29yaywgb25lIG9mIHdoaWNoIGlzIGJl dHdlZW4NCj4+Pj5lbGVtZW50cyB3aXRoaW4gYSBwdWJsaWMgbmV0d29yayBjb250cm9sbGVkIGJ5 IHRoZSBvcGVyYXRvciwNCj4+Pj5hbmQgb25lIG9mIHdoaWNoIGlzIGFuIGVuZHBvaW50IHJlcXVl c3QgZm9yIHJlc291cmNlIHByaW9yaXR5Lg0KPj4+Pg0KPj4+PlRob3NlIG9mIHVzIHJlcXVlc3Rp bmcgdGhpcyB3b3JrIHByb2NlZWQgYXJlIGhhcHB5IGlmIHRoZQ0KPj4+PmVuZHBvaW50IHBhcnQg aXMgc2ltcGx5IGxlZnQgYXMgcG9zc2libGUgKE1BWSksIGFuZCwgc3BlYWtpbmcNCj4+Pj5mb3Ig bXlzZWxmLCBoYXZpbmcgdGhlIGRyYWZ0IGRpc2N1c3MgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9u cw0KPj4+Pm9mIGVuZHBvaW50IG1hcmtpbmcgaXMgcmVhc29uYWJsZS4NCj4+Pj4NCj4+Pj5IYXZp bmcgZGlzY3Vzc2VkIHRoaXMgaXNzdWUgd2l0aCBhbiBpbXBsZW1lbnRhdGlvbiB0ZWFtIHdobw0K Pj4+PndvcmtlZCBvbiBNTFBQIHN5c3RlbXMsIEkgYW0gY29uZmlkZW50IEkga25vdyB3aGF0IEkn bSB0YWxraW5nDQo+Pj4+YWJvdXQsIGJ1dCBZTU1WLiAgVGhlIGZhY3QgdGhhdCB5b3UgY291bGQs IGlmIHlvdSB3YW50ZWQgdG8sDQo+Pj4+Z2l2ZSByZXNvdXJjZSBwcmlvcml0eSB0byBhIGNhbGwg eW91IGRlY2lkZWQsIGhvd2V2ZXIgeW91DQo+Pj4+ZGVjaWRlZCwgd2FzIGFuIGVtZXJnZW5jeSBj YWxsIGlzIGFuIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uLA0KPj4+PmFuZCBub3Qgc3ViamVjdCB0 byBzdGFuZGFyZGl6YXRpb24uDQo+Pj4+DQo+Pj4+UlBIIGlzIHRoZSBJRVRGIHN0YW5kYXJkIHdh eSBmb3Igb25lIGVudGl0eSB0byByZXF1ZXN0DQo+Pj4+cmVzb3VyY2UgcHJpb3JpdHkgb2YgYW5v dGhlciBlbnRpdHkgaW4gYSBTSVAgc3lzdGVtLiAgV2UncmUNCj4+Pj5hc2tpbmcgZm9yIGEgbmFt ZXNwYWNlIHRvIHVzZSB0aGF0IHdpdGhpbiB0aGUgZG9tYWluIG9mDQo+Pj4+ZW1lcmdlbmN5IGNh bGxzLiAgVGhhdCBpcywgSSB0aGluaywgYSBWRVJZIHJlYXNvbmFibGUgcmVxdWVzdC4NCj4+Pj4N Cj4+Pj5Ccmlhbg0KPj4+Pg0KPj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj5G cm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0NCj4+ Pj4+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwNiwgMjAwOSAxMDozMyBBTQ0KPj4+Pj5UbzogSGFu bmVzIFRzY2hvZmVuaWcNCj4+Pj4+Q2M6IEJyaWFuIFJvc2VuOyBUc2Nob2ZlbmlnLCBIYW5uZXMg KE5TTiAtIEZJL0VzcG9vKTsgRUNSSVQNCj4+Pj4+U3ViamVjdDogUmU6IFtFY3JpdF0gUlBIDQo+ Pj4+Pg0KPj4+Pj5UbyBjaGltZSBpbiBoZXJlOg0KPj4+Pj4NCj4+Pj4+SSBkb24ndCB0aGluayBp dCdzIHByb2R1Y3RpdmUgdG8gc2ltcGx5IHN0YXRlIHRoYXQgNDQxMg0KPj4+PmRvZXNuJ3Qgd29y cnkNCj4+Pj4+YWJvdXQgYXV0aG9yaXphdGlvbiwgc28gd2Ugc2hvdWxkbid0IGVpdGhlciAoc2lt cGxpZnlpbmcgYSBiaXQpLg0KPj4+Pj5BdXRob3JpemF0aW9uIHdhcyBkaXNjdXNzZWQgcmVwZWF0 ZWRseSwgYW5kIHRoZSBnZW5lcmFsDQo+Pj4+YXNzdW1wdGlvbiB3YXMNCj4+Pj4+dGhhdCB0aGVy ZSB3ZXJlIHR3byBjb25kaXRpb25zOiBFaXRoZXIgdGhlIHVzZXIgaW52b2tpbmcgcmVzb3VyY2Ut DQo+Pj4+PnByaW9yaXR5IHdhcyB3ZWxsIGtub3duIGFuZCBoYWQgYSBzZXQgb2YgcGVybWlzc2lv bnMgdGhhdCBjb3VsZCBiZQ0KPj4+Pj5jaGVja2VkIGluIHJlYWwgdGltZSBvciB0aGVyZSBhcmUg d2F5cyB0byBkZWFsIHdpdGggYWJ1c2UgYWZ0ZXIgdGhlDQo+Pj4+PmZhY3QgaW4gd2F5cyB0aGF0 IGRldGVyIGFidXNlICh0aGUgY291cnQtbWFydGlhbCBraW5kIG9mIHRoaW5nIGluIGENCj4+Pj4+ bWlsaXRhcnkgY29udGV4dCkuDQo+Pj4+Pg0KPj4+Pj5UaGUgUkZDIDQ0MTIgc2VjdXJpdHkgY29u c2lkZXJhdGlvbiAoMTEuMikgY2FsbCB0aGlzIG91dCBpbiBwcmV0dHkNCj4+Pj4+c3Ryb25nIGxh bmd1YWdlOg0KPj4+Pj4NCj4+Pj4+ICBQcmlvcml0aXplZCBhY2Nlc3MgdG8gbmV0d29yayBhbmQg ZW5kLXN5c3RlbSByZXNvdXJjZXMgaW1wb3Nlcw0KPj4+Pj4gICAgcGFydGljdWxhcmx5IHN0cmlu Z2VudCByZXF1aXJlbWVudHMgb24gYXV0aGVudGljYXRpb24gYW5kDQo+Pj4+PiAgICBhdXRob3Jp emF0aW9uIG1lY2hhbmlzbXMsIHNpbmNlIGFjY2VzcyB0byBwcmlvcml0aXplZA0KPj4+PnJlc291 cmNlcyBtYXkNCj4+Pj4+ICAgIGltcGFjdCBvdmVyYWxsIHN5c3RlbSBzdGFiaWxpdHkgYW5kIHBl cmZvcm1hbmNlIGFuZCBub3QNCj4+Pj5qdXN0IHJlc3VsdA0KPj4+Pj4gICAgaW4gdGhlZnQgb2Ys IHNheSwgYSBzaW5nbGUgcGhvbmUgY2FsbC4NCj4+Pj4+VGh1cywgdGhlIHF1ZXN0aW9uIGlzIHdo ZXRoZXIgd2UgaGF2ZSBzdWNoIHN0cm9uZyBhdXRoZW50aWNhdGlvbiBpbg0KPj4+Pj5lbWVyZ2Vu Y3kgY2FsbGluZy4gSW4gc29tZSBjYXNlcywgc3VjaCBhcyByZXNpZGVudGlhbCBmaXhlZCBsaW5l DQo+Pj4+PmRlcGxveW1lbnRzIHdoZXJlIElTUCA9IFZTUCwgd2UncmUgcHJvYmFibHkgcHJldHR5 IGNsb3NlLCANCj5pbiBvdGhlcnMsDQo+Pj4+PnN1Y2ggYXMgcHJlcGFpZCBjZWxsIHBob25lcyBv ciBob3Qgc3BvdHMgb3IgVlNQLW9ubHkgcHJvdmlkZXJzLCB3ZQ0KPj4+Pj5hcmVuJ3QuDQo+Pj4+ Pg0KPj4+Pj5UaGUgb3RoZXIgcG9pbnQgdGhhdCBJIHRoaW5rIEhhbm5lcyBpcyBtYWtpbmcgaXMg dGhhdCB0aGUNCj4+Pj5pbmZvcm1hdGlvbg0KPj4+Pj5pcyBlaXRoZXIgcmVkdW5kYW50IG9yIGRh bmdlcm91cy4gSWYgYSBwcm9jZXNzaW5nIGVsZW1lbnQgDQo+cmVjb2duaXplcw0KPj4+Pj50aGUg Y2FsbCBhcyBiZWluZyBhbiBlbWVyZ2VuY3kgY2FsbCwgaXQgY2FuIGFwcGx5IHdoYXRldmVyIA0K PnRyZWF0bWVudA0KPj4+Pj5pdCBkZWVtcyBhcHByb3ByaWF0ZSBhbmQgZG9lc24ndCBuZWVkIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb24uIElmIGl0DQo+Pj4+PmRvZXNuJ3Qgb3IgY2FuJ3QsIHVzaW5n IGp1c3QgdGhlIFJQSCBjYW4gYmUgcmF0aGVyIGRhbmdlcm91cyB1bmxlc3MNCj4+Pj4+dGhhdCBl bGVtZW50IGNhbiBiZSByZWFzb25hYmx5IGNlcnRhaW4gdGhhdCB0aGVyZSBpcyBzdHJvbmcNCj4+ Pj4+YXV0aGVudGljYXRpb24gYW5kIHJlY291cnNlLg0KPj4+Pj4NCj4+Pj4+SSBkb24ndCBidXkg dGhlIGFyZ3VtZW50IHRoYXQgc29tZWhvdyBmaW5kaW5nIHRoZSBSUEggaXMgDQo+ZmFzdGVyIHRo YW4NCj4+Pj4+anVzdCBsb29raW5nIGZvciB0aGUgaWRlbnRpZmllci4gVGh1cywgZ2l2ZW4gdGhh dCB0aGUgDQo+aW5mb3JtYXRpb24gaXMNCj4+Pj4+ZWl0aGVyIHJlZHVuZGFudCBvciBkYW5nZXJv dXMsIEkgZmFpbCB0byBzZWUgdGhlIGFkdmFudGFnZS4NCj4+Pj4+DQo+Pj4+Pkhlbm5pbmcNCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj5PbiBGZWIgNiwgMjAwOSwgYXQgMTA6MjAgQU0sIEhhbm5lcyBUc2No b2ZlbmlnIHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PkRvbid0IGdldCBodW5nIHVwIG9uIHRoZSBkZXRh aWxzLiBUaGVyZSBhcmUgd2F5cyB0byBvcHRpbWl6ZSBpdC4NCj4+Pj4+PlRoYXQgd2FzDQo+Pj4+ Pj5ub3QgdGhlIHBvaW50IG9mIHRoZSBjb2RlIGV4YW1wbGUuDQo+Pj4+Pj4NCj4+Pj4+PlRoZSBw cm9ibGVtIHRoYXQgbXkgcHNldWRvIGNvZGUgc2hvdWxkIGhhdmUgc2hvd24geW91IGlzIHRoYXQg eW91DQo+Pj4+Pj4qIGRvbid0IGdhaW4gYW55dGhpbmcgd2l0aCBSUEggbWFya2luZyBmb3IgdGhl IGVtZXJnZW5jeSBjYWxsIGNhc2UNCj4+Pj4+PmZyb20gdGhlIFNJUCBVQSB0b3dhcmRzIHRoZSBv dXRib3VuZCBwcm94eSBzaW5jZSB0aGUgZnVuY3Rpb25hbGl0eQ0KPj4+Pj4+aXMgYWxyZWFkeSBw cm92aWRlIG90aGVyd2lzZS4gSG93IG9mdGVuIGRvZXMgdGhlIHByb3h5IG5lZWQgdG8gZ2V0DQo+ Pj4+Pj50b2xkIHRoYXQgdGhpcyBpcyBhbiBlbWVyZ2VuY3kgY2FsbCB0b2RvIHdoYXRldmVyIGVt ZXJnZW5jeSBjYWxsDQo+Pj4+Pj5oYW5kbGluZyBwcm9jZWR1cmVzIGFyZSBuZWNlc3Nhcnk/DQo+ Pj4+Pj4qIHlvdSBvbmx5IGludHJvZHVjZSBmcmF1ZCBwcm9ibGVtcyAoaWYgeW91IGFyZSBub3QN Cj4+Pj5jYXJlZnVsIGFuZCB5b3UNCj4+Pj4+PnVuZGVyc3RhbmQgdGhlIHNlY3VyaXR5IHN0dWZm IHdlbGwgZW5vdWdoKQ0KPj4+Pj4+DQo+Pj4+Pj5JZiB5b3UgY2FuIHBvaW50IG1lIHRvIHBlb3Bs ZSB3aG8gaW1wbGVtZW50IHRoZSBSUEggZW1lcmdlbmN5IGNhbGwNCj4+Pj4+PmNhc2UgcGxlYXNl IGRvIHNvLiBJIHdvdWxkIGxvdmUgdG8gdGFsayB0byB0aGVtLg0KPj4+Pj4+DQo+Pj4+Pj5DaWFv DQo+Pj4+Pj5IYW5uZXMNCj4+Pj4+Pg0KPj4+Pj4+UFM6IFlvdSBuZWVkIHRvIHBhcnNlIGluY29t aW5nIG1lc3NhZ2VzIHRvIHNvbWUgZXh0ZW5kIHNvIHRoYXQgeW91DQo+Pj4+Pj5rbm93IHdoYXQg aXQgY29udGFpbnMgOi0pIE9ubHkgbG9va2luZyBmb3IgdGhlIGVtZXJnZW5jeQ0KPj4+PlJQSCBo ZWFkZXINCj4+Pj4+PihhbmQgbm90IGZvciB0aGUgU2VydmljZSBVUk4vZGlhbA0KPj4+Pj4+c3Ry aW5nKSB3b3VsZCBleGFjdGx5IGJlIHRoZSBEb1MvZnJhdWQgYXR0YWNrIEkgYW0gd29ycmllZCBh Ym91dC4NCj4+Pj4+PlRoYXQncyB0aGUgdGhpbmcgSGVubmluZyB3YXMgd29ycmllZCBhYm91dCAo Z28gYW5kIGxpc3RlbiB0byB0aGUNCj4+Pj4+PnBhc3QgbWVldGluZyBtaW51dGVzKS4NCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4+SGFubmVzDQo+Pj4+Pj4+DQo+Pj4+Pj4+WW91IG5lZWQgdG8gdGFs ayB0byBwZW9wbGUgd2hvIHJlYWxseSBpbXBsZW1lbnQgdGhpcyBraW5kDQo+Pj4+b2YgdGhpbmcu DQo+Pj4+Pj4+WW91IGFyZSB3YXkgb2ZmLg0KPj4+Pj4+Pg0KPj4+Pj4+PldoZW4geW91IGltcGxl bWVudCBhIHJlc291cmNlIHByaW9yaXR5IHN5c3RlbSwgdGhlIHBvaW50IG9mIGRvaW5nDQo+Pj4+ Pj4+dGhhdCBpcyB0byBsb29rIHRob3VnaCB0aGUgcXVldWUgb2Ygd29yayBhbmQgcGljayBvdXQg dGhlDQo+Pj4+b25lcyB3aXRoDQo+Pj4+Pj4+cHJpb3JpdHksIGhhbmRsaW5nIHRoZW0gZmlyc3Qu ICBZb3UgZG9uJ3QgZG8gYWxsIHRoZSBwYXJzaW5nLCB5b3UNCj4+Pj4+Pj5kb24ndCBkbyBhIGxv dCBvZiBkZWNpc2lvbiB0cmVlLg0KPj4+Pj4+Pg0KPj4+Pj4+PlR5cGljYWxseToNCj4+Pj4+Pj5D aGVjayBmb3IgRG9TIHRoaW5ncywgbGlrZSB0b28gYmlnIG1lc3NhZ2VzLCBldGMgRG8gYSBxdWlj ayBzY2FuDQo+Pj4+Pj4+Zm9yIHRoZSBSUEggbWVzc2FnZSBoZWFkZXIgSWYgZm91bmQ6DQo+Pj4+ Pj4+UGFyc2UgdGhlIG1lc3NhZ2UNCj4+Pj4+Pj5EZXRlcm1pbmUgdmFsaWRpdHkNCj4+Pj4+Pj5E ZXRlcm1pbmUgcHJpb3JpdHkNCj4+Pj4+Pj5RdWV1ZSBvbiB0aGUgY29ycmVjdCB3b3JrIHF1ZXVl DQo+Pj4+Pj4+DQo+Pj4+Pj4+VGhlIGZpcnN0IHR3byBhY3Rpb25zIGhhdmUgdG8gYmUgdmVyeSBm YXN0LiAgQW55b25lIHdobyBidWlsZHMgYQ0KPj4+Pj4+PlNJUCB0aGluZ2llIHdpbGwgdGVsbCB5 b3UgdGhhdCBwYXJzaW5nIGlzIG9uZSBvZiB0aGUgYmlnIGN5Y2xlDQo+Pj4+Pj4+Y29uc3VtZXJz OiBpZiB5b3UgaGF2ZSB0byBwYXJzZSBldmVyeSBtZXNzYWdlIEJFRk9SRSB5b3UNCj4+Pj5kZXRl cm1pbmUNCj4+Pj4+Pj5wcmlvcml0eSwgeW91IGNhbid0IGdpdmUgbXVjaCByZXNvdXJjZSBwcmlv cml0eS4NCj4+Pj4+Pj5PbmNlIHlvdSBnZXQgdGhlIHdob2xlIG1lc3NhZ2UgcGFyc2VkLCB5b3Ug bWlnaHQgYXMgd2VsbCBmaW5pc2gNCj4+Pj4+Pj53b3JraW5nIG9uIGl0LCBiZWNhdXNlIHlvdSd2 ZSBkb25lIHNvIG11Y2ggb2YgdGhlIHdvcmsuDQo+Pj4+Pj4+T1RIT0gsIGZpbmRpbmcgdGhlIGVu ZC1vZi1tZXNzYWdlIGRlbGltaXRlciBhbmQgZG9pbmcgYSBxdWljaw0KPj4+Pj4+PnN0cmluZyBz ZWFyY2ggZm9yIFJQSCBpcyBmYXN0LiAgSWYgeW91IGFyZSBkb2luZw0KPj4+PnByaW9yaXR5LCB5 b3UgbmVlZA0KPj4+Pj4+PnRvIGtlZXAgYWxsIHRoZSBwcmlvcml0eSBwcm9jZXNzaW5nIHByZXR0 eSB1bmlmb3JtLCBhbmQgcHJldHR5DQo+Pj4+Pj4+c2ltcGxlLCBvciB5b3UgdGVuZCB0byBzcGVu ZCB0b28gbXVjaCB0aW1lIGZ1dHppbmcgYXJvdW5kDQo+Pj4+ZmlndXJpbmcNCj4+Pj4+Pj5vdXQg d2hhdCB0byBkby4gIFlvdSBwdXQgYWxsIHRoZSBwcmlvcml0eSByZWxhdGVkIHN0dWZmIHRvZ2V0 aGVyLA0KPj4+Pj4+PmFuZCB1c2UgYXMgbXVjaCBjb21tb24gY29kZSBhcyBwb3NzaWJsZS4NCj4+ Pj4+Pj4NCj4+Pj4+Pj5Ccmlhbg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4+Pj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNy aXQtYm91bmNlc0BpZXRmLm9yZ10NCj4+Pj4+Pj5PbiBCZWhhbGYNCj4+Pj4+Pj4+T2YgSGFubmVz IFRzY2hvZmVuaWcNCj4+Pj4+Pj4+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwNiwgMjAwOSA4OjQx IEFNDQo+Pj4+Pj4+PlRvOiAnSGFubmVzIFRzY2hvZmVuaWcnOyAnSmFuZXQgUCBHdW5uJw0KPj4+ Pj4+Pj5DYzogVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7ICdFQ1JJVCc7IGVj cml0LQ0KPj4+Pj4+Pj5ib3VuY2VzQGlldGYub3JnDQo+Pj4+Pj4+PlN1YmplY3Q6IFtFY3JpdF0g UlBIDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5PdmVyIGx1bmNoIEkgd2FzIGFsc28gdGhpbmtpbmcgaG93 IGFuIG91dGJvdW5kIHByb3h5IHdvdWxkDQo+Pj4+PmltcGxlbWVudA0KPj4+Pj4+Pj5zb21lIG9m IHRoZSBlbWVyZ2VuY3kgcHJvY2VkdXJlcy4gSGVyZSBhcmUgc29tZSB0aG91Z2h0czoNCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+Ly8gUHJvY2VzcyBpbmNvbWluZyBtZXNzYWdlDQo+ Pj4+Pj4+PlBhcnNlKG1zZyk7DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4vLyBTSVAgSU5WSVRFIHdpdGhv dXQgU2VydmljZSBVUk4NCj4+Pj4+Pj4+Ly8gbGVnYWN5IGRldmljZXMNCj4+Pj4+Pj4+SWYgKHJl Y29nbml6ZS1kaWFsc3RyaW5nKG1zZyk9PVRSVUUpIHsgIC8vIHdlIGdvdCBhbiBlbWVyZ2VuY3kN Cj4+Pj4+Pj4+Y2FsbCBnb2luZyBvbiAgZW1lcmdlbmN5PVRSVUU7ICBpZiAoZGlhbHN0cmluZyht c2cpID09IDkxMSkNCj4+Pj4+Pj4+c2VydmljZVVSTj11cm46c2VydmljZTpzb3M7IH0gZWxzZSBp Zg0KPj4+Pj4+Pj4ocmVjb2duaXplLXNlcnZpY2VVUk4obXNnKT09VFJVRSkgeyAgLy8gb2guIEEg dXBkYXRlZA0KPj4+PmRldmljZSB0aGF0DQo+Pj4+Pj4+PmhhcyBhIHNlcnZpY2UgVVJOIGF0dGFj aGVkIHRvIHRoZQ0KPj4+Pj5jYWxsDQo+Pj4+Pj4+PnNlcnZpY2VVUk49cmV0cmlldmVfU2Vydmlj ZVVSTihtc2cpOw0KPj4+Pj4+Pj5lbWVyZ2VuY3k9VFJVRTsNCj4+Pj4+Pj4+fSBlbHNlIHsNCj4+ Pj4+Pj4+Ly8gc3RhbmRhcmQgU0lQIG1lc3NhZ2UNCj4+Pj4+Pj4+Ly8gcmVndWxhciBwcm9jZXNz aW5nDQo+Pj4+Pj4+PnByb2Nlc3MobXNnKTsNCj4+Pj4+Pj4+ZW1lcmdlbmN5PUZBTFNFOw0KPj4+ Pj4+Pj59DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5JZiAoZW1lcmdlbmN5ID09IFRSVUUpIHsNCj4+Pj4+ Pj4+ICAvLyBtYWtlIHN1cmUgdGhhdCB0aGUgZW1lcmdlbmN5IGNhbGwgZG9lcyBub3QgZ2V0DQo+ Pj4+ZHJvcHBlZCBvbiB0aGUNCj4+Pj4+Pj4+Zmxvb3INCj4+Pj4+Pj4+ICAvLyBza2lwIGF1dGhv cml6YXRpb24gZmFpbHVyZXMNCj4+Pj4+Pj4+ICAvLyBnaXZlIHRoZSBjYWxsIGEgc3BlY2lhbCB0 cmVhdG1lbnQNCj4+Pj4+Pj4+ICBsb3RzLW9mLWNvZGUtaGVyZSgpOw0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+ICAvLyB0cmlnZ2VyIGFsbCB0aGUgUW9TIHNpZ25hbGluZyB5b3UgaGF2ZSBpbiB0aGUNCj4+ Pj5uZXR3b3JrIHRvIG1ha2UNCj4+Pj4+Pj4+SmFtZXMgaGFwcHkNCj4+Pj4+Pj4+ICB0cmlnZ2Vy LXFvcygpOw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAvLyBxdWVyeSBsb2NhdGlvbg0KPj4+Pj4+Pj4g IGxvY2F0aW9uPXJldHJpZXZlLWxvY2F0aW9uKCk7DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gIC8vIGRl dGVybWluZSBuZXh0IGhvcA0KPj4+Pj4+Pj4gIG5leHQtaG9wPWxvc3QobG9jYXRpb24sIHNlcnZp Y2VVUk4pDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gIC8vIGF0dGFjaCBSUEggbWFya2luZyB0byBvdXRn b2luZyBtc2cgdG8gbWFrZSBKYW1lcyBhbmQNCj4+Pj4+Pj5LZWl0aCBoYXBweQ0KPj4+Pj4+Pj4g IG1zZz1hZGQobXNnLCBSUEgpOw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICBzZW5kKG1zZywgbmV4dC1o b3ApOw0KPj4+Pj4+Pj59DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5JZiAoKHJwaC1wcmVzZW50KG1zZykg PT0gVFJVRSkgJiYgKGVtZXJnZW5jeSA9PSBUUlVFKSkgew0KPj4+Pj4+Pj4gIC8vIGFsbCB0aGUg ZW1lcmdlbmN5IHJlbGF0ZWQgcHJvY2Vzc2luZyBkb25lIGFscmVhZHkgdXBmcm9udA0KPj4+Pj4+ Pj4gIC8vIGhlbmNlIEkgbG9nIHNvbWV0aGluZy4NCj4+Pj4+Pj4+ICBsb2coUlBIX1dBU19QUkVT RU5UX0pVSFUpOw0KPj4+Pj4+Pj59IGVsc2UgaWYgKChycGgtcHJlc2VudChtc2cpID09IFRSVUUp ICYmIChlbWVyZ2VuY3kgPT0NCj4+Pj5GQUxTRSkpIHsNCj4+Pj4+Pj4+Ly8gdGhpcyBpcyBub3Qg YW4gZW1lcmdlbmN5IGNhbGwgIC8vIHRoaXMgaXMgc29tZXRoaW5nDQo+Pj4+bGlrZSBHRVRTDQo+ Pj4+Pj4+PnJlc3VsdD1zcGVjaWFsLWF1dGhvcml6YXRpb24tcHJvY2VkdXJlKHVzZXIpOw0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+aWYgKHJlc3VsdCA9PSBBVVRIT1JJWkVEKSB7DQo+Pj4+Pj4+PiAgIC8v IGRvIHNvbWUgcHJpb3JpdHkgJiBwcmVlbXB0aW9uIHRoaW5nIGhlcmUuDQo+Pj4+Pj4+PiAgIC8v IHRyaWdnZXIgYWxsIHRoZSBRb1MgeW91IGhhdmUNCj4+Pj4+Pj4+ICAgbG90cy1vZi1jb2RlLWhl cmUoKTsNCj4+Pj4+Pj4+fSBlbHNlIHsNCj4+Pj4+Pj4+ICAgbG9nKCJOT1QgQVVUSE9SSVpFRDsg ZG9uJ3QgRG9TIG15IG5ldHdvcmsiKTsgIH0gfSBlbHNlIHsgIC8vDQo+Pj4+Pj4+PmRvbid0IG5l ZWQgdG9kbyBhbnkgUlBIIHByb2Nlc3NpbmcgIC8vIHRoaXMgaW5jbHVkZXMgdGhlIGNhc2UNCj4+ Pj4+Pj4+d2hlcmUgdGhlIGNhbGwgd2FzIGFuIGVtZXJnZW5jeSBjYWxsIGJ1dCB0aGUgUlBIDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4vLyBtYXJraW5nIHdhcyBub3QgdGhlcmUuDQo+Pj4+Pj4+Pm5vdGhp bmcoKTsNCj4+Pj4+Pj4+fQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+Q2lhbw0KPj4+Pj4+Pj5IYW5uZXMNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+Pj4+Pj5CZWhhbGYgT2YgSGFubmVz IFRzY2hvZmVuaWcNCj4+Pj4+Pj4+PlNlbnQ6IDA2IEZlYnJ1YXJ5LCAyMDA5IDE1OjA3DQo+Pj4+ Pj4+Pj5UbzogJ0phbmV0IFAgR3VubicNCj4+Pj4+Pj4+PkNjOiAnRUNSSVQnOyBlY3JpdC1ib3Vu Y2VzQGlldGYub3JnOyBUc2Nob2ZlbmlnLEhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+RkkvRXNwb28p DQo+Pj4+Pj4+Pj5TdWJqZWN0OiBSZTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsIEludGVyaW0gTWVl dGluZzogDQo+QWdlbmRhIChSUEgpDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PldobyB3b3VsZCBkZWZp bmUgc29tZXRoaW5nIHRoYXQgY291bGQgcHJldmVudCBEb1MgcHJvYmxlbXM/DQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiAgICAgICAgIEZyb206IEphbmV0IFAgR3VubiBbbWFpbHRvOmpndW5uNkBjc2MuY29t XQ0KPj4+Pj4+Pj4+ICAgICAgICAgU2VudDogMDYgRmVicnVhcnksIDIwMDkgMTQ6MTENCj4+Pj4+ Pj4+PiAgICAgICAgIFRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+Pj4+ICAgICAgICAgQ2M6 ICdCcmlhbiBSb3Nlbic7ICdEUkFHRSwgS2VpdGggKEtlaXRoKSc7ICdFQ1JJVCc7DQo+Pj4+Pj4+ Pj5lY3JpdC1ib3VuY2VzQGlldGYub3JnOyBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0Vz cG9vKTsNCj4+Pj4+J0phbWVzDQo+Pj4+Pj4+Pj5NLiBQb2xrJw0KPj4+Pj4+Pj4+ICAgICAgICAg U3ViamVjdDogUmU6IFtFY3JpdF0gRUNSSVQgVmlydHVhbCBJbnRlcmltDQo+Pj4+TWVldGluZzog QWdlbmRhIChSUEgpDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g ICAgICAgICBCdXQgdGhlcmUgaXMgbm90aGluZyBJTiBSRkM0NDEyIHRoYXQgc3BlY2lmaWNhbGx5 DQo+Pj4+Pj4+YWRkcmVzc2VzIGhvdyB0bw0KPj4+Pj4+Pj4+cHJldmVudCBhbnkgcGFydGljdWxh ciBuYW1lc3BhY2UgYmVpbmcgdXNlZCBmb3IgRG9TLiAgDQo+QW55b25lL2FueQ0KPj4+Pj5VQQ0K Pj4+Pj4+Pj4+Y2FuIEFUVEVNUFQgdG8gaW52b2tlIHByaW9yaXR5IHRyZWF0bWVudCBieSBhdHRh Y2hpbmcgUlBILiAgRm9yDQo+Pj4+PmFsbA0KPj4+Pj4+Pj4+b2YgdGhlIDQ0MTIgbmFtZXNwYWNl cywgYXMgd2l0aCB0aGUgbmV3IHByb3Bvc2VkIG5hbWVzcGFjZSwgdGhlDQo+Pj4+Pj4+Pj5tZWNo YW5pc21zIGZvciBwcmV2ZW50aW5nIERvUyBhcmUgbm90IHNwZWNpZmllZCBpbiB0aGUNCj4+Pj4+ Pj5kb2N1bWVudCB0aGF0DQo+Pj4+Pj4+Pj5kZWZpbmVzIHRoZSBuYW1lc3BhY2UuDQo+Pj4+Pj4+ Pj5UaGV5IGFyZS93aWxsIGJlIHNwZWNpZmllZCBlbHNld2hlcmUuDQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiAgICAgICAgIEphbmV0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAgICAgIFRoaXMgaXMg YSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4+Pj4+PnJl Y2lwaWVudCwNCj4+Pj4+Pj4+PnBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5k bHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZg0KPj4+Pj50aGUNCj4+Pj4+Pj4+Pm1pc3Rha2UgaW4g ZGVsaXZlcnkuDQo+Pj4+Pj4+Pj4gICAgICAgICBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQs IHRoaXMgZS1tYWlsIHNoYWxsIG5vdA0KPj4+Pj4+Pm9wZXJhdGUgdG8gYmluZA0KPj4+Pj4+Pj4+ Q1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhw bGljaXQNCj4+Pj4+Pj4+PndyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2 ZSBleHByZXNzbHkgcGVybWl0dGluZw0KPj4+Pj50aGUNCj4+Pj4+Pj4+PnVzZSBvZiBlLW1haWwg Zm9yIHN1Y2ggcHVycG9zZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgZWNyaXQtYm91 bmNlc0BpZXRmLm9yZyB3cm90ZSBvbiAwMi8wNi8yMDA5IA0KPjA0OjIxOjUxIEFNOg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IEhpIEphbWVzLA0KPj4+Pj4+Pj4+ICAgICAgICAgPg0K Pj4+Pj4+Pj4+ICAgICAgICAgPiBJIGhhdmUgcmVhZCBSRkMgNDQxMiBhbmQgYWxzbyB0aGUgR0VU Uy9NTFBQIElFVEYNCj4+Pj4+Pj5kb2N1bWVudHMuIFdoYXQgSQ0KPj4+Pj4+Pj4+d291bGQNCj4+ Pj4+Pj4+PiAgICAgICAgID4gbGlrZSB0byBwb2ludCBvdXQgaXMgdGhhdCB0aGVyZSBpcyBtb3Jl IHRoYW4ganVzdCBhDQo+Pj4+Pj4+aGVhZGVyIGFuZA0KPj4+Pj4+Pj4+dmFsdWVzIHdpdGhpbg0K Pj4+Pj4+Pj4+ICAgICAgICAgPiB0aGUgaGVhZGVyIHRoYXQgaGF2ZSB0byBiZSBjb25zaWRlcmVk IGluIG9yZGVyIHRvDQo+Pj4+Pj4+bWFrZSBhIGp1ZGdlbWVudA0KPj4+Pj4+Pj4+b2Ygd2hhdA0K Pj4+Pj4+Pj4+ICAgICAgICAgPiBpcyBhcHByb3ByaWF0ZSBhbmQgd2hhdCBpc24ndC4gVGhlcmUg aXMgYW4NCj4+Pj4+Pj5hcmNoaXRlY3R1cmFsIHF1ZXN0aW9uDQo+Pj4+Pj4+Pj5hbmQNCj4+Pj4+ Pj4+PiAgICAgICAgID4gd2hldGhlciB0aGUgZW52aXJvbm1lbnQgd2UgYXJlIHVzaW5nIHRoZSBz dHVmZiBpcw0KPj4+Pj4+PmluZGVlZCBwcm92aWRpbmcNCj4+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4+ ICAgICAgICAgPiBwcm9wZXJ0aWVzIHlvdSBuZWVkIGZvciB0aGUgc29sdXRpb24gdG8gYmUNCj4+ Pj5hcHByb3ByaWF0ZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+PiAgICAgICAgID4g TGV0IG1lIGRlc2NyaWJlIGluIG1vcmUgZGV0YWlsIHdoYXQgSSBtZWFudCAoYW5kDQo+Pj4+Pj4+ cGxlYXNlIGNvcnJlY3QgbWUNCj4+Pj4+Pj4+PmlmIEkgYW0NCj4+Pj4+Pj4+PiAgICAgICAgID4g d3JvbmcpLg0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiBHZXR0aW5n IHByaW9yaXR5IGZvciBTSVAgcmVxdWVzdHMgd2hlbiB1c2luZyBhIEdFVFMNCj4+Pj4+Pj5hbGlr ZSBzY2VuYXJpbw0KPj4+Pj4+Pj4+bWVhbnMNCj4+Pj4+Pj4+PiAgICAgICAgID4gdGhhdCB0aGUg ZW50aXR5IHRoYXQgaXNzdWVzIHRoZSByZXF1ZXN0IGlzIHNwZWNpYWxseQ0KPj4+Pj4+PmF1dGhv cml6ZWQNCj4+Pj4+Pj4+PnNpbmNlDQo+Pj4+Pj4+Pj4gICAgICAgICA+IG90aGVyd2lzZSB5b3Ug aW50cm9kdWNlIGEgbmljZSBkZW5pYWwgb2YNCj4+Pj5zZXJ2aWNlIGF0dGFjay4gVGhpcw0KPj4+ Pj4+Pj4+YXV0aG9yaXphdGlvbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiBpcyB0aWVkIHRvIHRoZSBl bnRpdHkgdGhhdCBtYWtlcyB0aGUgcmVxdWVzdC4gRm9yDQo+Pj4+Pj4+ZXhhbXBsZSwgdGhlDQo+ Pj4+Pj4+Pj5wZXJzb24gaXMNCj4+Pj4+Pj4+PiAgICAgICAgID4gd29ya2luZyBmb3IgdGhlIGdv dmVybm1lbnQgYW5kIGhhcyBzcGVjaWFsIHJpZ2h0cy4NCj4+Pj4+Pj4+PkphbWVzIEJvbmQgYXMg YSAobm90IHNvKQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBzZWNyZXQgYWdlbnQgbWlnaHQgaGF2ZSB0 aGVzZSByaWdodHMuDQo+Pj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IFRo ZSBlbWVyZ2VuY3kgc2VydmljZXMgY2FzZQ0KPj4+PihjaXRpemVuLXRvLWF1dGhvcml0eSkgaXMg YSBiaXQNCj4+Pj4+Pj4+PmRpZmZlcmVudCBhcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGVyZSBh cmVuJ3QgcmVhbGx5IHNwZWNpYWwgcmlnaHRzIHdpdGggcmVzcGVjdCB0bw0KPj4+Pj4+PmF1dGhv cml6YXRpb24NCj4+Pj4+Pj4+PnRpZWQgdG8NCj4+Pj4+Pj4+PiAgICAgICAgID4gaW5kaXZpZHVh bHMuIEluc3RlYWQsIHRoZSBmYWN0IHRoYXQgc29tZXRoaW5nIGlzIGFuDQo+Pj4+Pj4+ZW1lcmdl bmN5IGlzDQo+Pj4+Pj4+Pj5wdXJlbHkgYQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBqdWRnZW1lbnQg b2YgdGhlIGh1bWFuIHRoYXQgZGlhbHMgYSBzcGVjaWFsIG51bWJlci4NCj4+Pj4+Pj4+PlRvIGRl YWwgd2l0aCBmcmF1ZCwgd2UNCj4+Pj4+Pj4+PiAgICAgICAgID4gZGlzY3Vzc2VkIGluIHRoZSBn cm91cCBvbiB3aGF0IHdlIGNhbiBhY3R1YWxseSBkbyB0bw0KPj4+Pj4+PmVuc3VyZSB0aGF0DQo+ Pj4+Pj4+Pj5lbmQgdXNlcnMNCj4+Pj4+Pj4+PiAgICAgICAgID4gZG8gbm90IGJ5cGFzcyBzZWN1 cml0eSBwcm9jZWR1cmVzIChzdWNoIGFzDQo+Pj4+Pj4+YXV0aG9yaXphdGlvbiBjaGVja3MsDQo+ Pj4+Pj4+Pj5jaGFyZ2luZw0KPj4+Pj4+Pj4+ICAgICAgICAgPiBhbmQgc28gb24pLiBQYXJ0IG9m IHRoaXMgaW52ZXN0aWdhdGlvbiB3YXMNCj4+Pj50aGUgcHVibGljYXRpb24gb2YNCj4+Pj4+Pj4+ PiAgICAgICAgID4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNTA2OS50eHQgdGhhdCBhbHNv DQo+Pj4+ZGVzY3JpYmVzIHRoaXMNCj4+Pj4+Pj4+Pmlzc3VlLg0KPj4+Pj4+Pj4+ICAgICAgICAg Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiBTbywgaW1hZ2luZSB0aGUgaW1wbGVtZW50YXRpb24gb2Yg YSBTSVAgDQo+cHJveHkgKGFuZCB3ZQ0KPj4+Pj4+PmltcGxlbWVudGVkDQo+Pj4+Pj4+Pj50aGF0 DQo+Pj4+Pj4+Pj4gICAgICAgICA+IHN0dWZmKSB0aGF0IHJlY2VpdmVzIGEgY2FsbCB0aGF0IGNv bnRhaW5zIGEgU2VydmljZQ0KPj4+Pj4+PlVSTi4gVGhlIGNvZGUNCj4+Pj4+Pj4+PmJyYW5jaGVz DQo+Pj4+Pj4+Pj4gICAgICAgICA+IGludG8gYSBzcGVjaWFsIG1vZGUgd2hlcmUgZXZlcnl0aGlu ZyBpcyBkb25lDQo+Pj4+c28gdGhhdCB0aGUgY2FsbA0KPj4+Pj4+Pj4+cmVjZWl2ZXMNCj4+Pj4+ Pj4+PiAgICAgICAgID4gYXBwcm9wcmlhdGUgdHJlYXRtZW50IGFuZCBkb2VzIG5vdCBnZXQgDQo+ ZHJvcHBlZCBvbiB0aGUNCj4+Pj4+Pj5mbG9vci4gVGhlDQo+Pj4+Pj4+Pj53YXkgaG93IHRoZQ0K Pj4+Pj4+Pj4+ICAgICAgICAgPiBTZXJ2aWNlIFVSTiBpcyBwbGFjZWQgaW4gdGhlIG1lc3NhZ2Ug DQo+ZW5zdXJlcyB0aGF0IHRoZQ0KPj4+Pj4+PmNhbGwgY2Fubm90DQo+Pj4+Pj4+Pj5nbyB0byBt eQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBmcmllbmQgKGluc3RlYWQgb2YgdGhlIFBTQVApIHVubGVz cyB0aGUgZW5kIGhvc3QgcmFuDQo+Pj4+Pj4+TG9TVCBhbHJlYWR5Lg0KPj4+Pj4+Pj4+SW4gdGhl DQo+Pj4+Pj4+Pj4gICAgICAgICA+IGxhdHRlciBjYXNlLCB3ZSBkaXNjdXNzZWQgdGhpcyBhbHNv IG9uIHRoZSANCj5saXN0IGZvciBhDQo+Pj4+Pj4+d2hpbGUgYW5kDQo+Pj4+Pj4+Pj5SaWNoYXJk IGV2ZW4NCj4+Pj4+Pj4+PiAgICAgICAgID4gd3JvdGUgYSBkcmFmdCBhYm91dCBpdCBpbiB0aGUg Y29udGV4dCBvZiB0aGUNCj4+Pj5sb2NhdGlvbiBoaWRpbmcNCj4+Pj4+Pj4+PnRvcGljLCB3ZSBz YWlkDQo+Pj4+Pj4+Pj4gICAgICAgICA+IHRoYXQgdGhlIHByb3h5IHdvdWxkIGhhdmUgdG8gcnVu IExvU1QgaWYgaGUNCj4+Pj5jYXJlcyBhYm91dCBhDQo+Pj4+Pj4+Pj5wb3RlbnRpYWwNCj4+Pj4+ Pj4+PiAgICAgICAgID4gZnJhdWR1bGVudCB1c2FnZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4NCj4+ Pj4+Pj4+PiAgICAgICAgID4gU28sIHdoYXQgZG8gd2UgbmVlZCB0b2RvIGluIG9yZGVyIHRvIHBy b3ZpZGUNCj4+Pj5zZWN1cmUgUkZDIDQ0MTINCj4+Pj4+Pj4+PmZ1bmN0aW9uYWxpdHkNCj4+Pj4+ Pj4+PiAgICAgICAgID4gaW4gb3VyIGNvbnRleHQ/DQo+Pj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+ Pj4+Pj4gICAgICAgICA+IERvIHlvdSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHRleHQgaW4NCj4+ Pj4+Pj4+PiAgICAgICAgID4NCj4+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtZWNyaXQtbG9jYWwtZW1lcg0KPj4+Pj4+Pj4+Z2VuY3ktcnBoLW5h bQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiBlc3BhY2UtMDAudHh0IHJlZmxlY3RzIGFueSBvZiB0aGUN Cj4+Pj5hYm92ZS1kZXNjcmliZWQgaXNzdWVzOg0KPj4+Pj4+Pj4+ICAgICAgICAgPiAiDQo+Pj4+ Pj4+Pj4gICAgICAgICA+ICAgIFRoZSBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IGFwcGx5 IA0KPnRvIFJGQyA0NDEyDQo+Pj4+Pj4+Pj5bUkZDNDQxMl0NCj4+Pj4+Pj4+PmFwcGx5DQo+Pj4+ Pj4+Pj4gICAgICAgICA+ICAgIGhlcmUuICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgbm8gbmV3 IHNlY3VyaXR5DQo+Pj4+Pj4+Pj5pc3N1ZXMgcmVsYXRpdmUNCj4+Pj4+Pj4+PnRvDQo+Pj4+Pj4+ Pj4gICAgICAgICA+ICAgIFJGQyA0NDEyLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiAiDQo+Pj4+Pj4+ Pj4gICAgICAgICA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IEZyb20gdmFyaW91cyBkaXNjdXNzaW9u cyBpbiBHRU9QUklWIEkgcmVjYWxsDQo+Pj4+dGhhdCB5b3UgYXJlDQo+Pj4+Pj4+Pj5zdXBlci1z ZW5zaXRpdmUNCj4+Pj4+Pj4+PiAgICAgICAgID4gcmVnYXJkaW5nIHNlY3VyaXR5IGFuZCBwcml2 YWN5LiBGb3Igc29tZSByZWFzb25zIHlvdQ0KPj4+Pj4+PmRvbid0IHNlZW0gdG8NCj4+Pj4+Pj4+ PmhhdmUgdGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+IHNhbWUgY29uY2VybnMgaGVyZS4gSSB3b3Vs ZCBsaWtlIHRvDQo+Pj4+dW5kZXJzdGFuZCB5b3VyIHJlYXNvbmluZy4NCj4+Pj4+Pj4+PiAgICAg ICAgID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gUGxlYXNlIGFsc28gZG8gbWUgYW5vdGhlciBmYXZv cjogRG9uJ3QgYWx3YXlzIHNheQ0KPj4+Pj4+PnRoYXQgSSBkb24ndA0KPj4+Pj4+Pj4+dW5kZXJz dGFuZA0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGUgc3ViamVjdC4gRXZlbiBpZiB0aGF0IHdvdWxk IGJlIHRoZSBjYXNlIGl0IGlzbid0DQo+Pj4+Pj4+cGFydGljdWxhcg0KPj4+Pj4+Pj4+ZmFpciBn aXZlbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGF0IGRpZmZlcmVudCBmb2xrcyBoYWQgdG8gZWR1 Y2F0ZSB5b3Ugb24gb3RoZXINCj4+Pj4+Pj50b3BpY3MgaW4gdGhlDQo+Pj4+Pj4+Pj5wYXN0IGFz IHdlbGwuDQo+Pj4+Pj4+Pj4gICAgICAgICA+IEFkZGl0aW9uYWxseSwgaWYgeW91IGxpc3RlbiB0 byB0aGUgYXVkaW8gcmVjb3JkaW5ncw0KPj4+Pj4+PnRoZW4geW91IHdpbGwNCj4+Pj4+Pj4+Pm5v dGljZQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiB0aGF0IEhlbm5pbmcsIFRlZCwgYW5kIEpvbiBkbyBu b3Qgc2VlbSB0byB1bmRlcnN0YW5kDQo+Pj4+Pj4+dGhlIGlzc3VlDQo+Pj4+Pj4+Pj5laXRoZXIg YXMNCj4+Pj4+Pj4+PiAgICAgICAgID4gdGhleSBoYXZlIHJhaXNlZCBzaW1pbGFyIGlzc3VlcyBk dXJpbmcgdGhlDQo+Pj4+RjJGIG1lZXRpbmdzLg0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+ Pj4+ICAgICAgICAgPiBDaWFvDQo+Pj4+Pj4+Pj4gICAgICAgICA+IEhhbm5lcw0KPj4+Pj4+Pj4+ ICAgICAgICAgPg0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+SGFu bmVzIC0gSSBiZWxpZXZlIGl0IGlzIHlvdSB3aG8gZG8gbm90IHVuZGVyc3RhbmQNCj4+Pj4+Pj5S RkMgNDQxMiAtLQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+YW5kIG1hbnkgb2YgdXMgYXJlIHRyeWlu ZyB0byBnZXQgdGhhdA0KPj4+PnRocm91Z2ggdG8geW91LCBidXQgeW91DQo+Pj4+Pj4+Pj4gICAg ICAgICA+ID5kb24ndCBzZWVtIHRvIHdhbnQgdG8gbGlzdGVuL3JlYWQuDQo+Pj4+Pj4+Pj4gICAg ICAgICA+ID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPlJGQyA0NDEyIGlzICpmb3IqIHByaW9yaXR5 IG1hcmtpbmcgU0lQIHJlcXVlc3RzLA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+Pj4g ICAgICAgICA+ID5PbmUgdXNlIGlzIEdFVFMuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+ Pj4+PiAgICAgICAgID4gPk9uZSB1c2UgaXMgTUxQUC4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0K Pj4+Pj4+Pj4+ICAgICAgICAgPiA+VGhlc2UgZXhhbXBsZXMgYXJlIGluIFJGQyA0NDEyIGJlY2F1 c2UgdGhlcmUNCj4+Pj53ZXJlIHNwZWNpZmljDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3Bh Y2VzIGJlaW5nIGNyZWF0ZWQgZm9yIHRoZSBJQU5BIHNlY3Rpb24gb2YNCj4+Pj4+Pj50aGF0IGRv Y3VtZW50Lg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5SZWFk aW5nIHRoZSB3aG9sZSBkb2N1bWVudCwgeW91IHdpbGwgc2VlDQo+Pj4+dGhhdCBSUEggY2FuIGJl DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5zcGVjaWZpZWQgZm9yIG90aGVyIHVzZXMgdGhhbiBHRVRT IG9yIE1MUFANCj4+Pj5zcGVjaWZpY2FsbHkuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4NCj4+Pj4+ Pj4+PiAgICAgICAgID4gPkkga25ldyB3aGVuIEkgd3JvdGUgUkZDIDQ0MTIgdGhhdCBvbmUgZGF5 IHdlDQo+Pj4+d291bGQgc3BlY2lmeSBhDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3BhY2Ug Zm9yIEVDUklUICh0aGUgImVzbmV0IiBuYW1lc3BhY2UNCj4+Pj5ub3cpIC0tIGJ1dCBJIGFsc28N Cj4+Pj4+Pj4+PiAgICAgICAgID4gPmtuZXcgaXQgd2FzIHByZW1hdHVyZSBmb3IgUkZDIDQ0MTIg dG8NCj4+Pj5pbmNvcnBvcmF0ZSB0aGF0DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5uYW1lc3BhY2Us IHRoYXQgYSBmdXR1cmUgZG9jIHRvIFJGQyA0NDEyDQo+Pj4+d291bGQgaGF2ZSB0byBiZQ0KPj4+ Pj4+Pj4+ICAgICAgICAgPiA+d3JpdHRlbiB0byBkbyB0aGlzLiBCcmlhbiBhbmQgSSB0YWxrZWQg YWJvdXQNCj4+Pj50aGlzIGF0IHRoZQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+b3JpZ2luYWwgTkVO QSBtZWV0aW5nIHRoYXQgY3JlYXRlZCB0aGUgSVAgV0dzIHRoZXJlDQo+Pj4+Pj4+KGluIEF1Z3Vz dA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+b2YgMDMpLiAgV2UgYm90aCBhZ3JlZWQgd2Ugc2hvdWxk IHdhaXQgdW50aWwgaXQgd2FzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5hcHByb3ByaWF0ZSB0byB0 aGUgd29yayBpbiB0aGUgSUVURiB0bw0KPj4+PnN1Ym1pdCB0aGlzIGRvY3VtZW50DQo+Pj4+Pj4+ Pj4gICAgICAgICA+ID50aGF0IGlzIG5vdw0KPj4+Pj4+Pj4+ICAgICAgICAgPg0KPj4+Pj4+Pj4+ Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZWNyaXQtbA0K Pm9jYWwtZW1lcg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+Z2VuY3ktcnBoLW5hbWVzcGFjZS0wMC50 eHQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+WWV0LCB5b3Ug c2VlbSB0byB3YW50IHRvIHVzZSBzb21lIGFkZGl0aW9uYWwNCj4+Pj5tZWNoYW5pc20gdG8NCj4+ Pj4+Pj4+PiAgICAgICAgID4gPmluZGljYXRlIHByaW9yaXR5IG9mIGEgY2FsbCBpbiBTSVAuICBU aGF0DQo+Pj4+bWVhbnMgeW91IHdhbnQgdG8NCj4+Pj4+Pj4+PiAgICAgICAgID4gPmludHJvZHVj ZSBhIHNlY29uZCB3YXkgdG8gYWNjb21wbGlzaCB0aGlzIGluIFNJUC4NCj4+Pj4+Pj4+PldoeSBk byB5b3UNCj4+Pj4+Pj4+PiAgICAgICAgID4gPndhbnQgdG8gcHJvbW90ZSBhIHNlcGFyYXRlIHdh eSB0byBkbyBzb21ldGhpbmcgU0lQDQo+Pj4+Pj4+aGFzIGFscmVhZHkNCj4+Pj4+Pj4+PiAgICAg ICAgID4gPmRlZmluZWQ/IFRoYXQgd2lsbCBjYXVzZSBpbnRlcm9wZXJhYmlsaXR5IA0KPmlzc3Vl cyBhbmQNCj4+Pj4+Pj53ZSBib3RoIGtub3cNCj4+Pj4+Pj4+PnRoYXQuDQo+Pj4+Pj4+Pj4gICAg ICAgICA+ID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPllvdSd2ZSBzYWlkIHRvIG1lIChhbmQgb3Ro ZXJzKSB0aGF0IHlvdQ0KPj4+PmJlbGlldmUgUlBIIGlzIGp1c3QNCj4+Pj4+Pj4+PiAgICAgICAg ID4gPmFub3RoZXIgd2F5IHRvIGFjY29tcGxpc2ggd2hhdCBzb3Mgb3IgYSBVUkkgY2FuDQo+Pj4+ Pj4+aW5kaWNhdGUgLSBhbmQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPnlvdSdyZSB3cm9uZy4gIFlv dXIgd2F5IHdvdWxkIGJlDQo+Pj4+X3RoZV9zZWNvbmRfd2F5X3RvX2RvX2l0LA0KPj4+Pj4+Pj4+ ICAgICAgICAgPiA+YmVjYXVzZSBTSVAgYWxyZWFkeSBjb25zaWRlcnMgUlBIIHRvIGJlDQo+Pj4+ KnRoZSp3YXkqIHRvIHByaW9yaXR5DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5tYXJrIFNJUCByZXF1 ZXN0cy4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+SWYgeW91 IGRvbid0IGJlbGlldmUgbWUgKG5vIGNvbW1lbnQpLCB0aGVuDQo+Pj4+d2h5IGRvIHlvdSBub3QN Cj4+Pj4+Pj4+PiAgICAgICAgID4gPmJlbGlldmUgdGhlIFNJUCBXRyBjaGFpciAod2hvIGtub3dz IG1vcmUNCj4+Pj5hYm91dCBTSVAgdGhhbiBib3RoDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5vZiB1 cykgLSB3aG8sIG9uIHRoaXMgdGhyZWFkLCBoYXMgYWdhaW4gc2FpZA0KPj4+PnRvIHlvdSAiUkZD IDQ0MTINCj4+Pj4+Pj4+PiAgICAgICAgID4gPihSUEgpIGlzIHRoZSBTSVAgbWVjaGFuaXNtIHRv IHByaW9yaXR5IG1hcmsNCj4+Pj5TSVAgcmVxdWVzdHMiPw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+ DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5GdXJ0aGVyLCBJIGJlbGlldmUgaXQgaXMgaW5hcHByb3By aWF0ZSB0bw0KPj4+PnByb2hpYml0IGVuZHBvaW50cw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+ZnJv bSBiZWluZyBhYmxlIHRvIHNldCB0aGUgZXNuZXQgbmFtZXNwYWNlLg0KPj4+PkkgYWJzb2x1dGVs eQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+YmVsaWV2ZSBpdCB3aWxsIG5vdCBiZSBuZWVkZWQgbW9z dCBvZiB0aGUNCj4+Pj50aW1lLCBidXQgSSBiZWxpZXZlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5p ZiBzb21lb25lIGRvZXMgZmluZCBhIHZhbGlkIHVzZSBmb3INCj4+Pj5lbmRwb2ludHMgdG8gbWFy aw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+cHJpb3JpdHkgaW4gU0lQLCB0aGlzIElEIC0gb25jZSBp dCBoYXMNCj4+Pj5iZWNvbWUgYW4gUkZDIC0tIHdpbGwNCj4+Pj4+Pj4+PiAgICAgICAgID4gPmhh dmUgdG8gYmUgb2Jzb2xldGVkIHdpdGggYSBuZXcgUkZDIHNheWluZyANCj50aGUgZXhhY3QNCj4+ Pj4+Pj5vcHBvc2l0ZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAg PiA+KGNvbG9yIG1lIGNvbmZ1c2VkIC4uLiBvdmVyIGFuZCBvdmVyIGFnYWluKQ0KPj4+Pj4+Pj4+ ICAgICAgICAgPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5KYW1lcw0KPj4+Pj4+Pj4+ICAgICAg ICAgPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID5BdCAwMTowNSBQTSAyLzUvMjAwOSwgSGFubmVz IFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+S2VpdGgsIHBsZWFzZSB1 bmRlcnN0YW5kIHRoYXQgdGhlIHVzYWdlIA0KPm9mIFJGQyA0NDEyDQo+Pj4+Pj4+Zm9yIEdFVFMg YW5kDQo+Pj4+Pj4+Pj5mb3INCj4+Pj4+Pj4+PiAgICAgICAgID4gPj50aGUgdHlwZSBvZiBlbWVy Z2VuY3kgY2FsbCB3ZSBkaXNjdXNzIGhlcmUgaXMNCj4+Pj4+Pj5kaWZmZXJlbnQuIEp1c3QNCj4+ Pj4+Pj4+Pmxvb2tpbmcNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj5hdCB0aGUgaGVhZGVyIGFuZCB0 aGUgbmFtZSBvZiB0aGUgDQo+bmFtZXNwYWNlIGlzIGEgYml0DQo+Pj4+Pj4+Pj4gICAgICAgICA+ ID5hcnRpZmljaWFsLiBJIGhvcGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj55b3UgdW5kZXJzdGFu ZCB0aGF0Lg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPkZyb206 IERSQUdFLCBLZWl0aCAoS2VpdGgpDQo+Pj4+Pj4+Pj5bbWFpbHRvOmRyYWdlQGFsY2F0ZWwtbHVj ZW50LmNvbV0NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPlNlbnQ6IDA1IEZlYnJ1YXJ5LCAyMDA5 IDE0OjU1DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5UbzogQnJpYW4gUm9zZW47ICdIYW5uZXMg VHNjaG9mZW5pZyc7ICdKYW1lcyBNLg0KPj4+Pj4+Pj4+UG9sayc7ICdUc2Nob2ZlbmlnLA0KPj4+ Pj4+Pj4+ICAgICAgICAgPiA+PiA+SGFubmVzIChOU04gLSBGSS9Fc3BvbyknOyAnRUNSSVQnDQo+ Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFs IEludGVyaW0NCj4+Pj4+Pj4+Pk1lZXRpbmc6IEFnZW5kYSAobXkNCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+bWlzdGFrZSkNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPg0KPj4+ Pj4+Pj4+ICAgICAgICAgPiA+PiA+V2hpY2ggaXMgZXhhY3RseSB3aGF0IFJGQyA0NDEyIHNwZWNp ZmllcyBmb3IgYWxsDQo+Pj4+Pj4+bmFtZXNwYWNlcy4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+cmVnYXJkcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+ PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5LZWl0aA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+ PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcN Cj4+Pj4+Pj5bbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4+Pj4+Pj4gICAgICAg ICA+ID4+ID5PbiBCZWhhbGYNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gT2YgQnJpYW4gUm9z ZW4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw NCwgMjAwOSAxMDoxOSBQTQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBUbzogJ0hhbm5lcyBU c2Nob2ZlbmlnJzsgJ0phbWVzIE0uDQo+Pj4+UG9sayc7ICdUc2Nob2ZlbmlnLA0KPj4+Pj4+Pj4+ ICAgICAgICAgPiA+SGFubmVzIChOU04NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gLSBGSS9F c3BvbyknOyAnRUNSSVQnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFN1YmplY3Q6IFJlOiBb RWNyaXRdIEVDUklUIFZpcnR1YWwgSW50ZXJpbQ0KPj4+Pj4+Pj4+TWVldGluZzogQWdlbmRhICht eQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBtaXN0YWtlKQ0KPj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBUaGUgdmFsdWUgaXMgdGhhdCBpbiBz b21lIG5ldHdvcmtzDQo+Pj4+d2hlcmUgcHJpb3JpdHkgZm9yDQo+Pj4+Pj4+Pj4gICAgICAgICA+ ID4+ID5lbWVyZ2VuY3kgY2FsbHMNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gaXMgYXBwcm9w cmlhdGUsIGFuZCBhcHByb3ByaWF0ZQ0KPj4+PnBvbGljaW5nIG9mIG1hcmtpbmcgaXMNCj4+Pj4+ Pj4+PiAgICAgICAgID4gPmltcGxlbWVudGVkLA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBl bWVyZ2VuY3kgY2FsbHMgd2lsbCByZWNlaXZlIHJlc291cmNlIA0KPnByaW9yaXR5Lg0KPj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBOb3QgYWxsIG5l dHdvcmtzIHdvdWxkIG5lZWQgcG9saWNpbmcuICBTb21lDQo+Pj4+Pj4+d2lsbC4gIFBvbGljaW5n DQo+Pj4+Pj4+Pj5jb3VsZA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBiZSB0byBSb3V0ZSBo ZWFkZXIvUi1VUkkgY29udGVudCwgYnV0IG90aGVyDQo+Pj4+Pj4+Y3JpdGVyaWEgYXJlDQo+Pj4+ Pj4+Pj5wb3NzaWJsZS4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4NCj4+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gTm90IGFsbCBuZXR3b3JrcyB3aWxsIG5lZWQgcmVzb3VyY2UgcHJpb3JpdHkN Cj4+Pj4+Pj5mb3IgZW1lcmdlbmN5DQo+Pj4+Pj4+Pj5jYWxscy4NCj4+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gRmluZSwgaWdub3JlIHRoaXMgbWFya2luZy9uYW1lc3BhY2UuDQo+Pj4+Pj4+Pj4g ICAgICAgICA+ID4+ID4+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEJyaWFuDQo+Pj4+Pj4+ Pj4gICAgICAgICA+ID4+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4+Pj4+W21h aWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0XQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDQsIDIwMDkgNTowOSBQTQ0KPj4+Pj4+Pj4+ ICAgICAgICAgPiA+PiA+PiA+IFRvOiAnQnJpYW4gUm9zZW4nOyAnSmFtZXMgTS4gUG9sayc7DQo+ Pj4+Pj4+VHNjaG9mZW5pZywgSGFubmVzDQo+Pj4+Pj4+Pj4oTlNOIC0NCj4+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gPiBGSS9Fc3Bvbyk7ICdFQ1JJVCcNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g Pj4gPiBTdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsIEludGVyaW0NCj4+Pj4+Pj4+ Pk1lZXRpbmc6IEFnZW5kYSAobXkNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBtaXN0YWtl KQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ ID4gSSBkb24ndCBldmVuIHNlZSB0aGUgdmFsdWUgaW4gcGVybWl0dGluZyB0aGUNCj4+Pj4+Pj5l bmRwb2ludCB0b2RvDQo+Pj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBS UEggbWFya2luZy4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiBJbiBhZGRpdGlvbiB0byB0 aGUgc2VjdXJpdHkgY29uY2VybnMNCj4+Pj50aGVyZSBpcyBhbHNvIHRoZQ0KPj4+Pj4+Pj4+ICAg ICAgICAgPiA+PiA+cHJvYmxlbSB0aGF0DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gdGhl cmUgYXJlIG1vcmUgb3B0aW9ucyB0byBpbXBsZW1lbnQgd2l0aG91dA0KPj4+Pj4+PmFuIGFkZGl0 aW9uYWwNCj4+Pj4+Pj4+PnZhbHVlLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+DQo+Pj4+ Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkZyb206IEJyaWFuIFJvc2VuIA0KPlttYWlsdG86YnJA YnJpYW5yb3Nlbi5uZXRdDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPlNlbnQ6IDA1IEZl YnJ1YXJ5LCAyMDA5IDAwOjAzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPlRvOiAnSmFt ZXMgTS4gUG9sayc7ICdIYW5uZXMgVHNjaG9mZW5pZyc7DQo+Pj4+Pj4+J1RzY2hvZmVuaWcsDQo+ Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IEhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+RkkvRXNwb28pJzsgJ0VDUklUJw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiA+ID5TdWJqZWN0OiBSRTogW0Vjcml0XSBFQ1JJVCBWaXJ0dWFsDQo+Pj4+SW50ZXJpbSBNZWV0 aW5nOg0KPj4+Pj4+Pj4+QWdlbmRhIChteQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+IG1p c3Rha2UpDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+PiA+ID5IYW5uZXMNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+DQo+Pj4+Pj4+ Pj4gICAgICAgICA+ID4+ID4+ID4gPlRoaXMgbWF0Y2hlcyBteSB1bmRlcnN0YW5kaW5nDQo+Pj4+ cHJlY2lzZWx5LiAgV2Ugd2lzaCB0bw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBwZXJtaXQg ZW5kcG9pbnRzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRvIG1hcmsuIFdlIGRvIG5v dCByZXF1aXJlIGl0LCBhbmQNCj4+Pj5kb24ndCBuZWNlc3NhcmlseQ0KPj4+Pj4+Pj4+ZXhwZWN0 IGl0DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPmluIG1hbnkgKGV2ZW4NCj4+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gPiA+bW9zdCkgY2FzZXMuICBXZSBkb24ndCB3aXNoIHRvIHNlZSB0 aGUNCj4+Pj4+Pj5kb2N1bWVudCBwcm9oaWJpdA0KPj4+Pj4+Pj4+aXQuDQo+Pj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+ID4gPldlIGFsbCBzZWVtIHRvIGFncmVlIGl0IGhhcyB2YWx1ZSANCj53aXRo aW4gdGhlDQo+Pj4+Pj4+RW1lcmdlbmN5DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5TZXJ2aWNl cyBJUA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5OZXR3b3Jrcy4NCj4+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPkJyaWFuDQo+ Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ ID4gPj4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+W21haWx0bzplY3Jp dC1ib3VuY2VzQGlldGYub3JnXQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID5PbiBCZWhh bGYNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBPZiBKYW1lcyBNLiBQb2xrDQo+Pj4+ Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNCwg DQo+MjAwOSA0OjAxIFBNDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gVG86IEhhbm5l cyBUc2Nob2ZlbmlnOyBUc2Nob2ZlbmlnLA0KPj4+Pkhhbm5lcyAoTlNOIC0NCj4+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gRkkvRXNwb28pOyAnRUNSSVQnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ ID4+ID4gPj4gU3ViamVjdDogUmU6IFtFY3JpdF0gRUNSSVQgDQo+VmlydHVhbCBJbnRlcmltDQo+ Pj4+Pj4+Pj5NZWV0aW5nOg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+QWdlbmRhIChteQ0KPj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IG1pc3Rha2UpDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBBdCAwMjozNyBQTSAyLzQv MjAwOSwgSGFubmVzDQo+Pj4+VHNjaG9mZW5pZyB3cm90ZToNCj4+Pj4+Pj4+PiAgICAgICAgID4g Pj4gPj4gPiA+PiA+ID4gSmFtZXMgd3JvdGU6DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4g Pj4gPiA+PiB5b3UgYXJlIHRoZSBfbG9uZV8gdm9pY2Ugbm90DQo+Pj4+Pj4+c3VwcG9ydGluZyB0 aGlzIElELA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID4NCj4+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gPiA+PiA+TGlzdGVuaW5nIHRvIHRoZSBhdWRpbyByZWNvcmRpbmcgb2YgcGFz dA0KPj4+Pj4+Pm1lZXRpbmdzIEkNCj4+Pj4+Pj4+PmhhdmUgdG8NCj4+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+c2F5IHRoYXQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+SQ0K Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHdhcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+ PiA+PiA+ID4+ID5ub3QgdGhlIG9ubHkgcGVyc29ucyByYWlzaW5nDQo+Pj4+Y29uY2VybnMgYWJv dXQgdGhlDQo+Pj4+Pj4+Pj5kb2N1bWVudC4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+ PiA+VGhhdCB3YXMgcHJvYmFibHkgdGhlIHJlYXNvbiB3aHkgeW91DQo+Pj4+Pj4+YWdyZWVkIHRv IGxpbWl0DQo+Pj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+c2NvcGUg b2YgdGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPmRvY3VtZW50ICh3aGljaCB5 b3UgZGlkbid0IGxhdGVyIGRvKSB0bw0KPj4+Pj4+PmdldCBmb2xrcyB0bw0KPj4+Pj4+Pj4+YWdy ZWUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+dG8gbWFrZSBpdA0KPj4+Pj4+Pj4+ICAg ICAgICAgPiA+PiA+PiA+ID4+IGEgV0cNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiA+ aXRlbS4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAg PiA+PiA+PiA+ID4+IHJlLWxpc3RlbiB0byB0aGUgYXVkaW8gcGxlYXNlDQo+Pj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBUZWQncyBj b25jZXJucyB3ZXJlIGNvbnNpc3RlbnQgd2l0aCBtb3N0DQo+Pj4+Pj4+Pj4oYWxsPykgb3RoZXIN Cj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gY29uY2VybnMgLS0NCj4+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+PiB3aGljaCB3ZXJlIGJhc2VkIG9uIHRoZSBwcmVtaXNlIA0KPm9mIHdoZXRo ZXINCj4+Pj4+Pj5vciBub3QgdGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFVBQyBzaG91 bGQgYmUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiB0cnVzdGVkIHRvIGluaXRpYXRl IHRoZSBtYXJraW5nIG9uIHRoZQ0KPj4+Pj4+PklOVklURS4gIFRoZQ0KPj4+Pj4+Pj4+bW9zdA0K Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHJlY2VudCB2ZXJzaW9uIGhhcyBiYWNrZWQg b2ZmIHRoaXMNCj4+Pj50byBhICJjYW4iIC0tDQo+Pj4+Pj4+Pj5tZWFuaW5nIG5vdA0KPj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+cHJvaGliaXRlZA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ ID4+IChpLmUuLCBubyAyMTE5IHRleHQpLiAgSSBhbHNvIGJhY2tlZCBvZmYNCj4+Pj4+Pj50aGUg dGV4dCBpbg0KPj4+Pj4+Pj4+dGhlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IFNQIGRvbWFp bg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHBhcnQgdG8gImNhbiIsIHN1Y2ggdGhh dCB0aGVyZSBpcw0KPj4+Pm5vIDIxMTkgdGV4dA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+bWFu ZGF0aW5nIG9yIGV2ZW4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiByZWNvbW1lbmRp bmcgaXRzIHVzYWdlIHRoZXJlLiBJIGFsc28gZG8NCj4+Pj4+Pj5ub3QgcHJvaGliaXQNCj4+Pj4+ Pj4+Pml0cw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID51c2UsIGJhc2VkIG9uDQo+Pj4+ Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gbG9jYWwgcG9saWN5LiAgS2VpdGggaGFzIGNvbWUg DQo+Zm9yd2FyZCB3aXRoDQo+Pj4+Pj4+dGhlIHNwZWNpZmljDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiAgICAgICAgID4gPj4gPj4gPiA+PiByZXF1ZXN0IHRoYXQgbm9uLUVTSW5ldCBuZXR3b3JrcyBi ZQ0KPj4+Pj4+PmFsbG93ZWQgdG8gbWFyayBhbmQNCj4+Pj4+Pj4+PnBheQ0KPj4+Pj4+Pj4+ICAg ICAgICAgPiA+PiA+YXR0ZW50aW9uIHRvDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4g dGhpcyBwcmlvcml0eSBpbmRpY2F0aW9uIC0tIHdpdGggSU1TIGFzDQo+Pj4+Pj4+dGhlIHNwZWNp ZmljDQo+Pj4+Pj4+Pj5leGFtcGxlDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gaGUg d2lzaGVzIHRvIGhhdmUgdGhpcyB2YWxpZCBmb3IuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBXaGVyZSB0aGVyZSBpcyBubyBk aXNhZ3JlZW1lbnQsIHNhdmUgZm9yDQo+Pj4+Pj4+eW91ciByZWNlbnQNCj4+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4gPiA+cHVzaGJhY2sgLSBpcyBpbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiA+ID4+IHRoZSBFU0luZXQsIHdoaWNoIGlzIHdoZXJlIEJyaWFuDQo+Pj4+aGFzIHJlcXVlc3Rl ZCBpdCdzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPmRlZmluaXRpb24gaW4gdGhlDQo+ Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gSUVURiBvbiBiZWhhbGYgb2YgTkVOQS4gIEhl J3MgdGhlIGkzIFdHDQo+Pj4+Pj4+Y2hhaXIgd2l0aGluDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ ID4+IE5FTkEsIGFuZCBpZg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IGhlIGFza3Mg Zm9yIGl0LCBhcmUgeW91IGdvaW5nIHRvIHNheSB5b3UNCj4+Pj4+Pj5rbm93IGJldHRlcg0KPj4+ Pj4+Pj4+dGhhbiBoZT8NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+ ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPkJ0 dywgSSBub3QgZGlzYWdyZWVpbmcgd2l0aCB0aGUgZG9jdW1lbnQNCj4+Pj4+Pj5hcyBzdWNoLiBJ DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID5qdXN0IHdhbnQgdG8NCj4+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiB0aGUNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBzY29wZQ0KPj4+ Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50byBjaGFuZ2UuIFRoZSB1c2FnZSBvZiBSUEgN Cj4+Pj53aXRoaW4gdGhlIGVtZXJnZW5jeQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBzZXJ2 aWNlcyBuZXR3b3JrDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gaXMNCj4+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+PiBmaW5lDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4g PmZvciBtZS4gSSBtYXkgZ2V0IGNvbnZpbmNlZCB0byBzdGFydCB0aGUNCj4+Pj4+Pj5SUEggbWFy a2luZw0KPj4+Pj4+Pj4+ZnJvbQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID50aGUgdGhl IFZTUA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID50b3dhcmRzIHRoZSBQU0FQLiBJ IGZlZWwgdW5lYXN5IA0KPmFib3V0IHRoZQ0KPj4+Pj4+PmVuZCBob3N0DQo+Pj4+Pj4+Pj5kb2lu Zw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID50aGUgbWFya2luZy4NCj4+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHBsZWFz ZSByZWFkIHdoYXQgSSB3cm90ZSBhYm92ZSwgYW5kIHRoZW4NCj4+Pj4+Pj5yZS1yZWFkIHRoZQ0K Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+bW9zdCByZWNlbnQNCj4+Pj4+Pj4+PiAgICAgICAgID4g Pj4gPj4gPiA+PiB2ZXJzaW9uIG9mIHRoZSBJRC4gSSBkb24ndCBoYXZlIGVuZHBvaW50cw0KPj4+ Pj4+PnRoYXQgU0hPVUxEDQo+Pj4+Pj4+Pj5vcg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiBN VVNUIG1hcmsNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBhbnl0aGluZyB3cnQgUlBI LiAgSSBhbHNvIGRvbid0IHdhbnQgdG8NCj4+Pj4+Pj5wcm9oaWJpdCBpdCwNCj4+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gYmVjYXVzZSB0aGVyZQ0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ ID4+IG1pZ2h0IGJlIGNhc2VzICh0aGF0IEkgZG9uJ3Qga25vdw0KPj4+Pm9mKSBvZiB2YWxpZCB1 c2VzDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IHVuZGVyIGNlcnRhaW4NCj4+Pj4+Pj4+PiAg ICAgICAgID4gPj4gPj4gPiA+PiBjaXJjdW1zdGFuY2VzLiAgRmlndXJlIDEgaXMgdmVyeSBjbGVh cg0KPj4+Pj4+PnRoYXQgdGhlcmUgYXJlIDMNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gbmV0 d29ya2luZw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHBhcnRzIHRvIGNvbnNpZGVy DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g Pj4gPiA+PiAjMSAtIGZyb20gdGhlIGVuZHBvaW50DQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ ID4gPj4gIzIgLSB3aXRoaW4gdGhlIFZTUA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ ICMzIC0gd2l0aGluIHRoZSBFU0luZXQNCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+Pg0K Pj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRoZSBtb3N0IHJlY2VudCBJRCB2ZXJzaW9u IGhhcyAiY2FuIiBmb3INCj4+Pj4+Pj4jcyAxIGFuZCAyLA0KPj4+Pj4+Pj4+YW5kDQo+Pj4+Pj4+ Pj4gICAgICAgICA+ID4+ID4+ID4gPjIxMTkgbGFuZ3VhZ2UNCj4+Pj4+Pj4+PiAgICAgICAgID4g Pj4gPj4gPiA+PiBvZmZlcmluZyB0aG9zZSBzdXBwb3J0aW5nIHRoaXMNCj4+Pj4+Pj5zcGVjaWZp Y2F0aW9uIHdpbGwgaGF2ZQ0KPj4+Pj4+Pj4+UlBIDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ ID4gPj4gYWRoZXJlbmNlIHdpdGhpbiAjMyAodGhlIEVTSW5ldCkuDQo+Pj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gPiA+PiBXaGF0IG90aGVy IHNjb3BlIGNoYW5nZXMgZG8geW91IHdhbnQsDQo+Pj4+Pj4+YmVjYXVzZSBJIGhhdmVuJ3QNCj4+ Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gaGVhcmQgdGhlbS4NCj4+Pj4+Pj4+PiAgICAgICAgID4g Pj4gPj4gPiA+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IEkgb25seSBoZWFyZCB5 b3UgY2xhaW0gaW4gZW1haWwgDQo+ZHVyaW5nIHRoZQ0KPj4+Pj4+Pmxhc3QgSUVURg0KPj4+Pj4+ Pj4+YW5kIGluDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPnRoZSBFQ1JJVA0KPj4+Pj4+ Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHNlc3Npb24gdGhhdCBSUEggc2hvdWxkIG5vdCBiZQ0K Pj4+PnVzZWQgZm9yIHByaW9yaXR5DQo+Pj4+Pj4+Pj5tYXJraW5nDQo+Pj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+IHJlcXVlc3RzLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IFRoaXMg aXMgc29tZXRoaW5nIEtlaXRoIChTSVAgV0cNCj4+Pj5jaGFpcikgdm9pY2VkIGhpcw0KPj4+Pj4+ Pj4+b3Bwb3NpdGlvbg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IHRvIHlvdXIgdmll d3MgcmVnYXJkaW5nIGNyZWF0aW5nIGEgc2Vjb25kDQo+Pj4+Pj4+bWVhbnMgZm9yIFNJUA0KPj4+ Pj4+Pj4+dG8NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPnByaW9yaXR5DQo+Pj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+ID4gPj4gbWFyayByZXF1ZXN0ICJ3aGVuIFNJUCBhbHJlYWR5IGhhcyBvbmUN Cj4+Pj4+Pj5pbnRlcm9wZXJhYmxlDQo+Pj4+Pj4+Pj53YXkgdG8NCj4+Pj4+Pj4+PiAgICAgICAg ID4gPj4gPj4gPiA+PiBhY2NvbXBsaXNoIHRoaXMuLi4gaXQncyBjYWxsIHRoZSANCj5SUCBoZWFk ZXINCj4+Pj4+Pj5tZWNoYW5pc20iLg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+ Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gPkkgZG9uJ3Qgc2VlIGFkdmFudGFnZXMgLS0g b25seQ0KPj4+PmRpc2FkdmFudGFnZXMuDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4g Pg0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ID5DaWFvDQo+Pj4+Pj4+Pj4gICAgICAg ICA+ID4+ID4+ID4gPj4gPkhhbm5lcw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+DQo+ Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4NCj4+Pj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+ IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+PiA+ID4+IEVjcml0 QGlldGYub3JnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+ID4gPj4gDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4+Pj4+Pj4+ICAgICAgICAgPiA+PiA+ PiA+ID4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4g Pj4gDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+Pj4+PiAgICAgICAgID4gPj4gPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gICAg ICAgICA+ID4+ID4+IEVjcml0QGlldGYub3JnDQo+Pj4+Pj4+Pj4gICAgICAgICA+ID4+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+Pj4+PiAgICAg ICAgID4gPj4gPj4NCj4+Pj4+Pj4+PiAgICAgICAgID4gPj4gPg0KPj4+Pj4+Pj4+ICAgICAgICAg PiA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+DQo+Pj4+Pj4+Pj4gICAgICAgICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4gICAgICAgICA+ IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ICAgICAgICAgPiBFY3JpdEBpZXRmLm9yZw0K Pj4+Pj4+Pj4+ICAgICAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Vjcml0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+RWNyaXQg bWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj5FY3JpdEBpZXRmLm9yZw0KPj4+Pj4+Pj4+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+RWNy aXQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PkVjcml0QGlldGYub3JnDQo+Pj4+Pj4+Pmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+Pg0KPj4+Pj4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PkVjcml0IG1h aWxpbmcgbGlzdA0KPj4+Pj4+RWNyaXRAaWV0Zi5vcmcNCj4+Pj4+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PkVjcml0IG1haWxpbmcgbGlzdA0KPj4+RWNy aXRAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNy aXQNCj4+Pg0KPj4+DQo+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+PlRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg YW5kIG1heQ0KPj4+Y29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl IHByaXZhdGUgaW5mb3JtYXRpb24uDQo+Pj5JZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+Pj5pbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRo ZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQo+Pj50aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQo+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+PlttZjJdDQo+Pj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PkVjcml0IG1haWxpbmcgbGlzdA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5FY3JpdCBtYWlsaW5nIGxp c3QNCj5FY3JpdEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPkVjcml0IG1haWxpbmcgbGlzdA0KPkVjcml0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPg0KDQo= Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D843A6C10 for ; Fri, 6 Feb 2009 16:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2FHCG9pXLJZ for ; Fri, 6 Feb 2009 16:15:14 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id D48EA3A6BFF for ; Fri, 6 Feb 2009 16:15:12 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170Em9T028032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:14:48 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 7 Feb 2009 01:14:48 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , Hannes Tschofenig , Brian Rosen , Henning Schulzrinne Date: Sat, 7 Feb 2009 01:14:48 +0100 Thread-Topic: [Ecrit] RPH Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprow Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:15:17 -0000 It is a valid header for that usage. It carries exactly the semantics the u= ser wishes to convey, i.e. that the requestor would like the call to be tre= ated in processing by the network in a manner appropriate to emergency call= s. Yes the edge proxy may well review and make up its own mind, and either rem= ove, verify or pass on the header, but that does not mean it is wrong from = the UE. You might just as well argue that the UE should not inserted a P-Preferred-= ID if it knows that the value it contains will be the one inserted by the e= dge proxy. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Winterbottom, James > Sent: Friday, February 06, 2009 8:02 PM > To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne > Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > Subject: Re: [Ecrit] RPH > > Hi All, > > I have followed thi thread with some interest and I > struggling to see a use case for the providing RPH for > emergency calls from the end-point. > > The reference-model call in ECRIT, for better or worse, is > for all calls to go back through a home-VSP. > We placed quite a lot of emphasis, largely for traffing > reasons, for the VSP to be able to verify that a call is in > fact an emergency call. This is done by the proxy taking the > inband location, doing a LoST query with the provided URN, > and verifying that the resulting destination URI is the same > as the destination URI provide in the SIP INVITE. My > understanding was that VSPs would always do this check so > they could tell if they could bill for the call or not, and > because the VSP can be use that the call is an emergency call > it can apply any special priorities that may be applicable. > This obviates the need for RPH from the end-point to the network. > > This leaves us with the argument of "it doesn't hurt to it", > which is not a good reason to write a specification. > It was intimated on the geopriv mailing list last year that > great pains had been taken to keep SIP with in the MTU limits > of UDP over Ethernet > (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120 > .html). Assuming that this is the case, perhaps there is harm > in including information that we know will be ignored. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Fri 2/6/2009 12:33 PM > To: 'Brian Rosen'; 'Henning Schulzrinne' > Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > Subject: Re: [Ecrit] RPH > > To the story short here is the code for the proxy: > > --------------------- > > IF emergency call was recognized THEN > execute emergency call specific procedures (priority > queuing, preemption, fetch location, determine routing, do > funny QoS things & co) ELSE > normal call handling procedures. > > --------------------- > > If you can make this differentiation between an emergency > call and a regular call then you can also do everything that > is necessary for emergency call handling. > > Brian + Keith: Please tell me that we cannot do the above > with our currently specified mechanisms. > > Ciao > Hannes > > >-----Original Message----- > >From: Brian Rosen [mailto:br@brianrosen.net] > >Sent: 06 February, 2009 17:49 > >To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >Subject: RE: [Ecrit] RPH > > > >I agree that not all networks will permit (or pay attention > >to) a priority request from an end device. > > > >No one has asked for that. > > > >The namespace request has several uses, one of which is within an > >emergency services IP network, one of which is between > elements within > >a public network controlled by the operator, and one of which is an > >endpoint request for resource priority. > > > >Those of us requesting this work proceed are happy if the > endpoint part > >is simply left as possible (MAY), and, speaking for myself, > having the > >draft discuss the security implications of endpoint marking is > >reasonable. > > > >Having discussed this issue with an implementation team who > worked on > >MLPP systems, I am confident I know what I'm talking about, > but YMMV. > >The fact that you could, if you wanted to, give resource > priority to a > >call you decided, however you decided, was an emergency call is an > >implementation decision, and not subject to standardization. > > > >RPH is the IETF standard way for one entity to request resource > >priority of another entity in a SIP system. We're asking for a > >namespace to use that within the domain of emergency calls. > That is, I > >think, a VERY reasonable request. > > > >Brian > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Friday, February 06, 2009 10:33 AM > >> To: Hannes Tschofenig > >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >> Subject: Re: [Ecrit] RPH > >> > >> To chime in here: > >> > >> I don't think it's productive to simply state that 4412 > >doesn't worry > >> about authorization, so we shouldn't either (simplifying a bit). > >> Authorization was discussed repeatedly, and the general > >assumption was > >> that there were two conditions: Either the user invoking resource- > >> priority was well known and had a set of permissions that could be > >> checked in real time or there are ways to deal with abuse > after the > >> fact in ways that deter abuse (the court-martial kind of > thing in a > >> military context). > >> > >> The RFC 4412 security consideration (11.2) call this out in pretty > >> strong language: > >> > >> Prioritized access to network and end-system resources imposes > >> particularly stringent requirements on authentication and > >> authorization mechanisms, since access to prioritized > >resources may > >> impact overall system stability and performance and not > >just result > >> in theft of, say, a single phone call. > >> Thus, the question is whether we have such strong > authentication in > >> emergency calling. In some cases, such as residential fixed line > >> deployments where ISP =3D VSP, we're probably pretty close, > in others, > >> such as prepaid cell phones or hot spots or VSP-only providers, we > >> aren't. > >> > >> The other point that I think Hannes is making is that the > >information > >> is either redundant or dangerous. If a processing element > recognizes > >> the call as being an emergency call, it can apply whatever > treatment > >> it deems appropriate and doesn't need additional > information. If it > >> doesn't or can't, using just the RPH can be rather > dangerous unless > >> that element can be reasonably certain that there is strong > >> authentication and recourse. > >> > >> I don't buy the argument that somehow finding the RPH is > faster than > >> just looking for the identifier. Thus, given that the > information is > >> either redundant or dangerous, I fail to see the advantage. > >> > >> Henning > >> > >> > >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > >> > >> > Don't get hung up on the details. There are ways to optimize it. > >> > That was > >> > not the point of the code example. > >> > > >> > The problem that my pseudo code should have shown you is that you > >> > * don't gain anything with RPH marking for the emergency > call case > >> > from the SIP UA towards the outbound proxy since the > functionality > >> > is already provide otherwise. How often does the proxy > need to get > >> > told that this is an emergency call todo whatever emergency call > >> > handling procedures are necessary? > >> > * you only introduce fraud problems (if you are not > >careful and you > >> > understand the security stuff well enough) > >> > > >> > If you can point me to people who implement the RPH > emergency call > >> > case please do so. I would love to talk to them. > >> > > >> > Ciao > >> > Hannes > >> > > >> > PS: You need to parse incoming messages to some extend > so that you > >> > know what it contains :-) Only looking for the emergency > >RPH header > >> > (and not for the Service URN/dial > >> > string) would exactly be the DoS/fraud attack I am worried about. > >> > That's the thing Henning was worried about (go and listen to the > >> > past meeting minutes). > >> > > >> > > >> >> Hannes > >> >> > >> >> You need to talk to people who really implement this kind > >of thing. > >> >> You are way off. > >> >> > >> >> When you implement a resource priority system, the > point of doing > >> >> that is to look though the queue of work and pick out the > >ones with > >> >> priority, handling them first. You don't do all the > parsing, you > >> >> don't do a lot of decision tree. > >> >> > >> >> Typically: > >> >> Check for DoS things, like too big messages, etc Do a > quick scan > >> >> for the RPH message header If found: > >> >> Parse the message > >> >> Determine validity > >> >> Determine priority > >> >> Queue on the correct work queue > >> >> > >> >> The first two actions have to be very fast. Anyone who > builds a > >> >> SIP thingie will tell you that parsing is one of the big cycle > >> >> consumers: if you have to parse every message BEFORE you > >determine > >> >> priority, you can't give much resource priority. > >> >> Once you get the whole message parsed, you might as well finish > >> >> working on it, because you've done so much of the work. > >> >> OTHOH, finding the end-of-message delimiter and doing a quick > >> >> string search for RPH is fast. If you are doing > >priority, you need > >> >> to keep all the priority processing pretty uniform, and pretty > >> >> simple, or you tend to spend too much time futzing around > >figuring > >> >> out what to do. You put all the priority related stuff > together, > >> >> and use as much common code as possible. > >> >> > >> >> Brian > >> >> > >> >>> -----Original Message----- > >> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> On Behalf > >> >>> Of Hannes Tschofenig > >> >>> Sent: Friday, February 06, 2009 8:41 AM > >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' > >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >> >>> bounces@ietf.org > >> >>> Subject: [Ecrit] RPH > >> >>> > >> >>> Over lunch I was also thinking how an outbound proxy would > >> implement > >> >>> some of the emergency procedures. Here are some thoughts: > >> >>> > >> >>> --------------------------------------------------- > >> >>> > >> >>> // Process incoming message > >> >>> Parse(msg); > >> >>> > >> >>> // SIP INVITE without Service URN // legacy devices If > >> >>> (recognize-dialstring(msg)=3D=3DTRUE) { // we got an > emergency call > >> >>> going on emergency=3DTRUE; if (dialstring(msg) =3D=3D 911) > >> >>> serviceURN=3Durn:service:sos; } else if > >> >>> (recognize-serviceURN(msg)=3D=3DTRUE) { // oh. A updated > >device that > >> >>> has a service URN attached to the > >> call > >> >>> serviceURN=3Dretrieve_ServiceURN(msg); > >> >>> emergency=3DTRUE; > >> >>> } else { > >> >>> // standard SIP message > >> >>> // regular processing > >> >>> process(msg); > >> >>> emergency=3DFALSE; > >> >>> } > >> >>> > >> >>> If (emergency =3D=3D TRUE) { > >> >>> // make sure that the emergency call does not get > >dropped on the > >> >>> floor > >> >>> // skip authorization failures > >> >>> // give the call a special treatment > >> >>> lots-of-code-here(); > >> >>> > >> >>> // trigger all the QoS signaling you have in the > >network to make > >> >>> James happy > >> >>> trigger-qos(); > >> >>> > >> >>> // query location > >> >>> location=3Dretrieve-location(); > >> >>> > >> >>> // determine next hop > >> >>> next-hop=3Dlost(location, serviceURN) > >> >>> > >> >>> // attach RPH marking to outgoing msg to make James and > >> >> Keith happy > >> >>> msg=3Dadd(msg, RPH); > >> >>> > >> >>> send(msg, next-hop); > >> >>> } > >> >>> > >> >>> If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) { > >> >>> // all the emergency related processing done already upfront > >> >>> // hence I log something. > >> >>> log(RPH_WAS_PRESENT_JUHU); > >> >>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D > >FALSE)) { > >> >>> // this is not an emergency call // this is something > >like GETS > >> >>> result=3Dspecial-authorization-procedure(user); > >> >>> > >> >>> if (result =3D=3D AUTHORIZED) { > >> >>> // do some priority & preemption thing here. > >> >>> // trigger all the QoS you have > >> >>> lots-of-code-here(); > >> >>> } else { > >> >>> log("NOT AUTHORIZED; don't DoS my network"); } } > else { // > >> >>> don't need todo any RPH processing // this includes the case > >> >>> where the call was an emergency call but the RPH > >> >>> > >> >>> // marking was not there. > >> >>> nothing(); > >> >>> } > >> >>> > >> >>> --------------------------------------------------- > >> >>> > >> >>> > >> >>> Ciao > >> >>> Hannes > >> >>> > >> >>>> -----Original Message----- > >> >>>> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > >> >>>> Behalf Of Hannes Tschofenig > >> >>>> Sent: 06 February, 2009 15:07 > >> >>>> To: 'Janet P Gunn' > >> >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > >> >>> FI/Espoo) > >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > Agenda (RPH) > >> >>>> > >> >>>> Who would define something that could prevent DoS problems? > >> >>>> > >> >>>> ________________________________ > >> >>>> > >> >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >> >>>> Sent: 06 February, 2009 14:11 > >> >>>> To: Hannes Tschofenig > >> >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >> >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); > >> 'James > >> >>>> M. Polk' > >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim > >Meeting: Agenda (RPH) > >> >>>> > >> >>>> > >> >>>> > >> >>>> But there is nothing IN RFC4412 that specifically > >> >> addresses how to > >> >>>> prevent any particular namespace being used for DoS. > Anyone/any > >> UA > >> >>>> can ATTEMPT to invoke priority treatment by attaching > RPH. For > >> all > >> >>>> of the 4412 namespaces, as with the new proposed > namespace, the > >> >>>> mechanisms for preventing DoS are not specified in the > >> >> document that > >> >>>> defines the namespace. > >> >>>> They are/will be specified elsewhere. > >> >>>> > >> >>>> Janet > >> >>>> > >> >>>> This is a PRIVATE message. If you are not the intended > >> >> recipient, > >> >>>> please delete without copying and kindly advise us by > e-mail of > >> the > >> >>>> mistake in delivery. > >> >>>> NOTE: Regardless of content, this e-mail shall not > >> >> operate to bind > >> >>>> CSC to any order or other contract unless pursuant to > explicit > >> >>>> written agreement or government initiative expressly > permitting > >> the > >> >>>> use of e-mail for such purpose. > >> >>>> > >> >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: > >> >>>> > >> >>>> > Hi James, > >> >>>> > > >> >>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >> >> documents. What I > >> >>>> would > >> >>>> > like to point out is that there is more than just a > >> >> header and > >> >>>> values within > >> >>>> > the header that have to be considered in order to > >> >> make a judgement > >> >>>> of what > >> >>>> > is appropriate and what isn't. There is an > >> >> architectural question > >> >>>> and > >> >>>> > whether the environment we are using the stuff is > >> >> indeed providing > >> >>>> the > >> >>>> > properties you need for the solution to be > >appropriate. > >> >>>> > > >> >>>> > Let me describe in more detail what I meant (and > >> >> please correct me > >> >>>> if I am > >> >>>> > wrong). > >> >>>> > > >> >>>> > Getting priority for SIP requests when using a GETS > >> >> alike scenario > >> >>>> means > >> >>>> > that the entity that issues the request is specially > >> >> authorized > >> >>>> since > >> >>>> > otherwise you introduce a nice denial of > >service attack. This > >> >>>> authorization > >> >>>> > is tied to the entity that makes the request. For > >> >> example, the > >> >>>> person is > >> >>>> > working for the government and has special rights. > >> >>>> James Bond as a (not so) > >> >>>> > secret agent might have these rights. > >> >>>> > > >> >>>> > The emergency services case > >(citizen-to-authority) is a bit > >> >>>> different as > >> >>>> > there aren't really special rights with respect to > >> >> authorization > >> >>>> tied to > >> >>>> > individuals. Instead, the fact that something is an > >> >> emergency is > >> >>>> purely a > >> >>>> > judgement of the human that dials a special number. > >> >>>> To deal with fraud, we > >> >>>> > discussed in the group on what we can actually do to > >> >> ensure that > >> >>>> end users > >> >>>> > do not bypass security procedures (such as > >> >> authorization checks, > >> >>>> charging > >> >>>> > and so on). Part of this investigation was > >the publication of > >> >>>> > http://www.ietf.org/rfc/rfc5069.txt that also > >describes this > >> >>>> issue. > >> >>>> > > >> >>>> > So, imagine the implementation of a SIP proxy (and we > >> >> implemented > >> >>>> that > >> >>>> > stuff) that receives a call that contains a Service > >> >> URN. The code > >> >>>> branches > >> >>>> > into a special mode where everything is done > >so that the call > >> >>>> receives > >> >>>> > appropriate treatment and does not get dropped on the > >> >> floor. The > >> >>>> way how the > >> >>>> > Service URN is placed in the message ensures that the > >> >> call cannot > >> >>>> go to my > >> >>>> > friend (instead of the PSAP) unless the end host ran > >> >> LoST already. > >> >>>> In the > >> >>>> > latter case, we discussed this also on the list for a > >> >> while and > >> >>>> Richard even > >> >>>> > wrote a draft about it in the context of the > >location hiding > >> >>>> topic, we said > >> >>>> > that the proxy would have to run LoST if he > >cares about a > >> >>>> potential > >> >>>> > fraudulent usage. > >> >>>> > > >> >>>> > So, what do we need todo in order to provide > >secure RFC 4412 > >> >>>> functionality > >> >>>> > in our context? > >> >>>> > > >> >>>> > Do you think that the current text in > >> >>>> > > >> >>>> > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >>>> gency-rph-nam > >> >>>> > espace-00.txt reflects any of the > >above-described issues: > >> >>>> > " > >> >>>> > The Security considerations that apply to RFC 4412 > >> >>>> [RFC4412] > >> >>>> apply > >> >>>> > here. This document introduces no new security > >> >>>> issues relative > >> >>>> to > >> >>>> > RFC 4412. > >> >>>> > " > >> >>>> > > >> >>>> > From various discussions in GEOPRIV I recall > >that you are > >> >>>> super-sensitive > >> >>>> > regarding security and privacy. For some reasons you > >> >> don't seem to > >> >>>> have the > >> >>>> > same concerns here. I would like to > >understand your reasoning. > >> >>>> > > >> >>>> > Please also do me another favor: Don't always say > >> >> that I don't > >> >>>> understand > >> >>>> > the subject. Even if that would be the case it isn't > >> >> particular > >> >>>> fair given > >> >>>> > that different folks had to educate you on other > >> >> topics in the > >> >>>> past as well. > >> >>>> > Additionally, if you listen to the audio recordings > >> >> then you will > >> >>>> notice > >> >>>> > that Henning, Ted, and Jon do not seem to understand > >> >> the issue > >> >>>> either as > >> >>>> > they have raised similar issues during the > >F2F meetings. > >> >>>> > > >> >>>> > Ciao > >> >>>> > Hannes > >> >>>> > > >> >>>> > > >> >>>> > >Hannes - I believe it is you who do not understand > >> >> RFC 4412 -- > >> >>>> > >and many of us are trying to get that > >through to you, but you > >> >>>> > >don't seem to want to listen/read. > >> >>>> > > > >> >>>> > >RFC 4412 is *for* priority marking SIP requests, > >> >>>> > > > >> >>>> > >One use is GETS. > >> >>>> > > > >> >>>> > >One use is MLPP. > >> >>>> > > > >> >>>> > >These examples are in RFC 4412 because there > >were specific > >> >>>> > >namespaces being created for the IANA section of > >> >> that document. > >> >>>> > > > >> >>>> > >Reading the whole document, you will see > >that RPH can be > >> >>>> > >specified for other uses than GETS or MLPP > >specifically. > >> >>>> > > > >> >>>> > >I knew when I wrote RFC 4412 that one day we > >would specify a > >> >>>> > >namespace for ECRIT (the "esnet" namespace > >now) -- but I also > >> >>>> > >knew it was premature for RFC 4412 to > >incorporate that > >> >>>> > >namespace, that a future doc to RFC 4412 > >would have to be > >> >>>> > >written to do this. Brian and I talked about > >this at the > >> >>>> > >original NENA meeting that created the IP WGs there > >> >> (in August > >> >>>> > >of 03). We both agreed we should wait until it was > >> >>>> > >appropriate to the work in the IETF to > >submit this document > >> >>>> > >that is now > >> >>>> > > >> >>>>> > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >>>> > >gency-rph-namespace-00.txt > >> >>>> > > > >> >>>> > >Yet, you seem to want to use some additional > >mechanism to > >> >>>> > >indicate priority of a call in SIP. That > >means you want to > >> >>>> > >introduce a second way to accomplish this in SIP. > >> >>>> Why do you > >> >>>> > >want to promote a separate way to do something SIP > >> >> has already > >> >>>> > >defined? That will cause interoperability issues and > >> >> we both know > >> >>>> that. > >> >>>> > > > >> >>>> > >You've said to me (and others) that you > >believe RPH is just > >> >>>> > >another way to accomplish what sos or a URI can > >> >> indicate - and > >> >>>> > >you're wrong. Your way would be > >_the_second_way_to_do_it, > >> >>>> > >because SIP already considers RPH to be > >*the*way* to priority > >> >>>> > >mark SIP requests. > >> >>>> > > > >> >>>> > >If you don't believe me (no comment), then > >why do you not > >> >>>> > >believe the SIP WG chair (who knows more > >about SIP than both > >> >>>> > >of us) - who, on this thread, has again said > >to you "RFC 4412 > >> >>>> > >(RPH) is the SIP mechanism to priority mark > >SIP requests"? > >> >>>> > > > >> >>>> > >Further, I believe it is inappropriate to > >prohibit endpoints > >> >>>> > >from being able to set the esnet namespace. > >I absolutely > >> >>>> > >believe it will not be needed most of the > >time, but I believe > >> >>>> > >if someone does find a valid use for > >endpoints to mark > >> >>>> > >priority in SIP, this ID - once it has > >become an RFC -- will > >> >>>> > >have to be obsoleted with a new RFC saying the exact > >> >> opposite. > >> >>>> > > > >> >>>> > >(color me confused ... over and over again) > >> >>>> > > > >> >>>> > >James > >> >>>> > > > >> >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >> >>>> > >>Keith, please understand that the usage of RFC 4412 > >> >> for GETS and > >> >>>> for > >> >>>> > >>the type of emergency call we discuss here is > >> >> different. Just > >> >>>> looking > >> >>>> > >>at the header and the name of the namespace is a bit > >> >>>> > >artificial. I hope > >> >>>> > >>you understand that. > >> >>>> > >> > >> >>>> > >> >-----Original Message----- > >> >>>> > >> >From: DRAGE, Keith (Keith) > >> >>>> [mailto:drage@alcatel-lucent.com] > >> >>>> > >> >Sent: 05 February, 2009 14:55 > >> >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >> >>>> Polk'; 'Tschofenig, > >> >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: Agenda (my > >> >>>> > >> >>>> > >> >mistake) > >> >>>> > >> > > >> >>>> > >> >Which is exactly what RFC 4412 specifies for all > >> >> namespaces. > >> >>>> > >> > > >> >>>> > >> >regards > >> >>>> > >> > > >> >>>> > >> >Keith > >> >>>> > >> > > >> >>>> > >> >> -----Original Message----- > >> >>>> > >> >> From: ecrit-bounces@ietf.org > >> >> [mailto:ecrit-bounces@ietf.org] > >> >>>> > >> >On Behalf > >> >>>> > >> >> Of Brian Rosen > >> >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. > >Polk'; 'Tschofenig, > >> >>>> > >Hannes (NSN > >> >>>> > >> >> - FI/Espoo)'; 'ECRIT' > >> >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: Agenda (my > >> >>>> > >> >> mistake) > >> >>>> > >> >> > >> >>>> > >> >> The value is that in some networks > >where priority for > >> >>>> > >> >emergency calls > >> >>>> > >> >> is appropriate, and appropriate > >policing of marking is > >> >>>> > >implemented, > >> >>>> > >> >> emergency calls will receive resource priority. > >> >>>> > >> >> > >> >>>> > >> >> Not all networks would need policing. Some > >> >> will. Policing > >> >>>> could > >> >>>> > >> >> be to Route header/R-URI content, but other > >> >> criteria are > >> >>>> possible. > >> >>>> > >> >> > >> >>>> > >> >> Not all networks will need resource priority > >> >> for emergency > >> >>>> calls. > >> >>>> > >> >> Fine, ignore this marking/namespace. > >> >>>> > >> >> > >> >>>> > >> >> Brian > >> >>>> > >> >> > -----Original Message----- > >> >>>> > >> >> > From: Hannes Tschofenig > >> >>>> [mailto:Hannes.Tschofenig@gmx.net] > >> >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >> >> Tschofenig, Hannes > >> >>>> (NSN - > >> >>>> > >> >> > FI/Espoo); 'ECRIT' > >> >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: Agenda (my > >> >>>> > >> >> > mistake) > >> >>>> > >> >> > > >> >>>> > >> >> > I don't even see the value in permitting the > >> >> endpoint todo > >> >>>> the > >> >>>> > >> >> > RPH marking. > >> >>>> > >> >> > In addition to the security concerns > >there is also the > >> >>>> > >> >problem that > >> >>>> > >> >> > there are more options to implement without > >> >> an additional > >> >>>> value. > >> >>>> > >> >> > > >> >>>> > >> >> > >-----Original Message----- > >> >>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >>>> > >> >> > >Sent: 05 February, 2009 00:03 > >> >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >> >> 'Tschofenig, > >> >>>> > >> >> Hannes (NSN - > >> >>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >> >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual > >Interim Meeting: > >> >>>> Agenda (my > >> >>>> > >> >> > mistake) > >> >>>> > >> >> > > > >> >>>> > >> >> > >Hannes > >> >>>> > >> >> > > > >> >>>> > >> >> > >This matches my understanding > >precisely. We wish to > >> >>>> > >> >> permit endpoints > >> >>>> > >> >> > >to mark. We do not require it, and > >don't necessarily > >> >>>> expect it > >> >>>> > >> >> > >in many (even > >> >>>> > >> >> > >most) cases. We don't wish to see the > >> >> document prohibit > >> >>>> it. > >> >>>> > >> >> > >We all seem to agree it has value within the > >> >> Emergency > >> >>>> > >> >Services IP > >> >>>> > >> >> > >Networks. > >> >>>> > >> >> > > > >> >>>> > >> >> > >Brian > >> >>>> > >> >> > > > >> >>>> > >> >> > >> -----Original Message----- > >> >>>> > >> >> > >> From: ecrit-bounces@ietf.org > >> >>>> [mailto:ecrit-bounces@ietf.org] > >> >>>> > >> >> > >On Behalf > >> >>>> > >> >> > >> Of James M. Polk > >> >>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, > >Hannes (NSN - > >> >>>> > >> >> FI/Espoo); 'ECRIT' > >> >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >> >>>> Meeting: > >> >>>> > >Agenda (my > >> >>>> > >> >> > >> mistake) > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes > >Tschofenig wrote: > >> >>>> > >> >> > >> > > James wrote: > >> >>>> > >> >> > >> > >> you are the _lone_ voice not > >> >> supporting this ID, > >> >>>> > >> >> > >> > > >> >>>> > >> >> > >> >Listening to the audio recording of past > >> >> meetings I > >> >>>> have to > >> >>>> > >> >> > >say that > >> >>>> > >> >> > >> >I > >> >>>> > >> >> > >> was > >> >>>> > >> >> > >> >not the only persons raising > >concerns about the > >> >>>> document. > >> >>>> > >> >> > >> >That was probably the reason why you > >> >> agreed to limit > >> >>>> the > >> >>>> > >> >> > >scope of the > >> >>>> > >> >> > >> >document (which you didn't later do) to > >> >> get folks to > >> >>>> agree > >> >>>> > >> >> > >to make it > >> >>>> > >> >> > >> a WG > >> >>>> > >> >> > >> >item. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> re-listen to the audio please > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> Ted's concerns were consistent with most > >> >>>> (all?) other > >> >>>> > >> >> concerns -- > >> >>>> > >> >> > >> which were based on the premise of whether > >> >> or not the > >> >>>> > >> >> UAC should be > >> >>>> > >> >> > >> trusted to initiate the marking on the > >> >> INVITE. The > >> >>>> most > >> >>>> > >> >> > >> recent version has backed off this > >to a "can" -- > >> >>>> meaning not > >> >>>> > >> >prohibited > >> >>>> > >> >> > >> (i.e., no 2119 text). I also backed off > >> >> the text in > >> >>>> the > >> >>>> > >> >> SP domain > >> >>>> > >> >> > >> part to "can", such that there is > >no 2119 text > >> >>>> > >> >mandating or even > >> >>>> > >> >> > >> recommending its usage there. I also do > >> >> not prohibit > >> >>>> its > >> >>>> > >> >> > >use, based on > >> >>>> > >> >> > >> local policy. Keith has come forward with > >> >> the specific > >> >>>> > >> >>>> > >> >> > >> request that non-ESInet networks be > >> >> allowed to mark and > >> >>>> pay > >> >>>> > >> >attention to > >> >>>> > >> >> > >> this priority indication -- with IMS as > >> >> the specific > >> >>>> example > >> >>>> > >> >> > >> he wishes to have this valid for. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> Where there is no disagreement, save for > >> >> your recent > >> >>>> > >> >> > >pushback - is in > >> >>>> > >> >> > >> the ESInet, which is where Brian > >has requested it's > >> >>>> > >> >> > >definition in the > >> >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >> >> chair within > >> >>>> > >> >> NENA, and if > >> >>>> > >> >> > >> he asks for it, are you going to say you > >> >> know better > >> >>>> than he? > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> >Btw, I not disagreeing with the document > >> >> as such. I > >> >>>> > >> >just want to > >> >>>> > >> >> > the > >> >>>> > >> >> > >> scope > >> >>>> > >> >> > >> >to change. The usage of RPH > >within the emergency > >> >>>> > >> >> services network > >> >>>> > >> >> > is > >> >>>> > >> >> > >> fine > >> >>>> > >> >> > >> >for me. I may get convinced to start the > >> >> RPH marking > >> >>>> from > >> >>>> > >> >> > >the the VSP > >> >>>> > >> >> > >> >towards the PSAP. I feel uneasy about the > >> >> end host > >> >>>> doing > >> >>>> > >> >> > >the marking. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> please read what I wrote above, and then > >> >> re-read the > >> >>>> > >> >most recent > >> >>>> > >> >> > >> version of the ID. I don't have endpoints > >> >> that SHOULD > >> >>>> or > >> >>>> > >> >> MUST mark > >> >>>> > >> >> > >> anything wrt RPH. I also don't want to > >> >> prohibit it, > >> >>>> > >> >> because there > >> >>>> > >> >> > >> might be cases (that I don't know > >of) of valid uses > >> >>>> > >> >> under certain > >> >>>> > >> >> > >> circumstances. Figure 1 is very clear > >> >> that there are 3 > >> >>>> > >> >> networking > >> >>>> > >> >> > >> parts to consider > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> #1 - from the endpoint > >> >>>> > >> >> > >> #2 - within the VSP > >> >>>> > >> >> > >> #3 - within the ESInet > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> the most recent ID version has "can" for > >> >> #s 1 and 2, > >> >>>> and > >> >>>> > >> >> > >2119 language > >> >>>> > >> >> > >> offering those supporting this > >> >> specification will have > >> >>>> RPH > >> >>>> > >> >> > >> adherence within #3 (the ESInet). > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> What other scope changes do you want, > >> >> because I haven't > >> >>>> > >> >> heard them. > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> I only heard you claim in email during the > >> >> last IETF > >> >>>> and in > >> >>>> > >> >> > >the ECRIT > >> >>>> > >> >> > >> session that RPH should not be > >used for priority > >> >>>> marking > >> >>>> > >> >> requests. > >> >>>> > >> >> > >> This is something Keith (SIP WG > >chair) voiced his > >> >>>> opposition > >> >>>> > >> >> > >> to your views regarding creating a second > >> >> means for SIP > >> >>>> to > >> >>>> > >> >priority > >> >>>> > >> >> > >> mark request "when SIP already has one > >> >> interoperable > >> >>>> way to > >> >>>> > >> >> > >> accomplish this... it's call the RP header > >> >> mechanism". > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> >I don't see advantages -- only > >disadvantages. > >> >>>> > >> >> > >> > > >> >>>> > >> >> > >> >Ciao > >> >>>> > >> >> > >> >Hannes > >> >>>> > >> >> > >> > >> >>>> > >> >> > >> > >_______________________________________________ > >> >>>> > >> >> > >> Ecrit mailing list > >> >>>> > >> >> > >> Ecrit@ietf.org > >> >>>> > >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >> > > > >> >>>> > >> >> > >> >>>> > >> >> _______________________________________________ > >> >>>> > >> >> Ecrit mailing list > >> >>>> > >> >> Ecrit@ietf.org > >> >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >> > >> >>>> > >> > > >> >>>> > > > >> >>>> > > >> >>>> > _______________________________________________ > >> >>>> > Ecrit mailing list > >> >>>> > Ecrit@ietf.org > >> >>>> > https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Ecrit mailing list > >> >>>> Ecrit@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/ecrit > >> >>>> > >> >>> > >> >>> _______________________________________________ > >> >>> Ecrit mailing list > >> >>> Ecrit@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > >> > _______________________________________________ > >> > Ecrit mailing list > >> > Ecrit@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068313A6B70 for ; Fri, 6 Feb 2009 16:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2whzSct2cxje for ; Fri, 6 Feb 2009 16:21:55 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D4F413A6856 for ; Fri, 6 Feb 2009 16:21:54 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170LfM7029067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:21:41 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 7 Feb 2009 01:21:41 +0100 From: "DRAGE, Keith (Keith)" To: Henning Schulzrinne , "James M. Polk" Date: Sat, 7 Feb 2009 01:21:40 +0100 Thread-Topic: [Ecrit] RPH Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <001d01c9885b$d5d705d0$49b5b70a@nsnintra.net> <001f01c98860$910658c0$49b5b70a@nsnintra.net> <0d6901c9886b$6c9bfc50$45d3f4f0$@net> <003001c9886e$7d133280$49b5b70a@nsnintra.net> <1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu> <0d9101c98872$7b2129b0$71637d10$@net> <003d01c98889$666c23f0$49b5b70a@nsnintra.net> <7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> In-Reply-To: <7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:21:56 -0000 Well to be honest, I thought RFC 4412 defined exactly the usage from the UA= of any RPH header, and noone appears to be seeking to change that. Any UE = can insert an RPH header, and the outbound proxy that understands RPH can u= se this as absolute, guidance, or completely ignore it and throw it away de= pending on whatever rules it decides apply to its usage of that namespace. = IETF does not write those rules, just defines the namespace.=20 So I disagree with the statement of "underspecified" in relation to this. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Friday, February 06, 2009 10:29 PM > To: James M. Polk > Cc: ECRIT > Subject: Re: [Ecrit] RPH >=20 > To restate: I will object to any text mentioning use of ESNET=20 > in UAs. =20 > It's useless (since under-specified), likely to be harmful to=20 > reliable network operation and just causes confusion. The=20 > text should describe when it is useful (within a "closed"=20 > ESNET, presumably) and what conditions need to be met in=20 > order to ensure reliable and secure usage. That something=20 > might be useful somewhere else is always true, in any=20 > specification, but we don't add a "This document does not=20 > prevent the use of this mechanism somewhere else." in documents. >=20 > Henning >=20 > On Feb 6, 2009, at 5:21 PM, James M. Polk wrote: >=20 > > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote: > >> James, > >> > >> we don't go through every possible SIP header that might=20 > be inserted=20 > >> into emergency requests. Yes, somebody could add RPH, but this=20 > >> applies to PAI and dozens of other SIP headers as well. So far,=20 > >> nobody has provided, in my opinion, a compelling use case that is=20 > >> worth documenting. "It could be useful somewhere for something"=20 > >> doesn't cut it. I have provided multiple reasons why I=20 > think that it=20 > >> is a bad idea for (normal) UAs to do so, none of which you address. > > > > > >> I see no need to say "do not insert RPH", > > > > this is the only thing - right now - that I'm afraid one of us=20 > > believes should be the case. I'm glad you are not joining that=20 > > position. I really do not want to highlight the idea fo=20 > UAs inserting=20 > > esnet, but I believe sometime down the road - some customer=20 > will come=20 > > up with a valid reason for this, and I don't want to state in text=20 > > that it is prevented from being inserted (and yet have the=20 > vendor who=20 > > wants to sell to that customer also want that vendor to=20 > adhere to this=20 > > spec as well). > > > > I'm just advocating we not have the text prevent its inclusion. > > > > As I've said, I will beef up the security considerations=20 > section wrt=20 > > UA insertion of esnet - unless others object to this... >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475FC3A6856 for ; Fri, 6 Feb 2009 16:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2ZPtpnfHeAt for ; Fri, 6 Feb 2009 16:26:48 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7C5A33A6B70 for ; Fri, 6 Feb 2009 16:26:47 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170Q5fM029633 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:26:05 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 7 Feb 2009 01:26:05 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "'DOLLY, MARTIN C, ATTLABS'" , "jmpolk@cisco.com" , "hgs@cs.columbia.edu" , "James.Winterbottom@andrew.com" Date: Sat, 7 Feb 2009 01:26:02 +0100 Thread-Topic: [Ecrit] RPH Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAA19QMA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> In-Reply-To: <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ecrit@ietf.org" Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:26:51 -0000 It appears you want to develop an entirely separate codepath for the usage = of RPH in emergency calls, where the appropriate thing is to apply the test= ed usage of RPH that many networks will have to deploy anyway. So there wil= l be a standard RPH usage which is then configured to handle the emergency = namespace. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Friday, February 06, 2009 10:52 PM > To: 'DOLLY, MARTIN C, ATTLABS'; jmpolk@cisco.com; > hgs@cs.columbia.edu; James.Winterbottom@andrew.com > Cc: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > Subject: Re: [Ecrit] RPH > > Hi Martin, > > I am arguing that if the UE does mark the call with the ECRIT > RPH (I call it that way to differentiate it from RFC 4412 RPH > usage, which is very > different) then it should be ignored. > Processing it will not help in any way (as I described in my > pseudo code snippet). Incorrectly processing it (which is a > possibility when the implementer does not understand the > security implications -- they will not get it from the > current version of the draft) will lead to security problems > (fraud & DoS potential). > > While you cannot prevent someone from sending you, there is > certainly the chance to document what the receiver should do with it. > > Ciao > Hannes > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf > >Of DOLLY, MARTIN C, ATTLABS > >Sent: 07 February, 2009 00:15 > >To: jmpolk@cisco.com; hgs@cs.columbia.edu; > >James.Winterbottom@andrew.com > >Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org > >Subject: Re: [Ecrit] RPH > > > >You can not disallow this from an UE. The trust relationship will > >dictate whether it is accepted or not > > > >----- Original Message ----- > >From: ecrit-bounces@ietf.org > >To: Henning Schulzrinne ; Winterbottom, James > > > >Cc: Tschofenig, Hannes (NSN - FI/Espoo) ; > >ECRIT > >Sent: Fri Feb 06 17:10:08 2009 > >Subject: Re: [Ecrit] RPH > > > >At 03:05 PM 2/6/2009, Henning Schulzrinne wrote: > >>There's another problem with the "it doesn't hurt argument". > >Assume for > >>a moment we have a "UA MAY include RPH" wording. There are now two > >>cases: > >> > >>(1) All UAs implement it. > >> > >>(2) Only some UAs implement it. > >> > >>(1) seems unlikely for a MAY. If (2) occurs, we have the > >choice between > >>two undesirable outcomes: > >> > >>(a) some UAs that are otherwise compliant get worse service just > >>because they didn't include the RPH; > > > >am I reading this correctly - that unless all UAs implement this > >capability this should never be implemented by any UAs? > > > >This flies in the face of vendors solving for their customer's > >requirements. > > > >I will admit that at this time, I know of no Cisco customers > that want > >this capability, so I'm not angling for any of our revenue > here. I'm > >saying that I think I hear you saying this ID should say > something like > > > > UAs are prevented from implementing the RP namespace esnet > > > >I'm fighting against that, because customers are always > coming to every > >vendor with new requirements, some of them unique at the time. This > >prevention text would prevent a vendor from complying with this > >specification and still meet the customer's needs. > > > >I believe that this ID needs to retain the endpoints MAY > insert esnet, > >and have appropriate security considerations text that > highlights the > >concerns expressed here. > > > >Some future ID can then update this current RFC (to-be) within the > >2119 rules of the use of MAY here. > > > > > >>OR > >> > >>(b) the proxy has to look for the service URN to give the call the > >>appropriate treatment, thus obviating any advantage of having the > >>header, yet incurring more complicated processing logic. > >> > >> > >>I have no objection to whatever markings people want to > apply to calls > >>within an ESN - that's largely a private matter. > >> > >>Henning > >> > >>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: > >> > >>>Hi All, > >>> > >>>I have followed thi thread with some interest and I > struggling to see > >>>a use case for the providing RPH for emergency calls from the > >>>end-point. > >>> > >>>The reference-model call in ECRIT, for better or worse, is for all > >>>calls to go back through a home-VSP. > >>>We placed quite a lot of emphasis, largely for traffing > reasons, for > >>>the VSP to be able to verify that a call is in fact an emergency > >>>call. This is done by the proxy taking the inband > location, doing a > >>>LoST query with the provided URN, and verifying that the resulting > >>>destination URI is the same as the destination URI provide > in the SIP > >>>INVITE. My understanding was that VSPs would always do > this check so > >>>they could tell if they could bill for the call or not, > and because > >>>the VSP can be use that the call is an emergency call it can apply > >>>any special priorities that may be applicable. This > obviates the need > >>>for RPH from the end-point to the network. > >>> > >>>This leaves us with the argument of "it doesn't hurt to > it", which is > >>>not a good reason to write a specification. > >>>It was intimated on the geopriv mailing list last year that great > >>>pains had been taken to keep SIP with in the MTU limits of > UDP over > >>>Ethernet > >>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612 > >0.html ). Assuming > >>>that this is the case, perhaps there is harm in including > information > >>>that we know will be ignored. > >>> > >>>Cheers > >>>James > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > >>>Sent: Fri 2/6/2009 12:33 PM > >>>To: 'Brian Rosen'; 'Henning Schulzrinne' > >>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > >>>Subject: Re: [Ecrit] RPH > >>> > >>>To the story short here is the code for the proxy: > >>> > >>>--------------------- > >>> > >>>IF emergency call was recognized THEN > >>> execute emergency call specific procedures (priority queuing, > >>>preemption, fetch location, determine routing, do funny > QoS things & > >>>co) > >>>ELSE > >>> normal call handling procedures. > >>> > >>>--------------------- > >>> > >>>If you can make this differentiation between an emergency > call and a > >>>regular call then you can also do everything that is necessary for > >>>emergency call handling. > >>> > >>>Brian + Keith: Please tell me that we cannot do the above with our > >>>currently specified mechanisms. > >>> > >>>Ciao > >>>Hannes > >>> > >>>>-----Original Message----- > >>>>From: Brian Rosen [mailto:br@brianrosen.net] > >>>>Sent: 06 February, 2009 17:49 > >>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > >>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>>>Subject: RE: [Ecrit] RPH > >>>> > >>>>I agree that not all networks will permit (or pay attention > >>>>to) a priority request from an end device. > >>>> > >>>>No one has asked for that. > >>>> > >>>>The namespace request has several uses, one of which is within an > >>>>emergency services IP network, one of which is between elements > >>>>within a public network controlled by the operator, and > one of which > >>>>is an endpoint request for resource priority. > >>>> > >>>>Those of us requesting this work proceed are happy if the > endpoint > >>>>part is simply left as possible (MAY), and, speaking for myself, > >>>>having the draft discuss the security implications of endpoint > >>>>marking is reasonable. > >>>> > >>>>Having discussed this issue with an implementation team > who worked > >>>>on MLPP systems, I am confident I know what I'm talking > about, but > >>>>YMMV. The fact that you could, if you wanted to, give resource > >>>>priority to a call you decided, however you decided, was an > >>>>emergency call is an implementation decision, and not subject to > >>>>standardization. > >>>> > >>>>RPH is the IETF standard way for one entity to request resource > >>>>priority of another entity in a SIP system. We're asking for a > >>>>namespace to use that within the domain of emergency calls. That > >>>>is, I think, a VERY reasonable request. > >>>> > >>>>Brian > >>>> > >>>>>-----Original Message----- > >>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>Sent: Friday, February 06, 2009 10:33 AM > >>>>>To: Hannes Tschofenig > >>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >>>>>Subject: Re: [Ecrit] RPH > >>>>> > >>>>>To chime in here: > >>>>> > >>>>>I don't think it's productive to simply state that 4412 > >>>>doesn't worry > >>>>>about authorization, so we shouldn't either (simplifying a bit). > >>>>>Authorization was discussed repeatedly, and the general > >>>>assumption was > >>>>>that there were two conditions: Either the user invoking > resource- > >>>>>priority was well known and had a set of permissions > that could be > >>>>>checked in real time or there are ways to deal with > abuse after the > >>>>>fact in ways that deter abuse (the court-martial kind of > thing in a > >>>>>military context). > >>>>> > >>>>>The RFC 4412 security consideration (11.2) call this out > in pretty > >>>>>strong language: > >>>>> > >>>>> Prioritized access to network and end-system resources imposes > >>>>> particularly stringent requirements on authentication and > >>>>> authorization mechanisms, since access to prioritized > >>>>resources may > >>>>> impact overall system stability and performance and not > >>>>just result > >>>>> in theft of, say, a single phone call. > >>>>>Thus, the question is whether we have such strong > authentication in > >>>>>emergency calling. In some cases, such as residential fixed line > >>>>>deployments where ISP =3D VSP, we're probably pretty close, > >in others, > >>>>>such as prepaid cell phones or hot spots or VSP-only > providers, we > >>>>>aren't. > >>>>> > >>>>>The other point that I think Hannes is making is that the > >>>>information > >>>>>is either redundant or dangerous. If a processing element > >recognizes > >>>>>the call as being an emergency call, it can apply whatever > >treatment > >>>>>it deems appropriate and doesn't need additional > information. If it > >>>>>doesn't or can't, using just the RPH can be rather > dangerous unless > >>>>>that element can be reasonably certain that there is strong > >>>>>authentication and recourse. > >>>>> > >>>>>I don't buy the argument that somehow finding the RPH is > >faster than > >>>>>just looking for the identifier. Thus, given that the > >information is > >>>>>either redundant or dangerous, I fail to see the advantage. > >>>>> > >>>>>Henning > >>>>> > >>>>> > >>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > >>>>> > >>>>>>Don't get hung up on the details. There are ways to optimize it. > >>>>>>That was > >>>>>>not the point of the code example. > >>>>>> > >>>>>>The problem that my pseudo code should have shown you > is that you > >>>>>>* don't gain anything with RPH marking for the > emergency call case > >>>>>>from the SIP UA towards the outbound proxy since the > functionality > >>>>>>is already provide otherwise. How often does the proxy > need to get > >>>>>>told that this is an emergency call todo whatever > emergency call > >>>>>>handling procedures are necessary? > >>>>>>* you only introduce fraud problems (if you are not > >>>>careful and you > >>>>>>understand the security stuff well enough) > >>>>>> > >>>>>>If you can point me to people who implement the RPH > emergency call > >>>>>>case please do so. I would love to talk to them. > >>>>>> > >>>>>>Ciao > >>>>>>Hannes > >>>>>> > >>>>>>PS: You need to parse incoming messages to some extend > so that you > >>>>>>know what it contains :-) Only looking for the emergency > >>>>RPH header > >>>>>>(and not for the Service URN/dial > >>>>>>string) would exactly be the DoS/fraud attack I am > worried about. > >>>>>>That's the thing Henning was worried about (go and > listen to the > >>>>>>past meeting minutes). > >>>>>> > >>>>>> > >>>>>>>Hannes > >>>>>>> > >>>>>>>You need to talk to people who really implement this kind > >>>>of thing. > >>>>>>>You are way off. > >>>>>>> > >>>>>>>When you implement a resource priority system, the > point of doing > >>>>>>>that is to look though the queue of work and pick out the > >>>>ones with > >>>>>>>priority, handling them first. You don't do all the > parsing, you > >>>>>>>don't do a lot of decision tree. > >>>>>>> > >>>>>>>Typically: > >>>>>>>Check for DoS things, like too big messages, etc Do a > quick scan > >>>>>>>for the RPH message header If found: > >>>>>>>Parse the message > >>>>>>>Determine validity > >>>>>>>Determine priority > >>>>>>>Queue on the correct work queue > >>>>>>> > >>>>>>>The first two actions have to be very fast. Anyone > who builds a > >>>>>>>SIP thingie will tell you that parsing is one of the big cycle > >>>>>>>consumers: if you have to parse every message BEFORE you > >>>>determine > >>>>>>>priority, you can't give much resource priority. > >>>>>>>Once you get the whole message parsed, you might as > well finish > >>>>>>>working on it, because you've done so much of the work. > >>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick > >>>>>>>string search for RPH is fast. If you are doing > >>>>priority, you need > >>>>>>>to keep all the priority processing pretty uniform, and pretty > >>>>>>>simple, or you tend to spend too much time futzing around > >>>>figuring > >>>>>>>out what to do. You put all the priority related > stuff together, > >>>>>>>and use as much common code as possible. > >>>>>>> > >>>>>>>Brian > >>>>>>> > >>>>>>>>-----Original Message----- > >>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>>>>>>On Behalf > >>>>>>>>Of Hannes Tschofenig > >>>>>>>>Sent: Friday, February 06, 2009 8:41 AM > >>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn' > >>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >>>>>>>>bounces@ietf.org > >>>>>>>>Subject: [Ecrit] RPH > >>>>>>>> > >>>>>>>>Over lunch I was also thinking how an outbound proxy would > >>>>>implement > >>>>>>>>some of the emergency procedures. Here are some thoughts: > >>>>>>>> > >>>>>>>>--------------------------------------------------- > >>>>>>>> > >>>>>>>>// Process incoming message > >>>>>>>>Parse(msg); > >>>>>>>> > >>>>>>>>// SIP INVITE without Service URN // legacy devices If > >>>>>>>>(recognize-dialstring(msg)=3D=3DTRUE) { // we got an > emergency call > >>>>>>>>going on emergency=3DTRUE; if (dialstring(msg) =3D=3D 911) > >>>>>>>>serviceURN=3Durn:service:sos; } else if > >>>>>>>>(recognize-serviceURN(msg)=3D=3DTRUE) { // oh. A updated > >>>>device that > >>>>>>>>has a service URN attached to the > >>>>>call > >>>>>>>>serviceURN=3Dretrieve_ServiceURN(msg); > >>>>>>>>emergency=3DTRUE; > >>>>>>>>} else { > >>>>>>>>// standard SIP message > >>>>>>>>// regular processing > >>>>>>>>process(msg); > >>>>>>>>emergency=3DFALSE; > >>>>>>>>} > >>>>>>>> > >>>>>>>>If (emergency =3D=3D TRUE) { > >>>>>>>> // make sure that the emergency call does not get > >>>>dropped on the > >>>>>>>>floor > >>>>>>>> // skip authorization failures > >>>>>>>> // give the call a special treatment > >>>>>>>> lots-of-code-here(); > >>>>>>>> > >>>>>>>> // trigger all the QoS signaling you have in the > >>>>network to make > >>>>>>>>James happy > >>>>>>>> trigger-qos(); > >>>>>>>> > >>>>>>>> // query location > >>>>>>>> location=3Dretrieve-location(); > >>>>>>>> > >>>>>>>> // determine next hop > >>>>>>>> next-hop=3Dlost(location, serviceURN) > >>>>>>>> > >>>>>>>> // attach RPH marking to outgoing msg to make James and > >>>>>>>Keith happy > >>>>>>>> msg=3Dadd(msg, RPH); > >>>>>>>> > >>>>>>>> send(msg, next-hop); > >>>>>>>>} > >>>>>>>> > >>>>>>>>If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) { > >>>>>>>> // all the emergency related processing done already upfront > >>>>>>>> // hence I log something. > >>>>>>>> log(RPH_WAS_PRESENT_JUHU); > >>>>>>>>} else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D > >>>>FALSE)) { > >>>>>>>>// this is not an emergency call // this is something > >>>>like GETS > >>>>>>>>result=3Dspecial-authorization-procedure(user); > >>>>>>>> > >>>>>>>>if (result =3D=3D AUTHORIZED) { > >>>>>>>> // do some priority & preemption thing here. > >>>>>>>> // trigger all the QoS you have > >>>>>>>> lots-of-code-here(); > >>>>>>>>} else { > >>>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } > else { // > >>>>>>>>don't need todo any RPH processing // this includes the case > >>>>>>>>where the call was an emergency call but the RPH > >>>>>>>> > >>>>>>>>// marking was not there. > >>>>>>>>nothing(); > >>>>>>>>} > >>>>>>>> > >>>>>>>>--------------------------------------------------- > >>>>>>>> > >>>>>>>> > >>>>>>>>Ciao > >>>>>>>>Hannes > >>>>>>>> > >>>>>>>>>-----Original Message----- > >>>>>>>>>From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > >>>>>>>>>Behalf Of Hannes Tschofenig > >>>>>>>>>Sent: 06 February, 2009 15:07 > >>>>>>>>>To: 'Janet P Gunn' > >>>>>>>>>Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - > >>>>>>>>FI/Espoo) > >>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (RPH) > >>>>>>>>> > >>>>>>>>>Who would define something that could prevent DoS problems? > >>>>>>>>> > >>>>>>>>>________________________________ > >>>>>>>>> > >>>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >>>>>>>>> Sent: 06 February, 2009 14:11 > >>>>>>>>> To: Hannes Tschofenig > >>>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >>>>>>>>>ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); > >>>>>'James > >>>>>>>>>M. Polk' > >>>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>>Meeting: Agenda (RPH) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> But there is nothing IN RFC4412 that specifically > >>>>>>>addresses how to > >>>>>>>>>prevent any particular namespace being used for DoS. > >Anyone/any > >>>>>UA > >>>>>>>>>can ATTEMPT to invoke priority treatment by > attaching RPH. For > >>>>>all > >>>>>>>>>of the 4412 namespaces, as with the new proposed > namespace, the > >>>>>>>>>mechanisms for preventing DoS are not specified in the > >>>>>>>document that > >>>>>>>>>defines the namespace. > >>>>>>>>>They are/will be specified elsewhere. > >>>>>>>>> > >>>>>>>>> Janet > >>>>>>>>> > >>>>>>>>> This is a PRIVATE message. If you are not > the intended > >>>>>>>recipient, > >>>>>>>>>please delete without copying and kindly advise us > by e-mail of > >>>>>the > >>>>>>>>>mistake in delivery. > >>>>>>>>> NOTE: Regardless of content, this e-mail shall not > >>>>>>>operate to bind > >>>>>>>>>CSC to any order or other contract unless pursuant > to explicit > >>>>>>>>>written agreement or government initiative expressly > permitting > >>>>>the > >>>>>>>>>use of e-mail for such purpose. > >>>>>>>>> > >>>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 > >04:21:51 AM: > >>>>>>>>> > >>>>>>>>> > Hi James, > >>>>>>>>> > > >>>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >>>>>>>documents. What I > >>>>>>>>>would > >>>>>>>>> > like to point out is that there is more > than just a > >>>>>>>header and > >>>>>>>>>values within > >>>>>>>>> > the header that have to be considered in order to > >>>>>>>make a judgement > >>>>>>>>>of what > >>>>>>>>> > is appropriate and what isn't. There is an > >>>>>>>architectural question > >>>>>>>>>and > >>>>>>>>> > whether the environment we are using the stuff is > >>>>>>>indeed providing > >>>>>>>>>the > >>>>>>>>> > properties you need for the solution to be > >>>>appropriate. > >>>>>>>>> > > >>>>>>>>> > Let me describe in more detail what I meant (and > >>>>>>>please correct me > >>>>>>>>>if I am > >>>>>>>>> > wrong). > >>>>>>>>> > > >>>>>>>>> > Getting priority for SIP requests when > using a GETS > >>>>>>>alike scenario > >>>>>>>>>means > >>>>>>>>> > that the entity that issues the request > is specially > >>>>>>>authorized > >>>>>>>>>since > >>>>>>>>> > otherwise you introduce a nice denial of > >>>>service attack. This > >>>>>>>>>authorization > >>>>>>>>> > is tied to the entity that makes the request. For > >>>>>>>example, the > >>>>>>>>>person is > >>>>>>>>> > working for the government and has special rights. > >>>>>>>>>James Bond as a (not so) > >>>>>>>>> > secret agent might have these rights. > >>>>>>>>> > > >>>>>>>>> > The emergency services case > >>>>(citizen-to-authority) is a bit > >>>>>>>>>different as > >>>>>>>>> > there aren't really special rights with respect to > >>>>>>>authorization > >>>>>>>>>tied to > >>>>>>>>> > individuals. Instead, the fact that > something is an > >>>>>>>emergency is > >>>>>>>>>purely a > >>>>>>>>> > judgement of the human that dials a > special number. > >>>>>>>>>To deal with fraud, we > >>>>>>>>> > discussed in the group on what we can > actually do to > >>>>>>>ensure that > >>>>>>>>>end users > >>>>>>>>> > do not bypass security procedures (such as > >>>>>>>authorization checks, > >>>>>>>>>charging > >>>>>>>>> > and so on). Part of this investigation was > >>>>the publication of > >>>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also > >>>>describes this > >>>>>>>>>issue. > >>>>>>>>> > > >>>>>>>>> > So, imagine the implementation of a SIP > >proxy (and we > >>>>>>>implemented > >>>>>>>>>that > >>>>>>>>> > stuff) that receives a call that contains > a Service > >>>>>>>URN. The code > >>>>>>>>>branches > >>>>>>>>> > into a special mode where everything is done > >>>>so that the call > >>>>>>>>>receives > >>>>>>>>> > appropriate treatment and does not get > >dropped on the > >>>>>>>floor. The > >>>>>>>>>way how the > >>>>>>>>> > Service URN is placed in the message > >ensures that the > >>>>>>>call cannot > >>>>>>>>>go to my > >>>>>>>>> > friend (instead of the PSAP) unless the > end host ran > >>>>>>>LoST already. > >>>>>>>>>In the > >>>>>>>>> > latter case, we discussed this also on the > >list for a > >>>>>>>while and > >>>>>>>>>Richard even > >>>>>>>>> > wrote a draft about it in the context of the > >>>>location hiding > >>>>>>>>>topic, we said > >>>>>>>>> > that the proxy would have to run LoST if he > >>>>cares about a > >>>>>>>>>potential > >>>>>>>>> > fraudulent usage. > >>>>>>>>> > > >>>>>>>>> > So, what do we need todo in order to provide > >>>>secure RFC 4412 > >>>>>>>>>functionality > >>>>>>>>> > in our context? > >>>>>>>>> > > >>>>>>>>> > Do you think that the current text in > >>>>>>>>> > > >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit- > local-emer > >>>>>>>>>gency-rph-nam > >>>>>>>>> > espace-00.txt reflects any of the > >>>>above-described issues: > >>>>>>>>> > " > >>>>>>>>> > The Security considerations that apply > >to RFC 4412 > >>>>>>>>>[RFC4412] > >>>>>>>>>apply > >>>>>>>>> > here. This document introduces no new security > >>>>>>>>>issues relative > >>>>>>>>>to > >>>>>>>>> > RFC 4412. > >>>>>>>>> > " > >>>>>>>>> > > >>>>>>>>> > From various discussions in GEOPRIV I recall > >>>>that you are > >>>>>>>>>super-sensitive > >>>>>>>>> > regarding security and privacy. For some > reasons you > >>>>>>>don't seem to > >>>>>>>>>have the > >>>>>>>>> > same concerns here. I would like to > >>>>understand your reasoning. > >>>>>>>>> > > >>>>>>>>> > Please also do me another favor: Don't always say > >>>>>>>that I don't > >>>>>>>>>understand > >>>>>>>>> > the subject. Even if that would be the > case it isn't > >>>>>>>particular > >>>>>>>>>fair given > >>>>>>>>> > that different folks had to educate you on other > >>>>>>>topics in the > >>>>>>>>>past as well. > >>>>>>>>> > Additionally, if you listen to the audio > recordings > >>>>>>>then you will > >>>>>>>>>notice > >>>>>>>>> > that Henning, Ted, and Jon do not seem to > understand > >>>>>>>the issue > >>>>>>>>>either as > >>>>>>>>> > they have raised similar issues during the > >>>>F2F meetings. > >>>>>>>>> > > >>>>>>>>> > Ciao > >>>>>>>>> > Hannes > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > >Hannes - I believe it is you who do not > understand > >>>>>>>RFC 4412 -- > >>>>>>>>> > >and many of us are trying to get that > >>>>through to you, but you > >>>>>>>>> > >don't seem to want to listen/read. > >>>>>>>>> > > > >>>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, > >>>>>>>>> > > > >>>>>>>>> > >One use is GETS. > >>>>>>>>> > > > >>>>>>>>> > >One use is MLPP. > >>>>>>>>> > > > >>>>>>>>> > >These examples are in RFC 4412 because there > >>>>were specific > >>>>>>>>> > >namespaces being created for the IANA section of > >>>>>>>that document. > >>>>>>>>> > > > >>>>>>>>> > >Reading the whole document, you will see > >>>>that RPH can be > >>>>>>>>> > >specified for other uses than GETS or MLPP > >>>>specifically. > >>>>>>>>> > > > >>>>>>>>> > >I knew when I wrote RFC 4412 that one day we > >>>>would specify a > >>>>>>>>> > >namespace for ECRIT (the "esnet" namespace > >>>>now) -- but I also > >>>>>>>>> > >knew it was premature for RFC 4412 to > >>>>incorporate that > >>>>>>>>> > >namespace, that a future doc to RFC 4412 > >>>>would have to be > >>>>>>>>> > >written to do this. Brian and I talked about > >>>>this at the > >>>>>>>>> > >original NENA meeting that created the > IP WGs there > >>>>>>>(in August > >>>>>>>>> > >of 03). We both agreed we should wait > until it was > >>>>>>>>> > >appropriate to the work in the IETF to > >>>>submit this document > >>>>>>>>> > >that is now > >>>>>>>>> > > >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l > >ocal-emer > >>>>>>>>> > >gency-rph-namespace-00.txt > >>>>>>>>> > > > >>>>>>>>> > >Yet, you seem to want to use some additional > >>>>mechanism to > >>>>>>>>> > >indicate priority of a call in SIP. That > >>>>means you want to > >>>>>>>>> > >introduce a second way to accomplish this in SIP. > >>>>>>>>>Why do you > >>>>>>>>> > >want to promote a separate way to do > something SIP > >>>>>>>has already > >>>>>>>>> > >defined? That will cause interoperability > >issues and > >>>>>>>we both know > >>>>>>>>>that. > >>>>>>>>> > > > >>>>>>>>> > >You've said to me (and others) that you > >>>>believe RPH is just > >>>>>>>>> > >another way to accomplish what sos or a URI can > >>>>>>>indicate - and > >>>>>>>>> > >you're wrong. Your way would be > >>>>_the_second_way_to_do_it, > >>>>>>>>> > >because SIP already considers RPH to be > >>>>*the*way* to priority > >>>>>>>>> > >mark SIP requests. > >>>>>>>>> > > > >>>>>>>>> > >If you don't believe me (no comment), then > >>>>why do you not > >>>>>>>>> > >believe the SIP WG chair (who knows more > >>>>about SIP than both > >>>>>>>>> > >of us) - who, on this thread, has again said > >>>>to you "RFC 4412 > >>>>>>>>> > >(RPH) is the SIP mechanism to priority mark > >>>>SIP requests"? > >>>>>>>>> > > > >>>>>>>>> > >Further, I believe it is inappropriate to > >>>>prohibit endpoints > >>>>>>>>> > >from being able to set the esnet namespace. > >>>>I absolutely > >>>>>>>>> > >believe it will not be needed most of the > >>>>time, but I believe > >>>>>>>>> > >if someone does find a valid use for > >>>>endpoints to mark > >>>>>>>>> > >priority in SIP, this ID - once it has > >>>>become an RFC -- will > >>>>>>>>> > >have to be obsoleted with a new RFC saying > >the exact > >>>>>>>opposite. > >>>>>>>>> > > > >>>>>>>>> > >(color me confused ... over and over again) > >>>>>>>>> > > > >>>>>>>>> > >James > >>>>>>>>> > > > >>>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >>>>>>>>> > >>Keith, please understand that the usage > >of RFC 4412 > >>>>>>>for GETS and > >>>>>>>>>for > >>>>>>>>> > >>the type of emergency call we discuss here is > >>>>>>>different. Just > >>>>>>>>>looking > >>>>>>>>> > >>at the header and the name of the > >namespace is a bit > >>>>>>>>> > >artificial. I hope > >>>>>>>>> > >>you understand that. > >>>>>>>>> > >> > >>>>>>>>> > >> >-----Original Message----- > >>>>>>>>> > >> >From: DRAGE, Keith (Keith) > >>>>>>>>>[mailto:drage@alcatel-lucent.com] > >>>>>>>>> > >> >Sent: 05 February, 2009 14:55 > >>>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; > 'James M. > >>>>>>>>>Polk'; 'Tschofenig, > >>>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >>>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>>>>>>>Meeting: Agenda (my > >>>>>>>>> > >>>>>>>>> > >> >mistake) > >>>>>>>>> > >> > > >>>>>>>>> > >> >Which is exactly what RFC 4412 > specifies for all > >>>>>>>namespaces. > >>>>>>>>> > >> > > >>>>>>>>> > >> >regards > >>>>>>>>> > >> > > >>>>>>>>> > >> >Keith > >>>>>>>>> > >> > > >>>>>>>>> > >> >> -----Original Message----- > >>>>>>>>> > >> >> From: ecrit-bounces@ietf.org > >>>>>>>[mailto:ecrit-bounces@ietf.org] > >>>>>>>>> > >> >On Behalf > >>>>>>>>> > >> >> Of Brian Rosen > >>>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >>>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. > >>>>Polk'; 'Tschofenig, > >>>>>>>>> > >Hannes (NSN > >>>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' > >>>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >>>>>>>>>Meeting: Agenda (my > >>>>>>>>> > >> >> mistake) > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> The value is that in some networks > >>>>where priority for > >>>>>>>>> > >> >emergency calls > >>>>>>>>> > >> >> is appropriate, and appropriate > >>>>policing of marking is > >>>>>>>>> > >implemented, > >>>>>>>>> > >> >> emergency calls will receive resource > >priority. > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> Not all networks would need policing. Some > >>>>>>>will. Policing > >>>>>>>>>could > >>>>>>>>> > >> >> be to Route header/R-URI content, but other > >>>>>>>criteria are > >>>>>>>>>possible. > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> Not all networks will need resource priority > >>>>>>>for emergency > >>>>>>>>>calls. > >>>>>>>>> > >> >> Fine, ignore this marking/namespace. > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> Brian > >>>>>>>>> > >> >> > -----Original Message----- > >>>>>>>>> > >> >> > From: Hannes Tschofenig > >>>>>>>>>[mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >>>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >>>>>>>Tschofenig, Hannes > >>>>>>>>>(NSN - > >>>>>>>>> > >> >> > FI/Espoo); 'ECRIT' > >>>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >>>>>>>>>Meeting: Agenda (my > >>>>>>>>> > >> >> > mistake) > >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > I don't even see the value in > permitting the > >>>>>>>endpoint todo > >>>>>>>>>the > >>>>>>>>> > >> >> > RPH marking. > >>>>>>>>> > >> >> > In addition to the security concerns > >>>>there is also the > >>>>>>>>> > >> >problem that > >>>>>>>>> > >> >> > there are more options to > implement without > >>>>>>>an additional > >>>>>>>>>value. > >>>>>>>>> > >> >> > > >>>>>>>>> > >> >> > >-----Original Message----- > >>>>>>>>> > >> >> > >From: Brian Rosen > >[mailto:br@brianrosen.net] > >>>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 > >>>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >>>>>>>'Tschofenig, > >>>>>>>>> > >> >> Hannes (NSN - > >>>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >>>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual > >>>>Interim Meeting: > >>>>>>>>>Agenda (my > >>>>>>>>> > >> >> > mistake) > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >Hannes > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >This matches my understanding > >>>>precisely. We wish to > >>>>>>>>> > >> >> permit endpoints > >>>>>>>>> > >> >> > >to mark. We do not require it, and > >>>>don't necessarily > >>>>>>>>>expect it > >>>>>>>>> > >> >> > >in many (even > >>>>>>>>> > >> >> > >most) cases. We don't wish to see the > >>>>>>>document prohibit > >>>>>>>>>it. > >>>>>>>>> > >> >> > >We all seem to agree it has value > >within the > >>>>>>>Emergency > >>>>>>>>> > >> >Services IP > >>>>>>>>> > >> >> > >Networks. > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >Brian > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >> -----Original Message----- > >>>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org > >>>>>>>>>[mailto:ecrit-bounces@ietf.org] > >>>>>>>>> > >> >> > >On Behalf > >>>>>>>>> > >> >> > >> Of James M. Polk > >>>>>>>>> > >> >> > >> Sent: Wednesday, February 04, > >2009 4:01 PM > >>>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, > >>>>Hannes (NSN - > >>>>>>>>> > >> >> FI/Espoo); 'ECRIT' > >>>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT > >Virtual Interim > >>>>>>>>>Meeting: > >>>>>>>>> > >Agenda (my > >>>>>>>>> > >> >> > >> mistake) > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes > >>>>Tschofenig wrote: > >>>>>>>>> > >> >> > >> > > James wrote: > >>>>>>>>> > >> >> > >> > >> you are the _lone_ voice not > >>>>>>>supporting this ID, > >>>>>>>>> > >> >> > >> > > >>>>>>>>> > >> >> > >> >Listening to the audio > recording of past > >>>>>>>meetings I > >>>>>>>>>have to > >>>>>>>>> > >> >> > >say that > >>>>>>>>> > >> >> > >> >I > >>>>>>>>> > >> >> > >> was > >>>>>>>>> > >> >> > >> >not the only persons raising > >>>>concerns about the > >>>>>>>>>document. > >>>>>>>>> > >> >> > >> >That was probably the reason why you > >>>>>>>agreed to limit > >>>>>>>>>the > >>>>>>>>> > >> >> > >scope of the > >>>>>>>>> > >> >> > >> >document (which you didn't > later do) to > >>>>>>>get folks to > >>>>>>>>>agree > >>>>>>>>> > >> >> > >to make it > >>>>>>>>> > >> >> > >> a WG > >>>>>>>>> > >> >> > >> >item. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> re-listen to the audio please > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> Ted's concerns were consistent > with most > >>>>>>>>>(all?) other > >>>>>>>>> > >> >> concerns -- > >>>>>>>>> > >> >> > >> which were based on the premise > >of whether > >>>>>>>or not the > >>>>>>>>> > >> >> UAC should be > >>>>>>>>> > >> >> > >> trusted to initiate the marking on the > >>>>>>>INVITE. The > >>>>>>>>>most > >>>>>>>>> > >> >> > >> recent version has backed off this > >>>>to a "can" -- > >>>>>>>>>meaning not > >>>>>>>>> > >> >prohibited > >>>>>>>>> > >> >> > >> (i.e., no 2119 text). I also > backed off > >>>>>>>the text in > >>>>>>>>>the > >>>>>>>>> > >> >> SP domain > >>>>>>>>> > >> >> > >> part to "can", such that there is > >>>>no 2119 text > >>>>>>>>> > >> >mandating or even > >>>>>>>>> > >> >> > >> recommending its usage there. I also do > >>>>>>>not prohibit > >>>>>>>>>its > >>>>>>>>> > >> >> > >use, based on > >>>>>>>>> > >> >> > >> local policy. Keith has come > >forward with > >>>>>>>the specific > >>>>>>>>> > >>>>>>>>> > >> >> > >> request that non-ESInet networks be > >>>>>>>allowed to mark and > >>>>>>>>>pay > >>>>>>>>> > >> >attention to > >>>>>>>>> > >> >> > >> this priority indication -- with IMS as > >>>>>>>the specific > >>>>>>>>>example > >>>>>>>>> > >> >> > >> he wishes to have this valid for. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> Where there is no > disagreement, save for > >>>>>>>your recent > >>>>>>>>> > >> >> > >pushback - is in > >>>>>>>>> > >> >> > >> the ESInet, which is where Brian > >>>>has requested it's > >>>>>>>>> > >> >> > >definition in the > >>>>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >>>>>>>chair within > >>>>>>>>> > >> >> NENA, and if > >>>>>>>>> > >> >> > >> he asks for it, are you going > to say you > >>>>>>>know better > >>>>>>>>>than he? > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> >Btw, I not disagreeing with > the document > >>>>>>>as such. I > >>>>>>>>> > >> >just want to > >>>>>>>>> > >> >> > the > >>>>>>>>> > >> >> > >> scope > >>>>>>>>> > >> >> > >> >to change. The usage of RPH > >>>>within the emergency > >>>>>>>>> > >> >> services network > >>>>>>>>> > >> >> > is > >>>>>>>>> > >> >> > >> fine > >>>>>>>>> > >> >> > >> >for me. I may get convinced > to start the > >>>>>>>RPH marking > >>>>>>>>>from > >>>>>>>>> > >> >> > >the the VSP > >>>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy > >about the > >>>>>>>end host > >>>>>>>>>doing > >>>>>>>>> > >> >> > >the marking. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> please read what I wrote > above, and then > >>>>>>>re-read the > >>>>>>>>> > >> >most recent > >>>>>>>>> > >> >> > >> version of the ID. I don't > have endpoints > >>>>>>>that SHOULD > >>>>>>>>>or > >>>>>>>>> > >> >> MUST mark > >>>>>>>>> > >> >> > >> anything wrt RPH. I also don't want to > >>>>>>>prohibit it, > >>>>>>>>> > >> >> because there > >>>>>>>>> > >> >> > >> might be cases (that I don't know > >>>>of) of valid uses > >>>>>>>>> > >> >> under certain > >>>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear > >>>>>>>that there are 3 > >>>>>>>>> > >> >> networking > >>>>>>>>> > >> >> > >> parts to consider > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> #1 - from the endpoint > >>>>>>>>> > >> >> > >> #2 - within the VSP > >>>>>>>>> > >> >> > >> #3 - within the ESInet > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> the most recent ID version has > "can" for > >>>>>>>#s 1 and 2, > >>>>>>>>>and > >>>>>>>>> > >> >> > >2119 language > >>>>>>>>> > >> >> > >> offering those supporting this > >>>>>>>specification will have > >>>>>>>>>RPH > >>>>>>>>> > >> >> > >> adherence within #3 (the ESInet). > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> What other scope changes do you want, > >>>>>>>because I haven't > >>>>>>>>> > >> >> heard them. > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> I only heard you claim in email > >during the > >>>>>>>last IETF > >>>>>>>>>and in > >>>>>>>>> > >> >> > >the ECRIT > >>>>>>>>> > >> >> > >> session that RPH should not be > >>>>used for priority > >>>>>>>>>marking > >>>>>>>>> > >> >> requests. > >>>>>>>>> > >> >> > >> This is something Keith (SIP WG > >>>>chair) voiced his > >>>>>>>>>opposition > >>>>>>>>> > >> >> > >> to your views regarding > creating a second > >>>>>>>means for SIP > >>>>>>>>>to > >>>>>>>>> > >> >priority > >>>>>>>>> > >> >> > >> mark request "when SIP already has one > >>>>>>>interoperable > >>>>>>>>>way to > >>>>>>>>> > >> >> > >> accomplish this... it's call the > >RP header > >>>>>>>mechanism". > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> >I don't see advantages -- only > >>>>disadvantages. > >>>>>>>>> > >> >> > >> > > >>>>>>>>> > >> >> > >> >Ciao > >>>>>>>>> > >> >> > >> >Hannes > >>>>>>>>> > >> >> > >> > >>>>>>>>> > >> >> > >> > >>>>_______________________________________________ > >>>>>>>>> > >> >> > >> Ecrit mailing list > >>>>>>>>> > >> >> > >> Ecrit@ietf.org > >>>>>>>>> > >> >> > >> > >https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >> >> > > > >>>>>>>>> > >> >> > >>>>>>>>> > >> >> > >_______________________________________________ > >>>>>>>>> > >> >> Ecrit mailing list > >>>>>>>>> > >> >> Ecrit@ietf.org > >>>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >> >> > >>>>>>>>> > >> > > >>>>>>>>> > > > >>>>>>>>> > > >>>>>>>>> > _______________________________________________ > >>>>>>>>> > Ecrit mailing list > >>>>>>>>> > Ecrit@ietf.org > >>>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>_______________________________________________ > >>>>>>>>>Ecrit mailing list > >>>>>>>>>Ecrit@ietf.org > >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>>_______________________________________________ > >>>>>>>>Ecrit mailing list > >>>>>>>>Ecrit@ietf.org > >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Ecrit mailing list > >>>>>>Ecrit@ietf.org > >>>>>>https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >>>------------------------------------------------------------- > >----------------------------------- > >>>This message is for the designated recipient only and may contain > >>>privileged, proprietary, or otherwise private information. > >>>If you have received it in error, please notify the sender > >>>immediately and delete the original. Any unauthorized use of this > >>>email is prohibited. > >>>------------------------------------------------------------- > >----------------------------------- > >>>[mf2] > >>> > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325AB28C105 for ; Fri, 6 Feb 2009 16:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.985 X-Spam-Level: X-Spam-Status: No, score=-4.985 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZeTZclUMIuN for ; Fri, 6 Feb 2009 16:48:35 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id B37BF28C104 for ; Fri, 6 Feb 2009 16:48:34 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n170m3QS028283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Feb 2009 01:48:03 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 7 Feb 2009 01:48:03 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "'James M. Polk'" Date: Sat, 7 Feb 2009 01:47:57 +0100 Thread-Topic: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) Thread-Index: AcmIppJ3db5pt/4hRciq0u3Zrgn8DQABfvUgAAQ5v+A= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA12@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <000001c988ac$d0261940$0201a8c0@nsnintra.net> In-Reply-To: <000001c988ac$d0261940$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:48:37 -0000 I don't believe anyone has been saying that. GETS and emergency are two dif= ferent namespaces that work within the overvall framework of RPH. You implement RPH, and then configure or tailor it to the namespaces you ne= ed to support, not provide a separate implementation for every namespace yo= u are called upon to support. Go that way and every request will take hours to traverse end to end. regards Keith > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, February 06, 2009 10:47 PM > To: 'James M. Polk' > Cc: DRAGE, Keith (Keith); 'Brian Rosen'; Tschofenig, Hannes > (NSN - FI/Espoo); 'ECRIT' > Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) > > Good that you agree that GETS usage of RPH and the one we > discuss in ECRIT is different. > So far, some folks have been saying "what works for GETS > works for the ECRIT case as well". > > I argued that the environment is different and hence just > referencing RFC > 4412 isn't good enough. > > >-----Original Message----- > >From: James M. Polk [mailto:jmpolk@cisco.com] > >Sent: 07 February, 2009 00:02 > >To: Hannes Tschofenig > >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, Hannes (NSN - > >FI/Espoo); 'ECRIT' > >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) > > > >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote: > >>Hi James, > >> > >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I > >>would like to point out is that there is more than just a > header and > >>values within the header that have to be considered in order > >to make a > >>judgement of what is appropriate and what isn't. There is an > >>architectural question and whether the environment we are using the > >>stuff is indeed providing the properties you need for the > >solution to be appropriate. > >> > >>Let me describe in more detail what I meant (and please > >correct me if I > >>am wrong). > >> > >>Getting priority for SIP requests when using a GETS alike scenario > >>means that the entity that issues the request is specially > authorized > >>since otherwise you introduce a nice denial of service attack. > > > >You are missing a step in GETS here. The endpoint, who > sends the GETS > >set-up as an INVITE is not already authorized (not the > device, not the > >user). In North America, there is a 10 digit GETS number that is > >dialed (that I won't give out right now on an open list) - and there > >literally is only 1 number available to dial for this service. > >Literally anyone can dial this number today in North America > (no matter > >where the phone is - as long as it is in North America -- > and I might > >be too limiting in that it is dialable from anywhere, because it is > >going to a North American destination). > > > >Once this number is dialed, it is answered by an authentication and > >authorization IVR. This IVR challenges each caller for their > >authentication passcode, and a password). Once this has been > >successfully entered, then call is NOW authorized to proceed towards > >its destination number - this step is only known to the authorizing > >system because the destination 10 digit number is NOT entered until > >after the authentication and authorization step has completed. > > > >The authorized caller is prompted with a new dial tone - in > which they > >can enter any number on the planet and receive preferential > treatment > >through as many carriers (in IP, it's > >SPs) that have implemented this GETS service (which is an > SLA with the > >Department of Homeland Security now). > > > >Merely entering the GETS RP namespace is never intended, > alone, to gain > >any preferential treatment -- other than towards this > authentication & > >authorization IVR. > > > >I hope you can see that this is a completely separate type > of service > >and implementation type than ECRIT based emergency calling will use. > > > >BTW - to your comment below about me not calling your name > out when you > >are incorrect because I have been equally incorrect > >-- I'm not sure I've been spared as much as you think, given > that many > >have called me out by name when they've felt I've been wrong > over the > >years. > > > >>This authorization > >>is tied to the entity that makes the request. For example, > the person > >>is working for the government and has special rights. James > Bond as a > >>(not so) secret agent might have these rights. > >> > >>The emergency services case (citizen-to-authority) is a bit > different > >>as there aren't really special rights with respect to authorization > >>tied to individuals. Instead, the fact that something is an > emergency > >>is purely a judgement of the human that dials a special > >number. To deal > >>with fraud, we discussed in the group on what we can actually do to > >>ensure that end users do not bypass security procedures (such as > >>authorization checks, charging and so on). Part of this > investigation > >>was the publication of http://www.ietf.org/rfc/rfc5069.txt > >that also describes this issue. > >> > >>So, imagine the implementation of a SIP proxy (and we > implemented that > >>stuff) that receives a call that contains a Service URN. The code > >>branches into a special mode where everything is done so that > >the call > >>receives appropriate treatment and does not get dropped on > the floor. > >>The way how the Service URN is placed in the message > ensures that the > >>call cannot go to my friend (instead of the PSAP) unless > the end host > >>ran LoST already. In the latter case, we discussed this also on the > >>list for a while and Richard even wrote a draft about it in > >the context > >>of the location hiding topic, we said that the proxy would > >have to run > >>LoST if he cares about a potential fraudulent usage. > >> > >>So, what do we need todo in order to provide secure RFC 4412 > >>functionality in our context? > >> > >>Do you think that the current text in > >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme > >rgency-rp > >>h-nam espace-00.txt reflects any of the above-described issues: > >>" > >> The Security considerations that apply to RFC 4412 > [RFC4412] apply > >> here. This document introduces no new security issues > relative to > >> RFC 4412. > >>" > >> > >> From various discussions in GEOPRIV I recall that you are > >>super-sensitive regarding security and privacy. For some > reasons you > >>don't seem to have the same concerns here. I would like to > >understand your reasoning. > >> > >>Please also do me another favor: Don't always say that I don't > >>understand the subject. Even if that would be the case it isn't > >>particular fair given that different folks had to educate you > >on other topics in the past as well. > >>Additionally, if you listen to the audio recordings then you will > >>notice that Henning, Ted, and Jon do not seem to understand > the issue > >>either as they have raised similar issues during the F2F meetings. > >> > >>Ciao > >>Hannes > >> > >> > >> >Hannes - I believe it is you who do not understand RFC > 4412 -- and > >> >many of us are trying to get that through to you, but you > >don't seem > >> >to want to listen/read. > >> > > >> >RFC 4412 is *for* priority marking SIP requests, > >> > > >> >One use is GETS. > >> > > >> >One use is MLPP. > >> > > >> >These examples are in RFC 4412 because there were specific > >namespaces > >> >being created for the IANA section of that document. > >> > > >> >Reading the whole document, you will see that RPH can be > specified > >> >for other uses than GETS or MLPP specifically. > >> > > >> >I knew when I wrote RFC 4412 that one day we would specify a > >> >namespace for ECRIT (the "esnet" namespace now) -- but I > >also knew it > >> >was premature for RFC 4412 to incorporate that namespace, that a > >> >future doc to RFC 4412 would have to be written to do this. > >Brian and > >> >I talked about this at the original NENA meeting that > >created the IP > >> >WGs there (in August of 03). We both agreed we should wait > >until it > >> >was appropriate to the work in the IETF to submit this > >document that > >> >is now > >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >gency-rph-namespace-00.txt > >> > > >> >Yet, you seem to want to use some additional mechanism to > indicate > >> >priority of a call in SIP. That means you want to > >introduce a second > >> >way to accomplish this in SIP. Why do you want to promote > >a separate > >> >way to do something SIP has already defined? That will cause > >> >interoperability issues and we both know that. > >> > > >> >You've said to me (and others) that you believe RPH is > just another > >> >way to accomplish what sos or a URI can indicate - and > >you're wrong. > >> >Your way would be _the_second_way_to_do_it, because SIP already > >> >considers RPH to be *the*way* to priority mark SIP requests. > >> > > >> >If you don't believe me (no comment), then why do you not > >believe the > >> >SIP WG chair (who knows more about SIP than both of us) - who, on > >> >this thread, has again said to you "RFC 4412 > >> >(RPH) is the SIP mechanism to priority mark SIP requests"? > >> > > >> >Further, I believe it is inappropriate to prohibit endpoints from > >> >being able to set the esnet namespace. I absolutely > >believe it will > >> >not be needed most of the time, but I believe if someone > >does find a > >> >valid use for endpoints to mark priority in SIP, this ID > - once it > >> >has become an RFC -- will have to be obsoleted with a new > >RFC saying > >> >the exact opposite. > >> > > >> >(color me confused ... over and over again) > >> > > >> >James > >> > > >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >> >>Keith, please understand that the usage of RFC 4412 for > >GETS and for > >> >>the type of emergency call we discuss here is different. Just > >> >>looking at the header and the name of the namespace is a bit > >> >artificial. I hope > >> >>you understand that. > >> >> > >> >> >-----Original Message----- > >> >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> >> >Sent: 05 February, 2009 14:55 > >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; > >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> >mistake) > >> >> > > >> >> >Which is exactly what RFC 4412 specifies for all namespaces. > >> >> > > >> >> >regards > >> >> > > >> >> >Keith > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> >On Behalf > >> >> >> Of Brian Rosen > >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >> >Hannes (NSN > >> >> >> - FI/Espoo)'; 'ECRIT' > >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > Agenda (my > >> >> >> mistake) > >> >> >> > >> >> >> The value is that in some networks where priority for > >> >> >emergency calls > >> >> >> is appropriate, and appropriate policing of marking is > >> >implemented, > >> >> >> emergency calls will receive resource priority. > >> >> >> > >> >> >> Not all networks would need policing. Some will. Policing > >> >> >> could be to Route header/R-URI content, but other > >criteria are possible. > >> >> >> > >> >> >> Not all networks will need resource priority for > >emergency calls. > >> >> >> Fine, ignore this marking/namespace. > >> >> >> > >> >> >> Brian > >> >> >> > -----Original Message----- > >> >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, > >Hannes (NSN - > >> >> >> > FI/Espoo); 'ECRIT' > >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: > >Agenda (my > >> >> >> > mistake) > >> >> >> > > >> >> >> > I don't even see the value in permitting the > >endpoint todo the > >> >> >> > RPH marking. > >> >> >> > In addition to the security concerns there is also the > >> >> >problem that > >> >> >> > there are more options to implement without an > >additional value. > >> >> >> > > >> >> >> > >-----Original Message----- > >> >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >> >> > >Sent: 05 February, 2009 00:03 > >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> >> >> Hannes (NSN - > >> >> >> > >FI/Espoo)'; 'ECRIT' > >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim > Meeting: Agenda > >> >> >> > >(my > >> >> >> > mistake) > >> >> >> > > > >> >> >> > >Hannes > >> >> >> > > > >> >> >> > >This matches my understanding precisely. We wish to > >> >> >> permit endpoints > >> >> >> > >to mark. We do not require it, and don't > necessarily expect > >> >> >> > >it in many (even > >> >> >> > >most) cases. We don't wish to see the document > prohibit it. > >> >> >> > >We all seem to agree it has value within the Emergency > >> >> >Services IP > >> >> >> > >Networks. > >> >> >> > > > >> >> >> > >Brian > >> >> >> > > > >> >> >> > >> -----Original Message----- > >> >> >> > >> From: ecrit-bounces@ietf.org > >> >> >> > >> [mailto:ecrit-bounces@ietf.org] > >> >> >> > >On Behalf > >> >> >> > >> Of James M. Polk > >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> >> >> FI/Espoo); 'ECRIT' > >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >> >Agenda (my > >> >> >> > >> mistake) > >> >> >> > >> > >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> >> >> > >> > > James wrote: > >> >> >> > >> > >> you are the _lone_ voice not supporting this ID, > >> >> >> > >> > > >> >> >> > >> >Listening to the audio recording of past > meetings I have > >> >> >> > >> >to > >> >> >> > >say that > >> >> >> > >> >I > >> >> >> > >> was > >> >> >> > >> >not the only persons raising concerns about > the document. > >> >> >> > >> >That was probably the reason why you agreed to > limit the > >> >> >> > >scope of the > >> >> >> > >> >document (which you didn't later do) to get > >folks to agree > >> >> >> > >to make it > >> >> >> > >> a WG > >> >> >> > >> >item. > >> >> >> > >> > >> >> >> > >> re-listen to the audio please > >> >> >> > >> > >> >> >> > >> Ted's concerns were consistent with most (all?) other > >> >> >> concerns -- > >> >> >> > >> which were based on the premise of whether or not the > >> >> >> UAC should be > >> >> >> > >> trusted to initiate the marking on the INVITE. > The most > >> >> >> > >> recent version has backed off this to a "can" > -- meaning > >> >> >> > >> not > >> >> >prohibited > >> >> >> > >> (i.e., no 2119 text). I also backed off the text in the > >> >> >> SP domain > >> >> >> > >> part to "can", such that there is no 2119 text > >> >> >mandating or even > >> >> >> > >> recommending its usage there. I also do not prohibit its > >> >> >> > >use, based on > >> >> >> > >> local policy. Keith has come forward with the specific > >> >> >> > >> request that non-ESInet networks be allowed to > >mark and pay > >> >> >attention to > >> >> >> > >> this priority indication -- with IMS as the specific > >> >> >> > >> example he wishes to have this valid for. > >> >> >> > >> > >> >> >> > >> Where there is no disagreement, save for your recent > >> >> >> > >pushback - is in > >> >> >> > >> the ESInet, which is where Brian has requested it's > >> >> >> > >definition in the > >> >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> >> >> NENA, and if > >> >> >> > >> he asks for it, are you going to say you know > >better than he? > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> >Btw, I not disagreeing with the document as such. I > >> >> >just want to > >> >> >> > the > >> >> >> > >> scope > >> >> >> > >> >to change. The usage of RPH within the emergency > >> >> >> services network > >> >> >> > is > >> >> >> > >> fine > >> >> >> > >> >for me. I may get convinced to start the RPH > marking from > >> >> >> > >the the VSP > >> >> >> > >> >towards the PSAP. I feel uneasy about the end > host doing > >> >> >> > >the marking. > >> >> >> > >> > >> >> >> > >> please read what I wrote above, and then re-read the > >> >> >most recent > >> >> >> > >> version of the ID. I don't have endpoints that SHOULD or > >> >> >> MUST mark > >> >> >> > >> anything wrt RPH. I also don't want to prohibit it, > >> >> >> because there > >> >> >> > >> might be cases (that I don't know of) of valid uses > >> >> >> under certain > >> >> >> > >> circumstances. Figure 1 is very clear that there are 3 > >> >> >> networking > >> >> >> > >> parts to consider > >> >> >> > >> > >> >> >> > >> #1 - from the endpoint > >> >> >> > >> #2 - within the VSP > >> >> >> > >> #3 - within the ESInet > >> >> >> > >> > >> >> >> > >> the most recent ID version has "can" for #s 1 and 2, and > >> >> >> > >2119 language > >> >> >> > >> offering those supporting this specification will > >have RPH > >> >> >> > >> adherence within #3 (the ESInet). > >> >> >> > >> > >> >> >> > >> What other scope changes do you want, because I haven't > >> >> >> heard them. > >> >> >> > >> > >> >> >> > >> I only heard you claim in email during the last > >IETF and in > >> >> >> > >the ECRIT > >> >> >> > >> session that RPH should not be used for priority marking > >> >> >> requests. > >> >> >> > >> This is something Keith (SIP WG chair) voiced his > >> >> >> > >> opposition to your views regarding creating a > >second means > >> >> >> > >> for SIP to > >> >> >priority > >> >> >> > >> mark request "when SIP already has one > >interoperable way to > >> >> >> > >> accomplish this... it's call the RP header mechanism". > >> >> >> > >> > >> >> >> > >> >I don't see advantages -- only disadvantages. > >> >> >> > >> > > >> >> >> > >> >Ciao > >> >> >> > >> >Hannes > >> >> >> > >> > >> >> >> > >> _______________________________________________ > >> >> >> > >> Ecrit mailing list > >> >> >> > >> Ecrit@ietf.org > >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> > > > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Ecrit mailing list > >> >> >> Ecrit@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> > >> >> > > >> > > > > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9419E3A6BD0 for ; Sat, 7 Feb 2009 00:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46nz3YCEhUex for ; Sat, 7 Feb 2009 00:12:11 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CA9C73A688C for ; Sat, 7 Feb 2009 00:12:10 -0800 (PST) Received: (qmail invoked by alias); 07 Feb 2009 08:11:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 07 Feb 2009 09:11:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+0Aj4pMV60wgRF8shAD6mXoLv7OjpYk9Tp1R8HXq CXXnzdm8xcjbpD From: "Hannes Tschofenig" To: "'DOLLY, MARTIN C, ATTLABS'" , , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F65@gaalpa1msgusr7e.ugd.att.com> Date: Sat, 7 Feb 2009 10:12:40 +0200 Message-ID: <007101c988fb$e2fc3c80$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA01238F65@gaalpa1msgusr7e.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAAc6YOQAR4E/g X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 08:12:14 -0000 Security policies are an important part. If a VSP does not trust the UA regarding the marking of the ECRIT RPH then it gets ignored. If a VSP trusts it then it is irrelevant as my pseudo code example shows. Not a particular useful mechanism, I would argue. I understand the excitement for RPH but the case for RPH usage in ECRIT is a bit different since we already have ways to different an emergency call from a regular call. >-----Original Message----- >From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] >Sent: 07 February, 2009 01:39 >To: Hannes.Tschofenig@gmx.net; jmpolk@cisco.com; >hgs@cs.columbia.edu; James.Winterbottom@andrew.com >Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org >Subject: Re: [Ecrit] RPH > >Wrong, everything is based on security policies > >----- Original Message ----- >From: Hannes Tschofenig >To: DOLLY, MARTIN C, ATTLABS; jmpolk@cisco.com >; hgs@cs.columbia.edu ; >James.Winterbottom@andrew.com >Cc: Tschofenig, Hannes (NSN - FI/Espoo) >; ecrit@ietf.org >Sent: Fri Feb 06 17:52:07 2009 >Subject: RE: [Ecrit] RPH > >Hi Martin, > >I am arguing that if the UE does mark the call with the ECRIT >RPH (I call it that way to differentiate it from RFC 4412 RPH >usage, which is very >different) then it should be ignored. >Processing it will not help in any way (as I described in my >pseudo code snippet). Incorrectly processing it (which is a >possibility when the implementer does not understand the >security implications -- they will not get it from the current >version of the draft) will lead to security problems (fraud & >DoS potential). > >While you cannot prevent someone from sending you, there is >certainly the chance to document what the receiver should do with it. > >Ciao >Hannes > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of DOLLY, MARTIN C, ATTLABS >>Sent: 07 February, 2009 00:15 >>To: jmpolk@cisco.com; hgs@cs.columbia.edu; >>James.Winterbottom@andrew.com >>Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org >>Subject: Re: [Ecrit] RPH >> >>You can not disallow this from an UE. The trust relationship will >>dictate whether it is accepted or not >> >>----- Original Message ----- >>From: ecrit-bounces@ietf.org >>To: Henning Schulzrinne ; Winterbottom, James >> >>Cc: Tschofenig, Hannes (NSN - FI/Espoo) ; >>ECRIT >>Sent: Fri Feb 06 17:10:08 2009 >>Subject: Re: [Ecrit] RPH >> >>At 03:05 PM 2/6/2009, Henning Schulzrinne wrote: >>>There's another problem with the "it doesn't hurt argument". >>Assume for >>>a moment we have a "UA MAY include RPH" wording. There are now two >>>cases: >>> >>>(1) All UAs implement it. >>> >>>(2) Only some UAs implement it. >>> >>>(1) seems unlikely for a MAY. If (2) occurs, we have the >>choice between >>>two undesirable outcomes: >>> >>>(a) some UAs that are otherwise compliant get worse service just >>>because they didn't include the RPH; >> >>am I reading this correctly - that unless all UAs implement this >>capability this should never be implemented by any UAs? >> >>This flies in the face of vendors solving for their customer's >>requirements. >> >>I will admit that at this time, I know of no Cisco customers >that want >>this capability, so I'm not angling for any of our revenue here. I'm >>saying that I think I hear you saying this ID should say >something like >> >> UAs are prevented from implementing the RP namespace esnet >> >>I'm fighting against that, because customers are always >coming to every >>vendor with new requirements, some of them unique at the time. This >>prevention text would prevent a vendor from complying with this >>specification and still meet the customer's needs. >> >>I believe that this ID needs to retain the endpoints MAY >insert esnet, >>and have appropriate security considerations text that highlights the >>concerns expressed here. >> >>Some future ID can then update this current RFC (to-be) within the >>2119 rules of the use of MAY here. >> >> >>>OR >>> >>>(b) the proxy has to look for the service URN to give the call the >>>appropriate treatment, thus obviating any advantage of having the >>>header, yet incurring more complicated processing logic. >>> >>> >>>I have no objection to whatever markings people want to >apply to calls >>>within an ESN - that's largely a private matter. >>> >>>Henning >>> >>>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: >>> >>>>Hi All, >>>> >>>>I have followed thi thread with some interest and I >struggling to see >>>>a use case for the providing RPH for emergency calls from the >>>>end-point. >>>> >>>>The reference-model call in ECRIT, for better or worse, is for all >>>>calls to go back through a home-VSP. >>>>We placed quite a lot of emphasis, largely for traffing >reasons, for >>>>the VSP to be able to verify that a call is in fact an emergency >>>>call. This is done by the proxy taking the inband location, doing a >>>>LoST query with the provided URN, and verifying that the resulting >>>>destination URI is the same as the destination URI provide >in the SIP >>>>INVITE. My understanding was that VSPs would always do this >check so >>>>they could tell if they could bill for the call or not, and because >>>>the VSP can be use that the call is an emergency call it can apply >>>>any special priorities that may be applicable. This >obviates the need >>>>for RPH from the end-point to the network. >>>> >>>>This leaves us with the argument of "it doesn't hurt to >it", which is >>>>not a good reason to write a specification. >>>>It was intimated on the geopriv mailing list last year that great >>>>pains had been taken to keep SIP with in the MTU limits of UDP over >>>>Ethernet >>>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612 >>0.html ). Assuming >>>>that this is the case, perhaps there is harm in including >information >>>>that we know will be ignored. >>>> >>>>Cheers >>>>James >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >>>>Sent: Fri 2/6/2009 12:33 PM >>>>To: 'Brian Rosen'; 'Henning Schulzrinne' >>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >>>>Subject: Re: [Ecrit] RPH >>>> >>>>To the story short here is the code for the proxy: >>>> >>>>--------------------- >>>> >>>>IF emergency call was recognized THEN >>>> execute emergency call specific procedures (priority queuing, >>>>preemption, fetch location, determine routing, do funny QoS things & >>>>co) >>>>ELSE >>>> normal call handling procedures. >>>> >>>>--------------------- >>>> >>>>If you can make this differentiation between an emergency >call and a >>>>regular call then you can also do everything that is necessary for >>>>emergency call handling. >>>> >>>>Brian + Keith: Please tell me that we cannot do the above with our >>>>currently specified mechanisms. >>>> >>>>Ciao >>>>Hannes >>>> >>>>>-----Original Message----- >>>>>From: Brian Rosen [mailto:br@brianrosen.net] >>>>>Sent: 06 February, 2009 17:49 >>>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >>>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>>>Subject: RE: [Ecrit] RPH >>>>> >>>>>I agree that not all networks will permit (or pay attention >>>>>to) a priority request from an end device. >>>>> >>>>>No one has asked for that. >>>>> >>>>>The namespace request has several uses, one of which is within an >>>>>emergency services IP network, one of which is between elements >>>>>within a public network controlled by the operator, and >one of which >>>>>is an endpoint request for resource priority. >>>>> >>>>>Those of us requesting this work proceed are happy if the endpoint >>>>>part is simply left as possible (MAY), and, speaking for myself, >>>>>having the draft discuss the security implications of endpoint >>>>>marking is reasonable. >>>>> >>>>>Having discussed this issue with an implementation team who worked >>>>>on MLPP systems, I am confident I know what I'm talking about, but >>>>>YMMV. The fact that you could, if you wanted to, give resource >>>>>priority to a call you decided, however you decided, was an >>>>>emergency call is an implementation decision, and not subject to >>>>>standardization. >>>>> >>>>>RPH is the IETF standard way for one entity to request resource >>>>>priority of another entity in a SIP system. We're asking for a >>>>>namespace to use that within the domain of emergency calls. That >>>>>is, I think, a VERY reasonable request. >>>>> >>>>>Brian >>>>> >>>>>>-----Original Message----- >>>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>Sent: Friday, February 06, 2009 10:33 AM >>>>>>To: Hannes Tschofenig >>>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >>>>>>Subject: Re: [Ecrit] RPH >>>>>> >>>>>>To chime in here: >>>>>> >>>>>>I don't think it's productive to simply state that 4412 >>>>>doesn't worry >>>>>>about authorization, so we shouldn't either (simplifying a bit). >>>>>>Authorization was discussed repeatedly, and the general >>>>>assumption was >>>>>>that there were two conditions: Either the user invoking >resource- >>>>>>priority was well known and had a set of permissions that >could be >>>>>>checked in real time or there are ways to deal with abuse >after the >>>>>>fact in ways that deter abuse (the court-martial kind of >thing in a >>>>>>military context). >>>>>> >>>>>>The RFC 4412 security consideration (11.2) call this out >in pretty >>>>>>strong language: >>>>>> >>>>>> Prioritized access to network and end-system resources imposes >>>>>> particularly stringent requirements on authentication and >>>>>> authorization mechanisms, since access to prioritized >>>>>resources may >>>>>> impact overall system stability and performance and not >>>>>just result >>>>>> in theft of, say, a single phone call. >>>>>>Thus, the question is whether we have such strong >authentication in >>>>>>emergency calling. In some cases, such as residential fixed line >>>>>>deployments where ISP = VSP, we're probably pretty close, >>in others, >>>>>>such as prepaid cell phones or hot spots or VSP-only >providers, we >>>>>>aren't. >>>>>> >>>>>>The other point that I think Hannes is making is that the >>>>>information >>>>>>is either redundant or dangerous. If a processing element >>recognizes >>>>>>the call as being an emergency call, it can apply whatever >>treatment >>>>>>it deems appropriate and doesn't need additional >information. If it >>>>>>doesn't or can't, using just the RPH can be rather >dangerous unless >>>>>>that element can be reasonably certain that there is strong >>>>>>authentication and recourse. >>>>>> >>>>>>I don't buy the argument that somehow finding the RPH is >>faster than >>>>>>just looking for the identifier. Thus, given that the >>information is >>>>>>either redundant or dangerous, I fail to see the advantage. >>>>>> >>>>>>Henning >>>>>> >>>>>> >>>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >>>>>> >>>>>>>Don't get hung up on the details. There are ways to optimize it. >>>>>>>That was >>>>>>>not the point of the code example. >>>>>>> >>>>>>>The problem that my pseudo code should have shown you is that you >>>>>>>* don't gain anything with RPH marking for the emergency >call case >>>>>>>from the SIP UA towards the outbound proxy since the >functionality >>>>>>>is already provide otherwise. How often does the proxy >need to get >>>>>>>told that this is an emergency call todo whatever emergency call >>>>>>>handling procedures are necessary? >>>>>>>* you only introduce fraud problems (if you are not >>>>>careful and you >>>>>>>understand the security stuff well enough) >>>>>>> >>>>>>>If you can point me to people who implement the RPH >emergency call >>>>>>>case please do so. I would love to talk to them. >>>>>>> >>>>>>>Ciao >>>>>>>Hannes >>>>>>> >>>>>>>PS: You need to parse incoming messages to some extend >so that you >>>>>>>know what it contains :-) Only looking for the emergency >>>>>RPH header >>>>>>>(and not for the Service URN/dial >>>>>>>string) would exactly be the DoS/fraud attack I am worried about. >>>>>>>That's the thing Henning was worried about (go and listen to the >>>>>>>past meeting minutes). >>>>>>> >>>>>>> >>>>>>>>Hannes >>>>>>>> >>>>>>>>You need to talk to people who really implement this kind >>>>>of thing. >>>>>>>>You are way off. >>>>>>>> >>>>>>>>When you implement a resource priority system, the >point of doing >>>>>>>>that is to look though the queue of work and pick out the >>>>>ones with >>>>>>>>priority, handling them first. You don't do all the >parsing, you >>>>>>>>don't do a lot of decision tree. >>>>>>>> >>>>>>>>Typically: >>>>>>>>Check for DoS things, like too big messages, etc Do a >quick scan >>>>>>>>for the RPH message header If found: >>>>>>>>Parse the message >>>>>>>>Determine validity >>>>>>>>Determine priority >>>>>>>>Queue on the correct work queue >>>>>>>> >>>>>>>>The first two actions have to be very fast. Anyone who >builds a >>>>>>>>SIP thingie will tell you that parsing is one of the big cycle >>>>>>>>consumers: if you have to parse every message BEFORE you >>>>>determine >>>>>>>>priority, you can't give much resource priority. >>>>>>>>Once you get the whole message parsed, you might as well finish >>>>>>>>working on it, because you've done so much of the work. >>>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick >>>>>>>>string search for RPH is fast. If you are doing >>>>>priority, you need >>>>>>>>to keep all the priority processing pretty uniform, and pretty >>>>>>>>simple, or you tend to spend too much time futzing around >>>>>figuring >>>>>>>>out what to do. You put all the priority related stuff >together, >>>>>>>>and use as much common code as possible. >>>>>>>> >>>>>>>>Brian >>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>>>>>On Behalf >>>>>>>>>Of Hannes Tschofenig >>>>>>>>>Sent: Friday, February 06, 2009 8:41 AM >>>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn' >>>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >>>>>>>>>bounces@ietf.org >>>>>>>>>Subject: [Ecrit] RPH >>>>>>>>> >>>>>>>>>Over lunch I was also thinking how an outbound proxy would >>>>>>implement >>>>>>>>>some of the emergency procedures. Here are some thoughts: >>>>>>>>> >>>>>>>>>--------------------------------------------------- >>>>>>>>> >>>>>>>>>// Process incoming message >>>>>>>>>Parse(msg); >>>>>>>>> >>>>>>>>>// SIP INVITE without Service URN // legacy devices If >>>>>>>>>(recognize-dialstring(msg)==TRUE) { // we got an >emergency call >>>>>>>>>going on emergency=TRUE; if (dialstring(msg) == 911) >>>>>>>>>serviceURN=urn:service:sos; } else if >>>>>>>>>(recognize-serviceURN(msg)==TRUE) { // oh. A updated >>>>>device that >>>>>>>>>has a service URN attached to the >>>>>>call >>>>>>>>>serviceURN=retrieve_ServiceURN(msg); >>>>>>>>>emergency=TRUE; >>>>>>>>>} else { >>>>>>>>>// standard SIP message >>>>>>>>>// regular processing >>>>>>>>>process(msg); >>>>>>>>>emergency=FALSE; >>>>>>>>>} >>>>>>>>> >>>>>>>>>If (emergency == TRUE) { >>>>>>>>> // make sure that the emergency call does not get >>>>>dropped on the >>>>>>>>>floor >>>>>>>>> // skip authorization failures >>>>>>>>> // give the call a special treatment >>>>>>>>> lots-of-code-here(); >>>>>>>>> >>>>>>>>> // trigger all the QoS signaling you have in the >>>>>network to make >>>>>>>>>James happy >>>>>>>>> trigger-qos(); >>>>>>>>> >>>>>>>>> // query location >>>>>>>>> location=retrieve-location(); >>>>>>>>> >>>>>>>>> // determine next hop >>>>>>>>> next-hop=lost(location, serviceURN) >>>>>>>>> >>>>>>>>> // attach RPH marking to outgoing msg to make James and >>>>>>>>Keith happy >>>>>>>>> msg=add(msg, RPH); >>>>>>>>> >>>>>>>>> send(msg, next-hop); >>>>>>>>>} >>>>>>>>> >>>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >>>>>>>>> // all the emergency related processing done already upfront >>>>>>>>> // hence I log something. >>>>>>>>> log(RPH_WAS_PRESENT_JUHU); >>>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency == >>>>>FALSE)) { >>>>>>>>>// this is not an emergency call // this is something >>>>>like GETS >>>>>>>>>result=special-authorization-procedure(user); >>>>>>>>> >>>>>>>>>if (result == AUTHORIZED) { >>>>>>>>> // do some priority & preemption thing here. >>>>>>>>> // trigger all the QoS you have >>>>>>>>> lots-of-code-here(); >>>>>>>>>} else { >>>>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } >else { // >>>>>>>>>don't need todo any RPH processing // this includes the case >>>>>>>>>where the call was an emergency call but the RPH >>>>>>>>> >>>>>>>>>// marking was not there. >>>>>>>>>nothing(); >>>>>>>>>} >>>>>>>>> >>>>>>>>>--------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>>Ciao >>>>>>>>>Hannes >>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: ecrit-bounces@ietf.org >[mailto:ecrit-bounces@ietf.org] On >>>>>>>>>>Behalf Of Hannes Tschofenig >>>>>>>>>>Sent: 06 February, 2009 15:07 >>>>>>>>>>To: 'Janet P Gunn' >>>>>>>>>>Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >>>>>>>>>FI/Espoo) >>>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >>Agenda (RPH) >>>>>>>>>> >>>>>>>>>>Who would define something that could prevent DoS problems? >>>>>>>>>> >>>>>>>>>>________________________________ >>>>>>>>>> >>>>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>>>>>>>>> Sent: 06 February, 2009 14:11 >>>>>>>>>> To: Hannes Tschofenig >>>>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >>>>>>>>>>ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >>>>>>'James >>>>>>>>>>M. Polk' >>>>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>Meeting: Agenda (RPH) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But there is nothing IN RFC4412 that specifically >>>>>>>>addresses how to >>>>>>>>>>prevent any particular namespace being used for DoS. >>Anyone/any >>>>>>UA >>>>>>>>>>can ATTEMPT to invoke priority treatment by attaching >RPH. For >>>>>>all >>>>>>>>>>of the 4412 namespaces, as with the new proposed >namespace, the >>>>>>>>>>mechanisms for preventing DoS are not specified in the >>>>>>>>document that >>>>>>>>>>defines the namespace. >>>>>>>>>>They are/will be specified elsewhere. >>>>>>>>>> >>>>>>>>>> Janet >>>>>>>>>> >>>>>>>>>> This is a PRIVATE message. If you are not >the intended >>>>>>>>recipient, >>>>>>>>>>please delete without copying and kindly advise us by >e-mail of >>>>>>the >>>>>>>>>>mistake in delivery. >>>>>>>>>> NOTE: Regardless of content, this e-mail shall not >>>>>>>>operate to bind >>>>>>>>>>CSC to any order or other contract unless pursuant to >explicit >>>>>>>>>>written agreement or government initiative expressly >permitting >>>>>>the >>>>>>>>>>use of e-mail for such purpose. >>>>>>>>>> >>>>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 >>04:21:51 AM: >>>>>>>>>> >>>>>>>>>> > Hi James, >>>>>>>>>> > >>>>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF >>>>>>>>documents. What I >>>>>>>>>>would >>>>>>>>>> > like to point out is that there is more than just a >>>>>>>>header and >>>>>>>>>>values within >>>>>>>>>> > the header that have to be considered in order to >>>>>>>>make a judgement >>>>>>>>>>of what >>>>>>>>>> > is appropriate and what isn't. There is an >>>>>>>>architectural question >>>>>>>>>>and >>>>>>>>>> > whether the environment we are using the stuff is >>>>>>>>indeed providing >>>>>>>>>>the >>>>>>>>>> > properties you need for the solution to be >>>>>appropriate. >>>>>>>>>> > >>>>>>>>>> > Let me describe in more detail what I meant (and >>>>>>>>please correct me >>>>>>>>>>if I am >>>>>>>>>> > wrong). >>>>>>>>>> > >>>>>>>>>> > Getting priority for SIP requests when using a GETS >>>>>>>>alike scenario >>>>>>>>>>means >>>>>>>>>> > that the entity that issues the request is >specially >>>>>>>>authorized >>>>>>>>>>since >>>>>>>>>> > otherwise you introduce a nice denial of >>>>>service attack. This >>>>>>>>>>authorization >>>>>>>>>> > is tied to the entity that makes the request. For >>>>>>>>example, the >>>>>>>>>>person is >>>>>>>>>> > working for the government and has special rights. >>>>>>>>>>James Bond as a (not so) >>>>>>>>>> > secret agent might have these rights. >>>>>>>>>> > >>>>>>>>>> > The emergency services case >>>>>(citizen-to-authority) is a bit >>>>>>>>>>different as >>>>>>>>>> > there aren't really special rights with respect to >>>>>>>>authorization >>>>>>>>>>tied to >>>>>>>>>> > individuals. Instead, the fact that something is an >>>>>>>>emergency is >>>>>>>>>>purely a >>>>>>>>>> > judgement of the human that dials a special number. >>>>>>>>>>To deal with fraud, we >>>>>>>>>> > discussed in the group on what we can >actually do to >>>>>>>>ensure that >>>>>>>>>>end users >>>>>>>>>> > do not bypass security procedures (such as >>>>>>>>authorization checks, >>>>>>>>>>charging >>>>>>>>>> > and so on). Part of this investigation was >>>>>the publication of >>>>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also >>>>>describes this >>>>>>>>>>issue. >>>>>>>>>> > >>>>>>>>>> > So, imagine the implementation of a SIP >>proxy (and we >>>>>>>>implemented >>>>>>>>>>that >>>>>>>>>> > stuff) that receives a call that contains a Service >>>>>>>>URN. The code >>>>>>>>>>branches >>>>>>>>>> > into a special mode where everything is done >>>>>so that the call >>>>>>>>>>receives >>>>>>>>>> > appropriate treatment and does not get >>dropped on the >>>>>>>>floor. The >>>>>>>>>>way how the >>>>>>>>>> > Service URN is placed in the message >>ensures that the >>>>>>>>call cannot >>>>>>>>>>go to my >>>>>>>>>> > friend (instead of the PSAP) unless the >end host ran >>>>>>>>LoST already. >>>>>>>>>>In the >>>>>>>>>> > latter case, we discussed this also on the >>list for a >>>>>>>>while and >>>>>>>>>>Richard even >>>>>>>>>> > wrote a draft about it in the context of the >>>>>location hiding >>>>>>>>>>topic, we said >>>>>>>>>> > that the proxy would have to run LoST if he >>>>>cares about a >>>>>>>>>>potential >>>>>>>>>> > fraudulent usage. >>>>>>>>>> > >>>>>>>>>> > So, what do we need todo in order to provide >>>>>secure RFC 4412 >>>>>>>>>>functionality >>>>>>>>>> > in our context? >>>>>>>>>> > >>>>>>>>>> > Do you think that the current text in >>>>>>>>>> > >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l >ocal-emer >>>>>>>>>>gency-rph-nam >>>>>>>>>> > espace-00.txt reflects any of the >>>>>above-described issues: >>>>>>>>>> > " >>>>>>>>>> > The Security considerations that apply >>to RFC 4412 >>>>>>>>>>[RFC4412] >>>>>>>>>>apply >>>>>>>>>> > here. This document introduces no new security >>>>>>>>>>issues relative >>>>>>>>>>to >>>>>>>>>> > RFC 4412. >>>>>>>>>> > " >>>>>>>>>> > >>>>>>>>>> > From various discussions in GEOPRIV I recall >>>>>that you are >>>>>>>>>>super-sensitive >>>>>>>>>> > regarding security and privacy. For some >reasons you >>>>>>>>don't seem to >>>>>>>>>>have the >>>>>>>>>> > same concerns here. I would like to >>>>>understand your reasoning. >>>>>>>>>> > >>>>>>>>>> > Please also do me another favor: Don't always say >>>>>>>>that I don't >>>>>>>>>>understand >>>>>>>>>> > the subject. Even if that would be the >case it isn't >>>>>>>>particular >>>>>>>>>>fair given >>>>>>>>>> > that different folks had to educate you on other >>>>>>>>topics in the >>>>>>>>>>past as well. >>>>>>>>>> > Additionally, if you listen to the audio recordings >>>>>>>>then you will >>>>>>>>>>notice >>>>>>>>>> > that Henning, Ted, and Jon do not seem to >understand >>>>>>>>the issue >>>>>>>>>>either as >>>>>>>>>> > they have raised similar issues during the >>>>>F2F meetings. >>>>>>>>>> > >>>>>>>>>> > Ciao >>>>>>>>>> > Hannes >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >Hannes - I believe it is you who do not understand >>>>>>>>RFC 4412 -- >>>>>>>>>> > >and many of us are trying to get that >>>>>through to you, but you >>>>>>>>>> > >don't seem to want to listen/read. >>>>>>>>>> > > >>>>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, >>>>>>>>>> > > >>>>>>>>>> > >One use is GETS. >>>>>>>>>> > > >>>>>>>>>> > >One use is MLPP. >>>>>>>>>> > > >>>>>>>>>> > >These examples are in RFC 4412 because there >>>>>were specific >>>>>>>>>> > >namespaces being created for the IANA section of >>>>>>>>that document. >>>>>>>>>> > > >>>>>>>>>> > >Reading the whole document, you will see >>>>>that RPH can be >>>>>>>>>> > >specified for other uses than GETS or MLPP >>>>>specifically. >>>>>>>>>> > > >>>>>>>>>> > >I knew when I wrote RFC 4412 that one day we >>>>>would specify a >>>>>>>>>> > >namespace for ECRIT (the "esnet" namespace >>>>>now) -- but I also >>>>>>>>>> > >knew it was premature for RFC 4412 to >>>>>incorporate that >>>>>>>>>> > >namespace, that a future doc to RFC 4412 >>>>>would have to be >>>>>>>>>> > >written to do this. Brian and I talked about >>>>>this at the >>>>>>>>>> > >original NENA meeting that created the IP >WGs there >>>>>>>>(in August >>>>>>>>>> > >of 03). We both agreed we should wait >until it was >>>>>>>>>> > >appropriate to the work in the IETF to >>>>>submit this document >>>>>>>>>> > >that is now >>>>>>>>>> > >>>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l >>ocal-emer >>>>>>>>>> > >gency-rph-namespace-00.txt >>>>>>>>>> > > >>>>>>>>>> > >Yet, you seem to want to use some additional >>>>>mechanism to >>>>>>>>>> > >indicate priority of a call in SIP. That >>>>>means you want to >>>>>>>>>> > >introduce a second way to accomplish this in SIP. >>>>>>>>>>Why do you >>>>>>>>>> > >want to promote a separate way to do something SIP >>>>>>>>has already >>>>>>>>>> > >defined? That will cause interoperability >>issues and >>>>>>>>we both know >>>>>>>>>>that. >>>>>>>>>> > > >>>>>>>>>> > >You've said to me (and others) that you >>>>>believe RPH is just >>>>>>>>>> > >another way to accomplish what sos or a URI can >>>>>>>>indicate - and >>>>>>>>>> > >you're wrong. Your way would be >>>>>_the_second_way_to_do_it, >>>>>>>>>> > >because SIP already considers RPH to be >>>>>*the*way* to priority >>>>>>>>>> > >mark SIP requests. >>>>>>>>>> > > >>>>>>>>>> > >If you don't believe me (no comment), then >>>>>why do you not >>>>>>>>>> > >believe the SIP WG chair (who knows more >>>>>about SIP than both >>>>>>>>>> > >of us) - who, on this thread, has again said >>>>>to you "RFC 4412 >>>>>>>>>> > >(RPH) is the SIP mechanism to priority mark >>>>>SIP requests"? >>>>>>>>>> > > >>>>>>>>>> > >Further, I believe it is inappropriate to >>>>>prohibit endpoints >>>>>>>>>> > >from being able to set the esnet namespace. >>>>>I absolutely >>>>>>>>>> > >believe it will not be needed most of the >>>>>time, but I believe >>>>>>>>>> > >if someone does find a valid use for >>>>>endpoints to mark >>>>>>>>>> > >priority in SIP, this ID - once it has >>>>>become an RFC -- will >>>>>>>>>> > >have to be obsoleted with a new RFC saying >>the exact >>>>>>>>opposite. >>>>>>>>>> > > >>>>>>>>>> > >(color me confused ... over and over again) >>>>>>>>>> > > >>>>>>>>>> > >James >>>>>>>>>> > > >>>>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >>>>>>>>>> > >>Keith, please understand that the usage >>of RFC 4412 >>>>>>>>for GETS and >>>>>>>>>>for >>>>>>>>>> > >>the type of emergency call we discuss here is >>>>>>>>different. Just >>>>>>>>>>looking >>>>>>>>>> > >>at the header and the name of the >>namespace is a bit >>>>>>>>>> > >artificial. I hope >>>>>>>>>> > >>you understand that. >>>>>>>>>> > >> >>>>>>>>>> > >> >-----Original Message----- >>>>>>>>>> > >> >From: DRAGE, Keith (Keith) >>>>>>>>>>[mailto:drage@alcatel-lucent.com] >>>>>>>>>> > >> >Sent: 05 February, 2009 14:55 >>>>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >>>>>>>>>>Polk'; 'Tschofenig, >>>>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >>>>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>>>>Meeting: Agenda (my >>>>>>>>>> >>>>>>>>>> > >> >mistake) >>>>>>>>>> > >> > >>>>>>>>>> > >> >Which is exactly what RFC 4412 >specifies for all >>>>>>>>namespaces. >>>>>>>>>> > >> > >>>>>>>>>> > >> >regards >>>>>>>>>> > >> > >>>>>>>>>> > >> >Keith >>>>>>>>>> > >> > >>>>>>>>>> > >> >> -----Original Message----- >>>>>>>>>> > >> >> From: ecrit-bounces@ietf.org >>>>>>>>[mailto:ecrit-bounces@ietf.org] >>>>>>>>>> > >> >On Behalf >>>>>>>>>> > >> >> Of Brian Rosen >>>>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >>>>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >>>>>Polk'; 'Tschofenig, >>>>>>>>>> > >Hannes (NSN >>>>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' >>>>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >>>>>>>>>>Meeting: Agenda (my >>>>>>>>>> > >> >> mistake) >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> The value is that in some networks >>>>>where priority for >>>>>>>>>> > >> >emergency calls >>>>>>>>>> > >> >> is appropriate, and appropriate >>>>>policing of marking is >>>>>>>>>> > >implemented, >>>>>>>>>> > >> >> emergency calls will receive resource >>priority. >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> Not all networks would need policing. Some >>>>>>>>will. Policing >>>>>>>>>>could >>>>>>>>>> > >> >> be to Route header/R-URI content, but other >>>>>>>>criteria are >>>>>>>>>>possible. >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> Not all networks will need resource priority >>>>>>>>for emergency >>>>>>>>>>calls. >>>>>>>>>> > >> >> Fine, ignore this marking/namespace. >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> Brian >>>>>>>>>> > >> >> > -----Original Message----- >>>>>>>>>> > >> >> > From: Hannes Tschofenig >>>>>>>>>>[mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >>>>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >>>>>>>>Tschofenig, Hannes >>>>>>>>>>(NSN - >>>>>>>>>> > >> >> > FI/Espoo); 'ECRIT' >>>>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >>>>>>>>>>Meeting: Agenda (my >>>>>>>>>> > >> >> > mistake) >>>>>>>>>> > >> >> > >>>>>>>>>> > >> >> > I don't even see the value in >permitting the >>>>>>>>endpoint todo >>>>>>>>>>the >>>>>>>>>> > >> >> > RPH marking. >>>>>>>>>> > >> >> > In addition to the security concerns >>>>>there is also the >>>>>>>>>> > >> >problem that >>>>>>>>>> > >> >> > there are more options to implement without >>>>>>>>an additional >>>>>>>>>>value. >>>>>>>>>> > >> >> > >>>>>>>>>> > >> >> > >-----Original Message----- >>>>>>>>>> > >> >> > >From: Brian Rosen >>[mailto:br@brianrosen.net] >>>>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 >>>>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >>>>>>>>'Tschofenig, >>>>>>>>>> > >> >> Hannes (NSN - >>>>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' >>>>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >>>>>Interim Meeting: >>>>>>>>>>Agenda (my >>>>>>>>>> > >> >> > mistake) >>>>>>>>>> > >> >> > > >>>>>>>>>> > >> >> > >Hannes >>>>>>>>>> > >> >> > > >>>>>>>>>> > >> >> > >This matches my understanding >>>>>precisely. We wish to >>>>>>>>>> > >> >> permit endpoints >>>>>>>>>> > >> >> > >to mark. We do not require it, and >>>>>don't necessarily >>>>>>>>>>expect it >>>>>>>>>> > >> >> > >in many (even >>>>>>>>>> > >> >> > >most) cases. We don't wish to see the >>>>>>>>document prohibit >>>>>>>>>>it. >>>>>>>>>> > >> >> > >We all seem to agree it has value >>within the >>>>>>>>Emergency >>>>>>>>>> > >> >Services IP >>>>>>>>>> > >> >> > >Networks. >>>>>>>>>> > >> >> > > >>>>>>>>>> > >> >> > >Brian >>>>>>>>>> > >> >> > > >>>>>>>>>> > >> >> > >> -----Original Message----- >>>>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org >>>>>>>>>>[mailto:ecrit-bounces@ietf.org] >>>>>>>>>> > >> >> > >On Behalf >>>>>>>>>> > >> >> > >> Of James M. Polk >>>>>>>>>> > >> >> > >> Sent: Wednesday, February 04, >>2009 4:01 PM >>>>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >>>>>Hannes (NSN - >>>>>>>>>> > >> >> FI/Espoo); 'ECRIT' >>>>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT >>Virtual Interim >>>>>>>>>>Meeting: >>>>>>>>>> > >Agenda (my >>>>>>>>>> > >> >> > >> mistake) >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >>>>>Tschofenig wrote: >>>>>>>>>> > >> >> > >> > > James wrote: >>>>>>>>>> > >> >> > >> > >> you are the _lone_ voice not >>>>>>>>supporting this ID, >>>>>>>>>> > >> >> > >> > >>>>>>>>>> > >> >> > >> >Listening to the audio >recording of past >>>>>>>>meetings I >>>>>>>>>>have to >>>>>>>>>> > >> >> > >say that >>>>>>>>>> > >> >> > >> >I >>>>>>>>>> > >> >> > >> was >>>>>>>>>> > >> >> > >> >not the only persons raising >>>>>concerns about the >>>>>>>>>>document. >>>>>>>>>> > >> >> > >> >That was probably the reason why you >>>>>>>>agreed to limit >>>>>>>>>>the >>>>>>>>>> > >> >> > >scope of the >>>>>>>>>> > >> >> > >> >document (which you didn't later do) to >>>>>>>>get folks to >>>>>>>>>>agree >>>>>>>>>> > >> >> > >to make it >>>>>>>>>> > >> >> > >> a WG >>>>>>>>>> > >> >> > >> >item. >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> re-listen to the audio please >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> Ted's concerns were consistent with most >>>>>>>>>>(all?) other >>>>>>>>>> > >> >> concerns -- >>>>>>>>>> > >> >> > >> which were based on the premise >>of whether >>>>>>>>or not the >>>>>>>>>> > >> >> UAC should be >>>>>>>>>> > >> >> > >> trusted to initiate the marking on the >>>>>>>>INVITE. The >>>>>>>>>>most >>>>>>>>>> > >> >> > >> recent version has backed off this >>>>>to a "can" -- >>>>>>>>>>meaning not >>>>>>>>>> > >> >prohibited >>>>>>>>>> > >> >> > >> (i.e., no 2119 text). I also backed off >>>>>>>>the text in >>>>>>>>>>the >>>>>>>>>> > >> >> SP domain >>>>>>>>>> > >> >> > >> part to "can", such that there is >>>>>no 2119 text >>>>>>>>>> > >> >mandating or even >>>>>>>>>> > >> >> > >> recommending its usage there. I also do >>>>>>>>not prohibit >>>>>>>>>>its >>>>>>>>>> > >> >> > >use, based on >>>>>>>>>> > >> >> > >> local policy. Keith has come >>forward with >>>>>>>>the specific >>>>>>>>>> >>>>>>>>>> > >> >> > >> request that non-ESInet networks be >>>>>>>>allowed to mark and >>>>>>>>>>pay >>>>>>>>>> > >> >attention to >>>>>>>>>> > >> >> > >> this priority indication -- with IMS as >>>>>>>>the specific >>>>>>>>>>example >>>>>>>>>> > >> >> > >> he wishes to have this valid for. >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> Where there is no disagreement, save for >>>>>>>>your recent >>>>>>>>>> > >> >> > >pushback - is in >>>>>>>>>> > >> >> > >> the ESInet, which is where Brian >>>>>has requested it's >>>>>>>>>> > >> >> > >definition in the >>>>>>>>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >>>>>>>>chair within >>>>>>>>>> > >> >> NENA, and if >>>>>>>>>> > >> >> > >> he asks for it, are you going to say you >>>>>>>>know better >>>>>>>>>>than he? >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> >Btw, I not disagreeing with >the document >>>>>>>>as such. I >>>>>>>>>> > >> >just want to >>>>>>>>>> > >> >> > the >>>>>>>>>> > >> >> > >> scope >>>>>>>>>> > >> >> > >> >to change. The usage of RPH >>>>>within the emergency >>>>>>>>>> > >> >> services network >>>>>>>>>> > >> >> > is >>>>>>>>>> > >> >> > >> fine >>>>>>>>>> > >> >> > >> >for me. I may get convinced to >start the >>>>>>>>RPH marking >>>>>>>>>>from >>>>>>>>>> > >> >> > >the the VSP >>>>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy >>about the >>>>>>>>end host >>>>>>>>>>doing >>>>>>>>>> > >> >> > >the marking. >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> please read what I wrote above, and then >>>>>>>>re-read the >>>>>>>>>> > >> >most recent >>>>>>>>>> > >> >> > >> version of the ID. I don't have >endpoints >>>>>>>>that SHOULD >>>>>>>>>>or >>>>>>>>>> > >> >> MUST mark >>>>>>>>>> > >> >> > >> anything wrt RPH. I also don't want to >>>>>>>>prohibit it, >>>>>>>>>> > >> >> because there >>>>>>>>>> > >> >> > >> might be cases (that I don't know >>>>>of) of valid uses >>>>>>>>>> > >> >> under certain >>>>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear >>>>>>>>that there are 3 >>>>>>>>>> > >> >> networking >>>>>>>>>> > >> >> > >> parts to consider >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> #1 - from the endpoint >>>>>>>>>> > >> >> > >> #2 - within the VSP >>>>>>>>>> > >> >> > >> #3 - within the ESInet >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> the most recent ID version has "can" for >>>>>>>>#s 1 and 2, >>>>>>>>>>and >>>>>>>>>> > >> >> > >2119 language >>>>>>>>>> > >> >> > >> offering those supporting this >>>>>>>>specification will have >>>>>>>>>>RPH >>>>>>>>>> > >> >> > >> adherence within #3 (the ESInet). >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> What other scope changes do you want, >>>>>>>>because I haven't >>>>>>>>>> > >> >> heard them. >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> I only heard you claim in email >>during the >>>>>>>>last IETF >>>>>>>>>>and in >>>>>>>>>> > >> >> > >the ECRIT >>>>>>>>>> > >> >> > >> session that RPH should not be >>>>>used for priority >>>>>>>>>>marking >>>>>>>>>> > >> >> requests. >>>>>>>>>> > >> >> > >> This is something Keith (SIP WG >>>>>chair) voiced his >>>>>>>>>>opposition >>>>>>>>>> > >> >> > >> to your views regarding >creating a second >>>>>>>>means for SIP >>>>>>>>>>to >>>>>>>>>> > >> >priority >>>>>>>>>> > >> >> > >> mark request "when SIP already has one >>>>>>>>interoperable >>>>>>>>>>way to >>>>>>>>>> > >> >> > >> accomplish this... it's call the >>RP header >>>>>>>>mechanism". >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> >I don't see advantages -- only >>>>>disadvantages. >>>>>>>>>> > >> >> > >> > >>>>>>>>>> > >> >> > >> >Ciao >>>>>>>>>> > >> >> > >> >Hannes >>>>>>>>>> > >> >> > >> >>>>>>>>>> > >> >> > >> >>>>>_______________________________________________ >>>>>>>>>> > >> >> > >> Ecrit mailing list >>>>>>>>>> > >> >> > >> Ecrit@ietf.org >>>>>>>>>> > >> >> > >> >>https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> > >> >> > > >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>_______________________________________________ >>>>>>>>>> > >> >> Ecrit mailing list >>>>>>>>>> > >> >> Ecrit@ietf.org >>>>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> > >> >> >>>>>>>>>> > >> > >>>>>>>>>> > > >>>>>>>>>> > >>>>>>>>>> > _______________________________________________ >>>>>>>>>> > Ecrit mailing list >>>>>>>>>> > Ecrit@ietf.org >>>>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>Ecrit mailing list >>>>>>>>>>Ecrit@ietf.org >>>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>Ecrit mailing list >>>>>>>>>Ecrit@ietf.org >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Ecrit mailing list >>>>>>>Ecrit@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>>------------------------------------------------------------- >>----------------------------------- >>>>This message is for the designated recipient only and may contain >>>>privileged, proprietary, or otherwise private information. >>>>If you have received it in error, please notify the sender >>>>immediately and delete the original. Any unauthorized use of this >>>>email is prohibited. >>>>------------------------------------------------------------- >>----------------------------------- >>>>[mf2] >>>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A913A6CA6 for ; Sat, 7 Feb 2009 00:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Man7wY7kYfW1 for ; Sat, 7 Feb 2009 00:14:08 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0BEA63A67B1 for ; Sat, 7 Feb 2009 00:14:07 -0800 (PST) Received: (qmail invoked by alias); 07 Feb 2009 08:14:10 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 07 Feb 2009 09:14:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Aidc+WZ6ABXkf8M7elJcm53835OTD2CEA/9W7Yu msLn3vkoQrRDAg From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'Henning Schulzrinne'" , "'James M. Polk'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net><001d01c9885b$d5d705d0$49b5b70a@nsnintra.net><001f01c98860$910658c0$49b5b70a@nsnintra.net><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$49b5b70a@nsnintra.net><1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$49b5b70a@nsnintra.net><7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Sat, 7 Feb 2009 10:14:57 +0200 Message-ID: <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqAABCWV2A= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 08:14:09 -0000 PLEASE try to understand that the syntax is similar (header, new namespace, new values) BUT the semantic is different. For all message it is true that the sender can add whatever they want. The big question is what does it mean for the recipient. This is what the discussion is about. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of DRAGE, Keith (Keith) >Sent: 07 February, 2009 02:22 >To: Henning Schulzrinne; James M. Polk >Cc: ECRIT >Subject: Re: [Ecrit] RPH > >Well to be honest, I thought RFC 4412 defined exactly the >usage from the UA of any RPH header, and noone appears to be >seeking to change that. Any UE can insert an RPH header, and >the outbound proxy that understands RPH can use this as >absolute, guidance, or completely ignore it and throw it away >depending on whatever rules it decides apply to its usage of >that namespace. IETF does not write those rules, just defines >the namespace. > >So I disagree with the statement of "underspecified" in >relation to this. > >regards > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Henning Schulzrinne >> Sent: Friday, February 06, 2009 10:29 PM >> To: James M. Polk >> Cc: ECRIT >> Subject: Re: [Ecrit] RPH >> >> To restate: I will object to any text mentioning use of ESNET in UAs. >> It's useless (since under-specified), likely to be harmful >to reliable >> network operation and just causes confusion. The text should >describe >> when it is useful (within a "closed" >> ESNET, presumably) and what conditions need to be met in order to >> ensure reliable and secure usage. That something might be useful >> somewhere else is always true, in any specification, but we >don't add >> a "This document does not prevent the use of this mechanism >somewhere >> else." in documents. >> >> Henning >> >> On Feb 6, 2009, at 5:21 PM, James M. Polk wrote: >> >> > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote: >> >> James, >> >> >> >> we don't go through every possible SIP header that might >> be inserted >> >> into emergency requests. Yes, somebody could add RPH, but this >> >> applies to PAI and dozens of other SIP headers as well. So far, >> >> nobody has provided, in my opinion, a compelling use case that is >> >> worth documenting. "It could be useful somewhere for something" >> >> doesn't cut it. I have provided multiple reasons why I >> think that it >> >> is a bad idea for (normal) UAs to do so, none of which >you address. >> > >> > >> >> I see no need to say "do not insert RPH", >> > >> > this is the only thing - right now - that I'm afraid one of us >> > believes should be the case. I'm glad you are not joining that >> > position. I really do not want to highlight the idea fo >> UAs inserting >> > esnet, but I believe sometime down the road - some customer >> will come >> > up with a valid reason for this, and I don't want to state in text >> > that it is prevented from being inserted (and yet have the >> vendor who >> > wants to sell to that customer also want that vendor to >> adhere to this >> > spec as well). >> > >> > I'm just advocating we not have the text prevent its inclusion. >> > >> > As I've said, I will beef up the security considerations >> section wrt >> > UA insertion of esnet - unless others object to this... >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F9428C0D8 for ; Sat, 7 Feb 2009 00:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3jN1xfERPVk for ; Sat, 7 Feb 2009 00:22:11 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1B2843A6A5C for ; Sat, 7 Feb 2009 00:22:09 -0800 (PST) Received: (qmail invoked by alias); 07 Feb 2009 08:22:11 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp027) with SMTP; 07 Feb 2009 09:22:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/AmWUYbi7AccD12KI3ad4BzQo0hmFVZgOqourAZ8 Ij7yL3X9HClt4A From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'DOLLY, MARTIN C, ATTLABS'" , , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Sat, 7 Feb 2009 10:22:58 +0200 Message-ID: <007301c988fd$497f6940$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmIp7cDTjOFrFzQSeSaJoip38DOVgAAJrguAAEikiAAA19QMAAQefrQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 08:22:14 -0000 Hi Keith, >It appears you want to develop an entirely separate codepath >for the usage of RPH in emergency calls, where the appropriate >thing is to apply the tested usage of RPH that many networks >will have to deploy anyway. So there will be a standard RPH >usage which is then configured to handle the emergency namespace. IF you don't add any additional branch for the case where the call is an emergency call (Service URN or respective dial string present) AND the ECRIT RPH is set (in addition that the case where the call is detected as an emergency call) THEN the ECRIT RPH thing does not add any value. With the same argument we could also add another header "IGNORE_AUTHORIZATION_FAILURE" that can be set by the UA and 1) let the proxy decide whether it wants to trust it (a security policy, as folks argue) 2) if it does then there is a code branch that ignores authorization failures. Now, one would argue that (2) might be a bit risky from a security point of view when the call is not an emergency call. Hence, you have to make sure that the call is an emergency call (by checking Service URN and specific dial string presence). Then, someone who thinks about it might then argue: "Wait, we already have this code already in there for the case that the call is an emergency call anyway. There wouldn't be any additional value of sending such a header." This is exactly what is happening here with the ECRIT RPH case. Convincing? Ciao Hannes >regards > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Hannes Tschofenig >> Sent: Friday, February 06, 2009 10:52 PM >> To: 'DOLLY, MARTIN C, ATTLABS'; jmpolk@cisco.com; >hgs@cs.columbia.edu; >> James.Winterbottom@andrew.com >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org >> Subject: Re: [Ecrit] RPH >> >> Hi Martin, >> >> I am arguing that if the UE does mark the call with the ECRIT RPH (I >> call it that way to differentiate it from RFC 4412 RPH >usage, which is >> very >> different) then it should be ignored. >> Processing it will not help in any way (as I described in my pseudo >> code snippet). Incorrectly processing it (which is a >possibility when >> the implementer does not understand the security >implications -- they >> will not get it from the current version of the draft) will lead to >> security problems (fraud & DoS potential). >> >> While you cannot prevent someone from sending you, there is >certainly >> the chance to document what the receiver should do with it. >> >> Ciao >> Hannes >> >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf >> >Of DOLLY, MARTIN C, ATTLABS >> >Sent: 07 February, 2009 00:15 >> >To: jmpolk@cisco.com; hgs@cs.columbia.edu; >> >James.Winterbottom@andrew.com >> >Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org >> >Subject: Re: [Ecrit] RPH >> > >> >You can not disallow this from an UE. The trust relationship will >> >dictate whether it is accepted or not >> > >> >----- Original Message ----- >> >From: ecrit-bounces@ietf.org >> >To: Henning Schulzrinne ; Winterbottom, James >> > >> >Cc: Tschofenig, Hannes (NSN - FI/Espoo) >; >> >ECRIT >> >Sent: Fri Feb 06 17:10:08 2009 >> >Subject: Re: [Ecrit] RPH >> > >> >At 03:05 PM 2/6/2009, Henning Schulzrinne wrote: >> >>There's another problem with the "it doesn't hurt argument". >> >Assume for >> >>a moment we have a "UA MAY include RPH" wording. There are now two >> >>cases: >> >> >> >>(1) All UAs implement it. >> >> >> >>(2) Only some UAs implement it. >> >> >> >>(1) seems unlikely for a MAY. If (2) occurs, we have the >> >choice between >> >>two undesirable outcomes: >> >> >> >>(a) some UAs that are otherwise compliant get worse service just >> >>because they didn't include the RPH; >> > >> >am I reading this correctly - that unless all UAs implement this >> >capability this should never be implemented by any UAs? >> > >> >This flies in the face of vendors solving for their customer's >> >requirements. >> > >> >I will admit that at this time, I know of no Cisco customers >> that want >> >this capability, so I'm not angling for any of our revenue >> here. I'm >> >saying that I think I hear you saying this ID should say >> something like >> > >> > UAs are prevented from implementing the RP namespace esnet >> > >> >I'm fighting against that, because customers are always >> coming to every >> >vendor with new requirements, some of them unique at the >time. This >> >prevention text would prevent a vendor from complying with this >> >specification and still meet the customer's needs. >> > >> >I believe that this ID needs to retain the endpoints MAY >> insert esnet, >> >and have appropriate security considerations text that >> highlights the >> >concerns expressed here. >> > >> >Some future ID can then update this current RFC (to-be) within the >> >2119 rules of the use of MAY here. >> > >> > >> >>OR >> >> >> >>(b) the proxy has to look for the service URN to give the call the >> >>appropriate treatment, thus obviating any advantage of having the >> >>header, yet incurring more complicated processing logic. >> >> >> >> >> >>I have no objection to whatever markings people want to >> apply to calls >> >>within an ESN - that's largely a private matter. >> >> >> >>Henning >> >> >> >>On Feb 6, 2009, at 3:01 PM, Winterbottom, James wrote: >> >> >> >>>Hi All, >> >>> >> >>>I have followed thi thread with some interest and I >> struggling to see >> >>>a use case for the providing RPH for emergency calls from the >> >>>end-point. >> >>> >> >>>The reference-model call in ECRIT, for better or worse, >is for all >> >>>calls to go back through a home-VSP. >> >>>We placed quite a lot of emphasis, largely for traffing >> reasons, for >> >>>the VSP to be able to verify that a call is in fact an emergency >> >>>call. This is done by the proxy taking the inband >> location, doing a >> >>>LoST query with the provided URN, and verifying that the >resulting >> >>>destination URI is the same as the destination URI provide >> in the SIP >> >>>INVITE. My understanding was that VSPs would always do >> this check so >> >>>they could tell if they could bill for the call or not, >> and because >> >>>the VSP can be use that the call is an emergency call it >can apply >> >>>any special priorities that may be applicable. This >> obviates the need >> >>>for RPH from the end-point to the network. >> >>> >> >>>This leaves us with the argument of "it doesn't hurt to >> it", which is >> >>>not a good reason to write a specification. >> >>>It was intimated on the geopriv mailing list last year that great >> >>>pains had been taken to keep SIP with in the MTU limits of >> UDP over >> >>>Ethernet >> >>>(http://www.ietf.org/mail-archive/web/geopriv/current/msg0612 >> >0.html ). Assuming >> >>>that this is the case, perhaps there is harm in including >> information >> >>>that we know will be ignored. >> >>> >> >>>Cheers >> >>>James >> >>> >> >>> >> >>> >> >>>-----Original Message----- >> >>>From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >> >>>Sent: Fri 2/6/2009 12:33 PM >> >>>To: 'Brian Rosen'; 'Henning Schulzrinne' >> >>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >> >>>Subject: Re: [Ecrit] RPH >> >>> >> >>>To the story short here is the code for the proxy: >> >>> >> >>>--------------------- >> >>> >> >>>IF emergency call was recognized THEN >> >>> execute emergency call specific procedures (priority queuing, >> >>>preemption, fetch location, determine routing, do funny >> QoS things & >> >>>co) >> >>>ELSE >> >>> normal call handling procedures. >> >>> >> >>>--------------------- >> >>> >> >>>If you can make this differentiation between an emergency >> call and a >> >>>regular call then you can also do everything that is >necessary for >> >>>emergency call handling. >> >>> >> >>>Brian + Keith: Please tell me that we cannot do the above >with our >> >>>currently specified mechanisms. >> >>> >> >>>Ciao >> >>>Hannes >> >>> >> >>>>-----Original Message----- >> >>>>From: Brian Rosen [mailto:br@brianrosen.net] >> >>>>Sent: 06 February, 2009 17:49 >> >>>>To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >> >>>>Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >>>>Subject: RE: [Ecrit] RPH >> >>>> >> >>>>I agree that not all networks will permit (or pay attention >> >>>>to) a priority request from an end device. >> >>>> >> >>>>No one has asked for that. >> >>>> >> >>>>The namespace request has several uses, one of which is >within an >> >>>>emergency services IP network, one of which is between elements >> >>>>within a public network controlled by the operator, and >> one of which >> >>>>is an endpoint request for resource priority. >> >>>> >> >>>>Those of us requesting this work proceed are happy if the >> endpoint >> >>>>part is simply left as possible (MAY), and, speaking for myself, >> >>>>having the draft discuss the security implications of endpoint >> >>>>marking is reasonable. >> >>>> >> >>>>Having discussed this issue with an implementation team >> who worked >> >>>>on MLPP systems, I am confident I know what I'm talking >> about, but >> >>>>YMMV. The fact that you could, if you wanted to, give resource >> >>>>priority to a call you decided, however you decided, was an >> >>>>emergency call is an implementation decision, and not subject to >> >>>>standardization. >> >>>> >> >>>>RPH is the IETF standard way for one entity to request resource >> >>>>priority of another entity in a SIP system. We're asking for a >> >>>>namespace to use that within the domain of emergency >calls. That >> >>>>is, I think, a VERY reasonable request. >> >>>> >> >>>>Brian >> >>>> >> >>>>>-----Original Message----- >> >>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >>>>>Sent: Friday, February 06, 2009 10:33 AM >> >>>>>To: Hannes Tschofenig >> >>>>>Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> >>>>>Subject: Re: [Ecrit] RPH >> >>>>> >> >>>>>To chime in here: >> >>>>> >> >>>>>I don't think it's productive to simply state that 4412 >> >>>>doesn't worry >> >>>>>about authorization, so we shouldn't either (simplifying a bit). >> >>>>>Authorization was discussed repeatedly, and the general >> >>>>assumption was >> >>>>>that there were two conditions: Either the user invoking >> resource- >> >>>>>priority was well known and had a set of permissions >> that could be >> >>>>>checked in real time or there are ways to deal with >> abuse after the >> >>>>>fact in ways that deter abuse (the court-martial kind of >> thing in a >> >>>>>military context). >> >>>>> >> >>>>>The RFC 4412 security consideration (11.2) call this out >> in pretty >> >>>>>strong language: >> >>>>> >> >>>>> Prioritized access to network and end-system resources imposes >> >>>>> particularly stringent requirements on authentication and >> >>>>> authorization mechanisms, since access to prioritized >> >>>>resources may >> >>>>> impact overall system stability and performance and not >> >>>>just result >> >>>>> in theft of, say, a single phone call. >> >>>>>Thus, the question is whether we have such strong >> authentication in >> >>>>>emergency calling. In some cases, such as residential >fixed line >> >>>>>deployments where ISP = VSP, we're probably pretty close, >> >in others, >> >>>>>such as prepaid cell phones or hot spots or VSP-only >> providers, we >> >>>>>aren't. >> >>>>> >> >>>>>The other point that I think Hannes is making is that the >> >>>>information >> >>>>>is either redundant or dangerous. If a processing element >> >recognizes >> >>>>>the call as being an emergency call, it can apply whatever >> >treatment >> >>>>>it deems appropriate and doesn't need additional >> information. If it >> >>>>>doesn't or can't, using just the RPH can be rather >> dangerous unless >> >>>>>that element can be reasonably certain that there is strong >> >>>>>authentication and recourse. >> >>>>> >> >>>>>I don't buy the argument that somehow finding the RPH is >> >faster than >> >>>>>just looking for the identifier. Thus, given that the >> >information is >> >>>>>either redundant or dangerous, I fail to see the advantage. >> >>>>> >> >>>>>Henning >> >>>>> >> >>>>> >> >>>>>On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >> >>>>> >> >>>>>>Don't get hung up on the details. There are ways to >optimize it. >> >>>>>>That was >> >>>>>>not the point of the code example. >> >>>>>> >> >>>>>>The problem that my pseudo code should have shown you >> is that you >> >>>>>>* don't gain anything with RPH marking for the >> emergency call case >> >>>>>>from the SIP UA towards the outbound proxy since the >> functionality >> >>>>>>is already provide otherwise. How often does the proxy >> need to get >> >>>>>>told that this is an emergency call todo whatever >> emergency call >> >>>>>>handling procedures are necessary? >> >>>>>>* you only introduce fraud problems (if you are not >> >>>>careful and you >> >>>>>>understand the security stuff well enough) >> >>>>>> >> >>>>>>If you can point me to people who implement the RPH >> emergency call >> >>>>>>case please do so. I would love to talk to them. >> >>>>>> >> >>>>>>Ciao >> >>>>>>Hannes >> >>>>>> >> >>>>>>PS: You need to parse incoming messages to some extend >> so that you >> >>>>>>know what it contains :-) Only looking for the emergency >> >>>>RPH header >> >>>>>>(and not for the Service URN/dial >> >>>>>>string) would exactly be the DoS/fraud attack I am >> worried about. >> >>>>>>That's the thing Henning was worried about (go and >> listen to the >> >>>>>>past meeting minutes). >> >>>>>> >> >>>>>> >> >>>>>>>Hannes >> >>>>>>> >> >>>>>>>You need to talk to people who really implement this kind >> >>>>of thing. >> >>>>>>>You are way off. >> >>>>>>> >> >>>>>>>When you implement a resource priority system, the >> point of doing >> >>>>>>>that is to look though the queue of work and pick out the >> >>>>ones with >> >>>>>>>priority, handling them first. You don't do all the >> parsing, you >> >>>>>>>don't do a lot of decision tree. >> >>>>>>> >> >>>>>>>Typically: >> >>>>>>>Check for DoS things, like too big messages, etc Do a >> quick scan >> >>>>>>>for the RPH message header If found: >> >>>>>>>Parse the message >> >>>>>>>Determine validity >> >>>>>>>Determine priority >> >>>>>>>Queue on the correct work queue >> >>>>>>> >> >>>>>>>The first two actions have to be very fast. Anyone >> who builds a >> >>>>>>>SIP thingie will tell you that parsing is one of the big cycle >> >>>>>>>consumers: if you have to parse every message BEFORE you >> >>>>determine >> >>>>>>>priority, you can't give much resource priority. >> >>>>>>>Once you get the whole message parsed, you might as >> well finish >> >>>>>>>working on it, because you've done so much of the work. >> >>>>>>>OTHOH, finding the end-of-message delimiter and doing a quick >> >>>>>>>string search for RPH is fast. If you are doing >> >>>>priority, you need >> >>>>>>>to keep all the priority processing pretty uniform, >and pretty >> >>>>>>>simple, or you tend to spend too much time futzing around >> >>>>figuring >> >>>>>>>out what to do. You put all the priority related >> stuff together, >> >>>>>>>and use as much common code as possible. >> >>>>>>> >> >>>>>>>Brian >> >>>>>>> >> >>>>>>>>-----Original Message----- >> >>>>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >>>>>>>On Behalf >> >>>>>>>>Of Hannes Tschofenig >> >>>>>>>>Sent: Friday, February 06, 2009 8:41 AM >> >>>>>>>>To: 'Hannes Tschofenig'; 'Janet P Gunn' >> >>>>>>>>Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >> >>>>>>>>bounces@ietf.org >> >>>>>>>>Subject: [Ecrit] RPH >> >>>>>>>> >> >>>>>>>>Over lunch I was also thinking how an outbound proxy would >> >>>>>implement >> >>>>>>>>some of the emergency procedures. Here are some thoughts: >> >>>>>>>> >> >>>>>>>>--------------------------------------------------- >> >>>>>>>> >> >>>>>>>>// Process incoming message >> >>>>>>>>Parse(msg); >> >>>>>>>> >> >>>>>>>>// SIP INVITE without Service URN // legacy devices If >> >>>>>>>>(recognize-dialstring(msg)==TRUE) { // we got an >> emergency call >> >>>>>>>>going on emergency=TRUE; if (dialstring(msg) == 911) >> >>>>>>>>serviceURN=urn:service:sos; } else if >> >>>>>>>>(recognize-serviceURN(msg)==TRUE) { // oh. A updated >> >>>>device that >> >>>>>>>>has a service URN attached to the >> >>>>>call >> >>>>>>>>serviceURN=retrieve_ServiceURN(msg); >> >>>>>>>>emergency=TRUE; >> >>>>>>>>} else { >> >>>>>>>>// standard SIP message >> >>>>>>>>// regular processing >> >>>>>>>>process(msg); >> >>>>>>>>emergency=FALSE; >> >>>>>>>>} >> >>>>>>>> >> >>>>>>>>If (emergency == TRUE) { >> >>>>>>>> // make sure that the emergency call does not get >> >>>>dropped on the >> >>>>>>>>floor >> >>>>>>>> // skip authorization failures >> >>>>>>>> // give the call a special treatment >> >>>>>>>> lots-of-code-here(); >> >>>>>>>> >> >>>>>>>> // trigger all the QoS signaling you have in the >> >>>>network to make >> >>>>>>>>James happy >> >>>>>>>> trigger-qos(); >> >>>>>>>> >> >>>>>>>> // query location >> >>>>>>>> location=retrieve-location(); >> >>>>>>>> >> >>>>>>>> // determine next hop >> >>>>>>>> next-hop=lost(location, serviceURN) >> >>>>>>>> >> >>>>>>>> // attach RPH marking to outgoing msg to make James and >> >>>>>>>Keith happy >> >>>>>>>> msg=add(msg, RPH); >> >>>>>>>> >> >>>>>>>> send(msg, next-hop); >> >>>>>>>>} >> >>>>>>>> >> >>>>>>>>If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >> >>>>>>>> // all the emergency related processing done >already upfront >> >>>>>>>> // hence I log something. >> >>>>>>>> log(RPH_WAS_PRESENT_JUHU); >> >>>>>>>>} else if ((rph-present(msg) == TRUE) && (emergency == >> >>>>FALSE)) { >> >>>>>>>>// this is not an emergency call // this is something >> >>>>like GETS >> >>>>>>>>result=special-authorization-procedure(user); >> >>>>>>>> >> >>>>>>>>if (result == AUTHORIZED) { >> >>>>>>>> // do some priority & preemption thing here. >> >>>>>>>> // trigger all the QoS you have >> >>>>>>>> lots-of-code-here(); >> >>>>>>>>} else { >> >>>>>>>> log("NOT AUTHORIZED; don't DoS my network"); } } >> else { // >> >>>>>>>>don't need todo any RPH processing // this includes >the case >> >>>>>>>>where the call was an emergency call but the RPH >> >>>>>>>> >> >>>>>>>>// marking was not there. >> >>>>>>>>nothing(); >> >>>>>>>>} >> >>>>>>>> >> >>>>>>>>--------------------------------------------------- >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>Ciao >> >>>>>>>>Hannes >> >>>>>>>> >> >>>>>>>>>-----Original Message----- >> >>>>>>>>>From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >> >>>>>>>>>Behalf Of Hannes Tschofenig >> >>>>>>>>>Sent: 06 February, 2009 15:07 >> >>>>>>>>>To: 'Janet P Gunn' >> >>>>>>>>>Cc: 'ECRIT'; ecrit-bounces@ietf.org; >Tschofenig,Hannes (NSN - >> >>>>>>>>FI/Espoo) >> >>>>>>>>>Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >> >Agenda (RPH) >> >>>>>>>>> >> >>>>>>>>>Who would define something that could prevent DoS problems? >> >>>>>>>>> >> >>>>>>>>>________________________________ >> >>>>>>>>> >> >>>>>>>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >> >>>>>>>>> Sent: 06 February, 2009 14:11 >> >>>>>>>>> To: Hannes Tschofenig >> >>>>>>>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; >'ECRIT'; >> >>>>>>>>>ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >> >>>>>'James >> >>>>>>>>>M. Polk' >> >>>>>>>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >>>>Meeting: Agenda (RPH) >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> But there is nothing IN RFC4412 that specifically >> >>>>>>>addresses how to >> >>>>>>>>>prevent any particular namespace being used for DoS. >> >Anyone/any >> >>>>>UA >> >>>>>>>>>can ATTEMPT to invoke priority treatment by >> attaching RPH. For >> >>>>>all >> >>>>>>>>>of the 4412 namespaces, as with the new proposed >> namespace, the >> >>>>>>>>>mechanisms for preventing DoS are not specified in the >> >>>>>>>document that >> >>>>>>>>>defines the namespace. >> >>>>>>>>>They are/will be specified elsewhere. >> >>>>>>>>> >> >>>>>>>>> Janet >> >>>>>>>>> >> >>>>>>>>> This is a PRIVATE message. If you are not >> the intended >> >>>>>>>recipient, >> >>>>>>>>>please delete without copying and kindly advise us >> by e-mail of >> >>>>>the >> >>>>>>>>>mistake in delivery. >> >>>>>>>>> NOTE: Regardless of content, this e-mail shall not >> >>>>>>>operate to bind >> >>>>>>>>>CSC to any order or other contract unless pursuant >> to explicit >> >>>>>>>>>written agreement or government initiative expressly >> permitting >> >>>>>the >> >>>>>>>>>use of e-mail for such purpose. >> >>>>>>>>> >> >>>>>>>>> ecrit-bounces@ietf.org wrote on 02/06/2009 >> >04:21:51 AM: >> >>>>>>>>> >> >>>>>>>>> > Hi James, >> >>>>>>>>> > >> >>>>>>>>> > I have read RFC 4412 and also the GETS/MLPP IETF >> >>>>>>>documents. What I >> >>>>>>>>>would >> >>>>>>>>> > like to point out is that there is more >> than just a >> >>>>>>>header and >> >>>>>>>>>values within >> >>>>>>>>> > the header that have to be considered in order to >> >>>>>>>make a judgement >> >>>>>>>>>of what >> >>>>>>>>> > is appropriate and what isn't. There is an >> >>>>>>>architectural question >> >>>>>>>>>and >> >>>>>>>>> > whether the environment we are using the stuff is >> >>>>>>>indeed providing >> >>>>>>>>>the >> >>>>>>>>> > properties you need for the solution to be >> >>>>appropriate. >> >>>>>>>>> > >> >>>>>>>>> > Let me describe in more detail what I meant (and >> >>>>>>>please correct me >> >>>>>>>>>if I am >> >>>>>>>>> > wrong). >> >>>>>>>>> > >> >>>>>>>>> > Getting priority for SIP requests when >> using a GETS >> >>>>>>>alike scenario >> >>>>>>>>>means >> >>>>>>>>> > that the entity that issues the request >> is specially >> >>>>>>>authorized >> >>>>>>>>>since >> >>>>>>>>> > otherwise you introduce a nice denial of >> >>>>service attack. This >> >>>>>>>>>authorization >> >>>>>>>>> > is tied to the entity that makes the request. For >> >>>>>>>example, the >> >>>>>>>>>person is >> >>>>>>>>> > working for the government and has >special rights. >> >>>>>>>>>James Bond as a (not so) >> >>>>>>>>> > secret agent might have these rights. >> >>>>>>>>> > >> >>>>>>>>> > The emergency services case >> >>>>(citizen-to-authority) is a bit >> >>>>>>>>>different as >> >>>>>>>>> > there aren't really special rights with >respect to >> >>>>>>>authorization >> >>>>>>>>>tied to >> >>>>>>>>> > individuals. Instead, the fact that >> something is an >> >>>>>>>emergency is >> >>>>>>>>>purely a >> >>>>>>>>> > judgement of the human that dials a >> special number. >> >>>>>>>>>To deal with fraud, we >> >>>>>>>>> > discussed in the group on what we can >> actually do to >> >>>>>>>ensure that >> >>>>>>>>>end users >> >>>>>>>>> > do not bypass security procedures (such as >> >>>>>>>authorization checks, >> >>>>>>>>>charging >> >>>>>>>>> > and so on). Part of this investigation was >> >>>>the publication of >> >>>>>>>>> > http://www.ietf.org/rfc/rfc5069.txt that also >> >>>>describes this >> >>>>>>>>>issue. >> >>>>>>>>> > >> >>>>>>>>> > So, imagine the implementation of a SIP >> >proxy (and we >> >>>>>>>implemented >> >>>>>>>>>that >> >>>>>>>>> > stuff) that receives a call that contains >> a Service >> >>>>>>>URN. The code >> >>>>>>>>>branches >> >>>>>>>>> > into a special mode where everything is done >> >>>>so that the call >> >>>>>>>>>receives >> >>>>>>>>> > appropriate treatment and does not get >> >dropped on the >> >>>>>>>floor. The >> >>>>>>>>>way how the >> >>>>>>>>> > Service URN is placed in the message >> >ensures that the >> >>>>>>>call cannot >> >>>>>>>>>go to my >> >>>>>>>>> > friend (instead of the PSAP) unless the >> end host ran >> >>>>>>>LoST already. >> >>>>>>>>>In the >> >>>>>>>>> > latter case, we discussed this also on the >> >list for a >> >>>>>>>while and >> >>>>>>>>>Richard even >> >>>>>>>>> > wrote a draft about it in the context of the >> >>>>location hiding >> >>>>>>>>>topic, we said >> >>>>>>>>> > that the proxy would have to run LoST if he >> >>>>cares about a >> >>>>>>>>>potential >> >>>>>>>>> > fraudulent usage. >> >>>>>>>>> > >> >>>>>>>>> > So, what do we need todo in order to provide >> >>>>secure RFC 4412 >> >>>>>>>>>functionality >> >>>>>>>>> > in our context? >> >>>>>>>>> > >> >>>>>>>>> > Do you think that the current text in >> >>>>>>>>> > >> >>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit- >> local-emer >> >>>>>>>>>gency-rph-nam >> >>>>>>>>> > espace-00.txt reflects any of the >> >>>>above-described issues: >> >>>>>>>>> > " >> >>>>>>>>> > The Security considerations that apply >> >to RFC 4412 >> >>>>>>>>>[RFC4412] >> >>>>>>>>>apply >> >>>>>>>>> > here. This document introduces no >new security >> >>>>>>>>>issues relative >> >>>>>>>>>to >> >>>>>>>>> > RFC 4412. >> >>>>>>>>> > " >> >>>>>>>>> > >> >>>>>>>>> > From various discussions in GEOPRIV I recall >> >>>>that you are >> >>>>>>>>>super-sensitive >> >>>>>>>>> > regarding security and privacy. For some >> reasons you >> >>>>>>>don't seem to >> >>>>>>>>>have the >> >>>>>>>>> > same concerns here. I would like to >> >>>>understand your reasoning. >> >>>>>>>>> > >> >>>>>>>>> > Please also do me another favor: Don't always say >> >>>>>>>that I don't >> >>>>>>>>>understand >> >>>>>>>>> > the subject. Even if that would be the >> case it isn't >> >>>>>>>particular >> >>>>>>>>>fair given >> >>>>>>>>> > that different folks had to educate you on other >> >>>>>>>topics in the >> >>>>>>>>>past as well. >> >>>>>>>>> > Additionally, if you listen to the audio >> recordings >> >>>>>>>then you will >> >>>>>>>>>notice >> >>>>>>>>> > that Henning, Ted, and Jon do not seem to >> understand >> >>>>>>>the issue >> >>>>>>>>>either as >> >>>>>>>>> > they have raised similar issues during the >> >>>>F2F meetings. >> >>>>>>>>> > >> >>>>>>>>> > Ciao >> >>>>>>>>> > Hannes >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >Hannes - I believe it is you who do not >> understand >> >>>>>>>RFC 4412 -- >> >>>>>>>>> > >and many of us are trying to get that >> >>>>through to you, but you >> >>>>>>>>> > >don't seem to want to listen/read. >> >>>>>>>>> > > >> >>>>>>>>> > >RFC 4412 is *for* priority marking SIP requests, >> >>>>>>>>> > > >> >>>>>>>>> > >One use is GETS. >> >>>>>>>>> > > >> >>>>>>>>> > >One use is MLPP. >> >>>>>>>>> > > >> >>>>>>>>> > >These examples are in RFC 4412 because there >> >>>>were specific >> >>>>>>>>> > >namespaces being created for the IANA section of >> >>>>>>>that document. >> >>>>>>>>> > > >> >>>>>>>>> > >Reading the whole document, you will see >> >>>>that RPH can be >> >>>>>>>>> > >specified for other uses than GETS or MLPP >> >>>>specifically. >> >>>>>>>>> > > >> >>>>>>>>> > >I knew when I wrote RFC 4412 that one day we >> >>>>would specify a >> >>>>>>>>> > >namespace for ECRIT (the "esnet" namespace >> >>>>now) -- but I also >> >>>>>>>>> > >knew it was premature for RFC 4412 to >> >>>>incorporate that >> >>>>>>>>> > >namespace, that a future doc to RFC 4412 >> >>>>would have to be >> >>>>>>>>> > >written to do this. Brian and I talked about >> >>>>this at the >> >>>>>>>>> > >original NENA meeting that created the >> IP WGs there >> >>>>>>>(in August >> >>>>>>>>> > >of 03). We both agreed we should wait >> until it was >> >>>>>>>>> > >appropriate to the work in the IETF to >> >>>>submit this document >> >>>>>>>>> > >that is now >> >>>>>>>>> > >> >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-l >> >ocal-emer >> >>>>>>>>> > >gency-rph-namespace-00.txt >> >>>>>>>>> > > >> >>>>>>>>> > >Yet, you seem to want to use some additional >> >>>>mechanism to >> >>>>>>>>> > >indicate priority of a call in SIP. That >> >>>>means you want to >> >>>>>>>>> > >introduce a second way to accomplish >this in SIP. >> >>>>>>>>>Why do you >> >>>>>>>>> > >want to promote a separate way to do >> something SIP >> >>>>>>>has already >> >>>>>>>>> > >defined? That will cause interoperability >> >issues and >> >>>>>>>we both know >> >>>>>>>>>that. >> >>>>>>>>> > > >> >>>>>>>>> > >You've said to me (and others) that you >> >>>>believe RPH is just >> >>>>>>>>> > >another way to accomplish what sos or a URI can >> >>>>>>>indicate - and >> >>>>>>>>> > >you're wrong. Your way would be >> >>>>_the_second_way_to_do_it, >> >>>>>>>>> > >because SIP already considers RPH to be >> >>>>*the*way* to priority >> >>>>>>>>> > >mark SIP requests. >> >>>>>>>>> > > >> >>>>>>>>> > >If you don't believe me (no comment), then >> >>>>why do you not >> >>>>>>>>> > >believe the SIP WG chair (who knows more >> >>>>about SIP than both >> >>>>>>>>> > >of us) - who, on this thread, has again said >> >>>>to you "RFC 4412 >> >>>>>>>>> > >(RPH) is the SIP mechanism to priority mark >> >>>>SIP requests"? >> >>>>>>>>> > > >> >>>>>>>>> > >Further, I believe it is inappropriate to >> >>>>prohibit endpoints >> >>>>>>>>> > >from being able to set the esnet namespace. >> >>>>I absolutely >> >>>>>>>>> > >believe it will not be needed most of the >> >>>>time, but I believe >> >>>>>>>>> > >if someone does find a valid use for >> >>>>endpoints to mark >> >>>>>>>>> > >priority in SIP, this ID - once it has >> >>>>become an RFC -- will >> >>>>>>>>> > >have to be obsoleted with a new RFC saying >> >the exact >> >>>>>>>opposite. >> >>>>>>>>> > > >> >>>>>>>>> > >(color me confused ... over and over again) >> >>>>>>>>> > > >> >>>>>>>>> > >James >> >>>>>>>>> > > >> >>>>>>>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >> >>>>>>>>> > >>Keith, please understand that the usage >> >of RFC 4412 >> >>>>>>>for GETS and >> >>>>>>>>>for >> >>>>>>>>> > >>the type of emergency call we discuss here is >> >>>>>>>different. Just >> >>>>>>>>>looking >> >>>>>>>>> > >>at the header and the name of the >> >namespace is a bit >> >>>>>>>>> > >artificial. I hope >> >>>>>>>>> > >>you understand that. >> >>>>>>>>> > >> >> >>>>>>>>> > >> >-----Original Message----- >> >>>>>>>>> > >> >From: DRAGE, Keith (Keith) >> >>>>>>>>>[mailto:drage@alcatel-lucent.com] >> >>>>>>>>> > >> >Sent: 05 February, 2009 14:55 >> >>>>>>>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; >> 'James M. >> >>>>>>>>>Polk'; 'Tschofenig, >> >>>>>>>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >>>>>>>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >> >>>>>>>>>Meeting: Agenda (my >> >>>>>>>>> >> >>>>>>>>> > >> >mistake) >> >>>>>>>>> > >> > >> >>>>>>>>> > >> >Which is exactly what RFC 4412 >> specifies for all >> >>>>>>>namespaces. >> >>>>>>>>> > >> > >> >>>>>>>>> > >> >regards >> >>>>>>>>> > >> > >> >>>>>>>>> > >> >Keith >> >>>>>>>>> > >> > >> >>>>>>>>> > >> >> -----Original Message----- >> >>>>>>>>> > >> >> From: ecrit-bounces@ietf.org >> >>>>>>>[mailto:ecrit-bounces@ietf.org] >> >>>>>>>>> > >> >On Behalf >> >>>>>>>>> > >> >> Of Brian Rosen >> >>>>>>>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >>>>>>>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >> >>>>Polk'; 'Tschofenig, >> >>>>>>>>> > >Hannes (NSN >> >>>>>>>>> > >> >> - FI/Espoo)'; 'ECRIT' >> >>>>>>>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >>>>>>>>>Meeting: Agenda (my >> >>>>>>>>> > >> >> mistake) >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> >> The value is that in some networks >> >>>>where priority for >> >>>>>>>>> > >> >emergency calls >> >>>>>>>>> > >> >> is appropriate, and appropriate >> >>>>policing of marking is >> >>>>>>>>> > >implemented, >> >>>>>>>>> > >> >> emergency calls will receive resource >> >priority. >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> >> Not all networks would need policing. Some >> >>>>>>>will. Policing >> >>>>>>>>>could >> >>>>>>>>> > >> >> be to Route header/R-URI content, but other >> >>>>>>>criteria are >> >>>>>>>>>possible. >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> >> Not all networks will need >resource priority >> >>>>>>>for emergency >> >>>>>>>>>calls. >> >>>>>>>>> > >> >> Fine, ignore this marking/namespace. >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> >> Brian >> >>>>>>>>> > >> >> > -----Original Message----- >> >>>>>>>>> > >> >> > From: Hannes Tschofenig >> >>>>>>>>>[mailto:Hannes.Tschofenig@gmx.net] >> >>>>>>>>> > >> >> > Sent: Wednesday, February 04, >2009 5:09 PM >> >>>>>>>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >> >>>>>>>Tschofenig, Hannes >> >>>>>>>>>(NSN - >> >>>>>>>>> > >> >> > FI/Espoo); 'ECRIT' >> >>>>>>>>> > >> >> > Subject: RE: [Ecrit] ECRIT >Virtual Interim >> >>>>>>>>>Meeting: Agenda (my >> >>>>>>>>> > >> >> > mistake) >> >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > I don't even see the value in >> permitting the >> >>>>>>>endpoint todo >> >>>>>>>>>the >> >>>>>>>>> > >> >> > RPH marking. >> >>>>>>>>> > >> >> > In addition to the security concerns >> >>>>there is also the >> >>>>>>>>> > >> >problem that >> >>>>>>>>> > >> >> > there are more options to >> implement without >> >>>>>>>an additional >> >>>>>>>>>value. >> >>>>>>>>> > >> >> > >> >>>>>>>>> > >> >> > >-----Original Message----- >> >>>>>>>>> > >> >> > >From: Brian Rosen >> >[mailto:br@brianrosen.net] >> >>>>>>>>> > >> >> > >Sent: 05 February, 2009 00:03 >> >>>>>>>>> > >> >> > >To: 'James M. Polk'; 'Hannes >Tschofenig'; >> >>>>>>>'Tschofenig, >> >>>>>>>>> > >> >> Hannes (NSN - >> >>>>>>>>> > >> >> > >FI/Espoo)'; 'ECRIT' >> >>>>>>>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >> >>>>Interim Meeting: >> >>>>>>>>>Agenda (my >> >>>>>>>>> > >> >> > mistake) >> >>>>>>>>> > >> >> > > >> >>>>>>>>> > >> >> > >Hannes >> >>>>>>>>> > >> >> > > >> >>>>>>>>> > >> >> > >This matches my understanding >> >>>>precisely. We wish to >> >>>>>>>>> > >> >> permit endpoints >> >>>>>>>>> > >> >> > >to mark. We do not require it, and >> >>>>don't necessarily >> >>>>>>>>>expect it >> >>>>>>>>> > >> >> > >in many (even >> >>>>>>>>> > >> >> > >most) cases. We don't wish to see the >> >>>>>>>document prohibit >> >>>>>>>>>it. >> >>>>>>>>> > >> >> > >We all seem to agree it has value >> >within the >> >>>>>>>Emergency >> >>>>>>>>> > >> >Services IP >> >>>>>>>>> > >> >> > >Networks. >> >>>>>>>>> > >> >> > > >> >>>>>>>>> > >> >> > >Brian >> >>>>>>>>> > >> >> > > >> >>>>>>>>> > >> >> > >> -----Original Message----- >> >>>>>>>>> > >> >> > >> From: ecrit-bounces@ietf.org >> >>>>>>>>>[mailto:ecrit-bounces@ietf.org] >> >>>>>>>>> > >> >> > >On Behalf >> >>>>>>>>> > >> >> > >> Of James M. Polk >> >>>>>>>>> > >> >> > >> Sent: Wednesday, February 04, >> >2009 4:01 PM >> >>>>>>>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >> >>>>Hannes (NSN - >> >>>>>>>>> > >> >> FI/Espoo); 'ECRIT' >> >>>>>>>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT >> >Virtual Interim >> >>>>>>>>>Meeting: >> >>>>>>>>> > >Agenda (my >> >>>>>>>>> > >> >> > >> mistake) >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >> >>>>Tschofenig wrote: >> >>>>>>>>> > >> >> > >> > > James wrote: >> >>>>>>>>> > >> >> > >> > >> you are the _lone_ voice not >> >>>>>>>supporting this ID, >> >>>>>>>>> > >> >> > >> > >> >>>>>>>>> > >> >> > >> >Listening to the audio >> recording of past >> >>>>>>>meetings I >> >>>>>>>>>have to >> >>>>>>>>> > >> >> > >say that >> >>>>>>>>> > >> >> > >> >I >> >>>>>>>>> > >> >> > >> was >> >>>>>>>>> > >> >> > >> >not the only persons raising >> >>>>concerns about the >> >>>>>>>>>document. >> >>>>>>>>> > >> >> > >> >That was probably the reason why you >> >>>>>>>agreed to limit >> >>>>>>>>>the >> >>>>>>>>> > >> >> > >scope of the >> >>>>>>>>> > >> >> > >> >document (which you didn't >> later do) to >> >>>>>>>get folks to >> >>>>>>>>>agree >> >>>>>>>>> > >> >> > >to make it >> >>>>>>>>> > >> >> > >> a WG >> >>>>>>>>> > >> >> > >> >item. >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> re-listen to the audio please >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> Ted's concerns were consistent >> with most >> >>>>>>>>>(all?) other >> >>>>>>>>> > >> >> concerns -- >> >>>>>>>>> > >> >> > >> which were based on the premise >> >of whether >> >>>>>>>or not the >> >>>>>>>>> > >> >> UAC should be >> >>>>>>>>> > >> >> > >> trusted to initiate the marking on the >> >>>>>>>INVITE. The >> >>>>>>>>>most >> >>>>>>>>> > >> >> > >> recent version has backed off this >> >>>>to a "can" -- >> >>>>>>>>>meaning not >> >>>>>>>>> > >> >prohibited >> >>>>>>>>> > >> >> > >> (i.e., no 2119 text). I also >> backed off >> >>>>>>>the text in >> >>>>>>>>>the >> >>>>>>>>> > >> >> SP domain >> >>>>>>>>> > >> >> > >> part to "can", such that there is >> >>>>no 2119 text >> >>>>>>>>> > >> >mandating or even >> >>>>>>>>> > >> >> > >> recommending its usage there. >I also do >> >>>>>>>not prohibit >> >>>>>>>>>its >> >>>>>>>>> > >> >> > >use, based on >> >>>>>>>>> > >> >> > >> local policy. Keith has come >> >forward with >> >>>>>>>the specific >> >>>>>>>>> >> >>>>>>>>> > >> >> > >> request that non-ESInet networks be >> >>>>>>>allowed to mark and >> >>>>>>>>>pay >> >>>>>>>>> > >> >attention to >> >>>>>>>>> > >> >> > >> this priority indication -- >with IMS as >> >>>>>>>the specific >> >>>>>>>>>example >> >>>>>>>>> > >> >> > >> he wishes to have this valid for. >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> Where there is no >> disagreement, save for >> >>>>>>>your recent >> >>>>>>>>> > >> >> > >pushback - is in >> >>>>>>>>> > >> >> > >> the ESInet, which is where Brian >> >>>>has requested it's >> >>>>>>>>> > >> >> > >definition in the >> >>>>>>>>> > >> >> > >> IETF on behalf of NENA. He's >the i3 WG >> >>>>>>>chair within >> >>>>>>>>> > >> >> NENA, and if >> >>>>>>>>> > >> >> > >> he asks for it, are you going >> to say you >> >>>>>>>know better >> >>>>>>>>>than he? >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> >Btw, I not disagreeing with >> the document >> >>>>>>>as such. I >> >>>>>>>>> > >> >just want to >> >>>>>>>>> > >> >> > the >> >>>>>>>>> > >> >> > >> scope >> >>>>>>>>> > >> >> > >> >to change. The usage of RPH >> >>>>within the emergency >> >>>>>>>>> > >> >> services network >> >>>>>>>>> > >> >> > is >> >>>>>>>>> > >> >> > >> fine >> >>>>>>>>> > >> >> > >> >for me. I may get convinced >> to start the >> >>>>>>>RPH marking >> >>>>>>>>>from >> >>>>>>>>> > >> >> > >the the VSP >> >>>>>>>>> > >> >> > >> >towards the PSAP. I feel uneasy >> >about the >> >>>>>>>end host >> >>>>>>>>>doing >> >>>>>>>>> > >> >> > >the marking. >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> please read what I wrote >> above, and then >> >>>>>>>re-read the >> >>>>>>>>> > >> >most recent >> >>>>>>>>> > >> >> > >> version of the ID. I don't >> have endpoints >> >>>>>>>that SHOULD >> >>>>>>>>>or >> >>>>>>>>> > >> >> MUST mark >> >>>>>>>>> > >> >> > >> anything wrt RPH. I also >don't want to >> >>>>>>>prohibit it, >> >>>>>>>>> > >> >> because there >> >>>>>>>>> > >> >> > >> might be cases (that I don't know >> >>>>of) of valid uses >> >>>>>>>>> > >> >> under certain >> >>>>>>>>> > >> >> > >> circumstances. Figure 1 is very clear >> >>>>>>>that there are 3 >> >>>>>>>>> > >> >> networking >> >>>>>>>>> > >> >> > >> parts to consider >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> #1 - from the endpoint >> >>>>>>>>> > >> >> > >> #2 - within the VSP >> >>>>>>>>> > >> >> > >> #3 - within the ESInet >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> the most recent ID version has >> "can" for >> >>>>>>>#s 1 and 2, >> >>>>>>>>>and >> >>>>>>>>> > >> >> > >2119 language >> >>>>>>>>> > >> >> > >> offering those supporting this >> >>>>>>>specification will have >> >>>>>>>>>RPH >> >>>>>>>>> > >> >> > >> adherence within #3 (the ESInet). >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> What other scope changes do you want, >> >>>>>>>because I haven't >> >>>>>>>>> > >> >> heard them. >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> I only heard you claim in email >> >during the >> >>>>>>>last IETF >> >>>>>>>>>and in >> >>>>>>>>> > >> >> > >the ECRIT >> >>>>>>>>> > >> >> > >> session that RPH should not be >> >>>>used for priority >> >>>>>>>>>marking >> >>>>>>>>> > >> >> requests. >> >>>>>>>>> > >> >> > >> This is something Keith (SIP WG >> >>>>chair) voiced his >> >>>>>>>>>opposition >> >>>>>>>>> > >> >> > >> to your views regarding >> creating a second >> >>>>>>>means for SIP >> >>>>>>>>>to >> >>>>>>>>> > >> >priority >> >>>>>>>>> > >> >> > >> mark request "when SIP already has one >> >>>>>>>interoperable >> >>>>>>>>>way to >> >>>>>>>>> > >> >> > >> accomplish this... it's call the >> >RP header >> >>>>>>>mechanism". >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> >I don't see advantages -- only >> >>>>disadvantages. >> >>>>>>>>> > >> >> > >> > >> >>>>>>>>> > >> >> > >> >Ciao >> >>>>>>>>> > >> >> > >> >Hannes >> >>>>>>>>> > >> >> > >> >> >>>>>>>>> > >> >> > >> >> >>>>_______________________________________________ >> >>>>>>>>> > >> >> > >> Ecrit mailing list >> >>>>>>>>> > >> >> > >> Ecrit@ietf.org >> >>>>>>>>> > >> >> > >> >> >https://www.ietf.org/mailman/listinfo/ecrit >> >>>>>>>>> > >> >> > > >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> >> >> >_______________________________________________ >> >>>>>>>>> > >> >> Ecrit mailing list >> >>>>>>>>> > >> >> Ecrit@ietf.org >> >>>>>>>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> > >> >>>>>>>>> > > >> >>>>>>>>> > >> >>>>>>>>> > _______________________________________________ >> >>>>>>>>> > Ecrit mailing list >> >>>>>>>>> > Ecrit@ietf.org >> >>>>>>>>> > https://www.ietf.org/mailman/listinfo/ecrit >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>_______________________________________________ >> >>>>>>>>>Ecrit mailing list >> >>>>>>>>>Ecrit@ietf.org >> >>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >> >>>>>>>> >> >>>>>>>>_______________________________________________ >> >>>>>>>>Ecrit mailing list >> >>>>>>>>Ecrit@ietf.org >> >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >> >>>>>> >> >>>>>>_______________________________________________ >> >>>>>>Ecrit mailing list >> >>>>>>Ecrit@ietf.org >> >>>>>>https://www.ietf.org/mailman/listinfo/ecrit >> >>> >> >>>_______________________________________________ >> >>>Ecrit mailing list >> >>>Ecrit@ietf.org >> >>>https://www.ietf.org/mailman/listinfo/ecrit >> >>> >> >>> >> >>>------------------------------------------------------------- >> >----------------------------------- >> >>>This message is for the designated recipient only and may contain >> >>>privileged, proprietary, or otherwise private information. >> >>>If you have received it in error, please notify the sender >> >>>immediately and delete the original. Any unauthorized >use of this >> >>>email is prohibited. >> >>>------------------------------------------------------------- >> >----------------------------------- >> >>>[mf2] >> >>> >> >> >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www.ietf.org/mailman/listinfo/ecrit >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B831E3A67B1 for ; Sat, 7 Feb 2009 00:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQdmjZuhJHBc for ; Sat, 7 Feb 2009 00:27:54 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0C4283A679F for ; Sat, 7 Feb 2009 00:27:52 -0800 (PST) Received: (qmail invoked by alias); 07 Feb 2009 08:27:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp062) with SMTP; 07 Feb 2009 09:27:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX184DqUj8QQ4mk4KWBlv7Yn4SAks1DbX1826kP0bFO p55TGm3nIrijL3 From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'Winterbottom, James'" , "'Brian Rosen'" , "'Henning Schulzrinne'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net><001d01c9885b$d5d705d0$49b5b70a@nsnintra.net><001f01c98860$910658c0$49b5b70a@nsnintra.net><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$49b5b70a@nsnintra.net><1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$49b5b70a@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Sat, 7 Feb 2009 10:28:40 +0200 Message-ID: <007401c988fe$15e06cf0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprowABE/KKA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 08:27:56 -0000 What do you think is the semantic of the Service URN (or the respective dial string)? Emergency call with special processing needed? Do everything so that the call gets through? How often do you want to say that the call is really important to you? We could invent a few more headers say "Yes, it is really important. Believe me -- really, really important. Also add location because that it could be needed to locate me.". See my other mail where I invented such a new header that from a philosophical point of view (not from a practical) makes a lot of sense. Code just needs to know it is important and can do all the necessary steps. I doubt that someone would write code that does not treat the emergency call as less important when an emergency call comes in that does not have the ECRIT RPH header present. Would you think so? Ciao Hannes >-----Original Message----- >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 07 February, 2009 02:15 >To: Winterbottom, James; Hannes Tschofenig; Brian Rosen; >Henning Schulzrinne >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: RE: [Ecrit] RPH > >It is a valid header for that usage. It carries exactly the >semantics the user wishes to convey, i.e. that the requestor >would like the call to be treated in processing by the network >in a manner appropriate to emergency calls. > >Yes the edge proxy may well review and make up its own mind, >and either remove, verify or pass on the header, but that does >not mean it is wrong from the UE. > >You might just as well argue that the UE should not inserted a >P-Preferred-ID if it knows that the value it contains will be >the one inserted by the edge proxy. > >regards > >Keith > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Winterbottom, James >> Sent: Friday, February 06, 2009 8:02 PM >> To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> Subject: Re: [Ecrit] RPH >> >> Hi All, >> >> I have followed thi thread with some interest and I >struggling to see >> a use case for the providing RPH for emergency calls from the >> end-point. >> >> The reference-model call in ECRIT, for better or worse, is for all >> calls to go back through a home-VSP. >> We placed quite a lot of emphasis, largely for traffing reasons, for >> the VSP to be able to verify that a call is in fact an >emergency call. >> This is done by the proxy taking the inband location, doing a LoST >> query with the provided URN, and verifying that the resulting >> destination URI is the same as the destination URI provide >in the SIP >> INVITE. My understanding was that VSPs would always do this check so >> they could tell if they could bill for the call or not, and because >> the VSP can be use that the call is an emergency call it can >apply any >> special priorities that may be applicable. >> This obviates the need for RPH from the end-point to the network. >> >> This leaves us with the argument of "it doesn't hurt to it", >which is >> not a good reason to write a specification. >> It was intimated on the geopriv mailing list last year that great >> pains had been taken to keep SIP with in the MTU limits of UDP over >> Ethernet >> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120 >> .html). Assuming that this is the case, perhaps there is harm in >> including information that we know will be ignored. >> >> Cheers >> James >> >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >> Sent: Fri 2/6/2009 12:33 PM >> To: 'Brian Rosen'; 'Henning Schulzrinne' >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >> Subject: Re: [Ecrit] RPH >> >> To the story short here is the code for the proxy: >> >> --------------------- >> >> IF emergency call was recognized THEN >> execute emergency call specific procedures (priority queuing, >> preemption, fetch location, determine routing, do funny QoS things & >> co) ELSE >> normal call handling procedures. >> >> --------------------- >> >> If you can make this differentiation between an emergency call and a >> regular call then you can also do everything that is necessary for >> emergency call handling. >> >> Brian + Keith: Please tell me that we cannot do the above with our >> currently specified mechanisms. >> >> Ciao >> Hannes >> >> >-----Original Message----- >> >From: Brian Rosen [mailto:br@brianrosen.net] >> >Sent: 06 February, 2009 17:49 >> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >Subject: RE: [Ecrit] RPH >> > >> >I agree that not all networks will permit (or pay attention >> >to) a priority request from an end device. >> > >> >No one has asked for that. >> > >> >The namespace request has several uses, one of which is within an >> >emergency services IP network, one of which is between >> elements within >> >a public network controlled by the operator, and one of which is an >> >endpoint request for resource priority. >> > >> >Those of us requesting this work proceed are happy if the >> endpoint part >> >is simply left as possible (MAY), and, speaking for myself, >> having the >> >draft discuss the security implications of endpoint marking is >> >reasonable. >> > >> >Having discussed this issue with an implementation team who >> worked on >> >MLPP systems, I am confident I know what I'm talking about, >> but YMMV. >> >The fact that you could, if you wanted to, give resource >> priority to a >> >call you decided, however you decided, was an emergency call is an >> >implementation decision, and not subject to standardization. >> > >> >RPH is the IETF standard way for one entity to request resource >> >priority of another entity in a SIP system. We're asking for a >> >namespace to use that within the domain of emergency calls. >> That is, I >> >think, a VERY reasonable request. >> > >> >Brian >> > >> >> -----Original Message----- >> >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >> Sent: Friday, February 06, 2009 10:33 AM >> >> To: Hannes Tschofenig >> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> >> Subject: Re: [Ecrit] RPH >> >> >> >> To chime in here: >> >> >> >> I don't think it's productive to simply state that 4412 >> >doesn't worry >> >> about authorization, so we shouldn't either (simplifying a bit). >> >> Authorization was discussed repeatedly, and the general >> >assumption was >> >> that there were two conditions: Either the user invoking >resource- >> >> priority was well known and had a set of permissions that >could be >> >> checked in real time or there are ways to deal with abuse >> after the >> >> fact in ways that deter abuse (the court-martial kind of >> thing in a >> >> military context). >> >> >> >> The RFC 4412 security consideration (11.2) call this out >in pretty >> >> strong language: >> >> >> >> Prioritized access to network and end-system resources imposes >> >> particularly stringent requirements on authentication and >> >> authorization mechanisms, since access to prioritized >> >resources may >> >> impact overall system stability and performance and not >> >just result >> >> in theft of, say, a single phone call. >> >> Thus, the question is whether we have such strong >> authentication in >> >> emergency calling. In some cases, such as residential fixed line >> >> deployments where ISP = VSP, we're probably pretty close, >> in others, >> >> such as prepaid cell phones or hot spots or VSP-only >providers, we >> >> aren't. >> >> >> >> The other point that I think Hannes is making is that the >> >information >> >> is either redundant or dangerous. If a processing element >> recognizes >> >> the call as being an emergency call, it can apply whatever >> treatment >> >> it deems appropriate and doesn't need additional >> information. If it >> >> doesn't or can't, using just the RPH can be rather >> dangerous unless >> >> that element can be reasonably certain that there is strong >> >> authentication and recourse. >> >> >> >> I don't buy the argument that somehow finding the RPH is >> faster than >> >> just looking for the identifier. Thus, given that the >> information is >> >> either redundant or dangerous, I fail to see the advantage. >> >> >> >> Henning >> >> >> >> >> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >> >> >> >> > Don't get hung up on the details. There are ways to optimize it. >> >> > That was >> >> > not the point of the code example. >> >> > >> >> > The problem that my pseudo code should have shown you >is that you >> >> > * don't gain anything with RPH marking for the emergency >> call case >> >> > from the SIP UA towards the outbound proxy since the >> functionality >> >> > is already provide otherwise. How often does the proxy >> need to get >> >> > told that this is an emergency call todo whatever >emergency call >> >> > handling procedures are necessary? >> >> > * you only introduce fraud problems (if you are not >> >careful and you >> >> > understand the security stuff well enough) >> >> > >> >> > If you can point me to people who implement the RPH >> emergency call >> >> > case please do so. I would love to talk to them. >> >> > >> >> > Ciao >> >> > Hannes >> >> > >> >> > PS: You need to parse incoming messages to some extend >> so that you >> >> > know what it contains :-) Only looking for the emergency >> >RPH header >> >> > (and not for the Service URN/dial >> >> > string) would exactly be the DoS/fraud attack I am >worried about. >> >> > That's the thing Henning was worried about (go and >listen to the >> >> > past meeting minutes). >> >> > >> >> > >> >> >> Hannes >> >> >> >> >> >> You need to talk to people who really implement this kind >> >of thing. >> >> >> You are way off. >> >> >> >> >> >> When you implement a resource priority system, the >> point of doing >> >> >> that is to look though the queue of work and pick out the >> >ones with >> >> >> priority, handling them first. You don't do all the >> parsing, you >> >> >> don't do a lot of decision tree. >> >> >> >> >> >> Typically: >> >> >> Check for DoS things, like too big messages, etc Do a >> quick scan >> >> >> for the RPH message header If found: >> >> >> Parse the message >> >> >> Determine validity >> >> >> Determine priority >> >> >> Queue on the correct work queue >> >> >> >> >> >> The first two actions have to be very fast. Anyone who >> builds a >> >> >> SIP thingie will tell you that parsing is one of the big cycle >> >> >> consumers: if you have to parse every message BEFORE you >> >determine >> >> >> priority, you can't give much resource priority. >> >> >> Once you get the whole message parsed, you might as >well finish >> >> >> working on it, because you've done so much of the work. >> >> >> OTHOH, finding the end-of-message delimiter and doing a quick >> >> >> string search for RPH is fast. If you are doing >> >priority, you need >> >> >> to keep all the priority processing pretty uniform, and pretty >> >> >> simple, or you tend to spend too much time futzing around >> >figuring >> >> >> out what to do. You put all the priority related stuff >> together, >> >> >> and use as much common code as possible. >> >> >> >> >> >> Brian >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >> >> On Behalf >> >> >>> Of Hannes Tschofenig >> >> >>> Sent: Friday, February 06, 2009 8:41 AM >> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' >> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >> >> >>> bounces@ietf.org >> >> >>> Subject: [Ecrit] RPH >> >> >>> >> >> >>> Over lunch I was also thinking how an outbound proxy would >> >> implement >> >> >>> some of the emergency procedures. Here are some thoughts: >> >> >>> >> >> >>> --------------------------------------------------- >> >> >>> >> >> >>> // Process incoming message >> >> >>> Parse(msg); >> >> >>> >> >> >>> // SIP INVITE without Service URN // legacy devices If >> >> >>> (recognize-dialstring(msg)==TRUE) { // we got an >> emergency call >> >> >>> going on emergency=TRUE; if (dialstring(msg) == 911) >> >> >>> serviceURN=urn:service:sos; } else if >> >> >>> (recognize-serviceURN(msg)==TRUE) { // oh. A updated >> >device that >> >> >>> has a service URN attached to the >> >> call >> >> >>> serviceURN=retrieve_ServiceURN(msg); >> >> >>> emergency=TRUE; >> >> >>> } else { >> >> >>> // standard SIP message >> >> >>> // regular processing >> >> >>> process(msg); >> >> >>> emergency=FALSE; >> >> >>> } >> >> >>> >> >> >>> If (emergency == TRUE) { >> >> >>> // make sure that the emergency call does not get >> >dropped on the >> >> >>> floor >> >> >>> // skip authorization failures >> >> >>> // give the call a special treatment >> >> >>> lots-of-code-here(); >> >> >>> >> >> >>> // trigger all the QoS signaling you have in the >> >network to make >> >> >>> James happy >> >> >>> trigger-qos(); >> >> >>> >> >> >>> // query location >> >> >>> location=retrieve-location(); >> >> >>> >> >> >>> // determine next hop >> >> >>> next-hop=lost(location, serviceURN) >> >> >>> >> >> >>> // attach RPH marking to outgoing msg to make James and >> >> >> Keith happy >> >> >>> msg=add(msg, RPH); >> >> >>> >> >> >>> send(msg, next-hop); >> >> >>> } >> >> >>> >> >> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >> >> >>> // all the emergency related processing done already upfront >> >> >>> // hence I log something. >> >> >>> log(RPH_WAS_PRESENT_JUHU); >> >> >>> } else if ((rph-present(msg) == TRUE) && (emergency == >> >FALSE)) { >> >> >>> // this is not an emergency call // this is something >> >like GETS >> >> >>> result=special-authorization-procedure(user); >> >> >>> >> >> >>> if (result == AUTHORIZED) { >> >> >>> // do some priority & preemption thing here. >> >> >>> // trigger all the QoS you have >> >> >>> lots-of-code-here(); >> >> >>> } else { >> >> >>> log("NOT AUTHORIZED; don't DoS my network"); } } >> else { // >> >> >>> don't need todo any RPH processing // this includes the case >> >> >>> where the call was an emergency call but the RPH >> >> >>> >> >> >>> // marking was not there. >> >> >>> nothing(); >> >> >>> } >> >> >>> >> >> >>> --------------------------------------------------- >> >> >>> >> >> >>> >> >> >>> Ciao >> >> >>> Hannes >> >> >>> >> >> >>>> -----Original Message----- >> >> >>>> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >> >> >>>> Behalf Of Hannes Tschofenig >> >> >>>> Sent: 06 February, 2009 15:07 >> >> >>>> To: 'Janet P Gunn' >> >> >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; Tschofenig,Hannes (NSN - >> >> >>> FI/Espoo) >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >> Agenda (RPH) >> >> >>>> >> >> >>>> Who would define something that could prevent DoS problems? >> >> >>>> >> >> >>>> ________________________________ >> >> >>>> >> >> >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >> >> >>>> Sent: 06 February, 2009 14:11 >> >> >>>> To: Hannes Tschofenig >> >> >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >> >> >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); >> >> 'James >> >> >>>> M. Polk' >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >Meeting: Agenda (RPH) >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> But there is nothing IN RFC4412 that specifically >> >> >> addresses how to >> >> >>>> prevent any particular namespace being used for DoS. >> Anyone/any >> >> UA >> >> >>>> can ATTEMPT to invoke priority treatment by attaching >> RPH. For >> >> all >> >> >>>> of the 4412 namespaces, as with the new proposed >> namespace, the >> >> >>>> mechanisms for preventing DoS are not specified in the >> >> >> document that >> >> >>>> defines the namespace. >> >> >>>> They are/will be specified elsewhere. >> >> >>>> >> >> >>>> Janet >> >> >>>> >> >> >>>> This is a PRIVATE message. If you are not the intended >> >> >> recipient, >> >> >>>> please delete without copying and kindly advise us by >> e-mail of >> >> the >> >> >>>> mistake in delivery. >> >> >>>> NOTE: Regardless of content, this e-mail shall not >> >> >> operate to bind >> >> >>>> CSC to any order or other contract unless pursuant to >> explicit >> >> >>>> written agreement or government initiative expressly >> permitting >> >> the >> >> >>>> use of e-mail for such purpose. >> >> >>>> >> >> >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 04:21:51 AM: >> >> >>>> >> >> >>>> > Hi James, >> >> >>>> > >> >> >>>> > I have read RFC 4412 and also the GETS/MLPP IETF >> >> >> documents. What I >> >> >>>> would >> >> >>>> > like to point out is that there is more than just a >> >> >> header and >> >> >>>> values within >> >> >>>> > the header that have to be considered in order to >> >> >> make a judgement >> >> >>>> of what >> >> >>>> > is appropriate and what isn't. There is an >> >> >> architectural question >> >> >>>> and >> >> >>>> > whether the environment we are using the stuff is >> >> >> indeed providing >> >> >>>> the >> >> >>>> > properties you need for the solution to be >> >appropriate. >> >> >>>> > >> >> >>>> > Let me describe in more detail what I meant (and >> >> >> please correct me >> >> >>>> if I am >> >> >>>> > wrong). >> >> >>>> > >> >> >>>> > Getting priority for SIP requests when using a GETS >> >> >> alike scenario >> >> >>>> means >> >> >>>> > that the entity that issues the request is specially >> >> >> authorized >> >> >>>> since >> >> >>>> > otherwise you introduce a nice denial of >> >service attack. This >> >> >>>> authorization >> >> >>>> > is tied to the entity that makes the request. For >> >> >> example, the >> >> >>>> person is >> >> >>>> > working for the government and has special rights. >> >> >>>> James Bond as a (not so) >> >> >>>> > secret agent might have these rights. >> >> >>>> > >> >> >>>> > The emergency services case >> >(citizen-to-authority) is a bit >> >> >>>> different as >> >> >>>> > there aren't really special rights with respect to >> >> >> authorization >> >> >>>> tied to >> >> >>>> > individuals. Instead, the fact that something is an >> >> >> emergency is >> >> >>>> purely a >> >> >>>> > judgement of the human that dials a special number. >> >> >>>> To deal with fraud, we >> >> >>>> > discussed in the group on what we can actually do to >> >> >> ensure that >> >> >>>> end users >> >> >>>> > do not bypass security procedures (such as >> >> >> authorization checks, >> >> >>>> charging >> >> >>>> > and so on). Part of this investigation was >> >the publication of >> >> >>>> > http://www.ietf.org/rfc/rfc5069.txt that also >> >describes this >> >> >>>> issue. >> >> >>>> > >> >> >>>> > So, imagine the implementation of a SIP proxy (and we >> >> >> implemented >> >> >>>> that >> >> >>>> > stuff) that receives a call that contains a Service >> >> >> URN. The code >> >> >>>> branches >> >> >>>> > into a special mode where everything is done >> >so that the call >> >> >>>> receives >> >> >>>> > appropriate treatment and does not get dropped on the >> >> >> floor. The >> >> >>>> way how the >> >> >>>> > Service URN is placed in the message ensures that the >> >> >> call cannot >> >> >>>> go to my >> >> >>>> > friend (instead of the PSAP) unless the end host ran >> >> >> LoST already. >> >> >>>> In the >> >> >>>> > latter case, we discussed this also on the list for a >> >> >> while and >> >> >>>> Richard even >> >> >>>> > wrote a draft about it in the context of the >> >location hiding >> >> >>>> topic, we said >> >> >>>> > that the proxy would have to run LoST if he >> >cares about a >> >> >>>> potential >> >> >>>> > fraudulent usage. >> >> >>>> > >> >> >>>> > So, what do we need todo in order to provide >> >secure RFC 4412 >> >> >>>> functionality >> >> >>>> > in our context? >> >> >>>> > >> >> >>>> > Do you think that the current text in >> >> >>>> > >> >> >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >> >>>> gency-rph-nam >> >> >>>> > espace-00.txt reflects any of the >> >above-described issues: >> >> >>>> > " >> >> >>>> > The Security considerations that apply to RFC 4412 >> >> >>>> [RFC4412] >> >> >>>> apply >> >> >>>> > here. This document introduces no new security >> >> >>>> issues relative >> >> >>>> to >> >> >>>> > RFC 4412. >> >> >>>> > " >> >> >>>> > >> >> >>>> > From various discussions in GEOPRIV I recall >> >that you are >> >> >>>> super-sensitive >> >> >>>> > regarding security and privacy. For some reasons you >> >> >> don't seem to >> >> >>>> have the >> >> >>>> > same concerns here. I would like to >> >understand your reasoning. >> >> >>>> > >> >> >>>> > Please also do me another favor: Don't always say >> >> >> that I don't >> >> >>>> understand >> >> >>>> > the subject. Even if that would be the case it isn't >> >> >> particular >> >> >>>> fair given >> >> >>>> > that different folks had to educate you on other >> >> >> topics in the >> >> >>>> past as well. >> >> >>>> > Additionally, if you listen to the audio recordings >> >> >> then you will >> >> >>>> notice >> >> >>>> > that Henning, Ted, and Jon do not seem to understand >> >> >> the issue >> >> >>>> either as >> >> >>>> > they have raised similar issues during the >> >F2F meetings. >> >> >>>> > >> >> >>>> > Ciao >> >> >>>> > Hannes >> >> >>>> > >> >> >>>> > >> >> >>>> > >Hannes - I believe it is you who do not understand >> >> >> RFC 4412 -- >> >> >>>> > >and many of us are trying to get that >> >through to you, but you >> >> >>>> > >don't seem to want to listen/read. >> >> >>>> > > >> >> >>>> > >RFC 4412 is *for* priority marking SIP requests, >> >> >>>> > > >> >> >>>> > >One use is GETS. >> >> >>>> > > >> >> >>>> > >One use is MLPP. >> >> >>>> > > >> >> >>>> > >These examples are in RFC 4412 because there >> >were specific >> >> >>>> > >namespaces being created for the IANA section of >> >> >> that document. >> >> >>>> > > >> >> >>>> > >Reading the whole document, you will see >> >that RPH can be >> >> >>>> > >specified for other uses than GETS or MLPP >> >specifically. >> >> >>>> > > >> >> >>>> > >I knew when I wrote RFC 4412 that one day we >> >would specify a >> >> >>>> > >namespace for ECRIT (the "esnet" namespace >> >now) -- but I also >> >> >>>> > >knew it was premature for RFC 4412 to >> >incorporate that >> >> >>>> > >namespace, that a future doc to RFC 4412 >> >would have to be >> >> >>>> > >written to do this. Brian and I talked about >> >this at the >> >> >>>> > >original NENA meeting that created the IP WGs there >> >> >> (in August >> >> >>>> > >of 03). We both agreed we should wait until it was >> >> >>>> > >appropriate to the work in the IETF to >> >submit this document >> >> >>>> > >that is now >> >> >>>> > >> >> >>>>> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >> >>>> > >gency-rph-namespace-00.txt >> >> >>>> > > >> >> >>>> > >Yet, you seem to want to use some additional >> >mechanism to >> >> >>>> > >indicate priority of a call in SIP. That >> >means you want to >> >> >>>> > >introduce a second way to accomplish this in SIP. >> >> >>>> Why do you >> >> >>>> > >want to promote a separate way to do something SIP >> >> >> has already >> >> >>>> > >defined? That will cause interoperability issues and >> >> >> we both know >> >> >>>> that. >> >> >>>> > > >> >> >>>> > >You've said to me (and others) that you >> >believe RPH is just >> >> >>>> > >another way to accomplish what sos or a URI can >> >> >> indicate - and >> >> >>>> > >you're wrong. Your way would be >> >_the_second_way_to_do_it, >> >> >>>> > >because SIP already considers RPH to be >> >*the*way* to priority >> >> >>>> > >mark SIP requests. >> >> >>>> > > >> >> >>>> > >If you don't believe me (no comment), then >> >why do you not >> >> >>>> > >believe the SIP WG chair (who knows more >> >about SIP than both >> >> >>>> > >of us) - who, on this thread, has again said >> >to you "RFC 4412 >> >> >>>> > >(RPH) is the SIP mechanism to priority mark >> >SIP requests"? >> >> >>>> > > >> >> >>>> > >Further, I believe it is inappropriate to >> >prohibit endpoints >> >> >>>> > >from being able to set the esnet namespace. >> >I absolutely >> >> >>>> > >believe it will not be needed most of the >> >time, but I believe >> >> >>>> > >if someone does find a valid use for >> >endpoints to mark >> >> >>>> > >priority in SIP, this ID - once it has >> >become an RFC -- will >> >> >>>> > >have to be obsoleted with a new RFC saying the exact >> >> >> opposite. >> >> >>>> > > >> >> >>>> > >(color me confused ... over and over again) >> >> >>>> > > >> >> >>>> > >James >> >> >>>> > > >> >> >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >> >> >>>> > >>Keith, please understand that the usage of RFC 4412 >> >> >> for GETS and >> >> >>>> for >> >> >>>> > >>the type of emergency call we discuss here is >> >> >> different. Just >> >> >>>> looking >> >> >>>> > >>at the header and the name of the >namespace is a bit >> >> >>>> > >artificial. I hope >> >> >>>> > >>you understand that. >> >> >>>> > >> >> >> >>>> > >> >-----Original Message----- >> >> >>>> > >> >From: DRAGE, Keith (Keith) >> >> >>>> [mailto:drage@alcatel-lucent.com] >> >> >>>> > >> >Sent: 05 February, 2009 14:55 >> >> >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. >> >> >>>> Polk'; 'Tschofenig, >> >> >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >> >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >> >> >>>> Meeting: Agenda (my >> >> >>>> >> >> >>>> > >> >mistake) >> >> >>>> > >> > >> >> >>>> > >> >Which is exactly what RFC 4412 specifies for all >> >> >> namespaces. >> >> >>>> > >> > >> >> >>>> > >> >regards >> >> >>>> > >> > >> >> >>>> > >> >Keith >> >> >>>> > >> > >> >> >>>> > >> >> -----Original Message----- >> >> >>>> > >> >> From: ecrit-bounces@ietf.org >> >> >> [mailto:ecrit-bounces@ietf.org] >> >> >>>> > >> >On Behalf >> >> >>>> > >> >> Of Brian Rosen >> >> >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >> >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >> >Polk'; 'Tschofenig, >> >> >>>> > >Hannes (NSN >> >> >>>> > >> >> - FI/Espoo)'; 'ECRIT' >> >> >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >> >>>> Meeting: Agenda (my >> >> >>>> > >> >> mistake) >> >> >>>> > >> >> >> >> >>>> > >> >> The value is that in some networks >> >where priority for >> >> >>>> > >> >emergency calls >> >> >>>> > >> >> is appropriate, and appropriate >> >policing of marking is >> >> >>>> > >implemented, >> >> >>>> > >> >> emergency calls will receive resource priority. >> >> >>>> > >> >> >> >> >>>> > >> >> Not all networks would need policing. Some >> >> >> will. Policing >> >> >>>> could >> >> >>>> > >> >> be to Route header/R-URI content, but other >> >> >> criteria are >> >> >>>> possible. >> >> >>>> > >> >> >> >> >>>> > >> >> Not all networks will need resource priority >> >> >> for emergency >> >> >>>> calls. >> >> >>>> > >> >> Fine, ignore this marking/namespace. >> >> >>>> > >> >> >> >> >>>> > >> >> Brian >> >> >>>> > >> >> > -----Original Message----- >> >> >>>> > >> >> > From: Hannes Tschofenig >> >> >>>> [mailto:Hannes.Tschofenig@gmx.net] >> >> >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> >> >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >> >> >> Tschofenig, Hannes >> >> >>>> (NSN - >> >> >>>> > >> >> > FI/Espoo); 'ECRIT' >> >> >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >> >> >>>> Meeting: Agenda (my >> >> >>>> > >> >> > mistake) >> >> >>>> > >> >> > >> >> >>>> > >> >> > I don't even see the value in permitting the >> >> >> endpoint todo >> >> >>>> the >> >> >>>> > >> >> > RPH marking. >> >> >>>> > >> >> > In addition to the security concerns >> >there is also the >> >> >>>> > >> >problem that >> >> >>>> > >> >> > there are more options to implement without >> >> >> an additional >> >> >>>> value. >> >> >>>> > >> >> > >> >> >>>> > >> >> > >-----Original Message----- >> >> >>>> > >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> >> >>>> > >> >> > >Sent: 05 February, 2009 00:03 >> >> >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >> >> >> 'Tschofenig, >> >> >>>> > >> >> Hannes (NSN - >> >> >>>> > >> >> > >FI/Espoo)'; 'ECRIT' >> >> >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >> >Interim Meeting: >> >> >>>> Agenda (my >> >> >>>> > >> >> > mistake) >> >> >>>> > >> >> > > >> >> >>>> > >> >> > >Hannes >> >> >>>> > >> >> > > >> >> >>>> > >> >> > >This matches my understanding >> >precisely. We wish to >> >> >>>> > >> >> permit endpoints >> >> >>>> > >> >> > >to mark. We do not require it, and >> >don't necessarily >> >> >>>> expect it >> >> >>>> > >> >> > >in many (even >> >> >>>> > >> >> > >most) cases. We don't wish to see the >> >> >> document prohibit >> >> >>>> it. >> >> >>>> > >> >> > >We all seem to agree it has value within the >> >> >> Emergency >> >> >>>> > >> >Services IP >> >> >>>> > >> >> > >Networks. >> >> >>>> > >> >> > > >> >> >>>> > >> >> > >Brian >> >> >>>> > >> >> > > >> >> >>>> > >> >> > >> -----Original Message----- >> >> >>>> > >> >> > >> From: ecrit-bounces@ietf.org >> >> >>>> [mailto:ecrit-bounces@ietf.org] >> >> >>>> > >> >> > >On Behalf >> >> >>>> > >> >> > >> Of James M. Polk >> >> >>>> > >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> >> >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >> >Hannes (NSN - >> >> >>>> > >> >> FI/Espoo); 'ECRIT' >> >> >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >> >>>> Meeting: >> >> >>>> > >Agenda (my >> >> >>>> > >> >> > >> mistake) >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >> >Tschofenig wrote: >> >> >>>> > >> >> > >> > > James wrote: >> >> >>>> > >> >> > >> > >> you are the _lone_ voice not >> >> >> supporting this ID, >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> >Listening to the audio recording of past >> >> >> meetings I >> >> >>>> have to >> >> >>>> > >> >> > >say that >> >> >>>> > >> >> > >> >I >> >> >>>> > >> >> > >> was >> >> >>>> > >> >> > >> >not the only persons raising >> >concerns about the >> >> >>>> document. >> >> >>>> > >> >> > >> >That was probably the reason why you >> >> >> agreed to limit >> >> >>>> the >> >> >>>> > >> >> > >scope of the >> >> >>>> > >> >> > >> >document (which you didn't later do) to >> >> >> get folks to >> >> >>>> agree >> >> >>>> > >> >> > >to make it >> >> >>>> > >> >> > >> a WG >> >> >>>> > >> >> > >> >item. >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> re-listen to the audio please >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> Ted's concerns were consistent with most >> >> >>>> (all?) other >> >> >>>> > >> >> concerns -- >> >> >>>> > >> >> > >> which were based on the premise of whether >> >> >> or not the >> >> >>>> > >> >> UAC should be >> >> >>>> > >> >> > >> trusted to initiate the marking on the >> >> >> INVITE. The >> >> >>>> most >> >> >>>> > >> >> > >> recent version has backed off this >> >to a "can" -- >> >> >>>> meaning not >> >> >>>> > >> >prohibited >> >> >>>> > >> >> > >> (i.e., no 2119 text). I also backed off >> >> >> the text in >> >> >>>> the >> >> >>>> > >> >> SP domain >> >> >>>> > >> >> > >> part to "can", such that there is >> >no 2119 text >> >> >>>> > >> >mandating or even >> >> >>>> > >> >> > >> recommending its usage there. I also do >> >> >> not prohibit >> >> >>>> its >> >> >>>> > >> >> > >use, based on >> >> >>>> > >> >> > >> local policy. Keith has come forward with >> >> >> the specific >> >> >>>> >> >> >>>> > >> >> > >> request that non-ESInet networks be >> >> >> allowed to mark and >> >> >>>> pay >> >> >>>> > >> >attention to >> >> >>>> > >> >> > >> this priority indication -- with IMS as >> >> >> the specific >> >> >>>> example >> >> >>>> > >> >> > >> he wishes to have this valid for. >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> Where there is no disagreement, save for >> >> >> your recent >> >> >>>> > >> >> > >pushback - is in >> >> >>>> > >> >> > >> the ESInet, which is where Brian >> >has requested it's >> >> >>>> > >> >> > >definition in the >> >> >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >> >> >> chair within >> >> >>>> > >> >> NENA, and if >> >> >>>> > >> >> > >> he asks for it, are you going to say you >> >> >> know better >> >> >>>> than he? >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> >Btw, I not disagreeing with the document >> >> >> as such. I >> >> >>>> > >> >just want to >> >> >>>> > >> >> > the >> >> >>>> > >> >> > >> scope >> >> >>>> > >> >> > >> >to change. The usage of RPH >> >within the emergency >> >> >>>> > >> >> services network >> >> >>>> > >> >> > is >> >> >>>> > >> >> > >> fine >> >> >>>> > >> >> > >> >for me. I may get convinced to start the >> >> >> RPH marking >> >> >>>> from >> >> >>>> > >> >> > >the the VSP >> >> >>>> > >> >> > >> >towards the PSAP. I feel uneasy about the >> >> >> end host >> >> >>>> doing >> >> >>>> > >> >> > >the marking. >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> please read what I wrote above, and then >> >> >> re-read the >> >> >>>> > >> >most recent >> >> >>>> > >> >> > >> version of the ID. I don't have endpoints >> >> >> that SHOULD >> >> >>>> or >> >> >>>> > >> >> MUST mark >> >> >>>> > >> >> > >> anything wrt RPH. I also don't want to >> >> >> prohibit it, >> >> >>>> > >> >> because there >> >> >>>> > >> >> > >> might be cases (that I don't know >> >of) of valid uses >> >> >>>> > >> >> under certain >> >> >>>> > >> >> > >> circumstances. Figure 1 is very clear >> >> >> that there are 3 >> >> >>>> > >> >> networking >> >> >>>> > >> >> > >> parts to consider >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> #1 - from the endpoint >> >> >>>> > >> >> > >> #2 - within the VSP >> >> >>>> > >> >> > >> #3 - within the ESInet >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> the most recent ID version has "can" for >> >> >> #s 1 and 2, >> >> >>>> and >> >> >>>> > >> >> > >2119 language >> >> >>>> > >> >> > >> offering those supporting this >> >> >> specification will have >> >> >>>> RPH >> >> >>>> > >> >> > >> adherence within #3 (the ESInet). >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> What other scope changes do you want, >> >> >> because I haven't >> >> >>>> > >> >> heard them. >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> I only heard you claim in email during the >> >> >> last IETF >> >> >>>> and in >> >> >>>> > >> >> > >the ECRIT >> >> >>>> > >> >> > >> session that RPH should not be >> >used for priority >> >> >>>> marking >> >> >>>> > >> >> requests. >> >> >>>> > >> >> > >> This is something Keith (SIP WG >> >chair) voiced his >> >> >>>> opposition >> >> >>>> > >> >> > >> to your views regarding creating a second >> >> >> means for SIP >> >> >>>> to >> >> >>>> > >> >priority >> >> >>>> > >> >> > >> mark request "when SIP already has one >> >> >> interoperable >> >> >>>> way to >> >> >>>> > >> >> > >> accomplish this... it's call the RP header >> >> >> mechanism". >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> >I don't see advantages -- only >> >disadvantages. >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> >Ciao >> >> >>>> > >> >> > >> >Hannes >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >> >> >_______________________________________________ >> >> >>>> > >> >> > >> Ecrit mailing list >> >> >>>> > >> >> > >> Ecrit@ietf.org >> >> >>>> > >> >> > >> >https://www.ietf.org/mailman/listinfo/ecrit >> >> >>>> > >> >> > > >> >> >>>> > >> >> >> >> >>>> > >> >> _______________________________________________ >> >> >>>> > >> >> Ecrit mailing list >> >> >>>> > >> >> Ecrit@ietf.org >> >> >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >>>> > >> >> >> >> >>>> > >> > >> >> >>>> > > >> >> >>>> > >> >> >>>> > _______________________________________________ >> >> >>>> > Ecrit mailing list >> >> >>>> > Ecrit@ietf.org >> >> >>>> > https://www.ietf.org/mailman/listinfo/ecrit >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> Ecrit mailing list >> >> >>>> Ecrit@ietf.org >> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >>>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Ecrit mailing list >> >> >>> Ecrit@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> >> > >> >> > _______________________________________________ >> >> > Ecrit mailing list >> >> > Ecrit@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/ecrit >> >> > >> > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> -------------------------------------------------------------- >> ---------------------------------- >> This message is for the designated recipient only and may contain >> privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >immediately >> and delete the original. Any unauthorized use of this email is >> prohibited. >> -------------------------------------------------------------- >> ---------------------------------- >> [mf2] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05AB83A6CA6 for ; Sat, 7 Feb 2009 00:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zLDKCxVMlG3 for ; Sat, 7 Feb 2009 00:31:43 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6AC9B3A6A5C for ; Sat, 7 Feb 2009 00:31:41 -0800 (PST) Received: (qmail invoked by alias); 07 Feb 2009 08:31:44 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp048) with SMTP; 07 Feb 2009 09:31:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18va00mj48vC5udUcvOFTFbZZhxc6wlb9rgqT5rDA bz5rc6OQDY2vNc From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'James M. Polk'" References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <000001c988ac$d0261940$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA12@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Sat, 7 Feb 2009 10:32:30 +0200 Message-ID: <007501c988fe$9ec32670$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67499BA12@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmIppJ3db5pt/4hRciq0u3Zrgn8DQABfvUgAAQ5v+AAEDNLUA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 08:31:45 -0000 >I don't believe anyone has been saying that. GETS and >emergency are two different namespaces that work within the >overvall framework of RPH. > >You implement RPH, and then configure or tailor it to the >namespaces you need to support, not provide a separate >implementation for every namespace you are called upon to support. This is exactly the trap Henning warned us during the last meeting. Because the authorization handling is totally different (because of the different context) you need to write different code. If you don't then you introduce these security problems. The draft at least needs to contain a super big SECURITY WARNING so that implements don't make that mistake. Currently it says "no security issues beyond the initial RPH document". This is clearly wrong and even leads experts like you to go along the wrong track. > >Go that way and every request will take hours to traverse end to end. Not sure what you mean. Ciao Hannes > >regards > >Keith > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, February 06, 2009 10:47 PM >> To: 'James M. Polk' >> Cc: DRAGE, Keith (Keith); 'Brian Rosen'; Tschofenig, Hannes (NSN - >> FI/Espoo); 'ECRIT' >> Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) >> >> Good that you agree that GETS usage of RPH and the one we discuss in >> ECRIT is different. >> So far, some folks have been saying "what works for GETS >works for the >> ECRIT case as well". >> >> I argued that the environment is different and hence just >referencing >> RFC >> 4412 isn't good enough. >> >> >-----Original Message----- >> >From: James M. Polk [mailto:jmpolk@cisco.com] >> >Sent: 07 February, 2009 00:02 >> >To: Hannes Tschofenig >> >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, >Hannes (NSN - >> >FI/Espoo); 'ECRIT' >> >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) >> > >> >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote: >> >>Hi James, >> >> >> >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I >> >>would like to point out is that there is more than just a >> header and >> >>values within the header that have to be considered in order >> >to make a >> >>judgement of what is appropriate and what isn't. There is an >> >>architectural question and whether the environment we are >using the >> >>stuff is indeed providing the properties you need for the >> >solution to be appropriate. >> >> >> >>Let me describe in more detail what I meant (and please >> >correct me if I >> >>am wrong). >> >> >> >>Getting priority for SIP requests when using a GETS alike scenario >> >>means that the entity that issues the request is specially >> authorized >> >>since otherwise you introduce a nice denial of service attack. >> > >> >You are missing a step in GETS here. The endpoint, who >> sends the GETS >> >set-up as an INVITE is not already authorized (not the >> device, not the >> >user). In North America, there is a 10 digit GETS number that is >> >dialed (that I won't give out right now on an open list) - >and there >> >literally is only 1 number available to dial for this service. >> >Literally anyone can dial this number today in North America >> (no matter >> >where the phone is - as long as it is in North America -- >> and I might >> >be too limiting in that it is dialable from anywhere, because it is >> >going to a North American destination). >> > >> >Once this number is dialed, it is answered by an authentication and >> >authorization IVR. This IVR challenges each caller for their >> >authentication passcode, and a password). Once this has been >> >successfully entered, then call is NOW authorized to >proceed towards >> >its destination number - this step is only known to the authorizing >> >system because the destination 10 digit number is NOT entered until >> >after the authentication and authorization step has completed. >> > >> >The authorized caller is prompted with a new dial tone - in >> which they >> >can enter any number on the planet and receive preferential >> treatment >> >through as many carriers (in IP, it's >> >SPs) that have implemented this GETS service (which is an >> SLA with the >> >Department of Homeland Security now). >> > >> >Merely entering the GETS RP namespace is never intended, >> alone, to gain >> >any preferential treatment -- other than towards this >> authentication & >> >authorization IVR. >> > >> >I hope you can see that this is a completely separate type >> of service >> >and implementation type than ECRIT based emergency calling will use. >> > >> >BTW - to your comment below about me not calling your name >> out when you >> >are incorrect because I have been equally incorrect >> >-- I'm not sure I've been spared as much as you think, given >> that many >> >have called me out by name when they've felt I've been wrong >> over the >> >years. >> > >> >>This authorization >> >>is tied to the entity that makes the request. For example, >> the person >> >>is working for the government and has special rights. James >> Bond as a >> >>(not so) secret agent might have these rights. >> >> >> >>The emergency services case (citizen-to-authority) is a bit >> different >> >>as there aren't really special rights with respect to >authorization >> >>tied to individuals. Instead, the fact that something is an >> emergency >> >>is purely a judgement of the human that dials a special >> >number. To deal >> >>with fraud, we discussed in the group on what we can >actually do to >> >>ensure that end users do not bypass security procedures (such as >> >>authorization checks, charging and so on). Part of this >> investigation >> >>was the publication of http://www.ietf.org/rfc/rfc5069.txt >> >that also describes this issue. >> >> >> >>So, imagine the implementation of a SIP proxy (and we >> implemented that >> >>stuff) that receives a call that contains a Service URN. The code >> >>branches into a special mode where everything is done so that >> >the call >> >>receives appropriate treatment and does not get dropped on >> the floor. >> >>The way how the Service URN is placed in the message >> ensures that the >> >>call cannot go to my friend (instead of the PSAP) unless >> the end host >> >>ran LoST already. In the latter case, we discussed this >also on the >> >>list for a while and Richard even wrote a draft about it in >> >the context >> >>of the location hiding topic, we said that the proxy would >> >have to run >> >>LoST if he cares about a potential fraudulent usage. >> >> >> >>So, what do we need todo in order to provide secure RFC 4412 >> >>functionality in our context? >> >> >> >>Do you think that the current text in >> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme >> >rgency-rp >> >>h-nam espace-00.txt reflects any of the above-described issues: >> >>" >> >> The Security considerations that apply to RFC 4412 >> [RFC4412] apply >> >> here. This document introduces no new security issues >> relative to >> >> RFC 4412. >> >>" >> >> >> >> From various discussions in GEOPRIV I recall that you are >> >>super-sensitive regarding security and privacy. For some >> reasons you >> >>don't seem to have the same concerns here. I would like to >> >understand your reasoning. >> >> >> >>Please also do me another favor: Don't always say that I don't >> >>understand the subject. Even if that would be the case it isn't >> >>particular fair given that different folks had to educate you >> >on other topics in the past as well. >> >>Additionally, if you listen to the audio recordings then you will >> >>notice that Henning, Ted, and Jon do not seem to understand >> the issue >> >>either as they have raised similar issues during the F2F meetings. >> >> >> >>Ciao >> >>Hannes >> >> >> >> >> >> >Hannes - I believe it is you who do not understand RFC >> 4412 -- and >> >> >many of us are trying to get that through to you, but you >> >don't seem >> >> >to want to listen/read. >> >> > >> >> >RFC 4412 is *for* priority marking SIP requests, >> >> > >> >> >One use is GETS. >> >> > >> >> >One use is MLPP. >> >> > >> >> >These examples are in RFC 4412 because there were specific >> >namespaces >> >> >being created for the IANA section of that document. >> >> > >> >> >Reading the whole document, you will see that RPH can be >> specified >> >> >for other uses than GETS or MLPP specifically. >> >> > >> >> >I knew when I wrote RFC 4412 that one day we would specify a >> >> >namespace for ECRIT (the "esnet" namespace now) -- but I >> >also knew it >> >> >was premature for RFC 4412 to incorporate that namespace, that a >> >> >future doc to RFC 4412 would have to be written to do this. >> >Brian and >> >> >I talked about this at the original NENA meeting that >> >created the IP >> >> >WGs there (in August of 03). We both agreed we should wait >> >until it >> >> >was appropriate to the work in the IETF to submit this >> >document that >> >> >is now >> >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >> >gency-rph-namespace-00.txt >> >> > >> >> >Yet, you seem to want to use some additional mechanism to >> indicate >> >> >priority of a call in SIP. That means you want to >> >introduce a second >> >> >way to accomplish this in SIP. Why do you want to promote >> >a separate >> >> >way to do something SIP has already defined? That will cause >> >> >interoperability issues and we both know that. >> >> > >> >> >You've said to me (and others) that you believe RPH is >> just another >> >> >way to accomplish what sos or a URI can indicate - and >> >you're wrong. >> >> >Your way would be _the_second_way_to_do_it, because SIP already >> >> >considers RPH to be *the*way* to priority mark SIP requests. >> >> > >> >> >If you don't believe me (no comment), then why do you not >> >believe the >> >> >SIP WG chair (who knows more about SIP than both of us) >- who, on >> >> >this thread, has again said to you "RFC 4412 >> >> >(RPH) is the SIP mechanism to priority mark SIP requests"? >> >> > >> >> >Further, I believe it is inappropriate to prohibit >endpoints from >> >> >being able to set the esnet namespace. I absolutely >> >believe it will >> >> >not be needed most of the time, but I believe if someone >> >does find a >> >> >valid use for endpoints to mark priority in SIP, this ID >> - once it >> >> >has become an RFC -- will have to be obsoleted with a new >> >RFC saying >> >> >the exact opposite. >> >> > >> >> >(color me confused ... over and over again) >> >> > >> >> >James >> >> > >> >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >> >> >>Keith, please understand that the usage of RFC 4412 for >> >GETS and for >> >> >>the type of emergency call we discuss here is different. Just >> >> >>looking at the header and the name of the namespace is a bit >> >> >artificial. I hope >> >> >>you understand that. >> >> >> >> >> >> >-----Original Message----- >> >> >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> >> >> >Sent: 05 February, 2009 14:55 >> >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; >> >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my >> >> >> >mistake) >> >> >> > >> >> >> >Which is exactly what RFC 4412 specifies for all namespaces. >> >> >> > >> >> >> >regards >> >> >> > >> >> >> >Keith >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >> >> >On Behalf >> >> >> >> Of Brian Rosen >> >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, >> >> >Hannes (NSN >> >> >> >> - FI/Espoo)'; 'ECRIT' >> >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >> Agenda (my >> >> >> >> mistake) >> >> >> >> >> >> >> >> The value is that in some networks where priority for >> >> >> >emergency calls >> >> >> >> is appropriate, and appropriate policing of marking is >> >> >implemented, >> >> >> >> emergency calls will receive resource priority. >> >> >> >> >> >> >> >> Not all networks would need policing. Some will. Policing >> >> >> >> could be to Route header/R-URI content, but other >> >criteria are possible. >> >> >> >> >> >> >> >> Not all networks will need resource priority for >> >emergency calls. >> >> >> >> Fine, ignore this marking/namespace. >> >> >> >> >> >> >> >> Brian >> >> >> >> > -----Original Message----- >> >> >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, >> >Hannes (NSN - >> >> >> >> > FI/Espoo); 'ECRIT' >> >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: >> >Agenda (my >> >> >> >> > mistake) >> >> >> >> > >> >> >> >> > I don't even see the value in permitting the >> >endpoint todo the >> >> >> >> > RPH marking. >> >> >> >> > In addition to the security concerns there is also the >> >> >> >problem that >> >> >> >> > there are more options to implement without an >> >additional value. >> >> >> >> > >> >> >> >> > >-----Original Message----- >> >> >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] >> >> >> >> > >Sent: 05 February, 2009 00:03 >> >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, >> >> >> >> Hannes (NSN - >> >> >> >> > >FI/Espoo)'; 'ECRIT' >> >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim >> Meeting: Agenda >> >> >> >> > >(my >> >> >> >> > mistake) >> >> >> >> > > >> >> >> >> > >Hannes >> >> >> >> > > >> >> >> >> > >This matches my understanding precisely. We wish to >> >> >> >> permit endpoints >> >> >> >> > >to mark. We do not require it, and don't >> necessarily expect >> >> >> >> > >it in many (even >> >> >> >> > >most) cases. We don't wish to see the document >> prohibit it. >> >> >> >> > >We all seem to agree it has value within the Emergency >> >> >> >Services IP >> >> >> >> > >Networks. >> >> >> >> > > >> >> >> >> > >Brian >> >> >> >> > > >> >> >> >> > >> -----Original Message----- >> >> >> >> > >> From: ecrit-bounces@ietf.org >> >> >> >> > >> [mailto:ecrit-bounces@ietf.org] >> >> >> >> > >On Behalf >> >> >> >> > >> Of James M. Polk >> >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM >> >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - >> >> >> >> FI/Espoo); 'ECRIT' >> >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >> >> >Agenda (my >> >> >> >> > >> mistake) >> >> >> >> > >> >> >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: >> >> >> >> > >> > > James wrote: >> >> >> >> > >> > >> you are the _lone_ voice not supporting this ID, >> >> >> >> > >> > >> >> >> >> > >> >Listening to the audio recording of past >> meetings I have >> >> >> >> > >> >to >> >> >> >> > >say that >> >> >> >> > >> >I >> >> >> >> > >> was >> >> >> >> > >> >not the only persons raising concerns about >> the document. >> >> >> >> > >> >That was probably the reason why you agreed to >> limit the >> >> >> >> > >scope of the >> >> >> >> > >> >document (which you didn't later do) to get >> >folks to agree >> >> >> >> > >to make it >> >> >> >> > >> a WG >> >> >> >> > >> >item. >> >> >> >> > >> >> >> >> >> > >> re-listen to the audio please >> >> >> >> > >> >> >> >> >> > >> Ted's concerns were consistent with most (all?) other >> >> >> >> concerns -- >> >> >> >> > >> which were based on the premise of whether or not the >> >> >> >> UAC should be >> >> >> >> > >> trusted to initiate the marking on the INVITE. >> The most >> >> >> >> > >> recent version has backed off this to a "can" >> -- meaning >> >> >> >> > >> not >> >> >> >prohibited >> >> >> >> > >> (i.e., no 2119 text). I also backed off the >text in the >> >> >> >> SP domain >> >> >> >> > >> part to "can", such that there is no 2119 text >> >> >> >mandating or even >> >> >> >> > >> recommending its usage there. I also do not >prohibit its >> >> >> >> > >use, based on >> >> >> >> > >> local policy. Keith has come forward with the >specific >> >> >> >> > >> request that non-ESInet networks be allowed to >> >mark and pay >> >> >> >attention to >> >> >> >> > >> this priority indication -- with IMS as the specific >> >> >> >> > >> example he wishes to have this valid for. >> >> >> >> > >> >> >> >> >> > >> Where there is no disagreement, save for your recent >> >> >> >> > >pushback - is in >> >> >> >> > >> the ESInet, which is where Brian has requested it's >> >> >> >> > >definition in the >> >> >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within >> >> >> >> NENA, and if >> >> >> >> > >> he asks for it, are you going to say you know >> >better than he? >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >Btw, I not disagreeing with the document as such. I >> >> >> >just want to >> >> >> >> > the >> >> >> >> > >> scope >> >> >> >> > >> >to change. The usage of RPH within the emergency >> >> >> >> services network >> >> >> >> > is >> >> >> >> > >> fine >> >> >> >> > >> >for me. I may get convinced to start the RPH >> marking from >> >> >> >> > >the the VSP >> >> >> >> > >> >towards the PSAP. I feel uneasy about the end >> host doing >> >> >> >> > >the marking. >> >> >> >> > >> >> >> >> >> > >> please read what I wrote above, and then re-read the >> >> >> >most recent >> >> >> >> > >> version of the ID. I don't have endpoints that >SHOULD or >> >> >> >> MUST mark >> >> >> >> > >> anything wrt RPH. I also don't want to prohibit it, >> >> >> >> because there >> >> >> >> > >> might be cases (that I don't know of) of valid uses >> >> >> >> under certain >> >> >> >> > >> circumstances. Figure 1 is very clear that there are 3 >> >> >> >> networking >> >> >> >> > >> parts to consider >> >> >> >> > >> >> >> >> >> > >> #1 - from the endpoint >> >> >> >> > >> #2 - within the VSP >> >> >> >> > >> #3 - within the ESInet >> >> >> >> > >> >> >> >> >> > >> the most recent ID version has "can" for #s 1 >and 2, and >> >> >> >> > >2119 language >> >> >> >> > >> offering those supporting this specification will >> >have RPH >> >> >> >> > >> adherence within #3 (the ESInet). >> >> >> >> > >> >> >> >> >> > >> What other scope changes do you want, because I haven't >> >> >> >> heard them. >> >> >> >> > >> >> >> >> >> > >> I only heard you claim in email during the last >> >IETF and in >> >> >> >> > >the ECRIT >> >> >> >> > >> session that RPH should not be used for >priority marking >> >> >> >> requests. >> >> >> >> > >> This is something Keith (SIP WG chair) voiced his >> >> >> >> > >> opposition to your views regarding creating a >> >second means >> >> >> >> > >> for SIP to >> >> >> >priority >> >> >> >> > >> mark request "when SIP already has one >> >interoperable way to >> >> >> >> > >> accomplish this... it's call the RP header mechanism". >> >> >> >> > >> >> >> >> >> > >> >I don't see advantages -- only disadvantages. >> >> >> >> > >> > >> >> >> >> > >> >Ciao >> >> >> >> > >> >Hannes >> >> >> >> > >> >> >> >> >> > >> _______________________________________________ >> >> >> >> > >> Ecrit mailing list >> >> >> >> > >> Ecrit@ietf.org >> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> > > >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Ecrit mailing list >> >> >> >> Ecrit@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> >> >> >> > >> >> > >> > >> >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F110F3A692F; Sat, 7 Feb 2009 08:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3iyruZ+u2Fr; Sat, 7 Feb 2009 08:27:50 -0800 (PST) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 482363A6C7A; Sat, 7 Feb 2009 08:27:12 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-164.messagelabs.com!1234024034!16144134!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 32625 invoked from network); 7 Feb 2009 16:27:14 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 7 Feb 2009 16:27:14 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n17GRDCw023268; Sat, 7 Feb 2009 11:27:14 -0500 In-Reply-To: <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> To: "Hannes Tschofenig" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Sat, 7 Feb 2009 11:27:14 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/07/2009 11:29:35 AM, Serialize complete at 02/07/2009 11:29:35 AM Content-Type: multipart/alternative; boundary="=_alternative 005A5FB785257556_=" Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 16:27:52 -0000 This is a multipart message in MIME format. --=_alternative 005A5FB785257556_= Content-Type: text/plain; charset="US-ASCII" . ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > PLEASE try to understand that the syntax is similar (header, new namespace, > new values) > BUT the semantic is different. > > For all message it is true that the sender can add whatever they want. The > big question is what does it mean for the recipient. > > This is what the discussion is about. > On the contrary, the semantic is, or at least can be, very similar. Consider the hypothetical, but plausible, case of a network with an explicit call/capacity admission process, in which both 911-type-emergency calls and GETS calls get preferential admission treatment. By the time the INVITE gets to this Functional Module/ block of code, all authentication, authorization, and changes/confirmation of the destination have already taken place. All this block of code deals with is call/capacity admission. For the sake of argument, suppose this is the nature of the preference. 1) For INVITEs without RPH, or with an RPH this network does not use/understand, if the admission process fails, the INVITE fails 2) For INVITEs with RPH with the ets namespace, if the admission process initially fails, the INVITE is put in queue until the resources become available so it can be admitted. 3) For INVITEs with RPH with the esnet namespace, if the admission process initially fails, the INVITE is put in queue, but at lower priority than the calls with the ets namespace. With the esnet namespace, this block of code only needs to deal with the RPH in determining which INVITEs to reject, and which to queue, and how. But if there is no esnet namespace for RPH, then this block of code would need to deal with BOTH the RPH and the URN. That would be a completely unnecessary complication. Janet --=_alternative 005A5FB785257556_= Content-Type: text/html; charset="US-ASCII"

.

ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM:

> PLEASE try to understand that the syntax is similar (header, new namespace,
> new values)
> BUT the semantic is different.
>  
> For all message it is true that the sender can add whatever they want. The
> big question is what does it mean for the recipient.
>
> This is what the discussion is about.
>
On the contrary, the semantic is, or at least can be, very similar.

Consider the hypothetical, but plausible, case of a network with an explicit call/capacity admission process, in which both 911-type-emergency calls and GETS calls get preferential admission treatment.  By the time the INVITE gets to this Functional Module/ block of code, all authentication, authorization, and changes/confirmation of the destination have already taken place.  All this block of code deals with is call/capacity admission.

For the sake of argument, suppose this is the nature of the preference.

1) For INVITEs without RPH, or with an RPH this network does not use/understand, if the admission process fails, the INVITE fails

2) For INVITEs with RPH with the ets namespace, if the admission process initially fails, the INVITE is put in queue until the resources become available so it can be admitted.

3) For INVITEs with RPH with the esnet namespace, if the admission process initially fails, the INVITE is put in queue, but at lower priority than the calls with the ets namespace.

With the esnet namespace, this block of code only needs to deal with the RPH in determining which INVITEs to reject, and which to queue, and how.

But if there is no esnet namespace for RPH, then this block of code would need to deal with BOTH the RPH and the URN.  That would be a completely unnecessary complication.

Janet
 --=_alternative 005A5FB785257556_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1183A6CA4; Sat, 7 Feb 2009 08:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3pMxERrOMuQ; Sat, 7 Feb 2009 08:56:41 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 7B4D93A6CB0; Sat, 7 Feb 2009 08:56:41 -0800 (PST) Received: from Upstairs.home (pool-98-109-204-63.nwrknj.fios.verizon.net [98.109.204.63]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n17GugMc014391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Feb 2009 11:56:43 -0500 (EST) Message-Id: <050F625D-03BE-424B-A6FB-15F4937A43D0@cs.columbia.edu> From: Henning Schulzrinne To: Janet P Gunn In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Feb 2009 11:56:42 -0500 References: X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 16:56:42 -0000 Please see my earlier message as to why your approach fails for the UA- inserted case where not all emergency calls have RPH markings. I think it would be a really bad idea if emergency calls with RPH are treated differently than emergency calls without it. (Again, I'm talking about the user-initiated calls. An ESNET can do whatever it wants and can assign extra priority to calls from citizens that have bought PBA stickers or zip codes that pay more taxes, but that's a separate problem.) I also don't believe your implementation logic. A much better approach is to semantically declare the class of call early on (e.g., based on the URN or after authentication/authorization), and make that part of the call state record, rather than hunt for headers each time a handling decision needs to be made. Given the authorization requirements, just looking at "has header X" is never going to be sufficient anyway. Henning On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > > > . > > ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > > > PLEASE try to understand that the syntax is similar (header, new > namespace, > > new values) > > BUT the semantic is different. > > > > For all message it is true that the sender can add whatever they > want. The > > big question is what does it mean for the recipient. > > > > This is what the discussion is about. > > > On the contrary, the semantic is, or at least can be, very similar. > > Consider the hypothetical, but plausible, case of a network with an > explicit call/capacity admission process, in which both 911-type- > emergency calls and GETS calls get preferential admission > treatment. By the time the INVITE gets to this Functional Module/ > block of code, all authentication, authorization, and changes/ > confirmation of the destination have already taken place. All this > block of code deals with is call/capacity admission. > > For the sake of argument, suppose this is the nature of the > preference. > > 1) For INVITEs without RPH, or with an RPH this network does not use/ > understand, if the admission process fails, the INVITE fails > > 2) For INVITEs with RPH with the ets namespace, if the admission > process initially fails, the INVITE is put in queue until the > resources become available so it can be admitted. > > 3) For INVITEs with RPH with the esnet namespace, if the admission > process initially fails, the INVITE is put in queue, but at lower > priority than the calls with the ets namespace. > > With the esnet namespace, this block of code only needs to deal with > the RPH in determining which INVITEs to reject, and which to queue, > and how. > > But if there is no esnet namespace for RPH, then this block of code > would need to deal with BOTH the RPH and the URN. That would be a > completely unnecessary complication. > > Janet Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6CC3A6CD2; Sat, 7 Feb 2009 09:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxLMqo-AYZxJ; Sat, 7 Feb 2009 09:17:13 -0800 (PST) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 8E4F03A6CCD; Sat, 7 Feb 2009 09:17:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-164.messagelabs.com!1234027035!8941662!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 13943 invoked from network); 7 Feb 2009 17:17:15 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-6.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 7 Feb 2009 17:17:15 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n17HH7iR031145; Sat, 7 Feb 2009 12:17:14 -0500 In-Reply-To: <050F625D-03BE-424B-A6FB-15F4937A43D0@cs.columbia.edu> To: Henning Schulzrinne MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Sat, 7 Feb 2009 12:17:12 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/07/2009 12:19:36 PM, Serialize complete at 02/07/2009 12:19:36 PM Content-Type: multipart/alternative; boundary="=_alternative 005EF2FA85257556_=" Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 17:17:15 -0000 This is a multipart message in MIME format. --=_alternative 005EF2FA85257556_= Content-Type: text/plain; charset="US-ASCII" To clarify, My example has NOTHING to do with when the RPH is inserted. In particular I said "after the authentication and authorization", so it is NOT about user generated RPH (which I agree is "problematic") It is intended to show that the SEMANTICS of providing priority based on the RPH can be the SAME for different namespaces, even if many other aspects are quite different. It is intended to counter the argument that "you don't gain anything by having the RPH namespace esnet because you already have the URN" Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Henning Schulzrinne wrote on 02/07/2009 11:56:42 AM: > Please see my earlier message as to why your approach fails for the UA- > inserted case where not all emergency calls have RPH markings. I think > it would be a really bad idea if emergency calls with RPH are treated > differently than emergency calls without it. (Again, I'm talking about > the user-initiated calls. An ESNET can do whatever it wants and can > assign extra priority to calls from citizens that have bought PBA > stickers or zip codes that pay more taxes, but that's a separate > problem.) > > I also don't believe your implementation logic. A much better approach > is to semantically declare the class of call early on (e.g., based on > the URN or after authentication/authorization), and make that part of > the call state record, rather than hunt for headers each time a > handling decision needs to be made. Given the authorization > requirements, just looking at "has header X" is never going to be > sufficient anyway. > > Henning > > On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > > > > > > > . > > > > ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > > > > > PLEASE try to understand that the syntax is similar (header, new > > namespace, > > > new values) > > > BUT the semantic is different. > > > > > > For all message it is true that the sender can add whatever they > > want. The > > > big question is what does it mean for the recipient. > > > > > > This is what the discussion is about. > > > > > On the contrary, the semantic is, or at least can be, very similar. > > > > Consider the hypothetical, but plausible, case of a network with an > > explicit call/capacity admission process, in which both 911-type- > > emergency calls and GETS calls get preferential admission > > treatment. By the time the INVITE gets to this Functional Module/ > > block of code, all authentication, authorization, and changes/ > > confirmation of the destination have already taken place. All this > > block of code deals with is call/capacity admission. > > > > For the sake of argument, suppose this is the nature of the > > preference. > > > > 1) For INVITEs without RPH, or with an RPH this network does not use/ > > understand, if the admission process fails, the INVITE fails > > > > 2) For INVITEs with RPH with the ets namespace, if the admission > > process initially fails, the INVITE is put in queue until the > > resources become available so it can be admitted. > > > > 3) For INVITEs with RPH with the esnet namespace, if the admission > > process initially fails, the INVITE is put in queue, but at lower > > priority than the calls with the ets namespace. > > > > With the esnet namespace, this block of code only needs to deal with > > the RPH in determining which INVITEs to reject, and which to queue, > > and how. > > > > But if there is no esnet namespace for RPH, then this block of code > > would need to deal with BOTH the RPH and the URN. That would be a > > completely unnecessary complication. > > > > Janet > --=_alternative 005EF2FA85257556_= Content-Type: text/html; charset="US-ASCII"
To clarify,
My example has NOTHING to do with when the RPH is inserted.  In particular I said "after the authentication and authorization", so it is NOT about user generated RPH (which I agree is "problematic")

It is intended to show that the SEMANTICS of providing priority based on the RPH can be the SAME for different namespaces, even if many other aspects are quite different.

It is intended to counter the argument that "you don't gain anything by having the RPH namespace esnet because  you already have the URN"

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

Henning Schulzrinne <hgs@cs.columbia.edu> wrote on 02/07/2009 11:56:42 AM:

> Please see my earlier message as to why your approach fails for the UA-
> inserted case where not all emergency calls have RPH markings. I think  
> it would be a really bad idea if emergency calls with RPH are treated  
> differently than emergency calls without it. (Again, I'm talking about  
> the user-initiated calls. An ESNET can do whatever it wants and can  
> assign extra priority to calls from citizens that have bought PBA  
> stickers or zip codes that pay more taxes, but that's a separate  
> problem.)
>
> I also don't believe your implementation logic. A much better approach  
> is to semantically declare the class of call early on (e.g., based on  
> the URN or after authentication/authorization), and make that part of  
> the call state record, rather than hunt for headers each time a  
> handling decision needs to be made. Given the authorization  
> requirements, just looking at "has header X" is never going to be  
> sufficient anyway.
>
> Henning
>
> On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
>
> >
> >
> > .
> >
> > ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM:
> >
> > > PLEASE try to understand that the syntax is similar (header, new  
> > namespace,
> > > new values)
> > > BUT the semantic is different.
> > >
> > > For all message it is true that the sender can add whatever they  
> > want. The
> > > big question is what does it mean for the recipient.
> > >
> > > This is what the discussion is about.
> > >
> > On the contrary, the semantic is, or at least can be, very similar.
> >
> > Consider the hypothetical, but plausible, case of a network with an  
> > explicit call/capacity admission process, in which both 911-type-
> > emergency calls and GETS calls get preferential admission  
> > treatment.  By the time the INVITE gets to this Functional Module/  
> > block of code, all authentication, authorization, and changes/
> > confirmation of the destination have already taken place.  All this  
> > block of code deals with is call/capacity admission.
> >
> > For the sake of argument, suppose this is the nature of the  
> > preference.
> >
> > 1) For INVITEs without RPH, or with an RPH this network does not use/
> > understand, if the admission process fails, the INVITE fails
> >
> > 2) For INVITEs with RPH with the ets namespace, if the admission  
> > process initially fails, the INVITE is put in queue until the  
> > resources become available so it can be admitted.
> >
> > 3) For INVITEs with RPH with the esnet namespace, if the admission  
> > process initially fails, the INVITE is put in queue, but at lower  
> > priority than the calls with the ets namespace.
> >
> > With the esnet namespace, this block of code only needs to deal with  
> > the RPH in determining which INVITEs to reject, and which to queue,  
> > and how.
> >
> > But if there is no esnet namespace for RPH, then this block of code  
> > would need to deal with BOTH the RPH and the URN.  That would be a  
> > completely unnecessary complication.
> >
> > Janet
>
--=_alternative 005EF2FA85257556_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6114F3A6CC7; Sat, 7 Feb 2009 09:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8JuWHSuNFka; Sat, 7 Feb 2009 09:29:38 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 2781D3A6CB6; Sat, 7 Feb 2009 09:29:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-5.tower-146.messagelabs.com!1234027781!12454975!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 21766 invoked from network); 7 Feb 2009 17:29:42 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 7 Feb 2009 17:29:42 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n17HTdMR013933; Sat, 7 Feb 2009 12:29:39 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n17HTZkd013918; Sat, 7 Feb 2009 12:29:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 7 Feb 2009 12:29:35 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01238F6F@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Semantics Re: RPH Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88y From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: ecrit@ietf.org, ecrit-bounces@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 17:29:39 -0000 RG8geW91IGhhdmUgYSBjbHVlIGR1ZGU/IEErQSBvZiBhbiB1c2VyIGNvbWVzIGluIG1hbnkgZm9y bXMuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGVjcml0LWJvdW5jZXNA aWV0Zi5vcmcgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogSmFuZXQgUCBHdW5uIDxqZ3Vu bjZAY3NjLmNvbT4NCkNjOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+OyBlY3JpdC1ib3VuY2VzQGll dGYub3JnIDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPg0KU2VudDogU2F0IEZlYiAwNyAxMTo1Njo0 MiAyMDA5DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBTZW1hbnRpY3MgIFJlOiAgUlBIDQoNClBsZWFz ZSBzZWUgbXkgZWFybGllciBtZXNzYWdlIGFzIHRvIHdoeSB5b3VyIGFwcHJvYWNoIGZhaWxzIGZv ciB0aGUgVUEtIA0KaW5zZXJ0ZWQgY2FzZSB3aGVyZSBub3QgYWxsIGVtZXJnZW5jeSBjYWxscyBo YXZlIFJQSCBtYXJraW5ncy4gSSB0aGluayAgDQppdCB3b3VsZCBiZSBhIHJlYWxseSBiYWQgaWRl YSBpZiBlbWVyZ2VuY3kgY2FsbHMgd2l0aCBSUEggYXJlIHRyZWF0ZWQgIA0KZGlmZmVyZW50bHkg dGhhbiBlbWVyZ2VuY3kgY2FsbHMgd2l0aG91dCBpdC4gKEFnYWluLCBJJ20gdGFsa2luZyBhYm91 dCAgDQp0aGUgdXNlci1pbml0aWF0ZWQgY2FsbHMuIEFuIEVTTkVUIGNhbiBkbyB3aGF0ZXZlciBp dCB3YW50cyBhbmQgY2FuICANCmFzc2lnbiBleHRyYSBwcmlvcml0eSB0byBjYWxscyBmcm9tIGNp dGl6ZW5zIHRoYXQgaGF2ZSBib3VnaHQgUEJBICANCnN0aWNrZXJzIG9yIHppcCBjb2RlcyB0aGF0 IHBheSBtb3JlIHRheGVzLCBidXQgdGhhdCdzIGEgc2VwYXJhdGUgIA0KcHJvYmxlbS4pDQoNCkkg YWxzbyBkb24ndCBiZWxpZXZlIHlvdXIgaW1wbGVtZW50YXRpb24gbG9naWMuIEEgbXVjaCBiZXR0 ZXIgYXBwcm9hY2ggIA0KaXMgdG8gc2VtYW50aWNhbGx5IGRlY2xhcmUgdGhlIGNsYXNzIG9mIGNh bGwgZWFybHkgb24gKGUuZy4sIGJhc2VkIG9uICANCnRoZSBVUk4gb3IgYWZ0ZXIgYXV0aGVudGlj YXRpb24vYXV0aG9yaXphdGlvbiksIGFuZCBtYWtlIHRoYXQgcGFydCBvZiAgDQp0aGUgY2FsbCBz dGF0ZSByZWNvcmQsIHJhdGhlciB0aGFuIGh1bnQgZm9yIGhlYWRlcnMgZWFjaCB0aW1lIGEgIA0K aGFuZGxpbmcgZGVjaXNpb24gbmVlZHMgdG8gYmUgbWFkZS4gR2l2ZW4gdGhlIGF1dGhvcml6YXRp b24gIA0KcmVxdWlyZW1lbnRzLCBqdXN0IGxvb2tpbmcgYXQgImhhcyBoZWFkZXIgWCIgaXMgbmV2 ZXIgZ29pbmcgdG8gYmUgIA0Kc3VmZmljaWVudCBhbnl3YXkuDQoNCkhlbm5pbmcNCg0KT24gRmVi IDcsIDIwMDksIGF0IDExOjI3IEFNLCBKYW5ldCBQIEd1bm4gd3JvdGU6DQoNCj4NCj4NCj4gLg0K Pg0KPiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIHdyb3RlIG9uIDAyLzA3LzIwMDkgMDM6MTQ6NTcg QU06DQo+DQo+ID4gUExFQVNFIHRyeSB0byB1bmRlcnN0YW5kIHRoYXQgdGhlIHN5bnRheCBpcyBz aW1pbGFyIChoZWFkZXIsIG5ldyAgDQo+IG5hbWVzcGFjZSwNCj4gPiBuZXcgdmFsdWVzKQ0KPiA+ IEJVVCB0aGUgc2VtYW50aWMgaXMgZGlmZmVyZW50Lg0KPiA+DQo+ID4gRm9yIGFsbCBtZXNzYWdl IGl0IGlzIHRydWUgdGhhdCB0aGUgc2VuZGVyIGNhbiBhZGQgd2hhdGV2ZXIgdGhleSAgDQo+IHdh bnQuIFRoZQ0KPiA+IGJpZyBxdWVzdGlvbiBpcyB3aGF0IGRvZXMgaXQgbWVhbiBmb3IgdGhlIHJl Y2lwaWVudC4NCj4gPg0KPiA+IFRoaXMgaXMgd2hhdCB0aGUgZGlzY3Vzc2lvbiBpcyBhYm91dC4N Cj4gPg0KPiBPbiB0aGUgY29udHJhcnksIHRoZSBzZW1hbnRpYyBpcywgb3IgYXQgbGVhc3QgY2Fu IGJlLCB2ZXJ5IHNpbWlsYXIuDQo+DQo+IENvbnNpZGVyIHRoZSBoeXBvdGhldGljYWwsIGJ1dCBw bGF1c2libGUsIGNhc2Ugb2YgYSBuZXR3b3JrIHdpdGggYW4gIA0KPiBleHBsaWNpdCBjYWxsL2Nh cGFjaXR5IGFkbWlzc2lvbiBwcm9jZXNzLCBpbiB3aGljaCBib3RoIDkxMS10eXBlLSANCj4gZW1l cmdlbmN5IGNhbGxzIGFuZCBHRVRTIGNhbGxzIGdldCBwcmVmZXJlbnRpYWwgYWRtaXNzaW9uICAN Cj4gdHJlYXRtZW50LiAgQnkgdGhlIHRpbWUgdGhlIElOVklURSBnZXRzIHRvIHRoaXMgRnVuY3Rp b25hbCBNb2R1bGUvICANCj4gYmxvY2sgb2YgY29kZSwgYWxsIGF1dGhlbnRpY2F0aW9uLCBhdXRo b3JpemF0aW9uLCBhbmQgY2hhbmdlcy8gDQo+IGNvbmZpcm1hdGlvbiBvZiB0aGUgZGVzdGluYXRp b24gaGF2ZSBhbHJlYWR5IHRha2VuIHBsYWNlLiAgQWxsIHRoaXMgIA0KPiBibG9jayBvZiBjb2Rl IGRlYWxzIHdpdGggaXMgY2FsbC9jYXBhY2l0eSBhZG1pc3Npb24uDQo+DQo+IEZvciB0aGUgc2Fr ZSBvZiBhcmd1bWVudCwgc3VwcG9zZSB0aGlzIGlzIHRoZSBuYXR1cmUgb2YgdGhlICANCj4gcHJl ZmVyZW5jZS4NCj4NCj4gMSkgRm9yIElOVklURXMgd2l0aG91dCBSUEgsIG9yIHdpdGggYW4gUlBI IHRoaXMgbmV0d29yayBkb2VzIG5vdCB1c2UvIA0KPiB1bmRlcnN0YW5kLCBpZiB0aGUgYWRtaXNz aW9uIHByb2Nlc3MgZmFpbHMsIHRoZSBJTlZJVEUgZmFpbHMNCj4NCj4gMikgRm9yIElOVklURXMg d2l0aCBSUEggd2l0aCB0aGUgZXRzIG5hbWVzcGFjZSwgaWYgdGhlIGFkbWlzc2lvbiAgDQo+IHBy b2Nlc3MgaW5pdGlhbGx5IGZhaWxzLCB0aGUgSU5WSVRFIGlzIHB1dCBpbiBxdWV1ZSB1bnRpbCB0 aGUgIA0KPiByZXNvdXJjZXMgYmVjb21lIGF2YWlsYWJsZSBzbyBpdCBjYW4gYmUgYWRtaXR0ZWQu DQo+DQo+IDMpIEZvciBJTlZJVEVzIHdpdGggUlBIIHdpdGggdGhlIGVzbmV0IG5hbWVzcGFjZSwg aWYgdGhlIGFkbWlzc2lvbiAgDQo+IHByb2Nlc3MgaW5pdGlhbGx5IGZhaWxzLCB0aGUgSU5WSVRF IGlzIHB1dCBpbiBxdWV1ZSwgYnV0IGF0IGxvd2VyICANCj4gcHJpb3JpdHkgdGhhbiB0aGUgY2Fs bHMgd2l0aCB0aGUgZXRzIG5hbWVzcGFjZS4NCj4NCj4gV2l0aCB0aGUgZXNuZXQgbmFtZXNwYWNl LCB0aGlzIGJsb2NrIG9mIGNvZGUgb25seSBuZWVkcyB0byBkZWFsIHdpdGggIA0KPiB0aGUgUlBI IGluIGRldGVybWluaW5nIHdoaWNoIElOVklURXMgdG8gcmVqZWN0LCBhbmQgd2hpY2ggdG8gcXVl dWUsICANCj4gYW5kIGhvdy4NCj4NCj4gQnV0IGlmIHRoZXJlIGlzIG5vIGVzbmV0IG5hbWVzcGFj ZSBmb3IgUlBILCB0aGVuIHRoaXMgYmxvY2sgb2YgY29kZSAgDQo+IHdvdWxkIG5lZWQgdG8gZGVh bCB3aXRoIEJPVEggdGhlIFJQSCBhbmQgdGhlIFVSTi4gIFRoYXQgd291bGQgYmUgYSAgDQo+IGNv bXBsZXRlbHkgdW5uZWNlc3NhcnkgY29tcGxpY2F0aW9uLg0KPg0KPiBKYW5ldA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBs aXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lY3JpdA0K Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6498F3A67EC for ; Sat, 7 Feb 2009 16:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a-s+oFalSYe for ; Sat, 7 Feb 2009 16:59:26 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 84DAF3A67FB for ; Sat, 7 Feb 2009 16:59:24 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n180xAc7010230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 8 Feb 2009 01:59:10 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 8 Feb 2009 01:59:10 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "'Winterbottom, James'" , "'Brian Rosen'" , "'Henning Schulzrinne'" Date: Sun, 8 Feb 2009 01:59:10 +0100 Thread-Topic: [Ecrit] RPH Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprowABE/KKAAIrWZwA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67499BC21@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net><001d01c9885b$d5d705d0$49b5b70a@nsnintra.net><001f01c98860$910658c0$49b5b70a@nsnintra.net><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$49b5b70a@nsnintra.net><1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$49b5b70a@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <007401c988fe$15e06cf0$0201a8c0@nsnintra.net> In-Reply-To: <007401c988fe$15e06cf0$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 00:59:29 -0000 We go round and round in circles. We had this discussion on the mail list before the last IETF meeting. Different headers have different semantics. The service urn appears in a pa= rt of the SIP message where RFC 3261 defines exactly the semantics it has. = Those appearances have nothing to do with the semantics of a resource prior= ity header. regards Keith > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, February 07, 2009 8:29 AM > To: DRAGE, Keith (Keith); 'Winterbottom, James'; 'Brian > Rosen'; 'Henning Schulzrinne' > Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > Subject: RE: [Ecrit] RPH > > What do you think is the semantic of the Service URN (or the > respective dial string)? > Emergency call with special processing needed? Do everything > so that the call gets through? > > How often do you want to say that the call is really > important to you? > > We could invent a few more headers say "Yes, it is really > important. Believe me -- really, really important. Also add > location because that it could be needed to locate me.". See > my other mail where I invented such a new header that from a > philosophical point of view (not from a practical) makes a > lot of sense. > > Code just needs to know it is important and can do all the > necessary steps. > I doubt that someone would write code that does not treat the > emergency call as less important when an emergency call comes > in that does not have the ECRIT RPH header present. Would you > think so? > > Ciao > Hannes > > >-----Original Message----- > >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >Sent: 07 February, 2009 02:15 > >To: Winterbottom, James; Hannes Tschofenig; Brian Rosen; Henning > >Schulzrinne > >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >Subject: RE: [Ecrit] RPH > > > >It is a valid header for that usage. It carries exactly the > semantics > >the user wishes to convey, i.e. that the requestor would > like the call > >to be treated in processing by the network in a manner > appropriate to > >emergency calls. > > > >Yes the edge proxy may well review and make up its own mind, > and either > >remove, verify or pass on the header, but that does not mean it is > >wrong from the UE. > > > >You might just as well argue that the UE should not inserted a > >P-Preferred-ID if it knows that the value it contains will > be the one > >inserted by the edge proxy. > > > >regards > > > >Keith > > > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Winterbottom, James > >> Sent: Friday, February 06, 2009 8:02 PM > >> To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne > >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >> Subject: Re: [Ecrit] RPH > >> > >> Hi All, > >> > >> I have followed thi thread with some interest and I > >struggling to see > >> a use case for the providing RPH for emergency calls from the > >> end-point. > >> > >> The reference-model call in ECRIT, for better or worse, is for all > >> calls to go back through a home-VSP. > >> We placed quite a lot of emphasis, largely for traffing > reasons, for > >> the VSP to be able to verify that a call is in fact an > >emergency call. > >> This is done by the proxy taking the inband location, doing a LoST > >> query with the provided URN, and verifying that the resulting > >> destination URI is the same as the destination URI provide > >in the SIP > >> INVITE. My understanding was that VSPs would always do > this check so > >> they could tell if they could bill for the call or not, > and because > >> the VSP can be use that the call is an emergency call it can > >apply any > >> special priorities that may be applicable. > >> This obviates the need for RPH from the end-point to the network. > >> > >> This leaves us with the argument of "it doesn't hurt to it", > >which is > >> not a good reason to write a specification. > >> It was intimated on the geopriv mailing list last year that great > >> pains had been taken to keep SIP with in the MTU limits of > UDP over > >> Ethernet > >> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120 > >> .html). Assuming that this is the case, perhaps there is harm in > >> including information that we know will be ignored. > >> > >> Cheers > >> James > >> > >> > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > >> Sent: Fri 2/6/2009 12:33 PM > >> To: 'Brian Rosen'; 'Henning Schulzrinne' > >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > >> Subject: Re: [Ecrit] RPH > >> > >> To the story short here is the code for the proxy: > >> > >> --------------------- > >> > >> IF emergency call was recognized THEN > >> execute emergency call specific procedures (priority queuing, > >> preemption, fetch location, determine routing, do funny > QoS things & > >> co) ELSE > >> normal call handling procedures. > >> > >> --------------------- > >> > >> If you can make this differentiation between an emergency > call and a > >> regular call then you can also do everything that is necessary for > >> emergency call handling. > >> > >> Brian + Keith: Please tell me that we cannot do the above with our > >> currently specified mechanisms. > >> > >> Ciao > >> Hannes > >> > >> >-----Original Message----- > >> >From: Brian Rosen [mailto:br@brianrosen.net] > >> >Sent: 06 February, 2009 17:49 > >> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > >> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >Subject: RE: [Ecrit] RPH > >> > > >> >I agree that not all networks will permit (or pay attention > >> >to) a priority request from an end device. > >> > > >> >No one has asked for that. > >> > > >> >The namespace request has several uses, one of which is within an > >> >emergency services IP network, one of which is between > >> elements within > >> >a public network controlled by the operator, and one of > which is an > >> >endpoint request for resource priority. > >> > > >> >Those of us requesting this work proceed are happy if the > >> endpoint part > >> >is simply left as possible (MAY), and, speaking for myself, > >> having the > >> >draft discuss the security implications of endpoint marking is > >> >reasonable. > >> > > >> >Having discussed this issue with an implementation team who > >> worked on > >> >MLPP systems, I am confident I know what I'm talking about, > >> but YMMV. > >> >The fact that you could, if you wanted to, give resource > >> priority to a > >> >call you decided, however you decided, was an emergency > call is an > >> >implementation decision, and not subject to standardization. > >> > > >> >RPH is the IETF standard way for one entity to request resource > >> >priority of another entity in a SIP system. We're asking for a > >> >namespace to use that within the domain of emergency calls. > >> That is, I > >> >think, a VERY reasonable request. > >> > > >> >Brian > >> > > >> >> -----Original Message----- > >> >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> >> Sent: Friday, February 06, 2009 10:33 AM > >> >> To: Hannes Tschofenig > >> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >> >> Subject: Re: [Ecrit] RPH > >> >> > >> >> To chime in here: > >> >> > >> >> I don't think it's productive to simply state that 4412 > >> >doesn't worry > >> >> about authorization, so we shouldn't either (simplifying a bit). > >> >> Authorization was discussed repeatedly, and the general > >> >assumption was > >> >> that there were two conditions: Either the user invoking > >resource- > >> >> priority was well known and had a set of permissions that > >could be > >> >> checked in real time or there are ways to deal with abuse > >> after the > >> >> fact in ways that deter abuse (the court-martial kind of > >> thing in a > >> >> military context). > >> >> > >> >> The RFC 4412 security consideration (11.2) call this out > >in pretty > >> >> strong language: > >> >> > >> >> Prioritized access to network and end-system resources imposes > >> >> particularly stringent requirements on authentication and > >> >> authorization mechanisms, since access to prioritized > >> >resources may > >> >> impact overall system stability and performance and not > >> >just result > >> >> in theft of, say, a single phone call. > >> >> Thus, the question is whether we have such strong > >> authentication in > >> >> emergency calling. In some cases, such as residential > fixed line > >> >> deployments where ISP =3D VSP, we're probably pretty close, > >> in others, > >> >> such as prepaid cell phones or hot spots or VSP-only > >providers, we > >> >> aren't. > >> >> > >> >> The other point that I think Hannes is making is that the > >> >information > >> >> is either redundant or dangerous. If a processing element > >> recognizes > >> >> the call as being an emergency call, it can apply whatever > >> treatment > >> >> it deems appropriate and doesn't need additional > >> information. If it > >> >> doesn't or can't, using just the RPH can be rather > >> dangerous unless > >> >> that element can be reasonably certain that there is strong > >> >> authentication and recourse. > >> >> > >> >> I don't buy the argument that somehow finding the RPH is > >> faster than > >> >> just looking for the identifier. Thus, given that the > >> information is > >> >> either redundant or dangerous, I fail to see the advantage. > >> >> > >> >> Henning > >> >> > >> >> > >> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: > >> >> > >> >> > Don't get hung up on the details. There are ways to > optimize it. > >> >> > That was > >> >> > not the point of the code example. > >> >> > > >> >> > The problem that my pseudo code should have shown you > >is that you > >> >> > * don't gain anything with RPH marking for the emergency > >> call case > >> >> > from the SIP UA towards the outbound proxy since the > >> functionality > >> >> > is already provide otherwise. How often does the proxy > >> need to get > >> >> > told that this is an emergency call todo whatever > >emergency call > >> >> > handling procedures are necessary? > >> >> > * you only introduce fraud problems (if you are not > >> >careful and you > >> >> > understand the security stuff well enough) > >> >> > > >> >> > If you can point me to people who implement the RPH > >> emergency call > >> >> > case please do so. I would love to talk to them. > >> >> > > >> >> > Ciao > >> >> > Hannes > >> >> > > >> >> > PS: You need to parse incoming messages to some extend > >> so that you > >> >> > know what it contains :-) Only looking for the emergency > >> >RPH header > >> >> > (and not for the Service URN/dial > >> >> > string) would exactly be the DoS/fraud attack I am > >worried about. > >> >> > That's the thing Henning was worried about (go and > >listen to the > >> >> > past meeting minutes). > >> >> > > >> >> > > >> >> >> Hannes > >> >> >> > >> >> >> You need to talk to people who really implement this kind > >> >of thing. > >> >> >> You are way off. > >> >> >> > >> >> >> When you implement a resource priority system, the > >> point of doing > >> >> >> that is to look though the queue of work and pick out the > >> >ones with > >> >> >> priority, handling them first. You don't do all the > >> parsing, you > >> >> >> don't do a lot of decision tree. > >> >> >> > >> >> >> Typically: > >> >> >> Check for DoS things, like too big messages, etc Do a > >> quick scan > >> >> >> for the RPH message header If found: > >> >> >> Parse the message > >> >> >> Determine validity > >> >> >> Determine priority > >> >> >> Queue on the correct work queue > >> >> >> > >> >> >> The first two actions have to be very fast. Anyone who > >> builds a > >> >> >> SIP thingie will tell you that parsing is one of the > big cycle > >> >> >> consumers: if you have to parse every message BEFORE you > >> >determine > >> >> >> priority, you can't give much resource priority. > >> >> >> Once you get the whole message parsed, you might as > >well finish > >> >> >> working on it, because you've done so much of the work. > >> >> >> OTHOH, finding the end-of-message delimiter and > doing a quick > >> >> >> string search for RPH is fast. If you are doing > >> >priority, you need > >> >> >> to keep all the priority processing pretty uniform, > and pretty > >> >> >> simple, or you tend to spend too much time futzing around > >> >figuring > >> >> >> out what to do. You put all the priority related stuff > >> together, > >> >> >> and use as much common code as possible. > >> >> >> > >> >> >> Brian > >> >> >> > >> >> >>> -----Original Message----- > >> >> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> >> On Behalf > >> >> >>> Of Hannes Tschofenig > >> >> >>> Sent: Friday, February 06, 2009 8:41 AM > >> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' > >> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- > >> >> >>> bounces@ietf.org > >> >> >>> Subject: [Ecrit] RPH > >> >> >>> > >> >> >>> Over lunch I was also thinking how an outbound proxy would > >> >> implement > >> >> >>> some of the emergency procedures. Here are some thoughts: > >> >> >>> > >> >> >>> --------------------------------------------------- > >> >> >>> > >> >> >>> // Process incoming message > >> >> >>> Parse(msg); > >> >> >>> > >> >> >>> // SIP INVITE without Service URN // legacy devices If > >> >> >>> (recognize-dialstring(msg)=3D=3DTRUE) { // we got an > >> emergency call > >> >> >>> going on emergency=3DTRUE; if (dialstring(msg) =3D=3D 911) > >> >> >>> serviceURN=3Durn:service:sos; } else if > >> >> >>> (recognize-serviceURN(msg)=3D=3DTRUE) { // oh. A updated > >> >device that > >> >> >>> has a service URN attached to the > >> >> call > >> >> >>> serviceURN=3Dretrieve_ServiceURN(msg); > >> >> >>> emergency=3DTRUE; > >> >> >>> } else { > >> >> >>> // standard SIP message > >> >> >>> // regular processing > >> >> >>> process(msg); > >> >> >>> emergency=3DFALSE; > >> >> >>> } > >> >> >>> > >> >> >>> If (emergency =3D=3D TRUE) { > >> >> >>> // make sure that the emergency call does not get > >> >dropped on the > >> >> >>> floor > >> >> >>> // skip authorization failures > >> >> >>> // give the call a special treatment > >> >> >>> lots-of-code-here(); > >> >> >>> > >> >> >>> // trigger all the QoS signaling you have in the > >> >network to make > >> >> >>> James happy > >> >> >>> trigger-qos(); > >> >> >>> > >> >> >>> // query location > >> >> >>> location=3Dretrieve-location(); > >> >> >>> > >> >> >>> // determine next hop > >> >> >>> next-hop=3Dlost(location, serviceURN) > >> >> >>> > >> >> >>> // attach RPH marking to outgoing msg to make James and > >> >> >> Keith happy > >> >> >>> msg=3Dadd(msg, RPH); > >> >> >>> > >> >> >>> send(msg, next-hop); > >> >> >>> } > >> >> >>> > >> >> >>> If ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D TRUE)) = { > >> >> >>> // all the emergency related processing done > already upfront > >> >> >>> // hence I log something. > >> >> >>> log(RPH_WAS_PRESENT_JUHU); > >> >> >>> } else if ((rph-present(msg) =3D=3D TRUE) && (emergency =3D=3D > >> >FALSE)) { > >> >> >>> // this is not an emergency call // this is something > >> >like GETS > >> >> >>> result=3Dspecial-authorization-procedure(user); > >> >> >>> > >> >> >>> if (result =3D=3D AUTHORIZED) { > >> >> >>> // do some priority & preemption thing here. > >> >> >>> // trigger all the QoS you have > >> >> >>> lots-of-code-here(); > >> >> >>> } else { > >> >> >>> log("NOT AUTHORIZED; don't DoS my network"); } } > >> else { // > >> >> >>> don't need todo any RPH processing // this > includes the case > >> >> >>> where the call was an emergency call but the RPH > >> >> >>> > >> >> >>> // marking was not there. > >> >> >>> nothing(); > >> >> >>> } > >> >> >>> > >> >> >>> --------------------------------------------------- > >> >> >>> > >> >> >>> > >> >> >>> Ciao > >> >> >>> Hannes > >> >> >>> > >> >> >>>> -----Original Message----- > >> >> >>>> From: ecrit-bounces@ietf.org > >> [mailto:ecrit-bounces@ietf.org] On > >> >> >>>> Behalf Of Hannes Tschofenig > >> >> >>>> Sent: 06 February, 2009 15:07 > >> >> >>>> To: 'Janet P Gunn' > >> >> >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; > Tschofenig,Hannes (NSN - > >> >> >>> FI/Espoo) > >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >> Agenda (RPH) > >> >> >>>> > >> >> >>>> Who would define something that could prevent DoS problems? > >> >> >>>> > >> >> >>>> ________________________________ > >> >> >>>> > >> >> >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >> >> >>>> Sent: 06 February, 2009 14:11 > >> >> >>>> To: Hannes Tschofenig > >> >> >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; > >> >> >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - > FI/Espoo); > >> >> 'James > >> >> >>>> M. Polk' > >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim > >> >Meeting: Agenda (RPH) > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> But there is nothing IN RFC4412 that specifically > >> >> >> addresses how to > >> >> >>>> prevent any particular namespace being used for DoS. > >> Anyone/any > >> >> UA > >> >> >>>> can ATTEMPT to invoke priority treatment by attaching > >> RPH. For > >> >> all > >> >> >>>> of the 4412 namespaces, as with the new proposed > >> namespace, the > >> >> >>>> mechanisms for preventing DoS are not specified in the > >> >> >> document that > >> >> >>>> defines the namespace. > >> >> >>>> They are/will be specified elsewhere. > >> >> >>>> > >> >> >>>> Janet > >> >> >>>> > >> >> >>>> This is a PRIVATE message. If you are not > the intended > >> >> >> recipient, > >> >> >>>> please delete without copying and kindly advise us by > >> e-mail of > >> >> the > >> >> >>>> mistake in delivery. > >> >> >>>> NOTE: Regardless of content, this e-mail shall not > >> >> >> operate to bind > >> >> >>>> CSC to any order or other contract unless pursuant to > >> explicit > >> >> >>>> written agreement or government initiative expressly > >> permitting > >> >> the > >> >> >>>> use of e-mail for such purpose. > >> >> >>>> > >> >> >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 > 04:21:51 AM: > >> >> >>>> > >> >> >>>> > Hi James, > >> >> >>>> > > >> >> >>>> > I have read RFC 4412 and also the GETS/MLPP IETF > >> >> >> documents. What I > >> >> >>>> would > >> >> >>>> > like to point out is that there is more than just a > >> >> >> header and > >> >> >>>> values within > >> >> >>>> > the header that have to be considered in order to > >> >> >> make a judgement > >> >> >>>> of what > >> >> >>>> > is appropriate and what isn't. There is an > >> >> >> architectural question > >> >> >>>> and > >> >> >>>> > whether the environment we are using the stuff is > >> >> >> indeed providing > >> >> >>>> the > >> >> >>>> > properties you need for the solution to be > >> >appropriate. > >> >> >>>> > > >> >> >>>> > Let me describe in more detail what I meant (and > >> >> >> please correct me > >> >> >>>> if I am > >> >> >>>> > wrong). > >> >> >>>> > > >> >> >>>> > Getting priority for SIP requests when using a GETS > >> >> >> alike scenario > >> >> >>>> means > >> >> >>>> > that the entity that issues the request is > specially > >> >> >> authorized > >> >> >>>> since > >> >> >>>> > otherwise you introduce a nice denial of > >> >service attack. This > >> >> >>>> authorization > >> >> >>>> > is tied to the entity that makes the request. For > >> >> >> example, the > >> >> >>>> person is > >> >> >>>> > working for the government and has special rights. > >> >> >>>> James Bond as a (not so) > >> >> >>>> > secret agent might have these rights. > >> >> >>>> > > >> >> >>>> > The emergency services case > >> >(citizen-to-authority) is a bit > >> >> >>>> different as > >> >> >>>> > there aren't really special rights with respect to > >> >> >> authorization > >> >> >>>> tied to > >> >> >>>> > individuals. Instead, the fact that something is an > >> >> >> emergency is > >> >> >>>> purely a > >> >> >>>> > judgement of the human that dials a special number. > >> >> >>>> To deal with fraud, we > >> >> >>>> > discussed in the group on what we can > actually do to > >> >> >> ensure that > >> >> >>>> end users > >> >> >>>> > do not bypass security procedures (such as > >> >> >> authorization checks, > >> >> >>>> charging > >> >> >>>> > and so on). Part of this investigation was > >> >the publication of > >> >> >>>> > http://www.ietf.org/rfc/rfc5069.txt that also > >> >describes this > >> >> >>>> issue. > >> >> >>>> > > >> >> >>>> > So, imagine the implementation of a SIP > proxy (and we > >> >> >> implemented > >> >> >>>> that > >> >> >>>> > stuff) that receives a call that contains a Service > >> >> >> URN. The code > >> >> >>>> branches > >> >> >>>> > into a special mode where everything is done > >> >so that the call > >> >> >>>> receives > >> >> >>>> > appropriate treatment and does not get > dropped on the > >> >> >> floor. The > >> >> >>>> way how the > >> >> >>>> > Service URN is placed in the message > ensures that the > >> >> >> call cannot > >> >> >>>> go to my > >> >> >>>> > friend (instead of the PSAP) unless the > end host ran > >> >> >> LoST already. > >> >> >>>> In the > >> >> >>>> > latter case, we discussed this also on the > list for a > >> >> >> while and > >> >> >>>> Richard even > >> >> >>>> > wrote a draft about it in the context of the > >> >location hiding > >> >> >>>> topic, we said > >> >> >>>> > that the proxy would have to run LoST if he > >> >cares about a > >> >> >>>> potential > >> >> >>>> > fraudulent usage. > >> >> >>>> > > >> >> >>>> > So, what do we need todo in order to provide > >> >secure RFC 4412 > >> >> >>>> functionality > >> >> >>>> > in our context? > >> >> >>>> > > >> >> >>>> > Do you think that the current text in > >> >> >>>> > > >> >> >>>> > >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >> >>>> gency-rph-nam > >> >> >>>> > espace-00.txt reflects any of the > >> >above-described issues: > >> >> >>>> > " > >> >> >>>> > The Security considerations that apply > to RFC 4412 > >> >> >>>> [RFC4412] > >> >> >>>> apply > >> >> >>>> > here. This document introduces no new security > >> >> >>>> issues relative > >> >> >>>> to > >> >> >>>> > RFC 4412. > >> >> >>>> > " > >> >> >>>> > > >> >> >>>> > From various discussions in GEOPRIV I recall > >> >that you are > >> >> >>>> super-sensitive > >> >> >>>> > regarding security and privacy. For some > reasons you > >> >> >> don't seem to > >> >> >>>> have the > >> >> >>>> > same concerns here. I would like to > >> >understand your reasoning. > >> >> >>>> > > >> >> >>>> > Please also do me another favor: Don't always say > >> >> >> that I don't > >> >> >>>> understand > >> >> >>>> > the subject. Even if that would be the > case it isn't > >> >> >> particular > >> >> >>>> fair given > >> >> >>>> > that different folks had to educate you on other > >> >> >> topics in the > >> >> >>>> past as well. > >> >> >>>> > Additionally, if you listen to the audio recordings > >> >> >> then you will > >> >> >>>> notice > >> >> >>>> > that Henning, Ted, and Jon do not seem to > understand > >> >> >> the issue > >> >> >>>> either as > >> >> >>>> > they have raised similar issues during the > >> >F2F meetings. > >> >> >>>> > > >> >> >>>> > Ciao > >> >> >>>> > Hannes > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > >Hannes - I believe it is you who do not understand > >> >> >> RFC 4412 -- > >> >> >>>> > >and many of us are trying to get that > >> >through to you, but you > >> >> >>>> > >don't seem to want to listen/read. > >> >> >>>> > > > >> >> >>>> > >RFC 4412 is *for* priority marking SIP requests, > >> >> >>>> > > > >> >> >>>> > >One use is GETS. > >> >> >>>> > > > >> >> >>>> > >One use is MLPP. > >> >> >>>> > > > >> >> >>>> > >These examples are in RFC 4412 because there > >> >were specific > >> >> >>>> > >namespaces being created for the IANA section of > >> >> >> that document. > >> >> >>>> > > > >> >> >>>> > >Reading the whole document, you will see > >> >that RPH can be > >> >> >>>> > >specified for other uses than GETS or MLPP > >> >specifically. > >> >> >>>> > > > >> >> >>>> > >I knew when I wrote RFC 4412 that one day we > >> >would specify a > >> >> >>>> > >namespace for ECRIT (the "esnet" namespace > >> >now) -- but I also > >> >> >>>> > >knew it was premature for RFC 4412 to > >> >incorporate that > >> >> >>>> > >namespace, that a future doc to RFC 4412 > >> >would have to be > >> >> >>>> > >written to do this. Brian and I talked about > >> >this at the > >> >> >>>> > >original NENA meeting that created the IP > WGs there > >> >> >> (in August > >> >> >>>> > >of 03). We both agreed we should wait > until it was > >> >> >>>> > >appropriate to the work in the IETF to > >> >submit this document > >> >> >>>> > >that is now > >> >> >>>> > > >> >> >>>>> > >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >> >>>> > >gency-rph-namespace-00.txt > >> >> >>>> > > > >> >> >>>> > >Yet, you seem to want to use some additional > >> >mechanism to > >> >> >>>> > >indicate priority of a call in SIP. That > >> >means you want to > >> >> >>>> > >introduce a second way to accomplish this in SIP. > >> >> >>>> Why do you > >> >> >>>> > >want to promote a separate way to do something SIP > >> >> >> has already > >> >> >>>> > >defined? That will cause interoperability > issues and > >> >> >> we both know > >> >> >>>> that. > >> >> >>>> > > > >> >> >>>> > >You've said to me (and others) that you > >> >believe RPH is just > >> >> >>>> > >another way to accomplish what sos or a URI can > >> >> >> indicate - and > >> >> >>>> > >you're wrong. Your way would be > >> >_the_second_way_to_do_it, > >> >> >>>> > >because SIP already considers RPH to be > >> >*the*way* to priority > >> >> >>>> > >mark SIP requests. > >> >> >>>> > > > >> >> >>>> > >If you don't believe me (no comment), then > >> >why do you not > >> >> >>>> > >believe the SIP WG chair (who knows more > >> >about SIP than both > >> >> >>>> > >of us) - who, on this thread, has again said > >> >to you "RFC 4412 > >> >> >>>> > >(RPH) is the SIP mechanism to priority mark > >> >SIP requests"? > >> >> >>>> > > > >> >> >>>> > >Further, I believe it is inappropriate to > >> >prohibit endpoints > >> >> >>>> > >from being able to set the esnet namespace. > >> >I absolutely > >> >> >>>> > >believe it will not be needed most of the > >> >time, but I believe > >> >> >>>> > >if someone does find a valid use for > >> >endpoints to mark > >> >> >>>> > >priority in SIP, this ID - once it has > >> >become an RFC -- will > >> >> >>>> > >have to be obsoleted with a new RFC > saying the exact > >> >> >> opposite. > >> >> >>>> > > > >> >> >>>> > >(color me confused ... over and over again) > >> >> >>>> > > > >> >> >>>> > >James > >> >> >>>> > > > >> >> >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >> >> >>>> > >>Keith, please understand that the usage > of RFC 4412 > >> >> >> for GETS and > >> >> >>>> for > >> >> >>>> > >>the type of emergency call we discuss here is > >> >> >> different. Just > >> >> >>>> looking > >> >> >>>> > >>at the header and the name of the > >namespace is a bit > >> >> >>>> > >artificial. I hope > >> >> >>>> > >>you understand that. > >> >> >>>> > >> > >> >> >>>> > >> >-----Original Message----- > >> >> >>>> > >> >From: DRAGE, Keith (Keith) > >> >> >>>> [mailto:drage@alcatel-lucent.com] > >> >> >>>> > >> >Sent: 05 February, 2009 14:55 > >> >> >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. > >> >> >>>> Polk'; 'Tschofenig, > >> >> >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >> >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim > >> >> >>>> Meeting: Agenda (my > >> >> >>>> > >> >> >>>> > >> >mistake) > >> >> >>>> > >> > > >> >> >>>> > >> >Which is exactly what RFC 4412 > specifies for all > >> >> >> namespaces. > >> >> >>>> > >> > > >> >> >>>> > >> >regards > >> >> >>>> > >> > > >> >> >>>> > >> >Keith > >> >> >>>> > >> > > >> >> >>>> > >> >> -----Original Message----- > >> >> >>>> > >> >> From: ecrit-bounces@ietf.org > >> >> >> [mailto:ecrit-bounces@ietf.org] > >> >> >>>> > >> >On Behalf > >> >> >>>> > >> >> Of Brian Rosen > >> >> >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >> >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. > >> >Polk'; 'Tschofenig, > >> >> >>>> > >Hannes (NSN > >> >> >>>> > >> >> - FI/Espoo)'; 'ECRIT' > >> >> >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim > >> >> >>>> Meeting: Agenda (my > >> >> >>>> > >> >> mistake) > >> >> >>>> > >> >> > >> >> >>>> > >> >> The value is that in some networks > >> >where priority for > >> >> >>>> > >> >emergency calls > >> >> >>>> > >> >> is appropriate, and appropriate > >> >policing of marking is > >> >> >>>> > >implemented, > >> >> >>>> > >> >> emergency calls will receive > resource priority. > >> >> >>>> > >> >> > >> >> >>>> > >> >> Not all networks would need policing. Some > >> >> >> will. Policing > >> >> >>>> could > >> >> >>>> > >> >> be to Route header/R-URI content, but other > >> >> >> criteria are > >> >> >>>> possible. > >> >> >>>> > >> >> > >> >> >>>> > >> >> Not all networks will need resource priority > >> >> >> for emergency > >> >> >>>> calls. > >> >> >>>> > >> >> Fine, ignore this marking/namespace. > >> >> >>>> > >> >> > >> >> >>>> > >> >> Brian > >> >> >>>> > >> >> > -----Original Message----- > >> >> >>>> > >> >> > From: Hannes Tschofenig > >> >> >>>> [mailto:Hannes.Tschofenig@gmx.net] > >> >> >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >> >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; > >> >> >> Tschofenig, Hannes > >> >> >>>> (NSN - > >> >> >>>> > >> >> > FI/Espoo); 'ECRIT' > >> >> >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim > >> >> >>>> Meeting: Agenda (my > >> >> >>>> > >> >> > mistake) > >> >> >>>> > >> >> > > >> >> >>>> > >> >> > I don't even see the value in > permitting the > >> >> >> endpoint todo > >> >> >>>> the > >> >> >>>> > >> >> > RPH marking. > >> >> >>>> > >> >> > In addition to the security concerns > >> >there is also the > >> >> >>>> > >> >problem that > >> >> >>>> > >> >> > there are more options to implement without > >> >> >> an additional > >> >> >>>> value. > >> >> >>>> > >> >> > > >> >> >>>> > >> >> > >-----Original Message----- > >> >> >>>> > >> >> > >From: Brian Rosen > [mailto:br@brianrosen.net] > >> >> >>>> > >> >> > >Sent: 05 February, 2009 00:03 > >> >> >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; > >> >> >> 'Tschofenig, > >> >> >>>> > >> >> Hannes (NSN - > >> >> >>>> > >> >> > >FI/Espoo)'; 'ECRIT' > >> >> >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual > >> >Interim Meeting: > >> >> >>>> Agenda (my > >> >> >>>> > >> >> > mistake) > >> >> >>>> > >> >> > > > >> >> >>>> > >> >> > >Hannes > >> >> >>>> > >> >> > > > >> >> >>>> > >> >> > >This matches my understanding > >> >precisely. We wish to > >> >> >>>> > >> >> permit endpoints > >> >> >>>> > >> >> > >to mark. We do not require it, and > >> >don't necessarily > >> >> >>>> expect it > >> >> >>>> > >> >> > >in many (even > >> >> >>>> > >> >> > >most) cases. We don't wish to see the > >> >> >> document prohibit > >> >> >>>> it. > >> >> >>>> > >> >> > >We all seem to agree it has value > within the > >> >> >> Emergency > >> >> >>>> > >> >Services IP > >> >> >>>> > >> >> > >Networks. > >> >> >>>> > >> >> > > > >> >> >>>> > >> >> > >Brian > >> >> >>>> > >> >> > > > >> >> >>>> > >> >> > >> -----Original Message----- > >> >> >>>> > >> >> > >> From: ecrit-bounces@ietf.org > >> >> >>>> [mailto:ecrit-bounces@ietf.org] > >> >> >>>> > >> >> > >On Behalf > >> >> >>>> > >> >> > >> Of James M. Polk > >> >> >>>> > >> >> > >> Sent: Wednesday, February 04, > 2009 4:01 PM > >> >> >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, > >> >Hannes (NSN - > >> >> >>>> > >> >> FI/Espoo); 'ECRIT' > >> >> >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT > Virtual Interim > >> >> >>>> Meeting: > >> >> >>>> > >Agenda (my > >> >> >>>> > >> >> > >> mistake) > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes > >> >Tschofenig wrote: > >> >> >>>> > >> >> > >> > > James wrote: > >> >> >>>> > >> >> > >> > >> you are the _lone_ voice not > >> >> >> supporting this ID, > >> >> >>>> > >> >> > >> > > >> >> >>>> > >> >> > >> >Listening to the audio > recording of past > >> >> >> meetings I > >> >> >>>> have to > >> >> >>>> > >> >> > >say that > >> >> >>>> > >> >> > >> >I > >> >> >>>> > >> >> > >> was > >> >> >>>> > >> >> > >> >not the only persons raising > >> >concerns about the > >> >> >>>> document. > >> >> >>>> > >> >> > >> >That was probably the reason why you > >> >> >> agreed to limit > >> >> >>>> the > >> >> >>>> > >> >> > >scope of the > >> >> >>>> > >> >> > >> >document (which you didn't later do) to > >> >> >> get folks to > >> >> >>>> agree > >> >> >>>> > >> >> > >to make it > >> >> >>>> > >> >> > >> a WG > >> >> >>>> > >> >> > >> >item. > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> re-listen to the audio please > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> Ted's concerns were consistent with most > >> >> >>>> (all?) other > >> >> >>>> > >> >> concerns -- > >> >> >>>> > >> >> > >> which were based on the premise > of whether > >> >> >> or not the > >> >> >>>> > >> >> UAC should be > >> >> >>>> > >> >> > >> trusted to initiate the marking on the > >> >> >> INVITE. The > >> >> >>>> most > >> >> >>>> > >> >> > >> recent version has backed off this > >> >to a "can" -- > >> >> >>>> meaning not > >> >> >>>> > >> >prohibited > >> >> >>>> > >> >> > >> (i.e., no 2119 text). I also backed off > >> >> >> the text in > >> >> >>>> the > >> >> >>>> > >> >> SP domain > >> >> >>>> > >> >> > >> part to "can", such that there is > >> >no 2119 text > >> >> >>>> > >> >mandating or even > >> >> >>>> > >> >> > >> recommending its usage there. I also do > >> >> >> not prohibit > >> >> >>>> its > >> >> >>>> > >> >> > >use, based on > >> >> >>>> > >> >> > >> local policy. Keith has come > forward with > >> >> >> the specific > >> >> >>>> > >> >> >>>> > >> >> > >> request that non-ESInet networks be > >> >> >> allowed to mark and > >> >> >>>> pay > >> >> >>>> > >> >attention to > >> >> >>>> > >> >> > >> this priority indication -- with IMS as > >> >> >> the specific > >> >> >>>> example > >> >> >>>> > >> >> > >> he wishes to have this valid for. > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> Where there is no disagreement, save for > >> >> >> your recent > >> >> >>>> > >> >> > >pushback - is in > >> >> >>>> > >> >> > >> the ESInet, which is where Brian > >> >has requested it's > >> >> >>>> > >> >> > >definition in the > >> >> >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG > >> >> >> chair within > >> >> >>>> > >> >> NENA, and if > >> >> >>>> > >> >> > >> he asks for it, are you going to say you > >> >> >> know better > >> >> >>>> than he? > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> >Btw, I not disagreeing with > the document > >> >> >> as such. I > >> >> >>>> > >> >just want to > >> >> >>>> > >> >> > the > >> >> >>>> > >> >> > >> scope > >> >> >>>> > >> >> > >> >to change. The usage of RPH > >> >within the emergency > >> >> >>>> > >> >> services network > >> >> >>>> > >> >> > is > >> >> >>>> > >> >> > >> fine > >> >> >>>> > >> >> > >> >for me. I may get convinced to > start the > >> >> >> RPH marking > >> >> >>>> from > >> >> >>>> > >> >> > >the the VSP > >> >> >>>> > >> >> > >> >towards the PSAP. I feel > uneasy about the > >> >> >> end host > >> >> >>>> doing > >> >> >>>> > >> >> > >the marking. > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> please read what I wrote above, and then > >> >> >> re-read the > >> >> >>>> > >> >most recent > >> >> >>>> > >> >> > >> version of the ID. I don't have > endpoints > >> >> >> that SHOULD > >> >> >>>> or > >> >> >>>> > >> >> MUST mark > >> >> >>>> > >> >> > >> anything wrt RPH. I also don't want to > >> >> >> prohibit it, > >> >> >>>> > >> >> because there > >> >> >>>> > >> >> > >> might be cases (that I don't know > >> >of) of valid uses > >> >> >>>> > >> >> under certain > >> >> >>>> > >> >> > >> circumstances. Figure 1 is very clear > >> >> >> that there are 3 > >> >> >>>> > >> >> networking > >> >> >>>> > >> >> > >> parts to consider > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> #1 - from the endpoint > >> >> >>>> > >> >> > >> #2 - within the VSP > >> >> >>>> > >> >> > >> #3 - within the ESInet > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> the most recent ID version has "can" for > >> >> >> #s 1 and 2, > >> >> >>>> and > >> >> >>>> > >> >> > >2119 language > >> >> >>>> > >> >> > >> offering those supporting this > >> >> >> specification will have > >> >> >>>> RPH > >> >> >>>> > >> >> > >> adherence within #3 (the ESInet). > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> What other scope changes do you want, > >> >> >> because I haven't > >> >> >>>> > >> >> heard them. > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> I only heard you claim in email > during the > >> >> >> last IETF > >> >> >>>> and in > >> >> >>>> > >> >> > >the ECRIT > >> >> >>>> > >> >> > >> session that RPH should not be > >> >used for priority > >> >> >>>> marking > >> >> >>>> > >> >> requests. > >> >> >>>> > >> >> > >> This is something Keith (SIP WG > >> >chair) voiced his > >> >> >>>> opposition > >> >> >>>> > >> >> > >> to your views regarding > creating a second > >> >> >> means for SIP > >> >> >>>> to > >> >> >>>> > >> >priority > >> >> >>>> > >> >> > >> mark request "when SIP already has one > >> >> >> interoperable > >> >> >>>> way to > >> >> >>>> > >> >> > >> accomplish this... it's call > the RP header > >> >> >> mechanism". > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> >I don't see advantages -- only > >> >disadvantages. > >> >> >>>> > >> >> > >> > > >> >> >>>> > >> >> > >> >Ciao > >> >> >>>> > >> >> > >> >Hannes > >> >> >>>> > >> >> > >> > >> >> >>>> > >> >> > >> > >> >_______________________________________________ > >> >> >>>> > >> >> > >> Ecrit mailing list > >> >> >>>> > >> >> > >> Ecrit@ietf.org > >> >> >>>> > >> >> > >> > >https://www.ietf.org/mailman/listinfo/ecrit > >> >> >>>> > >> >> > > > >> >> >>>> > >> >> > >> >> >>>> > >> >> > _______________________________________________ > >> >> >>>> > >> >> Ecrit mailing list > >> >> >>>> > >> >> Ecrit@ietf.org > >> >> >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >>>> > >> >> > >> >> >>>> > >> > > >> >> >>>> > > > >> >> >>>> > > >> >> >>>> > _______________________________________________ > >> >> >>>> > Ecrit mailing list > >> >> >>>> > Ecrit@ietf.org > >> >> >>>> > https://www.ietf.org/mailman/listinfo/ecrit > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> _______________________________________________ > >> >> >>>> Ecrit mailing list > >> >> >>>> Ecrit@ietf.org > >> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >>>> > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> Ecrit mailing list > >> >> >>> Ecrit@ietf.org > >> >> >>> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> > >> >> > > >> >> > _______________________________________________ > >> >> > Ecrit mailing list > >> >> > Ecrit@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/ecrit > >> >> > > >> > > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> > >> -------------------------------------------------------------- > >> ---------------------------------- > >> This message is for the designated recipient only and may contain > >> privileged, proprietary, or otherwise private information. > >> If you have received it in error, please notify the sender > >immediately > >> and delete the original. Any unauthorized use of this email is > >> prohibited. > >> -------------------------------------------------------------- > >> ---------------------------------- > >> [mf2] > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D343A6870 for ; Sun, 8 Feb 2009 01:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFQDjZ6CcK6P for ; Sun, 8 Feb 2009 01:23:10 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6DECF3A6847 for ; Sun, 8 Feb 2009 01:23:08 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2009 09:23:10 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 08 Feb 2009 10:23:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18wN+h09fwwuzBCzgI0BRq6hV40msqkjxgoJerY43 fe0BiH0S7+i5J9 From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'Winterbottom, James'" , "'Brian Rosen'" , "'Henning Schulzrinne'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net><001d01c9885b$d5d705d0$49b5b70a@nsnintra.net><001f01c98860$910658c0$49b5b70a@nsnintra.net><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$49b5b70a@nsnintra.net><1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$49b5b70a@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <007401c988fe$15e06cf0$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499BC21@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Sun, 8 Feb 2009 11:23:55 +0200 Message-ID: <004601c989ce$f932e3e0$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67499BC21@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Thread-Index: AcmIcEMWynRMTvqBQWy4A3ghfLDfOQAALFXwAAXxMbAAAz+/JgAIprowABE/KKAAIrWZwAARrSHw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 09:23:13 -0000 Hi Keith, it seems that further arguments from my side will not help to convince you. That happens. Ciao Hannes >-----Original Message----- >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 08 February, 2009 02:59 >To: Hannes Tschofenig; 'Winterbottom, James'; 'Brian Rosen'; >'Henning Schulzrinne' >Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >Subject: RE: [Ecrit] RPH > >We go round and round in circles. > >We had this discussion on the mail list before the last IETF meeting. > >Different headers have different semantics. The service urn >appears in a part of the SIP message where RFC 3261 defines >exactly the semantics it has. Those appearances have nothing >to do with the semantics of a resource priority header. > >regards > >Keith > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, February 07, 2009 8:29 AM >> To: DRAGE, Keith (Keith); 'Winterbottom, James'; 'Brian Rosen'; >> 'Henning Schulzrinne' >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >> Subject: RE: [Ecrit] RPH >> >> What do you think is the semantic of the Service URN (or the >> respective dial string)? >> Emergency call with special processing needed? Do everything so that >> the call gets through? >> >> How often do you want to say that the call is really >important to you? >> >> We could invent a few more headers say "Yes, it is really important. >> Believe me -- really, really important. Also add location >because that >> it could be needed to locate me.". See my other mail where I >invented >> such a new header that from a philosophical point of view >(not from a >> practical) makes a lot of sense. >> >> Code just needs to know it is important and can do all the necessary >> steps. >> I doubt that someone would write code that does not treat the >> emergency call as less important when an emergency call >comes in that >> does not have the ECRIT RPH header present. Would you think so? >> >> Ciao >> Hannes >> >> >-----Original Message----- >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> >Sent: 07 February, 2009 02:15 >> >To: Winterbottom, James; Hannes Tschofenig; Brian Rosen; Henning >> >Schulzrinne >> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> >Subject: RE: [Ecrit] RPH >> > >> >It is a valid header for that usage. It carries exactly the >> semantics >> >the user wishes to convey, i.e. that the requestor would >> like the call >> >to be treated in processing by the network in a manner >> appropriate to >> >emergency calls. >> > >> >Yes the edge proxy may well review and make up its own mind, >> and either >> >remove, verify or pass on the header, but that does not mean it is >> >wrong from the UE. >> > >> >You might just as well argue that the UE should not inserted a >> >P-Preferred-ID if it knows that the value it contains will >> be the one >> >inserted by the edge proxy. >> > >> >regards >> > >> >Keith >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >> Of Winterbottom, James >> >> Sent: Friday, February 06, 2009 8:02 PM >> >> To: Hannes Tschofenig; Brian Rosen; Henning Schulzrinne >> >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> >> Subject: Re: [Ecrit] RPH >> >> >> >> Hi All, >> >> >> >> I have followed thi thread with some interest and I >> >struggling to see >> >> a use case for the providing RPH for emergency calls from the >> >> end-point. >> >> >> >> The reference-model call in ECRIT, for better or worse, >is for all >> >> calls to go back through a home-VSP. >> >> We placed quite a lot of emphasis, largely for traffing >> reasons, for >> >> the VSP to be able to verify that a call is in fact an >> >emergency call. >> >> This is done by the proxy taking the inband location, >doing a LoST >> >> query with the provided URN, and verifying that the resulting >> >> destination URI is the same as the destination URI provide >> >in the SIP >> >> INVITE. My understanding was that VSPs would always do >> this check so >> >> they could tell if they could bill for the call or not, >> and because >> >> the VSP can be use that the call is an emergency call it can >> >apply any >> >> special priorities that may be applicable. >> >> This obviates the need for RPH from the end-point to the network. >> >> >> >> This leaves us with the argument of "it doesn't hurt to it", >> >which is >> >> not a good reason to write a specification. >> >> It was intimated on the geopriv mailing list last year that great >> >> pains had been taken to keep SIP with in the MTU limits of >> UDP over >> >> Ethernet >> >> (http://www.ietf.org/mail-archive/web/geopriv/current/msg06120 >> >> .html). Assuming that this is the case, perhaps there is harm in >> >> including information that we know will be ignored. >> >> >> >> Cheers >> >> James >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig >> >> Sent: Fri 2/6/2009 12:33 PM >> >> To: 'Brian Rosen'; 'Henning Schulzrinne' >> >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >> >> Subject: Re: [Ecrit] RPH >> >> >> >> To the story short here is the code for the proxy: >> >> >> >> --------------------- >> >> >> >> IF emergency call was recognized THEN >> >> execute emergency call specific procedures (priority queuing, >> >> preemption, fetch location, determine routing, do funny >> QoS things & >> >> co) ELSE >> >> normal call handling procedures. >> >> >> >> --------------------- >> >> >> >> If you can make this differentiation between an emergency >> call and a >> >> regular call then you can also do everything that is >necessary for >> >> emergency call handling. >> >> >> >> Brian + Keith: Please tell me that we cannot do the above >with our >> >> currently specified mechanisms. >> >> >> >> Ciao >> >> Hannes >> >> >> >> >-----Original Message----- >> >> >From: Brian Rosen [mailto:br@brianrosen.net] >> >> >Sent: 06 February, 2009 17:49 >> >> >To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >> >> >Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >> >Subject: RE: [Ecrit] RPH >> >> > >> >> >I agree that not all networks will permit (or pay attention >> >> >to) a priority request from an end device. >> >> > >> >> >No one has asked for that. >> >> > >> >> >The namespace request has several uses, one of which is >within an >> >> >emergency services IP network, one of which is between >> >> elements within >> >> >a public network controlled by the operator, and one of >> which is an >> >> >endpoint request for resource priority. >> >> > >> >> >Those of us requesting this work proceed are happy if the >> >> endpoint part >> >> >is simply left as possible (MAY), and, speaking for myself, >> >> having the >> >> >draft discuss the security implications of endpoint marking is >> >> >reasonable. >> >> > >> >> >Having discussed this issue with an implementation team who >> >> worked on >> >> >MLPP systems, I am confident I know what I'm talking about, >> >> but YMMV. >> >> >The fact that you could, if you wanted to, give resource >> >> priority to a >> >> >call you decided, however you decided, was an emergency >> call is an >> >> >implementation decision, and not subject to standardization. >> >> > >> >> >RPH is the IETF standard way for one entity to request resource >> >> >priority of another entity in a SIP system. We're asking for a >> >> >namespace to use that within the domain of emergency calls. >> >> That is, I >> >> >think, a VERY reasonable request. >> >> > >> >> >Brian >> >> > >> >> >> -----Original Message----- >> >> >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >> >> Sent: Friday, February 06, 2009 10:33 AM >> >> >> To: Hannes Tschofenig >> >> >> Cc: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> >> >> Subject: Re: [Ecrit] RPH >> >> >> >> >> >> To chime in here: >> >> >> >> >> >> I don't think it's productive to simply state that 4412 >> >> >doesn't worry >> >> >> about authorization, so we shouldn't either >(simplifying a bit). >> >> >> Authorization was discussed repeatedly, and the general >> >> >assumption was >> >> >> that there were two conditions: Either the user invoking >> >resource- >> >> >> priority was well known and had a set of permissions that >> >could be >> >> >> checked in real time or there are ways to deal with abuse >> >> after the >> >> >> fact in ways that deter abuse (the court-martial kind of >> >> thing in a >> >> >> military context). >> >> >> >> >> >> The RFC 4412 security consideration (11.2) call this out >> >in pretty >> >> >> strong language: >> >> >> >> >> >> Prioritized access to network and end-system >resources imposes >> >> >> particularly stringent requirements on authentication and >> >> >> authorization mechanisms, since access to prioritized >> >> >resources may >> >> >> impact overall system stability and performance and not >> >> >just result >> >> >> in theft of, say, a single phone call. >> >> >> Thus, the question is whether we have such strong >> >> authentication in >> >> >> emergency calling. In some cases, such as residential >> fixed line >> >> >> deployments where ISP = VSP, we're probably pretty close, >> >> in others, >> >> >> such as prepaid cell phones or hot spots or VSP-only >> >providers, we >> >> >> aren't. >> >> >> >> >> >> The other point that I think Hannes is making is that the >> >> >information >> >> >> is either redundant or dangerous. If a processing element >> >> recognizes >> >> >> the call as being an emergency call, it can apply whatever >> >> treatment >> >> >> it deems appropriate and doesn't need additional >> >> information. If it >> >> >> doesn't or can't, using just the RPH can be rather >> >> dangerous unless >> >> >> that element can be reasonably certain that there is strong >> >> >> authentication and recourse. >> >> >> >> >> >> I don't buy the argument that somehow finding the RPH is >> >> faster than >> >> >> just looking for the identifier. Thus, given that the >> >> information is >> >> >> either redundant or dangerous, I fail to see the advantage. >> >> >> >> >> >> Henning >> >> >> >> >> >> >> >> >> On Feb 6, 2009, at 10:20 AM, Hannes Tschofenig wrote: >> >> >> >> >> >> > Don't get hung up on the details. There are ways to >> optimize it. >> >> >> > That was >> >> >> > not the point of the code example. >> >> >> > >> >> >> > The problem that my pseudo code should have shown you >> >is that you >> >> >> > * don't gain anything with RPH marking for the emergency >> >> call case >> >> >> > from the SIP UA towards the outbound proxy since the >> >> functionality >> >> >> > is already provide otherwise. How often does the proxy >> >> need to get >> >> >> > told that this is an emergency call todo whatever >> >emergency call >> >> >> > handling procedures are necessary? >> >> >> > * you only introduce fraud problems (if you are not >> >> >careful and you >> >> >> > understand the security stuff well enough) >> >> >> > >> >> >> > If you can point me to people who implement the RPH >> >> emergency call >> >> >> > case please do so. I would love to talk to them. >> >> >> > >> >> >> > Ciao >> >> >> > Hannes >> >> >> > >> >> >> > PS: You need to parse incoming messages to some extend >> >> so that you >> >> >> > know what it contains :-) Only looking for the emergency >> >> >RPH header >> >> >> > (and not for the Service URN/dial >> >> >> > string) would exactly be the DoS/fraud attack I am >> >worried about. >> >> >> > That's the thing Henning was worried about (go and >> >listen to the >> >> >> > past meeting minutes). >> >> >> > >> >> >> > >> >> >> >> Hannes >> >> >> >> >> >> >> >> You need to talk to people who really implement this kind >> >> >of thing. >> >> >> >> You are way off. >> >> >> >> >> >> >> >> When you implement a resource priority system, the >> >> point of doing >> >> >> >> that is to look though the queue of work and pick out the >> >> >ones with >> >> >> >> priority, handling them first. You don't do all the >> >> parsing, you >> >> >> >> don't do a lot of decision tree. >> >> >> >> >> >> >> >> Typically: >> >> >> >> Check for DoS things, like too big messages, etc Do a >> >> quick scan >> >> >> >> for the RPH message header If found: >> >> >> >> Parse the message >> >> >> >> Determine validity >> >> >> >> Determine priority >> >> >> >> Queue on the correct work queue >> >> >> >> >> >> >> >> The first two actions have to be very fast. Anyone who >> >> builds a >> >> >> >> SIP thingie will tell you that parsing is one of the >> big cycle >> >> >> >> consumers: if you have to parse every message BEFORE you >> >> >determine >> >> >> >> priority, you can't give much resource priority. >> >> >> >> Once you get the whole message parsed, you might as >> >well finish >> >> >> >> working on it, because you've done so much of the work. >> >> >> >> OTHOH, finding the end-of-message delimiter and >> doing a quick >> >> >> >> string search for RPH is fast. If you are doing >> >> >priority, you need >> >> >> >> to keep all the priority processing pretty uniform, >> and pretty >> >> >> >> simple, or you tend to spend too much time futzing around >> >> >figuring >> >> >> >> out what to do. You put all the priority related stuff >> >> together, >> >> >> >> and use as much common code as possible. >> >> >> >> >> >> >> >> Brian >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >> >>> From: ecrit-bounces@ietf.org >[mailto:ecrit-bounces@ietf.org] >> >> >> >> On Behalf >> >> >> >>> Of Hannes Tschofenig >> >> >> >>> Sent: Friday, February 06, 2009 8:41 AM >> >> >> >>> To: 'Hannes Tschofenig'; 'Janet P Gunn' >> >> >> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'; ecrit- >> >> >> >>> bounces@ietf.org >> >> >> >>> Subject: [Ecrit] RPH >> >> >> >>> >> >> >> >>> Over lunch I was also thinking how an outbound proxy would >> >> >> implement >> >> >> >>> some of the emergency procedures. Here are some thoughts: >> >> >> >>> >> >> >> >>> --------------------------------------------------- >> >> >> >>> >> >> >> >>> // Process incoming message >> >> >> >>> Parse(msg); >> >> >> >>> >> >> >> >>> // SIP INVITE without Service URN // legacy devices If >> >> >> >>> (recognize-dialstring(msg)==TRUE) { // we got an >> >> emergency call >> >> >> >>> going on emergency=TRUE; if (dialstring(msg) == 911) >> >> >> >>> serviceURN=urn:service:sos; } else if >> >> >> >>> (recognize-serviceURN(msg)==TRUE) { // oh. A updated >> >> >device that >> >> >> >>> has a service URN attached to the >> >> >> call >> >> >> >>> serviceURN=retrieve_ServiceURN(msg); >> >> >> >>> emergency=TRUE; >> >> >> >>> } else { >> >> >> >>> // standard SIP message >> >> >> >>> // regular processing >> >> >> >>> process(msg); >> >> >> >>> emergency=FALSE; >> >> >> >>> } >> >> >> >>> >> >> >> >>> If (emergency == TRUE) { >> >> >> >>> // make sure that the emergency call does not get >> >> >dropped on the >> >> >> >>> floor >> >> >> >>> // skip authorization failures >> >> >> >>> // give the call a special treatment >> >> >> >>> lots-of-code-here(); >> >> >> >>> >> >> >> >>> // trigger all the QoS signaling you have in the >> >> >network to make >> >> >> >>> James happy >> >> >> >>> trigger-qos(); >> >> >> >>> >> >> >> >>> // query location >> >> >> >>> location=retrieve-location(); >> >> >> >>> >> >> >> >>> // determine next hop >> >> >> >>> next-hop=lost(location, serviceURN) >> >> >> >>> >> >> >> >>> // attach RPH marking to outgoing msg to make James and >> >> >> >> Keith happy >> >> >> >>> msg=add(msg, RPH); >> >> >> >>> >> >> >> >>> send(msg, next-hop); >> >> >> >>> } >> >> >> >>> >> >> >> >>> If ((rph-present(msg) == TRUE) && (emergency == TRUE)) { >> >> >> >>> // all the emergency related processing done >> already upfront >> >> >> >>> // hence I log something. >> >> >> >>> log(RPH_WAS_PRESENT_JUHU); } else if >((rph-present(msg) == >> >> >> >>> TRUE) && (emergency == >> >> >FALSE)) { >> >> >> >>> // this is not an emergency call // this is something >> >> >like GETS >> >> >> >>> result=special-authorization-procedure(user); >> >> >> >>> >> >> >> >>> if (result == AUTHORIZED) { >> >> >> >>> // do some priority & preemption thing here. >> >> >> >>> // trigger all the QoS you have >> >> >> >>> lots-of-code-here(); >> >> >> >>> } else { >> >> >> >>> log("NOT AUTHORIZED; don't DoS my network"); } } >> >> else { // >> >> >> >>> don't need todo any RPH processing // this >> includes the case >> >> >> >>> where the call was an emergency call but the RPH >> >> >> >>> >> >> >> >>> // marking was not there. >> >> >> >>> nothing(); >> >> >> >>> } >> >> >> >>> >> >> >> >>> --------------------------------------------------- >> >> >> >>> >> >> >> >>> >> >> >> >>> Ciao >> >> >> >>> Hannes >> >> >> >>> >> >> >> >>>> -----Original Message----- >> >> >> >>>> From: ecrit-bounces@ietf.org >> >> [mailto:ecrit-bounces@ietf.org] On >> >> >> >>>> Behalf Of Hannes Tschofenig >> >> >> >>>> Sent: 06 February, 2009 15:07 >> >> >> >>>> To: 'Janet P Gunn' >> >> >> >>>> Cc: 'ECRIT'; ecrit-bounces@ietf.org; >> Tschofenig,Hannes (NSN - >> >> >> >>> FI/Espoo) >> >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: >> >> Agenda (RPH) >> >> >> >>>> >> >> >> >>>> Who would define something that could prevent DoS >problems? >> >> >> >>>> >> >> >> >>>> ________________________________ >> >> >> >>>> >> >> >> >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >> >> >> >>>> Sent: 06 February, 2009 14:11 >> >> >> >>>> To: Hannes Tschofenig >> >> >> >>>> Cc: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; 'ECRIT'; >> >> >> >>>> ecrit-bounces@ietf.org; Tschofenig, Hannes (NSN - >> FI/Espoo); >> >> >> 'James >> >> >> >>>> M. Polk' >> >> >> >>>> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >> >Meeting: Agenda (RPH) >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> But there is nothing IN RFC4412 that specifically >> >> >> >> addresses how to >> >> >> >>>> prevent any particular namespace being used for DoS. >> >> Anyone/any >> >> >> UA >> >> >> >>>> can ATTEMPT to invoke priority treatment by attaching >> >> RPH. For >> >> >> all >> >> >> >>>> of the 4412 namespaces, as with the new proposed >> >> namespace, the >> >> >> >>>> mechanisms for preventing DoS are not specified in the >> >> >> >> document that >> >> >> >>>> defines the namespace. >> >> >> >>>> They are/will be specified elsewhere. >> >> >> >>>> >> >> >> >>>> Janet >> >> >> >>>> >> >> >> >>>> This is a PRIVATE message. If you are not >> the intended >> >> >> >> recipient, >> >> >> >>>> please delete without copying and kindly advise us by >> >> e-mail of >> >> >> the >> >> >> >>>> mistake in delivery. >> >> >> >>>> NOTE: Regardless of content, this e-mail shall not >> >> >> >> operate to bind >> >> >> >>>> CSC to any order or other contract unless pursuant to >> >> explicit >> >> >> >>>> written agreement or government initiative expressly >> >> permitting >> >> >> the >> >> >> >>>> use of e-mail for such purpose. >> >> >> >>>> >> >> >> >>>> ecrit-bounces@ietf.org wrote on 02/06/2009 >> 04:21:51 AM: >> >> >> >>>> >> >> >> >>>> > Hi James, >> >> >> >>>> > >> >> >> >>>> > I have read RFC 4412 and also the GETS/MLPP IETF >> >> >> >> documents. What I >> >> >> >>>> would >> >> >> >>>> > like to point out is that there is more >than just a >> >> >> >> header and >> >> >> >>>> values within >> >> >> >>>> > the header that have to be considered in order to >> >> >> >> make a judgement >> >> >> >>>> of what >> >> >> >>>> > is appropriate and what isn't. There is an >> >> >> >> architectural question >> >> >> >>>> and >> >> >> >>>> > whether the environment we are using the stuff is >> >> >> >> indeed providing >> >> >> >>>> the >> >> >> >>>> > properties you need for the solution to be >> >> >appropriate. >> >> >> >>>> > >> >> >> >>>> > Let me describe in more detail what I meant (and >> >> >> >> please correct me >> >> >> >>>> if I am >> >> >> >>>> > wrong). >> >> >> >>>> > >> >> >> >>>> > Getting priority for SIP requests when >using a GETS >> >> >> >> alike scenario >> >> >> >>>> means >> >> >> >>>> > that the entity that issues the request is >> specially >> >> >> >> authorized >> >> >> >>>> since >> >> >> >>>> > otherwise you introduce a nice denial of >> >> >service attack. This >> >> >> >>>> authorization >> >> >> >>>> > is tied to the entity that makes the request. For >> >> >> >> example, the >> >> >> >>>> person is >> >> >> >>>> > working for the government and has special rights. >> >> >> >>>> James Bond as a (not so) >> >> >> >>>> > secret agent might have these rights. >> >> >> >>>> > >> >> >> >>>> > The emergency services case >> >> >(citizen-to-authority) is a bit >> >> >> >>>> different as >> >> >> >>>> > there aren't really special rights with respect to >> >> >> >> authorization >> >> >> >>>> tied to >> >> >> >>>> > individuals. Instead, the fact that >something is an >> >> >> >> emergency is >> >> >> >>>> purely a >> >> >> >>>> > judgement of the human that dials a >special number. >> >> >> >>>> To deal with fraud, we >> >> >> >>>> > discussed in the group on what we can >> actually do to >> >> >> >> ensure that >> >> >> >>>> end users >> >> >> >>>> > do not bypass security procedures (such as >> >> >> >> authorization checks, >> >> >> >>>> charging >> >> >> >>>> > and so on). Part of this investigation was >> >> >the publication of >> >> >> >>>> > http://www.ietf.org/rfc/rfc5069.txt that also >> >> >describes this >> >> >> >>>> issue. >> >> >> >>>> > >> >> >> >>>> > So, imagine the implementation of a SIP >> proxy (and we >> >> >> >> implemented >> >> >> >>>> that >> >> >> >>>> > stuff) that receives a call that contains >a Service >> >> >> >> URN. The code >> >> >> >>>> branches >> >> >> >>>> > into a special mode where everything is done >> >> >so that the call >> >> >> >>>> receives >> >> >> >>>> > appropriate treatment and does not get >> dropped on the >> >> >> >> floor. The >> >> >> >>>> way how the >> >> >> >>>> > Service URN is placed in the message >> ensures that the >> >> >> >> call cannot >> >> >> >>>> go to my >> >> >> >>>> > friend (instead of the PSAP) unless the >> end host ran >> >> >> >> LoST already. >> >> >> >>>> In the >> >> >> >>>> > latter case, we discussed this also on the >> list for a >> >> >> >> while and >> >> >> >>>> Richard even >> >> >> >>>> > wrote a draft about it in the context of the >> >> >location hiding >> >> >> >>>> topic, we said >> >> >> >>>> > that the proxy would have to run LoST if he >> >> >cares about a >> >> >> >>>> potential >> >> >> >>>> > fraudulent usage. >> >> >> >>>> > >> >> >> >>>> > So, what do we need todo in order to provide >> >> >secure RFC 4412 >> >> >> >>>> functionality >> >> >> >>>> > in our context? >> >> >> >>>> > >> >> >> >>>> > Do you think that the current text in >> >> >> >>>> > >> >> >> >>>> >> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >> >> >>>> gency-rph-nam >> >> >> >>>> > espace-00.txt reflects any of the >> >> >above-described issues: >> >> >> >>>> > " >> >> >> >>>> > The Security considerations that apply >> to RFC 4412 >> >> >> >>>> [RFC4412] >> >> >> >>>> apply >> >> >> >>>> > here. This document introduces no new security >> >> >> >>>> issues relative >> >> >> >>>> to >> >> >> >>>> > RFC 4412. >> >> >> >>>> > " >> >> >> >>>> > >> >> >> >>>> > From various discussions in GEOPRIV I recall >> >> >that you are >> >> >> >>>> super-sensitive >> >> >> >>>> > regarding security and privacy. For some >> reasons you >> >> >> >> don't seem to >> >> >> >>>> have the >> >> >> >>>> > same concerns here. I would like to >> >> >understand your reasoning. >> >> >> >>>> > >> >> >> >>>> > Please also do me another favor: Don't always say >> >> >> >> that I don't >> >> >> >>>> understand >> >> >> >>>> > the subject. Even if that would be the >> case it isn't >> >> >> >> particular >> >> >> >>>> fair given >> >> >> >>>> > that different folks had to educate you on other >> >> >> >> topics in the >> >> >> >>>> past as well. >> >> >> >>>> > Additionally, if you listen to the audio >recordings >> >> >> >> then you will >> >> >> >>>> notice >> >> >> >>>> > that Henning, Ted, and Jon do not seem to >> understand >> >> >> >> the issue >> >> >> >>>> either as >> >> >> >>>> > they have raised similar issues during the >> >> >F2F meetings. >> >> >> >>>> > >> >> >> >>>> > Ciao >> >> >> >>>> > Hannes >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> > >Hannes - I believe it is you who do not >understand >> >> >> >> RFC 4412 -- >> >> >> >>>> > >and many of us are trying to get that >> >> >through to you, but you >> >> >> >>>> > >don't seem to want to listen/read. >> >> >> >>>> > > >> >> >> >>>> > >RFC 4412 is *for* priority marking SIP requests, >> >> >> >>>> > > >> >> >> >>>> > >One use is GETS. >> >> >> >>>> > > >> >> >> >>>> > >One use is MLPP. >> >> >> >>>> > > >> >> >> >>>> > >These examples are in RFC 4412 because there >> >> >were specific >> >> >> >>>> > >namespaces being created for the IANA section of >> >> >> >> that document. >> >> >> >>>> > > >> >> >> >>>> > >Reading the whole document, you will see >> >> >that RPH can be >> >> >> >>>> > >specified for other uses than GETS or MLPP >> >> >specifically. >> >> >> >>>> > > >> >> >> >>>> > >I knew when I wrote RFC 4412 that one day we >> >> >would specify a >> >> >> >>>> > >namespace for ECRIT (the "esnet" namespace >> >> >now) -- but I also >> >> >> >>>> > >knew it was premature for RFC 4412 to >> >> >incorporate that >> >> >> >>>> > >namespace, that a future doc to RFC 4412 >> >> >would have to be >> >> >> >>>> > >written to do this. Brian and I talked about >> >> >this at the >> >> >> >>>> > >original NENA meeting that created the IP >> WGs there >> >> >> >> (in August >> >> >> >>>> > >of 03). We both agreed we should wait >> until it was >> >> >> >>>> > >appropriate to the work in the IETF to >> >> >submit this document >> >> >> >>>> > >that is now >> >> >> >>>> > >> >> >> >>>>> >> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >> >> >> >>>> > >gency-rph-namespace-00.txt >> >> >> >>>> > > >> >> >> >>>> > >Yet, you seem to want to use some additional >> >> >mechanism to >> >> >> >>>> > >indicate priority of a call in SIP. That >> >> >means you want to >> >> >> >>>> > >introduce a second way to accomplish this in SIP. >> >> >> >>>> Why do you >> >> >> >>>> > >want to promote a separate way to do >something SIP >> >> >> >> has already >> >> >> >>>> > >defined? That will cause interoperability >> issues and >> >> >> >> we both know >> >> >> >>>> that. >> >> >> >>>> > > >> >> >> >>>> > >You've said to me (and others) that you >> >> >believe RPH is just >> >> >> >>>> > >another way to accomplish what sos or a URI can >> >> >> >> indicate - and >> >> >> >>>> > >you're wrong. Your way would be >> >> >_the_second_way_to_do_it, >> >> >> >>>> > >because SIP already considers RPH to be >> >> >*the*way* to priority >> >> >> >>>> > >mark SIP requests. >> >> >> >>>> > > >> >> >> >>>> > >If you don't believe me (no comment), then >> >> >why do you not >> >> >> >>>> > >believe the SIP WG chair (who knows more >> >> >about SIP than both >> >> >> >>>> > >of us) - who, on this thread, has again said >> >> >to you "RFC 4412 >> >> >> >>>> > >(RPH) is the SIP mechanism to priority mark >> >> >SIP requests"? >> >> >> >>>> > > >> >> >> >>>> > >Further, I believe it is inappropriate to >> >> >prohibit endpoints >> >> >> >>>> > >from being able to set the esnet namespace. >> >> >I absolutely >> >> >> >>>> > >believe it will not be needed most of the >> >> >time, but I believe >> >> >> >>>> > >if someone does find a valid use for >> >> >endpoints to mark >> >> >> >>>> > >priority in SIP, this ID - once it has >> >> >become an RFC -- will >> >> >> >>>> > >have to be obsoleted with a new RFC >> saying the exact >> >> >> >> opposite. >> >> >> >>>> > > >> >> >> >>>> > >(color me confused ... over and over again) >> >> >> >>>> > > >> >> >> >>>> > >James >> >> >> >>>> > > >> >> >> >>>> > >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: >> >> >> >>>> > >>Keith, please understand that the usage >> of RFC 4412 >> >> >> >> for GETS and >> >> >> >>>> for >> >> >> >>>> > >>the type of emergency call we discuss here is >> >> >> >> different. Just >> >> >> >>>> looking >> >> >> >>>> > >>at the header and the name of the >> >namespace is a bit >> >> >> >>>> > >artificial. I hope >> >> >> >>>> > >>you understand that. >> >> >> >>>> > >> >> >> >> >>>> > >> >-----Original Message----- >> >> >> >>>> > >> >From: DRAGE, Keith (Keith) >> >> >> >>>> [mailto:drage@alcatel-lucent.com] >> >> >> >>>> > >> >Sent: 05 February, 2009 14:55 >> >> >> >>>> > >> >To: Brian Rosen; 'Hannes Tschofenig'; >'James M. >> >> >> >>>> Polk'; 'Tschofenig, >> >> >> >>>> > >> >Hannes (NSN - FI/Espoo)'; 'ECRIT' >> >> >> >>>> > >> >Subject: RE: [Ecrit] ECRIT Virtual Interim >> >> >> >>>> Meeting: Agenda (my >> >> >> >>>> >> >> >> >>>> > >> >mistake) >> >> >> >>>> > >> > >> >> >> >>>> > >> >Which is exactly what RFC 4412 >> specifies for all >> >> >> >> namespaces. >> >> >> >>>> > >> > >> >> >> >>>> > >> >regards >> >> >> >>>> > >> > >> >> >> >>>> > >> >Keith >> >> >> >>>> > >> > >> >> >> >>>> > >> >> -----Original Message----- >> >> >> >>>> > >> >> From: ecrit-bounces@ietf.org >> >> >> >> [mailto:ecrit-bounces@ietf.org] >> >> >> >>>> > >> >On Behalf >> >> >> >>>> > >> >> Of Brian Rosen >> >> >> >>>> > >> >> Sent: Wednesday, February 04, 2009 10:19 PM >> >> >> >>>> > >> >> To: 'Hannes Tschofenig'; 'James M. >> >> >Polk'; 'Tschofenig, >> >> >> >>>> > >Hannes (NSN >> >> >> >>>> > >> >> - FI/Espoo)'; 'ECRIT' >> >> >> >>>> > >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim >> >> >> >>>> Meeting: Agenda (my >> >> >> >>>> > >> >> mistake) >> >> >> >>>> > >> >> >> >> >> >>>> > >> >> The value is that in some networks >> >> >where priority for >> >> >> >>>> > >> >emergency calls >> >> >> >>>> > >> >> is appropriate, and appropriate >> >> >policing of marking is >> >> >> >>>> > >implemented, >> >> >> >>>> > >> >> emergency calls will receive >> resource priority. >> >> >> >>>> > >> >> >> >> >> >>>> > >> >> Not all networks would need policing. Some >> >> >> >> will. Policing >> >> >> >>>> could >> >> >> >>>> > >> >> be to Route header/R-URI content, but other >> >> >> >> criteria are >> >> >> >>>> possible. >> >> >> >>>> > >> >> >> >> >> >>>> > >> >> Not all networks will need resource priority >> >> >> >> for emergency >> >> >> >>>> calls. >> >> >> >>>> > >> >> Fine, ignore this marking/namespace. >> >> >> >>>> > >> >> >> >> >> >>>> > >> >> Brian >> >> >> >>>> > >> >> > -----Original Message----- >> >> >> >>>> > >> >> > From: Hannes Tschofenig >> >> >> >>>> [mailto:Hannes.Tschofenig@gmx.net] >> >> >> >>>> > >> >> > Sent: Wednesday, February 04, 2009 5:09 PM >> >> >> >>>> > >> >> > To: 'Brian Rosen'; 'James M. Polk'; >> >> >> >> Tschofenig, Hannes >> >> >> >>>> (NSN - >> >> >> >>>> > >> >> > FI/Espoo); 'ECRIT' >> >> >> >>>> > >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim >> >> >> >>>> Meeting: Agenda (my >> >> >> >>>> > >> >> > mistake) >> >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > I don't even see the value in >> permitting the >> >> >> >> endpoint todo >> >> >> >>>> the >> >> >> >>>> > >> >> > RPH marking. >> >> >> >>>> > >> >> > In addition to the security concerns >> >> >there is also the >> >> >> >>>> > >> >problem that >> >> >> >>>> > >> >> > there are more options to >implement without >> >> >> >> an additional >> >> >> >>>> value. >> >> >> >>>> > >> >> > >> >> >> >>>> > >> >> > >-----Original Message----- >> >> >> >>>> > >> >> > >From: Brian Rosen >> [mailto:br@brianrosen.net] >> >> >> >>>> > >> >> > >Sent: 05 February, 2009 00:03 >> >> >> >>>> > >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; >> >> >> >> 'Tschofenig, >> >> >> >>>> > >> >> Hannes (NSN - >> >> >> >>>> > >> >> > >FI/Espoo)'; 'ECRIT' >> >> >> >>>> > >> >> > >Subject: RE: [Ecrit] ECRIT Virtual >> >> >Interim Meeting: >> >> >> >>>> Agenda (my >> >> >> >>>> > >> >> > mistake) >> >> >> >>>> > >> >> > > >> >> >> >>>> > >> >> > >Hannes >> >> >> >>>> > >> >> > > >> >> >> >>>> > >> >> > >This matches my understanding >> >> >precisely. We wish to >> >> >> >>>> > >> >> permit endpoints >> >> >> >>>> > >> >> > >to mark. We do not require it, and >> >> >don't necessarily >> >> >> >>>> expect it >> >> >> >>>> > >> >> > >in many (even >> >> >> >>>> > >> >> > >most) cases. We don't wish to see the >> >> >> >> document prohibit >> >> >> >>>> it. >> >> >> >>>> > >> >> > >We all seem to agree it has value >> within the >> >> >> >> Emergency >> >> >> >>>> > >> >Services IP >> >> >> >>>> > >> >> > >Networks. >> >> >> >>>> > >> >> > > >> >> >> >>>> > >> >> > >Brian >> >> >> >>>> > >> >> > > >> >> >> >>>> > >> >> > >> -----Original Message----- >> >> >> >>>> > >> >> > >> From: ecrit-bounces@ietf.org >> >> >> >>>> [mailto:ecrit-bounces@ietf.org] >> >> >> >>>> > >> >> > >On Behalf >> >> >> >>>> > >> >> > >> Of James M. Polk >> >> >> >>>> > >> >> > >> Sent: Wednesday, February 04, >> 2009 4:01 PM >> >> >> >>>> > >> >> > >> To: Hannes Tschofenig; Tschofenig, >> >> >Hannes (NSN - >> >> >> >>>> > >> >> FI/Espoo); 'ECRIT' >> >> >> >>>> > >> >> > >> Subject: Re: [Ecrit] ECRIT >> Virtual Interim >> >> >> >>>> Meeting: >> >> >> >>>> > >Agenda (my >> >> >> >>>> > >> >> > >> mistake) >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> At 02:37 PM 2/4/2009, Hannes >> >> >Tschofenig wrote: >> >> >> >>>> > >> >> > >> > > James wrote: >> >> >> >>>> > >> >> > >> > >> you are the _lone_ voice not >> >> >> >> supporting this ID, >> >> >> >>>> > >> >> > >> > >> >> >> >>>> > >> >> > >> >Listening to the audio >> recording of past >> >> >> >> meetings I >> >> >> >>>> have to >> >> >> >>>> > >> >> > >say that >> >> >> >>>> > >> >> > >> >I >> >> >> >>>> > >> >> > >> was >> >> >> >>>> > >> >> > >> >not the only persons raising >> >> >concerns about the >> >> >> >>>> document. >> >> >> >>>> > >> >> > >> >That was probably the reason why you >> >> >> >> agreed to limit >> >> >> >>>> the >> >> >> >>>> > >> >> > >scope of the >> >> >> >>>> > >> >> > >> >document (which you didn't >later do) to >> >> >> >> get folks to >> >> >> >>>> agree >> >> >> >>>> > >> >> > >to make it >> >> >> >>>> > >> >> > >> a WG >> >> >> >>>> > >> >> > >> >item. >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> re-listen to the audio please >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> Ted's concerns were consistent >with most >> >> >> >>>> (all?) other >> >> >> >>>> > >> >> concerns -- >> >> >> >>>> > >> >> > >> which were based on the premise >> of whether >> >> >> >> or not the >> >> >> >>>> > >> >> UAC should be >> >> >> >>>> > >> >> > >> trusted to initiate the marking on the >> >> >> >> INVITE. The >> >> >> >>>> most >> >> >> >>>> > >> >> > >> recent version has backed off this >> >> >to a "can" -- >> >> >> >>>> meaning not >> >> >> >>>> > >> >prohibited >> >> >> >>>> > >> >> > >> (i.e., no 2119 text). I also >backed off >> >> >> >> the text in >> >> >> >>>> the >> >> >> >>>> > >> >> SP domain >> >> >> >>>> > >> >> > >> part to "can", such that there is >> >> >no 2119 text >> >> >> >>>> > >> >mandating or even >> >> >> >>>> > >> >> > >> recommending its usage there. I also do >> >> >> >> not prohibit >> >> >> >>>> its >> >> >> >>>> > >> >> > >use, based on >> >> >> >>>> > >> >> > >> local policy. Keith has come >> forward with >> >> >> >> the specific >> >> >> >>>> >> >> >> >>>> > >> >> > >> request that non-ESInet networks be >> >> >> >> allowed to mark and >> >> >> >>>> pay >> >> >> >>>> > >> >attention to >> >> >> >>>> > >> >> > >> this priority indication -- with IMS as >> >> >> >> the specific >> >> >> >>>> example >> >> >> >>>> > >> >> > >> he wishes to have this valid for. >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> Where there is no >disagreement, save for >> >> >> >> your recent >> >> >> >>>> > >> >> > >pushback - is in >> >> >> >>>> > >> >> > >> the ESInet, which is where Brian >> >> >has requested it's >> >> >> >>>> > >> >> > >definition in the >> >> >> >>>> > >> >> > >> IETF on behalf of NENA. He's the i3 WG >> >> >> >> chair within >> >> >> >>>> > >> >> NENA, and if >> >> >> >>>> > >> >> > >> he asks for it, are you going >to say you >> >> >> >> know better >> >> >> >>>> than he? >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> >Btw, I not disagreeing with >> the document >> >> >> >> as such. I >> >> >> >>>> > >> >just want to >> >> >> >>>> > >> >> > the >> >> >> >>>> > >> >> > >> scope >> >> >> >>>> > >> >> > >> >to change. The usage of RPH >> >> >within the emergency >> >> >> >>>> > >> >> services network >> >> >> >>>> > >> >> > is >> >> >> >>>> > >> >> > >> fine >> >> >> >>>> > >> >> > >> >for me. I may get convinced to >> start the >> >> >> >> RPH marking >> >> >> >>>> from >> >> >> >>>> > >> >> > >the the VSP >> >> >> >>>> > >> >> > >> >towards the PSAP. I feel >> uneasy about the >> >> >> >> end host >> >> >> >>>> doing >> >> >> >>>> > >> >> > >the marking. >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> please read what I wrote >above, and then >> >> >> >> re-read the >> >> >> >>>> > >> >most recent >> >> >> >>>> > >> >> > >> version of the ID. I don't have >> endpoints >> >> >> >> that SHOULD >> >> >> >>>> or >> >> >> >>>> > >> >> MUST mark >> >> >> >>>> > >> >> > >> anything wrt RPH. I also don't want to >> >> >> >> prohibit it, >> >> >> >>>> > >> >> because there >> >> >> >>>> > >> >> > >> might be cases (that I don't know >> >> >of) of valid uses >> >> >> >>>> > >> >> under certain >> >> >> >>>> > >> >> > >> circumstances. Figure 1 is very clear >> >> >> >> that there are 3 >> >> >> >>>> > >> >> networking >> >> >> >>>> > >> >> > >> parts to consider >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> #1 - from the endpoint >> >> >> >>>> > >> >> > >> #2 - within the VSP >> >> >> >>>> > >> >> > >> #3 - within the ESInet >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> the most recent ID version has >"can" for >> >> >> >> #s 1 and 2, >> >> >> >>>> and >> >> >> >>>> > >> >> > >2119 language >> >> >> >>>> > >> >> > >> offering those supporting this >> >> >> >> specification will have >> >> >> >>>> RPH >> >> >> >>>> > >> >> > >> adherence within #3 (the ESInet). >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> What other scope changes do you want, >> >> >> >> because I haven't >> >> >> >>>> > >> >> heard them. >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> I only heard you claim in email >> during the >> >> >> >> last IETF >> >> >> >>>> and in >> >> >> >>>> > >> >> > >the ECRIT >> >> >> >>>> > >> >> > >> session that RPH should not be >> >> >used for priority >> >> >> >>>> marking >> >> >> >>>> > >> >> requests. >> >> >> >>>> > >> >> > >> This is something Keith (SIP WG >> >> >chair) voiced his >> >> >> >>>> opposition >> >> >> >>>> > >> >> > >> to your views regarding >> creating a second >> >> >> >> means for SIP >> >> >> >>>> to >> >> >> >>>> > >> >priority >> >> >> >>>> > >> >> > >> mark request "when SIP already has one >> >> >> >> interoperable >> >> >> >>>> way to >> >> >> >>>> > >> >> > >> accomplish this... it's call >> the RP header >> >> >> >> mechanism". >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> >I don't see advantages -- only >> >> >disadvantages. >> >> >> >>>> > >> >> > >> > >> >> >> >>>> > >> >> > >> >Ciao >> >> >> >>>> > >> >> > >> >Hannes >> >> >> >>>> > >> >> > >> >> >> >> >>>> > >> >> > >> >> >> >_______________________________________________ >> >> >> >>>> > >> >> > >> Ecrit mailing list >> >> >> >>>> > >> >> > >> Ecrit@ietf.org >> >> >> >>>> > >> >> > >> >> >https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >>>> > >> >> > > >> >> >> >>>> > >> >> >> >> >> >>>> > >> >> >> _______________________________________________ >> >> >> >>>> > >> >> Ecrit mailing list >> >> >> >>>> > >> >> Ecrit@ietf.org >> >> >> >>>> > >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >>>> > >> >> >> >> >> >>>> > >> > >> >> >> >>>> > > >> >> >> >>>> > >> >> >> >>>> > _______________________________________________ >> >> >> >>>> > Ecrit mailing list >> >> >> >>>> > Ecrit@ietf.org >> >> >> >>>> > https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> _______________________________________________ >> >> >> >>>> Ecrit mailing list >> >> >> >>>> Ecrit@ietf.org >> >> >> >>>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >>>> >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> Ecrit mailing list >> >> >> >>> Ecrit@ietf.org >> >> >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Ecrit mailing list >> >> >> > Ecrit@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> >> >> -------------------------------------------------------------- >> >> ---------------------------------- >> >> This message is for the designated recipient only and may contain >> >> privileged, proprietary, or otherwise private information. >> >> If you have received it in error, please notify the sender >> >immediately >> >> and delete the original. Any unauthorized use of this email is >> >> prohibited. >> >> -------------------------------------------------------------- >> >> ---------------------------------- >> >> [mf2] >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > >> >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C643A69D2 for ; Sun, 8 Feb 2009 01:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwPMjYyZkMAk for ; Sun, 8 Feb 2009 01:31:35 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D181D3A69AC for ; Sun, 8 Feb 2009 01:31:34 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2009 09:31:37 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp036) with SMTP; 08 Feb 2009 10:31:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181VLgwbLc1NM0tOBfmvkCZG13qrabthjdA5fIGam 7msnbAnRZDfAWw From: "Hannes Tschofenig" To: "'DOLLY, MARTIN C, ATTLABS'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F6F@gaalpa1msgusr7e.ugd.att.com> Date: Sun, 8 Feb 2009 11:32:25 +0200 Message-ID: <004701c989d0$2781a320$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA01238F6F@gaalpa1msgusr7e.ugd.att.com> Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 09:31:36 -0000 Hi Martin, Your remarks are a bit a short. Clearly, authentication and authorization can come in different forms. This was actually one of the discussion we had so far that the authorization mechanisms for the GETS RPH and the proposed ECRIT RPH is different. So, could you elaborate a bit? Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of DOLLY, MARTIN C, ATTLABS >Sent: 07 February, 2009 19:30 >To: hgs@cs.columbia.edu; jgunn6@csc.com >Cc: ecrit@ietf.org; ecrit-bounces@ietf.org >Subject: Re: [Ecrit] Semantics Re: RPH > >Do you have a clue dude? A+A of an user comes in many forms. > >----- Original Message ----- >From: ecrit-bounces@ietf.org >To: Janet P Gunn >Cc: ECRIT ; ecrit-bounces@ietf.org > >Sent: Sat Feb 07 11:56:42 2009 >Subject: Re: [Ecrit] Semantics Re: RPH > >Please see my earlier message as to why your approach fails >for the UA- inserted case where not all emergency calls have >RPH markings. I think it would be a really bad idea if >emergency calls with RPH are treated differently than >emergency calls without it. (Again, I'm talking about the >user-initiated calls. An ESNET can do whatever it wants and >can assign extra priority to calls from citizens that have >bought PBA stickers or zip codes that pay more taxes, but >that's a separate >problem.) > >I also don't believe your implementation logic. A much better >approach is to semantically declare the class of call early on >(e.g., based on the URN or after >authentication/authorization), and make that part of the call >state record, rather than hunt for headers each time a >handling decision needs to be made. Given the authorization >requirements, just looking at "has header X" is never going to >be sufficient anyway. > >Henning > >On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > >> >> >> . >> >> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: >> >> > PLEASE try to understand that the syntax is similar (header, new >> namespace, >> > new values) >> > BUT the semantic is different. >> > >> > For all message it is true that the sender can add whatever they >> want. The >> > big question is what does it mean for the recipient. >> > >> > This is what the discussion is about. >> > >> On the contrary, the semantic is, or at least can be, very similar. >> >> Consider the hypothetical, but plausible, case of a network with an >> explicit call/capacity admission process, in which both 911-type- >> emergency calls and GETS calls get preferential admission >treatment. >> By the time the INVITE gets to this Functional Module/ block >of code, >> all authentication, authorization, and changes/ confirmation of the >> destination have already taken place. All this block of code deals >> with is call/capacity admission. >> >> For the sake of argument, suppose this is the nature of the >> preference. >> >> 1) For INVITEs without RPH, or with an RPH this network does >not use/ >> understand, if the admission process fails, the INVITE fails >> >> 2) For INVITEs with RPH with the ets namespace, if the admission >> process initially fails, the INVITE is put in queue until the >> resources become available so it can be admitted. >> >> 3) For INVITEs with RPH with the esnet namespace, if the admission >> process initially fails, the INVITE is put in queue, but at lower >> priority than the calls with the ets namespace. >> >> With the esnet namespace, this block of code only needs to deal with >> the RPH in determining which INVITEs to reject, and which to queue, >> and how. >> >> But if there is no esnet namespace for RPH, then this block of code >> would need to deal with BOTH the RPH and the URN. That would be a >> completely unnecessary complication. >> >> Janet > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E313A6870 for ; Sun, 8 Feb 2009 01:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufXr1t2HNzWS for ; Sun, 8 Feb 2009 01:47:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CEEFF3A6782 for ; Sun, 8 Feb 2009 01:47:41 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2009 09:47:41 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp063) with SMTP; 08 Feb 2009 10:47:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wibkcAFGwDUodxaxPCT1dEmLyguhZiLLodmrVet YALu4gRJxBE7A0 From: "Hannes Tschofenig" To: "'Janet P Gunn'" References: <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> Date: Sun, 8 Feb 2009 11:48:28 +0200 Message-ID: <004801c989d2$65eb0b90$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmJQO+/MrC029JNQj+nRmcE91C5+gAjrsqA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 09:47:43 -0000 Hi Janet, thanks for your text. I think I am getting a better understanding of the scenarios you have in mind. Let me comment inline (search for [hannes]): Consider the hypothetical, but plausible, case of a network with an explicit call/capacity admission process, in which both 911-type-emergency calls and GETS calls get preferential admission treatment. By the time the INVITE gets to this Functional Module/ block of code, all authentication, authorization, and changes/confirmation of the destination have already taken place. All this block of code deals with is call/capacity admission. For the sake of argument, suppose this is the nature of the preference. 1) For INVITEs without RPH, or with an RPH this network does not use/understand, if the admission process fails, the INVITE fails [hannes] This is the non-emergency case, I suspect. Section 4.6.2 of RFC 4412 discusses when to fail an INVITE if the RPH marking is not understood. It does not always fail. 2) For INVITEs with RPH with the ets namespace, if the admission process initially fails, the INVITE is put in queue until the resources become available so it can be admitted. 3) For INVITEs with RPH with the esnet namespace, if the admission process initially fails, the INVITE is put in queue, but at lower priority than the calls with the ets namespace. [hannes] Is this an INVITE for an emergecy call? I suspect, yes. What priority is given to the emergency call in relationship to the calls with the ETS namespace is a local policy matter? Or: would you like to put a description of it into draft-ietf-ecrit-local-emergency-rph-namespace-00.txt? What happens with an non-emergency call invite that has the esnet RPH marking? Does it get the emergency call treatement? With the esnet namespace, this block of code only needs to deal with the RPH in determining which INVITEs to reject, and which to queue, and how. [hannes] You talk about rejecting the INVITE: Emergency calls do not get rejected regardless of the RPH marking. But if there is no esnet namespace for RPH, then this block of code would need to deal with BOTH the RPH and the URN. That would be a completely unnecessary complication. [hannes] Are you saying that you wouldn't look at the Service URN / dial string when the esnet RPH namespace is present? I believe I now better understand what you (and maybe James and Keith) want to accomplish. You would like to allow the VSP to have two types of emergency calls: * "normal" emergency calls that would be placed in a queue as they arrive (These are the calls that are only marked as emergency calls using a Service URN or contain a special dial string.) * esnet RPH marked emergency calls that would skip other calls in the queue (if there is a queue and this queue contains non-emergency calls). These calls are sort of better than the "normal" emergency calls. Did I correctly understand it? Is this the scenario you had in mind with the esnet RPH mechanism? If someone would like to create two classes of emergency calls in that fashion then additional marking would be justified. Ciao Hannes Janet Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9743A69C2 for ; Sun, 8 Feb 2009 04:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjLJPG0+wimB for ; Sun, 8 Feb 2009 04:12:21 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 490143A686A for ; Sun, 8 Feb 2009 04:12:21 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1234095143!45432831!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 20064 invoked from network); 8 Feb 2009 12:12:23 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 8 Feb 2009 12:12:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18CCMjU014800; Sun, 8 Feb 2009 07:12:22 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18CCGDO014779; Sun, 8 Feb 2009 07:12:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 8 Feb 2009 07:12:16 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01238F71@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Semantics Re: RPH Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNA== From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:12:22 -0000 SGFubmVzLA0KDQpXZSBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIGF0dGFjaG1lbnQgb2YgdGhlIFVF IHRvIHRoZSBuZXR3b3JrLiBUaGVyZSBpcyBhbiBBQSBwcm9jZXNzIHByaW9yIHRvIGFsbG93aW5n IGFueSB1c2UuIFdpdGhvdXQgdGhpcyB3ZSB3b3VsZCBub3QgdHJ1c3QgdGhlIFJQSCwgZXZlbiBm b3IgRVRTLCBuZXZlciBtaW5kIDkxMQ0KDQpNYXJ0aW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5u ZXQ+DQpUbzogRE9MTFksIE1BUlRJTiBDLCBBVFRMQUJTOyBoZ3NAY3MuY29sdW1iaWEuZWR1IDxo Z3NAY3MuY29sdW1iaWEuZWR1Pjsgamd1bm42QGNzYy5jb20gPGpndW5uNkBjc2MuY29tPg0KQ2M6 IGVjcml0QGlldGYub3JnIDxlY3JpdEBpZXRmLm9yZz4NClNlbnQ6IFN1biBGZWIgMDggMDQ6MzI6 MjUgMjAwOQ0KU3ViamVjdDogUkU6IFtFY3JpdF0gU2VtYW50aWNzICBSZTogIFJQSA0KDQpIaSBN YXJ0aW4sIA0KDQpZb3VyIHJlbWFya3MgYXJlIGEgYml0IGEgc2hvcnQuDQoNCkNsZWFybHksIGF1 dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGNhbiBjb21lIGluIGRpZmZlcmVudCBmb3Jt cy4gDQpUaGlzIHdhcyBhY3R1YWxseSBvbmUgb2YgdGhlIGRpc2N1c3Npb24gd2UgaGFkIHNvIGZh ciB0aGF0IHRoZSBhdXRob3JpemF0aW9uDQptZWNoYW5pc21zIGZvciB0aGUgR0VUUyBSUEggYW5k IHRoZSBwcm9wb3NlZCBFQ1JJVCBSUEggaXMgZGlmZmVyZW50LiANCg0KU28sIGNvdWxkIHlvdSBl bGFib3JhdGUgYSBiaXQ/IA0KDQpDaWFvDQpIYW5uZXMNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5j ZXNAaWV0Zi5vcmddIA0KPk9uIEJlaGFsZiBPZiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlMNCj5T ZW50OiAwNyBGZWJydWFyeSwgMjAwOSAxOTozMA0KPlRvOiBoZ3NAY3MuY29sdW1iaWEuZWR1OyBq Z3VubjZAY3NjLmNvbQ0KPkNjOiBlY3JpdEBpZXRmLm9yZzsgZWNyaXQtYm91bmNlc0BpZXRmLm9y Zw0KPlN1YmplY3Q6IFJlOiBbRWNyaXRdIFNlbWFudGljcyBSZTogUlBIDQo+DQo+RG8geW91IGhh dmUgYSBjbHVlIGR1ZGU/IEErQSBvZiBhbiB1c2VyIGNvbWVzIGluIG1hbnkgZm9ybXMuDQo+DQo+ LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5v cmcgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+VG86IEphbmV0IFAgR3VubiA8amd1bm42QGNz Yy5jb20+DQo+Q2M6IEVDUklUIDxlY3JpdEBpZXRmLm9yZz47IGVjcml0LWJvdW5jZXNAaWV0Zi5v cmcgDQo+PGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+U2VudDogU2F0IEZlYiAwNyAxMTo1Njo0 MiAyMDA5DQo+U3ViamVjdDogUmU6IFtFY3JpdF0gU2VtYW50aWNzICBSZTogIFJQSA0KPg0KPlBs ZWFzZSBzZWUgbXkgZWFybGllciBtZXNzYWdlIGFzIHRvIHdoeSB5b3VyIGFwcHJvYWNoIGZhaWxz IA0KPmZvciB0aGUgVUEtIGluc2VydGVkIGNhc2Ugd2hlcmUgbm90IGFsbCBlbWVyZ2VuY3kgY2Fs bHMgaGF2ZSANCj5SUEggbWFya2luZ3MuIEkgdGhpbmsgaXQgd291bGQgYmUgYSByZWFsbHkgYmFk IGlkZWEgaWYgDQo+ZW1lcmdlbmN5IGNhbGxzIHdpdGggUlBIIGFyZSB0cmVhdGVkIGRpZmZlcmVu dGx5IHRoYW4gDQo+ZW1lcmdlbmN5IGNhbGxzIHdpdGhvdXQgaXQuIChBZ2FpbiwgSSdtIHRhbGtp bmcgYWJvdXQgdGhlIA0KPnVzZXItaW5pdGlhdGVkIGNhbGxzLiBBbiBFU05FVCBjYW4gZG8gd2hh dGV2ZXIgaXQgd2FudHMgYW5kIA0KPmNhbiBhc3NpZ24gZXh0cmEgcHJpb3JpdHkgdG8gY2FsbHMg ZnJvbSBjaXRpemVucyB0aGF0IGhhdmUgDQo+Ym91Z2h0IFBCQSBzdGlja2VycyBvciB6aXAgY29k ZXMgdGhhdCBwYXkgbW9yZSB0YXhlcywgYnV0IA0KPnRoYXQncyBhIHNlcGFyYXRlDQo+cHJvYmxl bS4pDQo+DQo+SSBhbHNvIGRvbid0IGJlbGlldmUgeW91ciBpbXBsZW1lbnRhdGlvbiBsb2dpYy4g QSBtdWNoIGJldHRlciANCj5hcHByb2FjaCBpcyB0byBzZW1hbnRpY2FsbHkgZGVjbGFyZSB0aGUg Y2xhc3Mgb2YgY2FsbCBlYXJseSBvbiANCj4oZS5nLiwgYmFzZWQgb24gdGhlIFVSTiBvciBhZnRl ciANCj5hdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uKSwgYW5kIG1ha2UgdGhhdCBwYXJ0IG9m IHRoZSBjYWxsIA0KPnN0YXRlIHJlY29yZCwgcmF0aGVyIHRoYW4gaHVudCBmb3IgaGVhZGVycyBl YWNoIHRpbWUgYSANCj5oYW5kbGluZyBkZWNpc2lvbiBuZWVkcyB0byBiZSBtYWRlLiBHaXZlbiB0 aGUgYXV0aG9yaXphdGlvbiANCj5yZXF1aXJlbWVudHMsIGp1c3QgbG9va2luZyBhdCAiaGFzIGhl YWRlciBYIiBpcyBuZXZlciBnb2luZyB0byANCj5iZSBzdWZmaWNpZW50IGFueXdheS4NCj4NCj5I ZW5uaW5nDQo+DQo+T24gRmViIDcsIDIwMDksIGF0IDExOjI3IEFNLCBKYW5ldCBQIEd1bm4gd3Jv dGU6DQo+DQo+Pg0KPj4NCj4+IC4NCj4+DQo+PiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIHdyb3Rl IG9uIDAyLzA3LzIwMDkgMDM6MTQ6NTcgQU06DQo+Pg0KPj4gPiBQTEVBU0UgdHJ5IHRvIHVuZGVy c3RhbmQgdGhhdCB0aGUgc3ludGF4IGlzIHNpbWlsYXIgKGhlYWRlciwgbmV3DQo+PiBuYW1lc3Bh Y2UsDQo+PiA+IG5ldyB2YWx1ZXMpDQo+PiA+IEJVVCB0aGUgc2VtYW50aWMgaXMgZGlmZmVyZW50 Lg0KPj4gPg0KPj4gPiBGb3IgYWxsIG1lc3NhZ2UgaXQgaXMgdHJ1ZSB0aGF0IHRoZSBzZW5kZXIg Y2FuIGFkZCB3aGF0ZXZlciB0aGV5DQo+PiB3YW50LiBUaGUNCj4+ID4gYmlnIHF1ZXN0aW9uIGlz IHdoYXQgZG9lcyBpdCBtZWFuIGZvciB0aGUgcmVjaXBpZW50Lg0KPj4gPg0KPj4gPiBUaGlzIGlz IHdoYXQgdGhlIGRpc2N1c3Npb24gaXMgYWJvdXQuDQo+PiA+DQo+PiBPbiB0aGUgY29udHJhcnks IHRoZSBzZW1hbnRpYyBpcywgb3IgYXQgbGVhc3QgY2FuIGJlLCB2ZXJ5IHNpbWlsYXIuDQo+Pg0K Pj4gQ29uc2lkZXIgdGhlIGh5cG90aGV0aWNhbCwgYnV0IHBsYXVzaWJsZSwgY2FzZSBvZiBhIG5l dHdvcmsgd2l0aCBhbiANCj4+IGV4cGxpY2l0IGNhbGwvY2FwYWNpdHkgYWRtaXNzaW9uIHByb2Nl c3MsIGluIHdoaWNoIGJvdGggOTExLXR5cGUtIA0KPj4gZW1lcmdlbmN5IGNhbGxzIGFuZCBHRVRT IGNhbGxzIGdldCBwcmVmZXJlbnRpYWwgYWRtaXNzaW9uIA0KPnRyZWF0bWVudC4gIA0KPj4gQnkg dGhlIHRpbWUgdGhlIElOVklURSBnZXRzIHRvIHRoaXMgRnVuY3Rpb25hbCBNb2R1bGUvIGJsb2Nr IA0KPm9mIGNvZGUsIA0KPj4gYWxsIGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uLCBhbmQg Y2hhbmdlcy8gY29uZmlybWF0aW9uIG9mIHRoZSANCj4+IGRlc3RpbmF0aW9uIGhhdmUgYWxyZWFk eSB0YWtlbiBwbGFjZS4gIEFsbCB0aGlzIGJsb2NrIG9mIGNvZGUgZGVhbHMgDQo+PiB3aXRoIGlz IGNhbGwvY2FwYWNpdHkgYWRtaXNzaW9uLg0KPj4NCj4+IEZvciB0aGUgc2FrZSBvZiBhcmd1bWVu dCwgc3VwcG9zZSB0aGlzIGlzIHRoZSBuYXR1cmUgb2YgdGhlIA0KPj4gcHJlZmVyZW5jZS4NCj4+ DQo+PiAxKSBGb3IgSU5WSVRFcyB3aXRob3V0IFJQSCwgb3Igd2l0aCBhbiBSUEggdGhpcyBuZXR3 b3JrIGRvZXMgDQo+bm90IHVzZS8gDQo+PiB1bmRlcnN0YW5kLCBpZiB0aGUgYWRtaXNzaW9uIHBy b2Nlc3MgZmFpbHMsIHRoZSBJTlZJVEUgZmFpbHMNCj4+DQo+PiAyKSBGb3IgSU5WSVRFcyB3aXRo IFJQSCB3aXRoIHRoZSBldHMgbmFtZXNwYWNlLCBpZiB0aGUgYWRtaXNzaW9uIA0KPj4gcHJvY2Vz cyBpbml0aWFsbHkgZmFpbHMsIHRoZSBJTlZJVEUgaXMgcHV0IGluIHF1ZXVlIHVudGlsIHRoZSAN Cj4+IHJlc291cmNlcyBiZWNvbWUgYXZhaWxhYmxlIHNvIGl0IGNhbiBiZSBhZG1pdHRlZC4NCj4+ DQo+PiAzKSBGb3IgSU5WSVRFcyB3aXRoIFJQSCB3aXRoIHRoZSBlc25ldCBuYW1lc3BhY2UsIGlm IHRoZSBhZG1pc3Npb24gDQo+PiBwcm9jZXNzIGluaXRpYWxseSBmYWlscywgdGhlIElOVklURSBp cyBwdXQgaW4gcXVldWUsIGJ1dCBhdCBsb3dlciANCj4+IHByaW9yaXR5IHRoYW4gdGhlIGNhbGxz IHdpdGggdGhlIGV0cyBuYW1lc3BhY2UuDQo+Pg0KPj4gV2l0aCB0aGUgZXNuZXQgbmFtZXNwYWNl LCB0aGlzIGJsb2NrIG9mIGNvZGUgb25seSBuZWVkcyB0byBkZWFsIHdpdGggDQo+PiB0aGUgUlBI IGluIGRldGVybWluaW5nIHdoaWNoIElOVklURXMgdG8gcmVqZWN0LCBhbmQgd2hpY2ggdG8gcXVl dWUsIA0KPj4gYW5kIGhvdy4NCj4+DQo+PiBCdXQgaWYgdGhlcmUgaXMgbm8gZXNuZXQgbmFtZXNw YWNlIGZvciBSUEgsIHRoZW4gdGhpcyBibG9jayBvZiBjb2RlIA0KPj4gd291bGQgbmVlZCB0byBk ZWFsIHdpdGggQk9USCB0aGUgUlBIIGFuZCB0aGUgVVJOLiAgVGhhdCB3b3VsZCBiZSBhIA0KPj4g Y29tcGxldGVseSB1bm5lY2Vzc2FyeSBjb21wbGljYXRpb24uDQo+Pg0KPj4gSmFuZXQNCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkVjcml0IG1h aWxpbmcgbGlzdA0KPkVjcml0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+RWNyaXQgbWFpbGluZyBsaXN0DQo+RWNyaXRAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+DQoNCg== Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668333A6A4D for ; Sun, 8 Feb 2009 05:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo6iknLofZsp for ; Sun, 8 Feb 2009 05:13:46 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C259F3A68A6 for ; Sun, 8 Feb 2009 05:13:45 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2009 13:13:46 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp043) with SMTP; 08 Feb 2009 14:13:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/k+lgScQPkRtEb4VZzi8kSJtljfRHZtXUTOmZpdO c0uSrQSHgbMjM/ From: "Hannes Tschofenig" To: "'DOLLY, MARTIN C, ATTLABS'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F71@gaalpa1msgusr7e.ugd.att.com> Date: Sun, 8 Feb 2009 15:14:32 +0200 Message-ID: <004901c989ef$302749c0$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA01238F71@gaalpa1msgusr7e.ugd.att.com> Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNAABBb6A X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:13:47 -0000 Hi Martin, Thanks for the quick response. I am aware of these network access authentication and authorization procedures (including the authentication and authorization procedure at the SIP layer). They are clearly important for some of the RPH usage scenarios. For this specific case (the new esnet RPH mechanism) there are additional facets that needs to be considered (beyond the above-mentioned security aspects): * What does the esnet RPH usage mean in the context of an emergency call (for example, in comparison to an emergency call without esnet RPH usage)? * For emergency calls the authorization procedures are different than with regular calls. There are certainly differences to the GETS-alike calls as well. (We ignore for a moment that there are these unauthenticated emergency calls where even the authentication procedure is missing.) The current security consideration section does not acknowledge these differences. It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace captures some of these aspects to allow those who implement and deploy the esnet RPH mechanism to understand what it does and how to correctly implement it. Ciao Hannes PS: There are details that also need to be discussed. For example, which esnet value would the device use for an emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", "esnet.4". Out-of-scope is a possible answer but it will not help the implementer in doing it's job. Is there a specific default value (maybe the highest value, just to be sure)? Would the UA get provisioned to pick a specific value? What is the provisioning mechanism? Is there a relationship between the esnet values and the Service URN values? Do the urn:service:counseling:* services get a lower priority than the urn:service:sos:* services? >Hannes, > >We need to understand the attachment of the UE to the network. >There is an AA process prior to allowing any use. Without this >we would not trust the RPH, even for ETS, never mind 911 > >Martin > >----- Original Message ----- >From: Hannes Tschofenig >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu >; jgunn6@csc.com >Cc: ecrit@ietf.org >Sent: Sun Feb 08 04:32:25 2009 >Subject: RE: [Ecrit] Semantics Re: RPH > >Hi Martin, > >Your remarks are a bit a short. > >Clearly, authentication and authorization can come in different forms. >This was actually one of the discussion we had so far that the >authorization mechanisms for the GETS RPH and the proposed >ECRIT RPH is different. > >So, could you elaborate a bit? > >Ciao >Hannes > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of DOLLY, MARTIN C, ATTLABS >>Sent: 07 February, 2009 19:30 >>To: hgs@cs.columbia.edu; jgunn6@csc.com >>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org >>Subject: Re: [Ecrit] Semantics Re: RPH >> >>Do you have a clue dude? A+A of an user comes in many forms. >> >>----- Original Message ----- >>From: ecrit-bounces@ietf.org >>To: Janet P Gunn >>Cc: ECRIT ; ecrit-bounces@ietf.org >> >>Sent: Sat Feb 07 11:56:42 2009 >>Subject: Re: [Ecrit] Semantics Re: RPH >> >>Please see my earlier message as to why your approach fails >for the UA- >>inserted case where not all emergency calls have RPH >markings. I think >>it would be a really bad idea if emergency calls with RPH are treated >>differently than emergency calls without it. (Again, I'm >talking about >>the user-initiated calls. An ESNET can do whatever it wants and can >>assign extra priority to calls from citizens that have bought PBA >>stickers or zip codes that pay more taxes, but that's a separate >>problem.) >> >>I also don't believe your implementation logic. A much better >approach >>is to semantically declare the class of call early on (e.g., based on >>the URN or after authentication/authorization), and make that part of >>the call state record, rather than hunt for headers each time a >>handling decision needs to be made. Given the authorization >>requirements, just looking at "has header X" is never going to be >>sufficient anyway. >> >>Henning >> >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: >> >>> >>> >>> . >>> >>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: >>> >>> > PLEASE try to understand that the syntax is similar (header, new >>> namespace, >>> > new values) >>> > BUT the semantic is different. >>> > >>> > For all message it is true that the sender can add whatever they >>> want. The >>> > big question is what does it mean for the recipient. >>> > >>> > This is what the discussion is about. >>> > >>> On the contrary, the semantic is, or at least can be, very similar. >>> >>> Consider the hypothetical, but plausible, case of a network with an >>> explicit call/capacity admission process, in which both 911-type- >>> emergency calls and GETS calls get preferential admission >>treatment. >>> By the time the INVITE gets to this Functional Module/ block >>of code, >>> all authentication, authorization, and changes/ confirmation of the >>> destination have already taken place. All this block of code deals >>> with is call/capacity admission. >>> >>> For the sake of argument, suppose this is the nature of the >>> preference. >>> >>> 1) For INVITEs without RPH, or with an RPH this network does >>not use/ >>> understand, if the admission process fails, the INVITE fails >>> >>> 2) For INVITEs with RPH with the ets namespace, if the admission >>> process initially fails, the INVITE is put in queue until the >>> resources become available so it can be admitted. >>> >>> 3) For INVITEs with RPH with the esnet namespace, if the admission >>> process initially fails, the INVITE is put in queue, but at lower >>> priority than the calls with the ets namespace. >>> >>> With the esnet namespace, this block of code only needs to >deal with >>> the RPH in determining which INVITEs to reject, and which to queue, >>> and how. >>> >>> But if there is no esnet namespace for RPH, then this block of code >>> would need to deal with BOTH the RPH and the URN. That would be a >>> completely unnecessary complication. >>> >>> Janet >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA423A6B4B for ; Sun, 8 Feb 2009 06:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a6qslh3Y06U for ; Sun, 8 Feb 2009 06:02:22 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 529FF28C0E2 for ; Sun, 8 Feb 2009 06:02:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-11.tower-129.messagelabs.com!1234101726!5806118!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 3864 invoked from network); 8 Feb 2009 14:02:06 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 8 Feb 2009 14:02:06 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18E25Ta001087; Sun, 8 Feb 2009 09:02:05 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n18E22ki001067; Sun, 8 Feb 2009 09:02:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 8 Feb 2009 09:02:01 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01238F74@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Semantics Re: RPH Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNAABBb6AAALPqOk= From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 14:02:23 -0000 VGhlc2UgYXJlIHRoZSBydWxlLCBub3QgdGhlIGV4Y2VwdGlvbi4gSSBkbyBub3QgY2FyZSBhYm91 dCB0aGUgaW50ZXJuZXQgZnJlZSBzY2VuYXJpb3MuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQpGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5l dD4NClRvOiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlM7IGhnc0Bjcy5jb2x1bWJpYS5lZHUgPGhn c0Bjcy5jb2x1bWJpYS5lZHU+OyBqZ3VubjZAY3NjLmNvbSA8amd1bm42QGNzYy5jb20+DQpDYzog ZWNyaXRAaWV0Zi5vcmcgPGVjcml0QGlldGYub3JnPg0KU2VudDogU3VuIEZlYiAwOCAwODoxNDoz MiAyMDA5DQpTdWJqZWN0OiBSRTogW0Vjcml0XSBTZW1hbnRpY3MgIFJlOiAgUlBIDQoNCkhpIE1h cnRpbiwgDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiANCg0KSSBhbSBhd2FyZSBv ZiB0aGVzZSBuZXR3b3JrIGFjY2VzcyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbg0K cHJvY2VkdXJlcyAoaW5jbHVkaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv biBwcm9jZWR1cmUgYXQgdGhlDQpTSVAgbGF5ZXIpLiBUaGV5IGFyZSBjbGVhcmx5IGltcG9ydGFu dCBmb3Igc29tZSBvZiB0aGUgUlBIIHVzYWdlIHNjZW5hcmlvcy4gDQoNCkZvciB0aGlzIHNwZWNp ZmljIGNhc2UgKHRoZSBuZXcgZXNuZXQgUlBIIG1lY2hhbmlzbSkgdGhlcmUgYXJlIGFkZGl0aW9u YWwNCmZhY2V0cyB0aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgKGJleW9uZCB0aGUgYWJvdmUt bWVudGlvbmVkIHNlY3VyaXR5DQphc3BlY3RzKTogDQoNCiogV2hhdCBkb2VzIHRoZSBlc25ldCBS UEggdXNhZ2UgbWVhbiBpbiB0aGUgY29udGV4dCBvZiBhbiBlbWVyZ2VuY3kgY2FsbA0KKGZvciBl eGFtcGxlLCBpbiBjb21wYXJpc29uIHRvIGFuIGVtZXJnZW5jeSBjYWxsIHdpdGhvdXQgZXNuZXQg UlBIIHVzYWdlKT8gDQoNCiogRm9yIGVtZXJnZW5jeSBjYWxscyB0aGUgYXV0aG9yaXphdGlvbiBw cm9jZWR1cmVzIGFyZSBkaWZmZXJlbnQgdGhhbiB3aXRoDQpyZWd1bGFyIGNhbGxzLiBUaGVyZSBh cmUgY2VydGFpbmx5IGRpZmZlcmVuY2VzIHRvIHRoZSBHRVRTLWFsaWtlIGNhbGxzIGFzDQp3ZWxs LiAoV2UgaWdub3JlIGZvciBhIG1vbWVudCB0aGF0IHRoZXJlIGFyZSB0aGVzZSB1bmF1dGhlbnRp Y2F0ZWQgZW1lcmdlbmN5DQpjYWxscyB3aGVyZSBldmVuIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9j ZWR1cmUgaXMgbWlzc2luZy4pIFRoZSBjdXJyZW50DQpzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNl Y3Rpb24gZG9lcyBub3QgYWNrbm93bGVkZ2UgdGhlc2UgZGlmZmVyZW5jZXMuIA0KDQpJdCB3b3Vs ZCBiZSBoZWxwZnVsIHRoYXQgZHJhZnQtaWV0Zi1lY3JpdC1sb2NhbC1lbWVyZ2VuY3ktcnBoLW5h bWVzcGFjZQ0KY2FwdHVyZXMgc29tZSBvZiB0aGVzZSBhc3BlY3RzIHRvIGFsbG93IHRob3NlIHdo byBpbXBsZW1lbnQgYW5kIGRlcGxveSB0aGUNCmVzbmV0IFJQSCBtZWNoYW5pc20gdG8gdW5kZXJz dGFuZCB3aGF0IGl0IGRvZXMgYW5kIGhvdyB0byBjb3JyZWN0bHkNCmltcGxlbWVudCBpdC4gIA0K DQpDaWFvDQpIYW5uZXMNCg0KUFM6IFRoZXJlIGFyZSBkZXRhaWxzIHRoYXQgYWxzbyBuZWVkIHRv IGJlIGRpc2N1c3NlZC4gRm9yIGV4YW1wbGUsIHdoaWNoDQplc25ldCB2YWx1ZSB3b3VsZCB0aGUg ZGV2aWNlIHVzZSBmb3IgYW4gZW1lcmdlbmN5IGNhbGw/ICJlc25ldC4wIiwNCiJlc25ldC4xIiwg ImVzbmV0LjIiLCAiZXNuZXQuMyIsICJlc25ldC40Ii4gT3V0LW9mLXNjb3BlIGlzIGEgcG9zc2li bGUNCmFuc3dlciBidXQgaXQgd2lsbCBub3QgaGVscCB0aGUgaW1wbGVtZW50ZXIgaW4gZG9pbmcg aXQncyBqb2IuIElzIHRoZXJlIGENCnNwZWNpZmljIGRlZmF1bHQgdmFsdWUgKG1heWJlIHRoZSBo aWdoZXN0IHZhbHVlLCBqdXN0IHRvIGJlIHN1cmUpPyBXb3VsZCB0aGUNClVBIGdldCBwcm92aXNp b25lZCB0byBwaWNrIGEgc3BlY2lmaWMgdmFsdWU/IFdoYXQgaXMgdGhlIHByb3Zpc2lvbmluZw0K bWVjaGFuaXNtPyBJcyB0aGVyZSBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBlc25ldCB2YWx1 ZXMgYW5kIHRoZSBTZXJ2aWNlDQpVUk4gdmFsdWVzPyBEbyB0aGUgdXJuOnNlcnZpY2U6Y291bnNl bGluZzoqIHNlcnZpY2VzIGdldCBhIGxvd2VyIHByaW9yaXR5DQp0aGFuIHRoZSB1cm46c2Vydmlj ZTpzb3M6KiBzZXJ2aWNlcz8gICANCg0KPkhhbm5lcywNCj4NCj5XZSBuZWVkIHRvIHVuZGVyc3Rh bmQgdGhlIGF0dGFjaG1lbnQgb2YgdGhlIFVFIHRvIHRoZSBuZXR3b3JrLiANCj5UaGVyZSBpcyBh biBBQSBwcm9jZXNzIHByaW9yIHRvIGFsbG93aW5nIGFueSB1c2UuIFdpdGhvdXQgdGhpcyANCj53 ZSB3b3VsZCBub3QgdHJ1c3QgdGhlIFJQSCwgZXZlbiBmb3IgRVRTLCBuZXZlciBtaW5kIDkxMQ0K Pg0KPk1hcnRpbg0KPg0KPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj5Gcm9tOiBIYW5u ZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4NCj5UbzogRE9MTFksIE1B UlRJTiBDLCBBVFRMQUJTOyBoZ3NAY3MuY29sdW1iaWEuZWR1IA0KPjxoZ3NAY3MuY29sdW1iaWEu ZWR1Pjsgamd1bm42QGNzYy5jb20gPGpndW5uNkBjc2MuY29tPg0KPkNjOiBlY3JpdEBpZXRmLm9y ZyA8ZWNyaXRAaWV0Zi5vcmc+DQo+U2VudDogU3VuIEZlYiAwOCAwNDozMjoyNSAyMDA5DQo+U3Vi amVjdDogUkU6IFtFY3JpdF0gU2VtYW50aWNzICBSZTogIFJQSA0KPg0KPkhpIE1hcnRpbiwgDQo+ DQo+WW91ciByZW1hcmtzIGFyZSBhIGJpdCBhIHNob3J0Lg0KPg0KPkNsZWFybHksIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGNhbiBjb21lIGluIGRpZmZlcmVudCBmb3Jtcy4gDQo+ VGhpcyB3YXMgYWN0dWFsbHkgb25lIG9mIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBzbyBmYXIgdGhh dCB0aGUgDQo+YXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIGZvciB0aGUgR0VUUyBSUEggYW5kIHRo ZSBwcm9wb3NlZCANCj5FQ1JJVCBSUEggaXMgZGlmZmVyZW50LiANCj4NCj5TbywgY291bGQgeW91 IGVsYWJvcmF0ZSBhIGJpdD8gDQo+DQo+Q2lhbw0KPkhhbm5lcw0KPg0KPj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNy aXQtYm91bmNlc0BpZXRmLm9yZ10gDQo+T24gQmVoYWxmIA0KPj5PZiBET0xMWSwgTUFSVElOIEMs IEFUVExBQlMNCj4+U2VudDogMDcgRmVicnVhcnksIDIwMDkgMTk6MzANCj4+VG86IGhnc0Bjcy5j b2x1bWJpYS5lZHU7IGpndW5uNkBjc2MuY29tDQo+PkNjOiBlY3JpdEBpZXRmLm9yZzsgZWNyaXQt Ym91bmNlc0BpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW0Vjcml0XSBTZW1hbnRpY3MgUmU6IFJQ SA0KPj4NCj4+RG8geW91IGhhdmUgYSBjbHVlIGR1ZGU/IEErQSBvZiBhbiB1c2VyIGNvbWVzIGlu IG1hbnkgZm9ybXMuDQo+Pg0KPj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+PkZyb206 IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+PlRvOiBK YW5ldCBQIEd1bm4gPGpndW5uNkBjc2MuY29tPg0KPj5DYzogRUNSSVQgPGVjcml0QGlldGYub3Jn PjsgZWNyaXQtYm91bmNlc0BpZXRmLm9yZyANCj4+PGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+DQo+ PlNlbnQ6IFNhdCBGZWIgMDcgMTE6NTY6NDIgMjAwOQ0KPj5TdWJqZWN0OiBSZTogW0Vjcml0XSBT ZW1hbnRpY3MgIFJlOiAgUlBIDQo+Pg0KPj5QbGVhc2Ugc2VlIG15IGVhcmxpZXIgbWVzc2FnZSBh cyB0byB3aHkgeW91ciBhcHByb2FjaCBmYWlscyANCj5mb3IgdGhlIFVBLSANCj4+aW5zZXJ0ZWQg Y2FzZSB3aGVyZSBub3QgYWxsIGVtZXJnZW5jeSBjYWxscyBoYXZlIFJQSCANCj5tYXJraW5ncy4g SSB0aGluayANCj4+aXQgd291bGQgYmUgYSByZWFsbHkgYmFkIGlkZWEgaWYgZW1lcmdlbmN5IGNh bGxzIHdpdGggUlBIIGFyZSB0cmVhdGVkIA0KPj5kaWZmZXJlbnRseSB0aGFuIGVtZXJnZW5jeSBj YWxscyB3aXRob3V0IGl0LiAoQWdhaW4sIEknbSANCj50YWxraW5nIGFib3V0IA0KPj50aGUgdXNl ci1pbml0aWF0ZWQgY2FsbHMuIEFuIEVTTkVUIGNhbiBkbyB3aGF0ZXZlciBpdCB3YW50cyBhbmQg Y2FuIA0KPj5hc3NpZ24gZXh0cmEgcHJpb3JpdHkgdG8gY2FsbHMgZnJvbSBjaXRpemVucyB0aGF0 IGhhdmUgYm91Z2h0IFBCQSANCj4+c3RpY2tlcnMgb3IgemlwIGNvZGVzIHRoYXQgcGF5IG1vcmUg dGF4ZXMsIGJ1dCB0aGF0J3MgYSBzZXBhcmF0ZQ0KPj5wcm9ibGVtLikNCj4+DQo+PkkgYWxzbyBk b24ndCBiZWxpZXZlIHlvdXIgaW1wbGVtZW50YXRpb24gbG9naWMuIEEgbXVjaCBiZXR0ZXIgDQo+ YXBwcm9hY2ggDQo+PmlzIHRvIHNlbWFudGljYWxseSBkZWNsYXJlIHRoZSBjbGFzcyBvZiBjYWxs IGVhcmx5IG9uIChlLmcuLCBiYXNlZCBvbiANCj4+dGhlIFVSTiBvciBhZnRlciBhdXRoZW50aWNh dGlvbi9hdXRob3JpemF0aW9uKSwgYW5kIG1ha2UgdGhhdCBwYXJ0IG9mIA0KPj50aGUgY2FsbCBz dGF0ZSByZWNvcmQsIHJhdGhlciB0aGFuIGh1bnQgZm9yIGhlYWRlcnMgZWFjaCB0aW1lIGEgDQo+ PmhhbmRsaW5nIGRlY2lzaW9uIG5lZWRzIHRvIGJlIG1hZGUuIEdpdmVuIHRoZSBhdXRob3JpemF0 aW9uIA0KPj5yZXF1aXJlbWVudHMsIGp1c3QgbG9va2luZyBhdCAiaGFzIGhlYWRlciBYIiBpcyBu ZXZlciBnb2luZyB0byBiZSANCj4+c3VmZmljaWVudCBhbnl3YXkuDQo+Pg0KPj5IZW5uaW5nDQo+ Pg0KPj5PbiBGZWIgNywgMjAwOSwgYXQgMTE6MjcgQU0sIEphbmV0IFAgR3VubiB3cm90ZToNCj4+ DQo+Pj4NCj4+Pg0KPj4+IC4NCj4+Pg0KPj4+IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUg b24gMDIvMDcvMjAwOSAwMzoxNDo1NyBBTToNCj4+Pg0KPj4+ID4gUExFQVNFIHRyeSB0byB1bmRl cnN0YW5kIHRoYXQgdGhlIHN5bnRheCBpcyBzaW1pbGFyIChoZWFkZXIsIG5ldw0KPj4+IG5hbWVz cGFjZSwNCj4+PiA+IG5ldyB2YWx1ZXMpDQo+Pj4gPiBCVVQgdGhlIHNlbWFudGljIGlzIGRpZmZl cmVudC4NCj4+PiA+DQo+Pj4gPiBGb3IgYWxsIG1lc3NhZ2UgaXQgaXMgdHJ1ZSB0aGF0IHRoZSBz ZW5kZXIgY2FuIGFkZCB3aGF0ZXZlciB0aGV5DQo+Pj4gd2FudC4gVGhlDQo+Pj4gPiBiaWcgcXVl c3Rpb24gaXMgd2hhdCBkb2VzIGl0IG1lYW4gZm9yIHRoZSByZWNpcGllbnQuDQo+Pj4gPg0KPj4+ ID4gVGhpcyBpcyB3aGF0IHRoZSBkaXNjdXNzaW9uIGlzIGFib3V0Lg0KPj4+ID4NCj4+PiBPbiB0 aGUgY29udHJhcnksIHRoZSBzZW1hbnRpYyBpcywgb3IgYXQgbGVhc3QgY2FuIGJlLCB2ZXJ5IHNp bWlsYXIuDQo+Pj4NCj4+PiBDb25zaWRlciB0aGUgaHlwb3RoZXRpY2FsLCBidXQgcGxhdXNpYmxl LCBjYXNlIG9mIGEgbmV0d29yayB3aXRoIGFuIA0KPj4+IGV4cGxpY2l0IGNhbGwvY2FwYWNpdHkg YWRtaXNzaW9uIHByb2Nlc3MsIGluIHdoaWNoIGJvdGggOTExLXR5cGUtIA0KPj4+IGVtZXJnZW5j eSBjYWxscyBhbmQgR0VUUyBjYWxscyBnZXQgcHJlZmVyZW50aWFsIGFkbWlzc2lvbg0KPj50cmVh dG1lbnQuICANCj4+PiBCeSB0aGUgdGltZSB0aGUgSU5WSVRFIGdldHMgdG8gdGhpcyBGdW5jdGlv bmFsIE1vZHVsZS8gYmxvY2sNCj4+b2YgY29kZSwNCj4+PiBhbGwgYXV0aGVudGljYXRpb24sIGF1 dGhvcml6YXRpb24sIGFuZCBjaGFuZ2VzLyBjb25maXJtYXRpb24gb2YgdGhlIA0KPj4+IGRlc3Rp bmF0aW9uIGhhdmUgYWxyZWFkeSB0YWtlbiBwbGFjZS4gIEFsbCB0aGlzIGJsb2NrIG9mIGNvZGUg ZGVhbHMgDQo+Pj4gd2l0aCBpcyBjYWxsL2NhcGFjaXR5IGFkbWlzc2lvbi4NCj4+Pg0KPj4+IEZv ciB0aGUgc2FrZSBvZiBhcmd1bWVudCwgc3VwcG9zZSB0aGlzIGlzIHRoZSBuYXR1cmUgb2YgdGhl IA0KPj4+IHByZWZlcmVuY2UuDQo+Pj4NCj4+PiAxKSBGb3IgSU5WSVRFcyB3aXRob3V0IFJQSCwg b3Igd2l0aCBhbiBSUEggdGhpcyBuZXR3b3JrIGRvZXMNCj4+bm90IHVzZS8NCj4+PiB1bmRlcnN0 YW5kLCBpZiB0aGUgYWRtaXNzaW9uIHByb2Nlc3MgZmFpbHMsIHRoZSBJTlZJVEUgZmFpbHMNCj4+ Pg0KPj4+IDIpIEZvciBJTlZJVEVzIHdpdGggUlBIIHdpdGggdGhlIGV0cyBuYW1lc3BhY2UsIGlm IHRoZSBhZG1pc3Npb24gDQo+Pj4gcHJvY2VzcyBpbml0aWFsbHkgZmFpbHMsIHRoZSBJTlZJVEUg aXMgcHV0IGluIHF1ZXVlIHVudGlsIHRoZSANCj4+PiByZXNvdXJjZXMgYmVjb21lIGF2YWlsYWJs ZSBzbyBpdCBjYW4gYmUgYWRtaXR0ZWQuDQo+Pj4NCj4+PiAzKSBGb3IgSU5WSVRFcyB3aXRoIFJQ SCB3aXRoIHRoZSBlc25ldCBuYW1lc3BhY2UsIGlmIHRoZSBhZG1pc3Npb24gDQo+Pj4gcHJvY2Vz cyBpbml0aWFsbHkgZmFpbHMsIHRoZSBJTlZJVEUgaXMgcHV0IGluIHF1ZXVlLCBidXQgYXQgbG93 ZXIgDQo+Pj4gcHJpb3JpdHkgdGhhbiB0aGUgY2FsbHMgd2l0aCB0aGUgZXRzIG5hbWVzcGFjZS4N Cj4+Pg0KPj4+IFdpdGggdGhlIGVzbmV0IG5hbWVzcGFjZSwgdGhpcyBibG9jayBvZiBjb2RlIG9u bHkgbmVlZHMgdG8gDQo+ZGVhbCB3aXRoIA0KPj4+IHRoZSBSUEggaW4gZGV0ZXJtaW5pbmcgd2hp Y2ggSU5WSVRFcyB0byByZWplY3QsIGFuZCB3aGljaCB0byBxdWV1ZSwgDQo+Pj4gYW5kIGhvdy4N Cj4+Pg0KPj4+IEJ1dCBpZiB0aGVyZSBpcyBubyBlc25ldCBuYW1lc3BhY2UgZm9yIFJQSCwgdGhl biB0aGlzIGJsb2NrIG9mIGNvZGUgDQo+Pj4gd291bGQgbmVlZCB0byBkZWFsIHdpdGggQk9USCB0 aGUgUlBIIGFuZCB0aGUgVVJOLiAgVGhhdCB3b3VsZCBiZSBhIA0KPj4+IGNvbXBsZXRlbHkgdW5u ZWNlc3NhcnkgY29tcGxpY2F0aW9uLg0KPj4+DQo+Pj4gSmFuZXQNCj4+DQo+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkVjcml0IG1haWxpbmcgbGlz dA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Vjcml0DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PkVjcml0IG1haWxpbmcgbGlzdA0KPj5FY3JpdEBpZXRmLm9yZw0KPj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pg0KPg0KPg0KDQo= Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097C53A6B64 for ; Sun, 8 Feb 2009 06:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGcCdwfmPk2g for ; Sun, 8 Feb 2009 06:04:49 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 6F85D3A6B62 for ; Sun, 8 Feb 2009 06:04:48 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n18E4evP026269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 8 Feb 2009 15:04:40 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 8 Feb 2009 15:04:40 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "'Henning Schulzrinne'" , "'James M. Polk'" Date: Sun, 8 Feb 2009 15:04:38 +0100 Thread-Topic: [Ecrit] RPH Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqAABCWV2AAIvWSkA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6749D647E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net><001d01c9885b$d5d705d0$49b5b70a@nsnintra.net><001f01c98860$910658c0$49b5b70a@nsnintra.net><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$49b5b70a@nsnintra.net><1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$49b5b70a@nsnintra.net><7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> In-Reply-To: <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 14:04:51 -0000 The semantics of the individual namespaces is part of the queue service alg= orithm. The authentication policy is part of the individual namespace.=20 I see no need at all to specify the former in an RFC. I don't see the need = for a lot of detail on the latter.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, February 07, 2009 8:15 AM > To: DRAGE, Keith (Keith); 'Henning Schulzrinne'; 'James M. Polk' > Cc: 'ECRIT' > Subject: RE: [Ecrit] RPH >=20 > PLEASE try to understand that the syntax is similar (header,=20 > new namespace, new values) BUT the semantic is different.=20 > =20 > For all message it is true that the sender can add whatever=20 > they want. The big question is what does it mean for the recipient.=20 >=20 > This is what the discussion is about.=20 >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf=20 > >Of DRAGE, Keith (Keith) > >Sent: 07 February, 2009 02:22 > >To: Henning Schulzrinne; James M. Polk > >Cc: ECRIT > >Subject: Re: [Ecrit] RPH > > > >Well to be honest, I thought RFC 4412 defined exactly the usage from=20 > >the UA of any RPH header, and noone appears to be seeking to change=20 > >that. Any UE can insert an RPH header, and the outbound proxy that=20 > >understands RPH can use this as absolute, guidance, or completely=20 > >ignore it and throw it away depending on whatever rules it decides=20 > >apply to its usage of that namespace. IETF does not write=20 > those rules,=20 > >just defines the namespace. > > > >So I disagree with the statement of "underspecified" in relation to=20 > >this. > > > >regards > > > >Keith > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Henning Schulzrinne > >> Sent: Friday, February 06, 2009 10:29 PM > >> To: James M. Polk > >> Cc: ECRIT > >> Subject: Re: [Ecrit] RPH > >>=20 > >> To restate: I will object to any text mentioning use of=20 > ESNET in UAs. > >> It's useless (since under-specified), likely to be harmful > >to reliable > >> network operation and just causes confusion. The text should > >describe > >> when it is useful (within a "closed" > >> ESNET, presumably) and what conditions need to be met in order to=20 > >> ensure reliable and secure usage. That something might be useful=20 > >> somewhere else is always true, in any specification, but we > >don't add > >> a "This document does not prevent the use of this mechanism > >somewhere > >> else." in documents. > >>=20 > >> Henning > >>=20 > >> On Feb 6, 2009, at 5:21 PM, James M. Polk wrote: > >>=20 > >> > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote: > >> >> James, > >> >> > >> >> we don't go through every possible SIP header that might > >> be inserted > >> >> into emergency requests. Yes, somebody could add RPH, but this=20 > >> >> applies to PAI and dozens of other SIP headers as well. So far,=20 > >> >> nobody has provided, in my opinion, a compelling use=20 > case that is=20 > >> >> worth documenting. "It could be useful somewhere for something" > >> >> doesn't cut it. I have provided multiple reasons why I > >> think that it > >> >> is a bad idea for (normal) UAs to do so, none of which > >you address. > >> > > >> > > >> >> I see no need to say "do not insert RPH", > >> > > >> > this is the only thing - right now - that I'm afraid one of us=20 > >> > believes should be the case. I'm glad you are not joining that=20 > >> > position. I really do not want to highlight the idea fo > >> UAs inserting > >> > esnet, but I believe sometime down the road - some customer > >> will come > >> > up with a valid reason for this, and I don't want to=20 > state in text=20 > >> > that it is prevented from being inserted (and yet have the > >> vendor who > >> > wants to sell to that customer also want that vendor to > >> adhere to this > >> > spec as well). > >> > > >> > I'm just advocating we not have the text prevent its inclusion. > >> > > >> > As I've said, I will beef up the security considerations > >> section wrt > >> > UA insertion of esnet - unless others object to this... > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > = Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09DF3A6929 for ; Sun, 8 Feb 2009 10:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUKTIqNs6eBt for ; Sun, 8 Feb 2009 10:41:31 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9F24F3A68DE for ; Sun, 8 Feb 2009 10:41:29 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2009 18:41:32 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 08 Feb 2009 19:41:32 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18O4pVR64sOAps73nyGNjTwgSOhBPUdPIBWkMieGg NSyX1+T9gWUSBg From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'Henning Schulzrinne'" , "'James M. Polk'" References: <000701c9883c$59b095d0$49b5b70a@nsnintra.net><001d01c9885b$d5d705d0$49b5b70a@nsnintra.net><001f01c98860$910658c0$49b5b70a@nsnintra.net><0d6901c9886b$6c9bfc50$45d3f4f0$@net><003001c9886e$7d133280$49b5b70a@nsnintra.net><1CC6E7BB-98D9-4D96-9340-2CA9A81F2562@cs.columbia.edu><0d9101c98872$7b2129b0$71637d10$@net><003d01c98889$666c23f0$49b5b70a@nsnintra.net><7B9BAE14-E074-46F2-A598-91B698FBFD11@cs.columbia.edu> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA0E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D6749D647E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Sun, 8 Feb 2009 20:42:14 +0200 Message-ID: <005001c98a1c$fa8afd60$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6749D647E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Thread-Index: AcmIqmZ/facwrgsDSaOG521IP+Vb0gADyoqAABCWV2AAIvWSkAAlKZRA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: 'ECRIT' Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 18:41:33 -0000 I think we will not come to an agreement. Our approaches are just too different: Your approach is to describe the syntax. I want a bit of the semantic being described. Ciao Hannes >-----Original Message----- >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 08 February, 2009 16:05 >To: Hannes Tschofenig; 'Henning Schulzrinne'; 'James M. Polk' >Cc: 'ECRIT' >Subject: RE: [Ecrit] RPH > >The semantics of the individual namespaces is part of the >queue service algorithm. The authentication policy is part of >the individual namespace. > >I see no need at all to specify the former in an RFC. I don't >see the need for a lot of detail on the latter. > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, February 07, 2009 8:15 AM >> To: DRAGE, Keith (Keith); 'Henning Schulzrinne'; 'James M. Polk' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] RPH >> >> PLEASE try to understand that the syntax is similar (header, new >> namespace, new values) BUT the semantic is different. >> >> For all message it is true that the sender can add whatever >they want. >> The big question is what does it mean for the recipient. >> >> This is what the discussion is about. >> >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf >> >Of DRAGE, Keith (Keith) >> >Sent: 07 February, 2009 02:22 >> >To: Henning Schulzrinne; James M. Polk >> >Cc: ECRIT >> >Subject: Re: [Ecrit] RPH >> > >> >Well to be honest, I thought RFC 4412 defined exactly the >usage from >> >the UA of any RPH header, and noone appears to be seeking to change >> >that. Any UE can insert an RPH header, and the outbound proxy that >> >understands RPH can use this as absolute, guidance, or completely >> >ignore it and throw it away depending on whatever rules it decides >> >apply to its usage of that namespace. IETF does not write >> those rules, >> >just defines the namespace. >> > >> >So I disagree with the statement of "underspecified" in relation to >> >this. >> > >> >regards >> > >> >Keith >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >> Of Henning Schulzrinne >> >> Sent: Friday, February 06, 2009 10:29 PM >> >> To: James M. Polk >> >> Cc: ECRIT >> >> Subject: Re: [Ecrit] RPH >> >> >> >> To restate: I will object to any text mentioning use of >> ESNET in UAs. >> >> It's useless (since under-specified), likely to be harmful >> >to reliable >> >> network operation and just causes confusion. The text should >> >describe >> >> when it is useful (within a "closed" >> >> ESNET, presumably) and what conditions need to be met in order to >> >> ensure reliable and secure usage. That something might be useful >> >> somewhere else is always true, in any specification, but we >> >don't add >> >> a "This document does not prevent the use of this mechanism >> >somewhere >> >> else." in documents. >> >> >> >> Henning >> >> >> >> On Feb 6, 2009, at 5:21 PM, James M. Polk wrote: >> >> >> >> > At 04:05 PM 2/6/2009, Henning Schulzrinne wrote: >> >> >> James, >> >> >> >> >> >> we don't go through every possible SIP header that might >> >> be inserted >> >> >> into emergency requests. Yes, somebody could add RPH, but this >> >> >> applies to PAI and dozens of other SIP headers as >well. So far, >> >> >> nobody has provided, in my opinion, a compelling use >> case that is >> >> >> worth documenting. "It could be useful somewhere for something" >> >> >> doesn't cut it. I have provided multiple reasons why I >> >> think that it >> >> >> is a bad idea for (normal) UAs to do so, none of which >> >you address. >> >> > >> >> > >> >> >> I see no need to say "do not insert RPH", >> >> > >> >> > this is the only thing - right now - that I'm afraid one of us >> >> > believes should be the case. I'm glad you are not joining that >> >> > position. I really do not want to highlight the idea fo >> >> UAs inserting >> >> > esnet, but I believe sometime down the road - some customer >> >> will come >> >> > up with a valid reason for this, and I don't want to >> state in text >> >> > that it is prevented from being inserted (and yet have the >> >> vendor who >> >> > wants to sell to that customer also want that vendor to >> >> adhere to this >> >> > spec as well). >> >> > >> >> > I'm just advocating we not have the text prevent its inclusion. >> >> > >> >> > As I've said, I will beef up the security considerations >> >> section wrt >> >> > UA insertion of esnet - unless others object to this... >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> > >> >> > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D243A687D for ; Sun, 8 Feb 2009 10:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIIiEaYqq48m for ; Sun, 8 Feb 2009 10:44:37 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 068593A698E for ; Sun, 8 Feb 2009 10:44:36 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2009 18:44:37 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 08 Feb 2009 19:44:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/r6INWuOrr3LeliwI5P7s2FuWdHPSZ6/7uuHn5BR tGJUW5Dc9hP9Hq From: "Hannes Tschofenig" To: "'DOLLY, MARTIN C, ATTLABS'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F74@gaalpa1msgusr7e.ugd.att.com> Date: Sun, 8 Feb 2009 20:45:21 +0200 Message-ID: <005101c98a1d$686ba6e0$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA01238F74@gaalpa1msgusr7e.ugd.att.com> Thread-Index: AcmJRRX7MtWq02JtRZaMQukWCeihVwABI88yACGKpsAABarkNAABBb6AAALPqOkACc/Q0A== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 18:44:38 -0000 Not sure what you mean. Let me ask you a basic question that we have been struggling with for some time in this discussion that Janet recently highlighted: How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1 call that does not have the esnet RPH marking? In what sense does the processing in the SIP proxy differ? Ciao Hannes >-----Original Message----- >From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] >Sent: 08 February, 2009 16:02 >To: Hannes.Tschofenig@gmx.net; hgs@cs.columbia.edu; jgunn6@csc.com >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Semantics Re: RPH > >These are the rule, not the exception. I do not care about the >internet free scenarios. > >----- Original Message ----- >From: Hannes Tschofenig >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu >; jgunn6@csc.com >Cc: ecrit@ietf.org >Sent: Sun Feb 08 08:14:32 2009 >Subject: RE: [Ecrit] Semantics Re: RPH > >Hi Martin, > >Thanks for the quick response. > >I am aware of these network access authentication and >authorization procedures (including the authentication and >authorization procedure at the SIP layer). They are clearly >important for some of the RPH usage scenarios. > >For this specific case (the new esnet RPH mechanism) there are >additional facets that needs to be considered (beyond the >above-mentioned security >aspects): > >* What does the esnet RPH usage mean in the context of an >emergency call (for example, in comparison to an emergency >call without esnet RPH usage)? > >* For emergency calls the authorization procedures are >different than with regular calls. There are certainly >differences to the GETS-alike calls as well. (We ignore for a >moment that there are these unauthenticated emergency calls >where even the authentication procedure is missing.) The >current security consideration section does not acknowledge >these differences. > >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace >captures some of these aspects to allow those who implement >and deploy the esnet RPH mechanism to understand what it does >and how to correctly implement it. > >Ciao >Hannes > >PS: There are details that also need to be discussed. For >example, which esnet value would the device use for an >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", >"esnet.4". Out-of-scope is a possible answer but it will not >help the implementer in doing it's job. Is there a specific >default value (maybe the highest value, just to be sure)? >Would the UA get provisioned to pick a specific value? What is >the provisioning mechanism? Is there a relationship between >the esnet values and the Service URN values? Do the >urn:service:counseling:* services get a lower priority >than the urn:service:sos:* services? > >>Hannes, >> >>We need to understand the attachment of the UE to the network. >>There is an AA process prior to allowing any use. Without >this we would >>not trust the RPH, even for ETS, never mind 911 >> >>Martin >> >>----- Original Message ----- >>From: Hannes Tschofenig >>To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu >>; jgunn6@csc.com >>Cc: ecrit@ietf.org >>Sent: Sun Feb 08 04:32:25 2009 >>Subject: RE: [Ecrit] Semantics Re: RPH >> >>Hi Martin, >> >>Your remarks are a bit a short. >> >>Clearly, authentication and authorization can come in >different forms. >>This was actually one of the discussion we had so far that the >>authorization mechanisms for the GETS RPH and the proposed >ECRIT RPH is >>different. >> >>So, could you elaborate a bit? >> >>Ciao >>Hannes >> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf >>>Of DOLLY, MARTIN C, ATTLABS >>>Sent: 07 February, 2009 19:30 >>>To: hgs@cs.columbia.edu; jgunn6@csc.com >>>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org >>>Subject: Re: [Ecrit] Semantics Re: RPH >>> >>>Do you have a clue dude? A+A of an user comes in many forms. >>> >>>----- Original Message ----- >>>From: ecrit-bounces@ietf.org >>>To: Janet P Gunn >>>Cc: ECRIT ; ecrit-bounces@ietf.org >>> >>>Sent: Sat Feb 07 11:56:42 2009 >>>Subject: Re: [Ecrit] Semantics Re: RPH >>> >>>Please see my earlier message as to why your approach fails >>for the UA- >>>inserted case where not all emergency calls have RPH >>markings. I think >>>it would be a really bad idea if emergency calls with RPH >are treated >>>differently than emergency calls without it. (Again, I'm >>talking about >>>the user-initiated calls. An ESNET can do whatever it wants and can >>>assign extra priority to calls from citizens that have bought PBA >>>stickers or zip codes that pay more taxes, but that's a separate >>>problem.) >>> >>>I also don't believe your implementation logic. A much better >>approach >>>is to semantically declare the class of call early on (e.g., >based on >>>the URN or after authentication/authorization), and make >that part of >>>the call state record, rather than hunt for headers each time a >>>handling decision needs to be made. Given the authorization >>>requirements, just looking at "has header X" is never going to be >>>sufficient anyway. >>> >>>Henning >>> >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: >>> >>>> >>>> >>>> . >>>> >>>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: >>>> >>>> > PLEASE try to understand that the syntax is similar (header, new >>>> namespace, >>>> > new values) >>>> > BUT the semantic is different. >>>> > >>>> > For all message it is true that the sender can add whatever they >>>> want. The >>>> > big question is what does it mean for the recipient. >>>> > >>>> > This is what the discussion is about. >>>> > >>>> On the contrary, the semantic is, or at least can be, very similar. >>>> >>>> Consider the hypothetical, but plausible, case of a >network with an >>>> explicit call/capacity admission process, in which both 911-type- >>>> emergency calls and GETS calls get preferential admission >>>treatment. >>>> By the time the INVITE gets to this Functional Module/ block >>>of code, >>>> all authentication, authorization, and changes/ >confirmation of the >>>> destination have already taken place. All this block of >code deals >>>> with is call/capacity admission. >>>> >>>> For the sake of argument, suppose this is the nature of the >>>> preference. >>>> >>>> 1) For INVITEs without RPH, or with an RPH this network does >>>not use/ >>>> understand, if the admission process fails, the INVITE fails >>>> >>>> 2) For INVITEs with RPH with the ets namespace, if the admission >>>> process initially fails, the INVITE is put in queue until the >>>> resources become available so it can be admitted. >>>> >>>> 3) For INVITEs with RPH with the esnet namespace, if the admission >>>> process initially fails, the INVITE is put in queue, but at lower >>>> priority than the calls with the ets namespace. >>>> >>>> With the esnet namespace, this block of code only needs to >>deal with >>>> the RPH in determining which INVITEs to reject, and which >to queue, >>>> and how. >>>> >>>> But if there is no esnet namespace for RPH, then this >block of code >>>> would need to deal with BOTH the RPH and the URN. That would be a >>>> completely unnecessary complication. >>>> >>>> Janet >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www.ietf.org/mailman/listinfo/ecrit >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4F228C0F3 for ; Sun, 8 Feb 2009 12:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpG491udjPVU for ; Sun, 8 Feb 2009 12:12:54 -0800 (PST) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id CF8BA3A6783 for ; Sun, 8 Feb 2009 12:12:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-164.messagelabs.com!1234123975!9908727!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 3670 invoked from network); 8 Feb 2009 20:12:56 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-13.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 8 Feb 2009 20:12:56 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n18KCt3b029015 for ; Sun, 8 Feb 2009 15:12:55 -0500 In-Reply-To: <005101c98a1d$686ba6e0$0201a8c0@nsnintra.net> To: "Hannes Tschofenig" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Sun, 8 Feb 2009 15:12:50 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/08/2009 03:15:16 PM, Serialize complete at 02/08/2009 03:15:16 PM Content-Type: multipart/alternative; boundary="=_alternative 006F076685257557_=" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 20:12:55 -0000 This is a multipart message in MIME format. --=_alternative 006F076685257557_= Content-Type: text/plain; charset="US-ASCII" Up to local policy. Janet "Hannes Tschofenig" wrote on 02/08/2009 01:45:21 PM: > Not sure what you mean. > > Let me ask you a basic question that we have been struggling with for some > time in this discussion that Janet recently highlighted: > > How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1 > call that does not have the esnet RPH marking? In what sense does the > processing in the SIP proxy differ? > > Ciao > Hannes > > >-----Original Message----- > >From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > >Sent: 08 February, 2009 16:02 > >To: Hannes.Tschofenig@gmx.net; hgs@cs.columbia.edu; jgunn6@csc.com > >Cc: ecrit@ietf.org > >Subject: Re: [Ecrit] Semantics Re: RPH > > > >These are the rule, not the exception. I do not care about the > >internet free scenarios. > > > >----- Original Message ----- > >From: Hannes Tschofenig > >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >; jgunn6@csc.com > >Cc: ecrit@ietf.org > >Sent: Sun Feb 08 08:14:32 2009 > >Subject: RE: [Ecrit] Semantics Re: RPH > > > >Hi Martin, > > > >Thanks for the quick response. > > > >I am aware of these network access authentication and > >authorization procedures (including the authentication and > >authorization procedure at the SIP layer). They are clearly > >important for some of the RPH usage scenarios. > > > >For this specific case (the new esnet RPH mechanism) there are > >additional facets that needs to be considered (beyond the > >above-mentioned security > >aspects): > > > >* What does the esnet RPH usage mean in the context of an > >emergency call (for example, in comparison to an emergency > >call without esnet RPH usage)? > > > >* For emergency calls the authorization procedures are > >different than with regular calls. There are certainly > >differences to the GETS-alike calls as well. (We ignore for a > >moment that there are these unauthenticated emergency calls > >where even the authentication procedure is missing.) The > >current security consideration section does not acknowledge > >these differences. > > > >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace > >captures some of these aspects to allow those who implement > >and deploy the esnet RPH mechanism to understand what it does > >and how to correctly implement it. > > > >Ciao > >Hannes > > > >PS: There are details that also need to be discussed. For > >example, which esnet value would the device use for an > >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", > >"esnet.4". Out-of-scope is a possible answer but it will not > >help the implementer in doing it's job. Is there a specific > >default value (maybe the highest value, just to be sure)? > >Would the UA get provisioned to pick a specific value? What is > >the provisioning mechanism? Is there a relationship between > >the esnet values and the Service URN values? Do the > >urn:service:counseling:* services get a lower priority > >than the urn:service:sos:* services? > > > >>Hannes, > >> > >>We need to understand the attachment of the UE to the network. > >>There is an AA process prior to allowing any use. Without > >this we would > >>not trust the RPH, even for ETS, never mind 911 > >> > >>Martin > >> > >>----- Original Message ----- > >>From: Hannes Tschofenig > >>To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >>; jgunn6@csc.com > >>Cc: ecrit@ietf.org > >>Sent: Sun Feb 08 04:32:25 2009 > >>Subject: RE: [Ecrit] Semantics Re: RPH > >> > >>Hi Martin, > >> > >>Your remarks are a bit a short. > >> > >>Clearly, authentication and authorization can come in > >different forms. > >>This was actually one of the discussion we had so far that the > >>authorization mechanisms for the GETS RPH and the proposed > >ECRIT RPH is > >>different. > >> > >>So, could you elaborate a bit? > >> > >>Ciao > >>Hannes > >> > >>>-----Original Message----- > >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>On Behalf > >>>Of DOLLY, MARTIN C, ATTLABS > >>>Sent: 07 February, 2009 19:30 > >>>To: hgs@cs.columbia.edu; jgunn6@csc.com > >>>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org > >>>Subject: Re: [Ecrit] Semantics Re: RPH > >>> > >>>Do you have a clue dude? A+A of an user comes in many forms. > >>> > >>>----- Original Message ----- > >>>From: ecrit-bounces@ietf.org > >>>To: Janet P Gunn > >>>Cc: ECRIT ; ecrit-bounces@ietf.org > >>> > >>>Sent: Sat Feb 07 11:56:42 2009 > >>>Subject: Re: [Ecrit] Semantics Re: RPH > >>> > >>>Please see my earlier message as to why your approach fails > >>for the UA- > >>>inserted case where not all emergency calls have RPH > >>markings. I think > >>>it would be a really bad idea if emergency calls with RPH > >are treated > >>>differently than emergency calls without it. (Again, I'm > >>talking about > >>>the user-initiated calls. An ESNET can do whatever it wants and can > >>>assign extra priority to calls from citizens that have bought PBA > >>>stickers or zip codes that pay more taxes, but that's a separate > >>>problem.) > >>> > >>>I also don't believe your implementation logic. A much better > >>approach > >>>is to semantically declare the class of call early on (e.g., > >based on > >>>the URN or after authentication/authorization), and make > >that part of > >>>the call state record, rather than hunt for headers each time a > >>>handling decision needs to be made. Given the authorization > >>>requirements, just looking at "has header X" is never going to be > >>>sufficient anyway. > >>> > >>>Henning > >>> > >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > >>> > >>>> > >>>> > >>>> . > >>>> > >>>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > >>>> > >>>> > PLEASE try to understand that the syntax is similar (header, new > >>>> namespace, > >>>> > new values) > >>>> > BUT the semantic is different. > >>>> > > >>>> > For all message it is true that the sender can add whatever they > >>>> want. The > >>>> > big question is what does it mean for the recipient. > >>>> > > >>>> > This is what the discussion is about. > >>>> > > >>>> On the contrary, the semantic is, or at least can be, very similar. > >>>> > >>>> Consider the hypothetical, but plausible, case of a > >network with an > >>>> explicit call/capacity admission process, in which both 911-type- > >>>> emergency calls and GETS calls get preferential admission > >>>treatment. > >>>> By the time the INVITE gets to this Functional Module/ block > >>>of code, > >>>> all authentication, authorization, and changes/ > >confirmation of the > >>>> destination have already taken place. All this block of > >code deals > >>>> with is call/capacity admission. > >>>> > >>>> For the sake of argument, suppose this is the nature of the > >>>> preference. > >>>> > >>>> 1) For INVITEs without RPH, or with an RPH this network does > >>>not use/ > >>>> understand, if the admission process fails, the INVITE fails > >>>> > >>>> 2) For INVITEs with RPH with the ets namespace, if the admission > >>>> process initially fails, the INVITE is put in queue until the > >>>> resources become available so it can be admitted. > >>>> > >>>> 3) For INVITEs with RPH with the esnet namespace, if the admission > >>>> process initially fails, the INVITE is put in queue, but at lower > >>>> priority than the calls with the ets namespace. > >>>> > >>>> With the esnet namespace, this block of code only needs to > >>deal with > >>>> the RPH in determining which INVITEs to reject, and which > >to queue, > >>>> and how. > >>>> > >>>> But if there is no esnet namespace for RPH, then this > >block of code > >>>> would need to deal with BOTH the RPH and the URN. That would be a > >>>> completely unnecessary complication. > >>>> > >>>> Janet > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> > > > > > --=_alternative 006F076685257557_= Content-Type: text/html; charset="US-ASCII"


Up to local policy.

Janet

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote on 02/08/2009 01:45:21 PM:

> Not sure what you mean.
>
> Let me ask you a basic question that we have been struggling with for some
> time in this discussion that Janet recently highlighted:
>
> How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1
> call that does not have the esnet RPH marking? In what sense does the
> processing in the SIP proxy differ?
>
> Ciao
> Hannes
>  
> >-----Original Message-----
> >From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]
> >Sent: 08 February, 2009 16:02
> >To: Hannes.Tschofenig@gmx.net; hgs@cs.columbia.edu; jgunn6@csc.com
> >Cc: ecrit@ietf.org
> >Subject: Re: [Ecrit] Semantics Re: RPH
> >
> >These are the rule, not the exception. I do not care about the
> >internet free scenarios.
> >
> >----- Original Message -----
> >From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu
> ><hgs@cs.columbia.edu>; jgunn6@csc.com <jgunn6@csc.com>
> >Cc: ecrit@ietf.org <ecrit@ietf.org>
> >Sent: Sun Feb 08 08:14:32 2009
> >Subject: RE: [Ecrit] Semantics  Re:  RPH
> >
> >Hi Martin,
> >
> >Thanks for the quick response.
> >
> >I am aware of these network access authentication and
> >authorization procedures (including the authentication and
> >authorization procedure at the SIP layer). They are clearly
> >important for some of the RPH usage scenarios.
> >
> >For this specific case (the new esnet RPH mechanism) there are
> >additional facets that needs to be considered (beyond the
> >above-mentioned security
> >aspects):
> >
> >* What does the esnet RPH usage mean in the context of an
> >emergency call (for example, in comparison to an emergency
> >call without esnet RPH usage)?
> >
> >* For emergency calls the authorization procedures are
> >different than with regular calls. There are certainly
> >differences to the GETS-alike calls as well. (We ignore for a
> >moment that there are these unauthenticated emergency calls
> >where even the authentication procedure is missing.) The
> >current security consideration section does not acknowledge
> >these differences.
> >
> >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace
> >captures some of these aspects to allow those who implement
> >and deploy the esnet RPH mechanism to understand what it does
> >and how to correctly implement it.  
> >
> >Ciao
> >Hannes
> >
> >PS: There are details that also need to be discussed. For
> >example, which esnet value would the device use for an
> >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3",
> >"esnet.4". Out-of-scope is a possible answer but it will not
> >help the implementer in doing it's job. Is there a specific
> >default value (maybe the highest value, just to be sure)?
> >Would the UA get provisioned to pick a specific value? What is
> >the provisioning mechanism? Is there a relationship between
> >the esnet values and the Service URN values? Do the
> >urn:service:counseling:* services get a lower priority
> >than the urn:service:sos:* services?  
> >
> >>Hannes,
> >>
> >>We need to understand the attachment of the UE to the network.
> >>There is an AA process prior to allowing any use. Without
> >this we would
> >>not trust the RPH, even for ETS, never mind 911
> >>
> >>Martin
> >>
> >>----- Original Message -----
> >>From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> >>To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu
> >><hgs@cs.columbia.edu>; jgunn6@csc.com <jgunn6@csc.com>
> >>Cc: ecrit@ietf.org <ecrit@ietf.org>
> >>Sent: Sun Feb 08 04:32:25 2009
> >>Subject: RE: [Ecrit] Semantics  Re:  RPH
> >>
> >>Hi Martin,
> >>
> >>Your remarks are a bit a short.
> >>
> >>Clearly, authentication and authorization can come in
> >different forms.
> >>This was actually one of the discussion we had so far that the
> >>authorization mechanisms for the GETS RPH and the proposed
> >ECRIT RPH is
> >>different.
> >>
> >>So, could you elaborate a bit?
> >>
> >>Ciao
> >>Hannes
> >>
> >>>-----Original Message-----
> >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> >>On Behalf
> >>>Of DOLLY, MARTIN C, ATTLABS
> >>>Sent: 07 February, 2009 19:30
> >>>To: hgs@cs.columbia.edu; jgunn6@csc.com
> >>>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org
> >>>Subject: Re: [Ecrit] Semantics Re: RPH
> >>>
> >>>Do you have a clue dude? A+A of an user comes in many forms.
> >>>
> >>>----- Original Message -----
> >>>From: ecrit-bounces@ietf.org <ecrit-bounces@ietf.org>
> >>>To: Janet P Gunn <jgunn6@csc.com>
> >>>Cc: ECRIT <ecrit@ietf.org>; ecrit-bounces@ietf.org
> >>><ecrit-bounces@ietf.org>
> >>>Sent: Sat Feb 07 11:56:42 2009
> >>>Subject: Re: [Ecrit] Semantics  Re:  RPH
> >>>
> >>>Please see my earlier message as to why your approach fails
> >>for the UA-
> >>>inserted case where not all emergency calls have RPH
> >>markings. I think
> >>>it would be a really bad idea if emergency calls with RPH
> >are treated
> >>>differently than emergency calls without it. (Again, I'm
> >>talking about
> >>>the user-initiated calls. An ESNET can do whatever it wants and can
> >>>assign extra priority to calls from citizens that have bought PBA
> >>>stickers or zip codes that pay more taxes, but that's a separate
> >>>problem.)
> >>>
> >>>I also don't believe your implementation logic. A much better
> >>approach
> >>>is to semantically declare the class of call early on (e.g.,
> >based on
> >>>the URN or after authentication/authorization), and make
> >that part of
> >>>the call state record, rather than hunt for headers each time a
> >>>handling decision needs to be made. Given the authorization
> >>>requirements, just looking at "has header X" is never going to be
> >>>sufficient anyway.
> >>>
> >>>Henning
> >>>
> >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote:
> >>>
> >>>>
> >>>>
> >>>> .
> >>>>
> >>>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM:
> >>>>
> >>>> > PLEASE try to understand that the syntax is similar (header, new
> >>>> namespace,
> >>>> > new values)
> >>>> > BUT the semantic is different.
> >>>> >
> >>>> > For all message it is true that the sender can add whatever they
> >>>> want. The
> >>>> > big question is what does it mean for the recipient.
> >>>> >
> >>>> > This is what the discussion is about.
> >>>> >
> >>>> On the contrary, the semantic is, or at least can be, very similar.
> >>>>
> >>>> Consider the hypothetical, but plausible, case of a
> >network with an
> >>>> explicit call/capacity admission process, in which both 911-type-
> >>>> emergency calls and GETS calls get preferential admission
> >>>treatment.  
> >>>> By the time the INVITE gets to this Functional Module/ block
> >>>of code,
> >>>> all authentication, authorization, and changes/
> >confirmation of the
> >>>> destination have already taken place.  All this block of
> >code deals
> >>>> with is call/capacity admission.
> >>>>
> >>>> For the sake of argument, suppose this is the nature of the
> >>>> preference.
> >>>>
> >>>> 1) For INVITEs without RPH, or with an RPH this network does
> >>>not use/
> >>>> understand, if the admission process fails, the INVITE fails
> >>>>
> >>>> 2) For INVITEs with RPH with the ets namespace, if the admission
> >>>> process initially fails, the INVITE is put in queue until the
> >>>> resources become available so it can be admitted.
> >>>>
> >>>> 3) For INVITEs with RPH with the esnet namespace, if the admission
> >>>> process initially fails, the INVITE is put in queue, but at lower
> >>>> priority than the calls with the ets namespace.
> >>>>
> >>>> With the esnet namespace, this block of code only needs to
> >>deal with
> >>>> the RPH in determining which INVITEs to reject, and which
> >to queue,
> >>>> and how.
> >>>>
> >>>> But if there is no esnet namespace for RPH, then this
> >block of code
> >>>> would need to deal with BOTH the RPH and the URN.  That would be a
> >>>> completely unnecessary complication.
> >>>>
> >>>> Janet
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>Ecrit@ietf.org
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>Ecrit@ietf.org
> >>>https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>
> >>
> >
> >
>
--=_alternative 006F076685257557_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714513A6B2C for ; Sun, 8 Feb 2009 23:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJaYlhIcN1Sy for ; Sun, 8 Feb 2009 23:33:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 820B93A6994 for ; Sun, 8 Feb 2009 23:33:51 -0800 (PST) Received: (qmail invoked by alias); 09 Feb 2009 07:33:55 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp052) with SMTP; 09 Feb 2009 08:33:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/qX5xv3q3qa+k0hr734L/mj2oPkMuhbWW/XV36FT N1KW5tcCLWj0mM From: "Hannes Tschofenig" To: "'Janet P Gunn'" References: <005101c98a1d$686ba6e0$0201a8c0@nsnintra.net> Date: Mon, 9 Feb 2009 09:34:42 +0200 Message-ID: <007901c98a88$e0c2add0$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmKKaJr8ARQIZ9aRYSjxto6ln5OpAAXEJew X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 07:33:53 -0000 I could have guessed the response already. I believe that the draft would benefit from a few sentences that describes what "local policy" decisions the operator deploying this mechanism has to make. Ciao Hannes ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: 08 February, 2009 22:13 To: Hannes Tschofenig Cc: ecrit@ietf.org; hgs@cs.columbia.edu; 'DOLLY, MARTIN C, ATTLABS' Subject: RE: [Ecrit] Semantics Re: RPH Up to local policy. Janet "Hannes Tschofenig" wrote on 02/08/2009 01:45:21 PM: > Not sure what you mean. > > Let me ask you a basic question that we have been struggling with for some > time in this discussion that Janet recently highlighted: > > How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1 > call that does not have the esnet RPH marking? In what sense does the > processing in the SIP proxy differ? > > Ciao > Hannes > > >-----Original Message----- > >From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > >Sent: 08 February, 2009 16:02 > >To: Hannes.Tschofenig@gmx.net; hgs@cs.columbia.edu; jgunn6@csc.com > >Cc: ecrit@ietf.org > >Subject: Re: [Ecrit] Semantics Re: RPH > > > >These are the rule, not the exception. I do not care about the > >internet free scenarios. > > > >----- Original Message ----- > >From: Hannes Tschofenig > >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >; jgunn6@csc.com > >Cc: ecrit@ietf.org > >Sent: Sun Feb 08 08:14:32 2009 > >Subject: RE: [Ecrit] Semantics Re: RPH > > > >Hi Martin, > > > >Thanks for the quick response. > > > >I am aware of these network access authentication and > >authorization procedures (including the authentication and > >authorization procedure at the SIP layer). They are clearly > >important for some of the RPH usage scenarios. > > > >For this specific case (the new esnet RPH mechanism) there are > >additional facets that needs to be considered (beyond the > >above-mentioned security > >aspects): > > > >* What does the esnet RPH usage mean in the context of an > >emergency call (for example, in comparison to an emergency > >call without esnet RPH usage)? > > > >* For emergency calls the authorization procedures are > >different than with regular calls. There are certainly > >differences to the GETS-alike calls as well. (We ignore for a > >moment that there are these unauthenticated emergency calls > >where even the authentication procedure is missing.) The > >current security consideration section does not acknowledge > >these differences. > > > >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace > >captures some of these aspects to allow those who implement > >and deploy the esnet RPH mechanism to understand what it does > >and how to correctly implement it. > > > >Ciao > >Hannes > > > >PS: There are details that also need to be discussed. For > >example, which esnet value would the device use for an > >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", > >"esnet.4". Out-of-scope is a possible answer but it will not > >help the implementer in doing it's job. Is there a specific > >default value (maybe the highest value, just to be sure)? > >Would the UA get provisioned to pick a specific value? What is > >the provisioning mechanism? Is there a relationship between > >the esnet values and the Service URN values? Do the > >urn:service:counseling:* services get a lower priority > >than the urn:service:sos:* services? > > > >>Hannes, > >> > >>We need to understand the attachment of the UE to the network. > >>There is an AA process prior to allowing any use. Without > >this we would > >>not trust the RPH, even for ETS, never mind 911 > >> > >>Martin > >> > >>----- Original Message ----- > >>From: Hannes Tschofenig > >>To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >>; jgunn6@csc.com > >>Cc: ecrit@ietf.org > >>Sent: Sun Feb 08 04:32:25 2009 > >>Subject: RE: [Ecrit] Semantics Re: RPH > >> > >>Hi Martin, > >> > >>Your remarks are a bit a short. > >> > >>Clearly, authentication and authorization can come in > >different forms. > >>This was actually one of the discussion we had so far that the > >>authorization mechanisms for the GETS RPH and the proposed > >ECRIT RPH is > >>different. > >> > >>So, could you elaborate a bit? > >> > >>Ciao > >>Hannes > >> > >>>-----Original Message----- > >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>On Behalf > >>>Of DOLLY, MARTIN C, ATTLABS > >>>Sent: 07 February, 2009 19:30 > >>>To: hgs@cs.columbia.edu; jgunn6@csc.com > >>>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org > >>>Subject: Re: [Ecrit] Semantics Re: RPH > >>> > >>>Do you have a clue dude? A+A of an user comes in many forms. > >>> > >>>----- Original Message ----- > >>>From: ecrit-bounces@ietf.org > >>>To: Janet P Gunn > >>>Cc: ECRIT ; ecrit-bounces@ietf.org > >>> > >>>Sent: Sat Feb 07 11:56:42 2009 > >>>Subject: Re: [Ecrit] Semantics Re: RPH > >>> > >>>Please see my earlier message as to why your approach fails > >>for the UA- > >>>inserted case where not all emergency calls have RPH > >>markings. I think > >>>it would be a really bad idea if emergency calls with RPH > >are treated > >>>differently than emergency calls without it. (Again, I'm > >>talking about > >>>the user-initiated calls. An ESNET can do whatever it wants and can > >>>assign extra priority to calls from citizens that have bought PBA > >>>stickers or zip codes that pay more taxes, but that's a separate > >>>problem.) > >>> > >>>I also don't believe your implementation logic. A much better > >>approach > >>>is to semantically declare the class of call early on (e.g., > >based on > >>>the URN or after authentication/authorization), and make > >that part of > >>>the call state record, rather than hunt for headers each time a > >>>handling decision needs to be made. Given the authorization > >>>requirements, just looking at "has header X" is never going to be > >>>sufficient anyway. > >>> > >>>Henning > >>> > >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > >>> > >>>> > >>>> > >>>> . > >>>> > >>>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > >>>> > >>>> > PLEASE try to understand that the syntax is similar (header, new > >>>> namespace, > >>>> > new values) > >>>> > BUT the semantic is different. > >>>> > > >>>> > For all message it is true that the sender can add whatever they > >>>> want. The > >>>> > big question is what does it mean for the recipient. > >>>> > > >>>> > This is what the discussion is about. > >>>> > > >>>> On the contrary, the semantic is, or at least can be, very similar. > >>>> > >>>> Consider the hypothetical, but plausible, case of a > >network with an > >>>> explicit call/capacity admission process, in which both 911-type- > >>>> emergency calls and GETS calls get preferential admission > >>>treatment. > >>>> By the time the INVITE gets to this Functional Module/ block > >>>of code, > >>>> all authentication, authorization, and changes/ > >confirmation of the > >>>> destination have already taken place. All this block of > >code deals > >>>> with is call/capacity admission. > >>>> > >>>> For the sake of argument, suppose this is the nature of the > >>>> preference. > >>>> > >>>> 1) For INVITEs without RPH, or with an RPH this network does > >>>not use/ > >>>> understand, if the admission process fails, the INVITE fails > >>>> > >>>> 2) For INVITEs with RPH with the ets namespace, if the admission > >>>> process initially fails, the INVITE is put in queue until the > >>>> resources become available so it can be admitted. > >>>> > >>>> 3) For INVITEs with RPH with the esnet namespace, if the admission > >>>> process initially fails, the INVITE is put in queue, but at lower > >>>> priority than the calls with the ets namespace. > >>>> > >>>> With the esnet namespace, this block of code only needs to > >>deal with > >>>> the RPH in determining which INVITEs to reject, and which > >to queue, > >>>> and how. > >>>> > >>>> But if there is no esnet namespace for RPH, then this > >block of code > >>>> would need to deal with BOTH the RPH and the URN. That would be a > >>>> completely unnecessary complication. > >>>> > >>>> Janet > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> > > > > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF153A6BBC for ; Mon, 9 Feb 2009 05:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju6ZR1bNAXl6 for ; Mon, 9 Feb 2009 05:53:15 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DEE793A67AE for ; Mon, 9 Feb 2009 05:53:14 -0800 (PST) Received: (qmail invoked by alias); 09 Feb 2009 13:46:37 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp012) with SMTP; 09 Feb 2009 14:46:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19A73o1gIhAU4VY3D7VhduwyY2fFvNrc7c6o6NuYZ m4daldFgLcgCQW From: "Hannes Tschofenig" To: "'Janet P Gunn'" , "'Brian Rosen'" References: <054601c98545$ccd81280$66883780$@net> Date: Mon, 9 Feb 2009 15:47:25 +0200 Message-ID: <011901c98abc$f172d810$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmFcdbm9wRihwACSKyhQJneXcFjnAFSm/5g X-Y-GMX-Trusted: 0 X-FuHaFi: 0.76 Cc: ecrit@ietf.org, ecrit-bounces@ietf.org Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 13:53:15 -0000 -- found this old mail in my inbox. Hi Janet, that's certainly true. The main problems are unregistered phones (unauthenticated emergency calls). Still, many regulators do not give clear signs that they would discontinue this practise and hence network operators are (in an phase of uncertainty) are prepared to support it. The latest example that I am aware of where a regulator indicates the demand for it comes from Canada. As such, I would argue that the situation between emergency email and (unauthenticated) emergency calls isn't all that different. Ciao Hannes ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: 02 February, 2009 22:07 To: Brian Rosen Cc: ecrit@ietf.org; ecrit-bounces@ietf.org; 'Hannes Tschofenig'; 'James M. Polk' Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? However, current PSTN emergency calls suffer from both "Emergency butt calls", and people making "Emergency" calls as a way of testing/demonstrating that an unsubscribed handset is functional (apparently a big problem in European "flea market" scenarios). Quite analogous to spam. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ecrit-bounces@ietf.org wrote on 02/02/2009 09:51:56 AM: > > > - had a HIGH likelihood of SPAM on the recepient's end > Increasingly true of SMS, but this is true, sadly > > > - SPAM could in general become the biggest issue wrt actually having > > someone at the PSAP have to "look" at each and every message because > > no one can build in the proper automated filters to cover all > > possible misspellings of a legitimate email message > No doubt about it. Not clear that is reason enough to kill the idea, but > it's certainly an issue. On the other hand, that would argue that no > improvement to email other than spam related improvements should be > accepted. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31D53A6A6A for ; Mon, 9 Feb 2009 08:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmVhQr9+1o7r for ; Mon, 9 Feb 2009 08:49:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BA3E13A6A48 for ; Mon, 9 Feb 2009 08:49:29 -0800 (PST) Received: (qmail invoked by alias); 09 Feb 2009 15:49:25 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 09 Feb 2009 16:49:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18fnopt6MEfdp76MPxtNDo73Wnja60N9ceRLlhMbw RluvsNqVwR9b+0 From: "Hannes Tschofenig" To: Date: Mon, 9 Feb 2009 17:50:14 +0200 Message-ID: <017301c98ace$1a18d1a0$0201a8c0@nsnintra.net> 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.3350 Thread-Index: AcmKzhkUZBM/AyChSmWdMt9/BOw/Pw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Cc: 'ext Gonzalo Camarillo' Subject: [Ecrit] Next steps for draft-patel-ecrit-sos-parameter-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 16:49:34 -0000 Hi all, After the 3GPP - IETF conference call last week I had a chat with Jon about the next steps regarding http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt As mentioned on the list we wanted to submit a re-charter proposal after the PhoneBCP document left the working group. It seems that this is not fast enough for the 3GPP folks. Jon offered to AD sponsor that document and I asked Gonzalo to be the expert reviewer for it. Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF743A6A6A for ; Mon, 9 Feb 2009 09:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.17 X-Spam-Level: X-Spam-Status: No, score=-105.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXaQCXUUR7FU for ; Mon, 9 Feb 2009 09:03:35 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 99E773A69A8 for ; Mon, 9 Feb 2009 09:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1234199018; x=1265735018; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20<14C85D6CCB E92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.co m>=0D=0A=20<000101c988ad$8ac92e90$0201a8c0@nsnintra.net> =0D=0A=20|Date:=20Mon,=209=20Feb=202009=2009:03:34=20-0800 |To:=20"James=20M.=20Polk"=20,=0D=0A=20 =20=20=20=20=20=20=20Hannes=20Tschofenig=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'DOLLY ,=20MARTIN=20C,=20=20ATTLABS'"=20,=0D=0A =20=20=20=20=20=20=20=20"hgs@cs.columbia.edu"=20,=0D=0A=20=20=20=20=20=20=20=20"James.Winterb ottom@andrew.com"=0D=0A=09 |From:=20Ted=20Hardie=20|Subject:=20 Re:=20[Ecrit]=20RPH|CC:=20"Tschofenig,=20Hannes=20(NSN=20 -=20FI/Espoo)"=20,=0D=0A=20=20 =20=20=20=20=20=20"ecrit@ietf.org"=20 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5520"=3B=20 a=3D"15347285"; bh=0IPforLVd9xGVbWCPIawwuJbPbznM07hB4y2gZBfbgo=; b=hLOR9n2C++g5xP6HajFElZkjiEUBESQH8Rqdby8EHYKASCxrsCqYf3/A m16IwQpC8eGk0/RkEIBroI1To7ZnyhKT1VRnhblXy4ObN15G6kEckaKWL uCxzRHIJMJSXllSFhf8P8X94VrmHHeRnyWtFf+n/w6/9gILretIMlY8d4 g=; X-IronPort-AV: E=McAfee;i="5300,2777,5520"; a="15347285" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2009 09:03:37 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19H3bw2010379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Feb 2009 09:03:37 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19H3a2s020583 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2009 09:03:36 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 09:03:36 -0800 Received: from [10.227.68.59] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 09:03:35 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> Date: Mon, 9 Feb 2009 09:03:34 -0800 To: "James M. Polk" , Hannes Tschofenig , "'DOLLY, MARTIN C, ATTLABS'" , "hgs@cs.columbia.edu" , "James.Winterbottom@andrew.com" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ecrit@ietf.org" Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:03:36 -0000 Howdy, After reading through the discussion through Monday morning and seeing a remarkable lack of convergence, I began wondering if the core of the issue isn't way back here: James Polk wrote: >Along comes a new ID that defines a new RP namespaces in SIP for >ECRIT, called "esnet". > >This new namespace is needed because the 5 header-values defined in >RFC 4412 do not match the usage for the ECRIT effort, therefore a new >one needs to be created. > >RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of >the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create >5 IANA registered namespaces (and associated priority-values). If the new RP namespace in SIP is only for ESNET, defining a header for it and describing what to do is both relatively trivial and, I would argue, pretty well understood. ESNET can be understood for this purpose as a closed network or a relatively tightly bound overlay. Defining the semantics for what happens in that network/for that overlay is clearly only up to those operating that network. The rest of us can ignore it, as the spec allows. Where we seem to have wrapped ourselves around the axles is whether this namespace is for *uses of ECRIT* rather than *ESNET nodes*. If it is for any use of ECRIT, then the semantics get a lot fuzzier (since there may be other mechanisms at play) and the apparent intention seems to be that every node that cares about ECRIT must understand ESNET markings. When I go back and look at draft-ietf-ecrit-local-emergency-rph-namespace-00, this text seems a major part of that: This new namespace can be from a caller in distress, or added at the entry server into an emergency services managed network, towards a public safety answering point (PSAP), i.e., the 911 or 112-based emergency services call taker. This new namespace can be used between PSAPs, and between a PSAP and first responders and their organizations. As a way forward, I suggest we separate out the PSAP--first responder/organizations use case and define only a namespace for that. If we need a second namespace for caller insertion/entry server insertion, we can create that. Strings are cheap. But there seems to be a long road ahead in combining the two, since the kinds of devices that have to care and the kinds of networks they may have to traverse seem different enough to hinder early consensus. regards, Ted Hardie Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7FA3A67DA for ; Mon, 9 Feb 2009 09:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeoi7puDWpYh for ; Mon, 9 Feb 2009 09:13:32 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 60DA43A69DC for ; Mon, 9 Feb 2009 09:13:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139822517" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 17:13:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19HDNdW021276; Mon, 9 Feb 2009 09:13:23 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19HDNpq016347; Mon, 9 Feb 2009 17:13:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:13:23 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:13:22 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 11:13:21 -0600 To: "Hannes Tschofenig" , "'DRAGE, Keith \(Keith\)'" From: "James M. Polk" In-Reply-To: <007501c988fe$9ec32670$0201a8c0@nsnintra.net> References: <000801c98708$5973f6f0$0201a8c0@nsnintra.net> <09fe01c98714$6acc7650$406562f0$@net> <001c01c98715$3900b360$0201a8c0@nsnintra.net> <0a1101c98716$91287db0$b3797910$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67499B647@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <009701c987c4$c3cb7340$0201a8c0@nsnintra.net> <000701c9883c$59b095d0$49b5b70a@nsnintra.net> <000001c988ac$d0261940$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67499BA12@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <007501c988fe$9ec32670$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 17:13:22.0963 (UTC) FILETIME=[B668D630:01C98AD9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=21176; t=1234199603; x=1235063603; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20ECRIT=20Virtual=20Interim=20Meeting=3A= 20Agenda=20(RPH=20&=20GETS) |Sender:=20; bh=UuP/2rjah9/54pO4cWfSNz84BcDOa2AMS40qUBRGWos=; b=ZG63V4uxfOB0jRxCEKwTivj3jbkTgKAq8/W8caA/pcKhNB71ZENv+twEs0 fhrOu6g3duofMxtPYSn5eOJcgGlpanDF+EVPa51NBtaUJK27Da9zUa7aeKvP VgtTK09XOANwBd3vSuLbbVWVDhmZk+uJtNJq4MoZOJHbo9f0ehQl0=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:13:34 -0000 At 02:32 AM 2/7/2009, Hannes Tschofenig wrote: > >I don't believe anyone has been saying that. GETS and > >emergency are two different namespaces that work within the > >overvall framework of RPH. > > > >You implement RPH, and then configure or tailor it to the > >namespaces you need to support, not provide a separate > >implementation for every namespace you are called upon to support. > > >This is exactly the trap Henning warned us during the last meeting. >Because the authorization handling is totally different (because of the >different context) you need to write different code. If you don't then you >introduce these security problems. > >The draft at least needs to contain a super big SECURITY WARNING so that >implements don't make that mistake. Currently it says "no security issues >beyond the initial RPH document". I've already agreed to write a more robust sec. cons. section just for the UAC insertion case... so please stop harping on this point -- unless I don't write it into the next version. >This is clearly wrong and even leads >experts like you to go along the wrong track. > > > > >Go that way and every request will take hours to traverse end to end. >Not sure what you mean. > >Ciao >Hannes > > > > >regards > > > >Keith > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Friday, February 06, 2009 10:47 PM > >> To: 'James M. Polk' > >> Cc: DRAGE, Keith (Keith); 'Brian Rosen'; Tschofenig, Hannes (NSN - > >> FI/Espoo); 'ECRIT' > >> Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) > >> > >> Good that you agree that GETS usage of RPH and the one we discuss in > >> ECRIT is different. > >> So far, some folks have been saying "what works for GETS > >works for the > >> ECRIT case as well". > >> > >> I argued that the environment is different and hence just > >referencing > >> RFC > >> 4412 isn't good enough. > >> > >> >-----Original Message----- > >> >From: James M. Polk [mailto:jmpolk@cisco.com] > >> >Sent: 07 February, 2009 00:02 > >> >To: Hannes Tschofenig > >> >Cc: 'DRAGE, Keith (Keith)'; 'Brian Rosen'; Tschofenig, > >Hannes (NSN - > >> >FI/Espoo); 'ECRIT' > >> >Subject: RE: ECRIT Virtual Interim Meeting: Agenda (RPH & GETS) > >> > > >> >At 03:21 AM 2/6/2009, Hannes Tschofenig wrote: > >> >>Hi James, > >> >> > >> >>I have read RFC 4412 and also the GETS/MLPP IETF documents. What I > >> >>would like to point out is that there is more than just a > >> header and > >> >>values within the header that have to be considered in order > >> >to make a > >> >>judgement of what is appropriate and what isn't. There is an > >> >>architectural question and whether the environment we are > >using the > >> >>stuff is indeed providing the properties you need for the > >> >solution to be appropriate. > >> >> > >> >>Let me describe in more detail what I meant (and please > >> >correct me if I > >> >>am wrong). > >> >> > >> >>Getting priority for SIP requests when using a GETS alike scenario > >> >>means that the entity that issues the request is specially > >> authorized > >> >>since otherwise you introduce a nice denial of service attack. > >> > > >> >You are missing a step in GETS here. The endpoint, who > >> sends the GETS > >> >set-up as an INVITE is not already authorized (not the > >> device, not the > >> >user). In North America, there is a 10 digit GETS number that is > >> >dialed (that I won't give out right now on an open list) - > >and there > >> >literally is only 1 number available to dial for this service. > >> >Literally anyone can dial this number today in North America > >> (no matter > >> >where the phone is - as long as it is in North America -- > >> and I might > >> >be too limiting in that it is dialable from anywhere, because it is > >> >going to a North American destination). > >> > > >> >Once this number is dialed, it is answered by an authentication and > >> >authorization IVR. This IVR challenges each caller for their > >> >authentication passcode, and a password). Once this has been > >> >successfully entered, then call is NOW authorized to > >proceed towards > >> >its destination number - this step is only known to the authorizing > >> >system because the destination 10 digit number is NOT entered until > >> >after the authentication and authorization step has completed. > >> > > >> >The authorized caller is prompted with a new dial tone - in > >> which they > >> >can enter any number on the planet and receive preferential > >> treatment > >> >through as many carriers (in IP, it's > >> >SPs) that have implemented this GETS service (which is an > >> SLA with the > >> >Department of Homeland Security now). > >> > > >> >Merely entering the GETS RP namespace is never intended, > >> alone, to gain > >> >any preferential treatment -- other than towards this > >> authentication & > >> >authorization IVR. > >> > > >> >I hope you can see that this is a completely separate type > >> of service > >> >and implementation type than ECRIT based emergency calling will use. > >> > > >> >BTW - to your comment below about me not calling your name > >> out when you > >> >are incorrect because I have been equally incorrect > >> >-- I'm not sure I've been spared as much as you think, given > >> that many > >> >have called me out by name when they've felt I've been wrong > >> over the > >> >years. > >> > > >> >>This authorization > >> >>is tied to the entity that makes the request. For example, > >> the person > >> >>is working for the government and has special rights. James > >> Bond as a > >> >>(not so) secret agent might have these rights. > >> >> > >> >>The emergency services case (citizen-to-authority) is a bit > >> different > >> >>as there aren't really special rights with respect to > >authorization > >> >>tied to individuals. Instead, the fact that something is an > >> emergency > >> >>is purely a judgement of the human that dials a special > >> >number. To deal > >> >>with fraud, we discussed in the group on what we can > >actually do to > >> >>ensure that end users do not bypass security procedures (such as > >> >>authorization checks, charging and so on). Part of this > >> investigation > >> >>was the publication of http://www.ietf.org/rfc/rfc5069.txt > >> >that also describes this issue. > >> >> > >> >>So, imagine the implementation of a SIP proxy (and we > >> implemented that > >> >>stuff) that receives a call that contains a Service URN. The code > >> >>branches into a special mode where everything is done so that > >> >the call > >> >>receives appropriate treatment and does not get dropped on > >> the floor. > >> >>The way how the Service URN is placed in the message > >> ensures that the > >> >>call cannot go to my friend (instead of the PSAP) unless > >> the end host > >> >>ran LoST already. In the latter case, we discussed this > >also on the > >> >>list for a while and Richard even wrote a draft about it in > >> >the context > >> >>of the location hiding topic, we said that the proxy would > >> >have to run > >> >>LoST if he cares about a potential fraudulent usage. > >> >> > >> >>So, what do we need todo in order to provide secure RFC 4412 > >> >>functionality in our context? > >> >> > >> >>Do you think that the current text in > >> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-eme > >> >rgency-rp > >> >>h-nam espace-00.txt reflects any of the above-described issues: > >> >>" > >> >> The Security considerations that apply to RFC 4412 > >> [RFC4412] apply > >> >> here. This document introduces no new security issues > >> relative to > >> >> RFC 4412. > >> >>" > >> >> > >> >> From various discussions in GEOPRIV I recall that you are > >> >>super-sensitive regarding security and privacy. For some > >> reasons you > >> >>don't seem to have the same concerns here. I would like to > >> >understand your reasoning. > >> >> > >> >>Please also do me another favor: Don't always say that I don't > >> >>understand the subject. Even if that would be the case it isn't > >> >>particular fair given that different folks had to educate you > >> >on other topics in the past as well. > >> >>Additionally, if you listen to the audio recordings then you will > >> >>notice that Henning, Ted, and Jon do not seem to understand > >> the issue > >> >>either as they have raised similar issues during the F2F meetings. > >> >> > >> >>Ciao > >> >>Hannes > >> >> > >> >> > >> >> >Hannes - I believe it is you who do not understand RFC > >> 4412 -- and > >> >> >many of us are trying to get that through to you, but you > >> >don't seem > >> >> >to want to listen/read. > >> >> > > >> >> >RFC 4412 is *for* priority marking SIP requests, > >> >> > > >> >> >One use is GETS. > >> >> > > >> >> >One use is MLPP. > >> >> > > >> >> >These examples are in RFC 4412 because there were specific > >> >namespaces > >> >> >being created for the IANA section of that document. > >> >> > > >> >> >Reading the whole document, you will see that RPH can be > >> specified > >> >> >for other uses than GETS or MLPP specifically. > >> >> > > >> >> >I knew when I wrote RFC 4412 that one day we would specify a > >> >> >namespace for ECRIT (the "esnet" namespace now) -- but I > >> >also knew it > >> >> >was premature for RFC 4412 to incorporate that namespace, that a > >> >> >future doc to RFC 4412 would have to be written to do this. > >> >Brian and > >> >> >I talked about this at the original NENA meeting that > >> >created the IP > >> >> >WGs there (in August of 03). We both agreed we should wait > >> >until it > >> >> >was appropriate to the work in the IETF to submit this > >> >document that > >> >> >is now > >> >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer > >> >> >gency-rph-namespace-00.txt > >> >> > > >> >> >Yet, you seem to want to use some additional mechanism to > >> indicate > >> >> >priority of a call in SIP. That means you want to > >> >introduce a second > >> >> >way to accomplish this in SIP. Why do you want to promote > >> >a separate > >> >> >way to do something SIP has already defined? That will cause > >> >> >interoperability issues and we both know that. > >> >> > > >> >> >You've said to me (and others) that you believe RPH is > >> just another > >> >> >way to accomplish what sos or a URI can indicate - and > >> >you're wrong. > >> >> >Your way would be _the_second_way_to_do_it, because SIP already > >> >> >considers RPH to be *the*way* to priority mark SIP requests. > >> >> > > >> >> >If you don't believe me (no comment), then why do you not > >> >believe the > >> >> >SIP WG chair (who knows more about SIP than both of us) > >- who, on > >> >> >this thread, has again said to you "RFC 4412 > >> >> >(RPH) is the SIP mechanism to priority mark SIP requests"? > >> >> > > >> >> >Further, I believe it is inappropriate to prohibit > >endpoints from > >> >> >being able to set the esnet namespace. I absolutely > >> >believe it will > >> >> >not be needed most of the time, but I believe if someone > >> >does find a > >> >> >valid use for endpoints to mark priority in SIP, this ID > >> - once it > >> >> >has become an RFC -- will have to be obsoleted with a new > >> >RFC saying > >> >> >the exact opposite. > >> >> > > >> >> >(color me confused ... over and over again) > >> >> > > >> >> >James > >> >> > > >> >> >At 01:05 PM 2/5/2009, Hannes Tschofenig wrote: > >> >> >>Keith, please understand that the usage of RFC 4412 for > >> >GETS and for > >> >> >>the type of emergency call we discuss here is different. Just > >> >> >>looking at the header and the name of the namespace is a bit > >> >> >artificial. I hope > >> >> >>you understand that. > >> >> >> > >> >> >> >-----Original Message----- > >> >> >> >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> >> >> >Sent: 05 February, 2009 14:55 > >> >> >> >To: Brian Rosen; 'Hannes Tschofenig'; 'James M. Polk'; > >> >> >> >'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> >> >> >Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: Agenda (my > >> >> >> >mistake) > >> >> >> > > >> >> >> >Which is exactly what RFC 4412 specifies for all namespaces. > >> >> >> > > >> >> >> >regards > >> >> >> > > >> >> >> >Keith > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >> >> >On Behalf > >> >> >> >> Of Brian Rosen > >> >> >> >> Sent: Wednesday, February 04, 2009 10:19 PM > >> >> >> >> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, > >> >> >Hannes (NSN > >> >> >> >> - FI/Espoo)'; 'ECRIT' > >> >> >> >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >> Agenda (my > >> >> >> >> mistake) > >> >> >> >> > >> >> >> >> The value is that in some networks where priority for > >> >> >> >emergency calls > >> >> >> >> is appropriate, and appropriate policing of marking is > >> >> >implemented, > >> >> >> >> emergency calls will receive resource priority. > >> >> >> >> > >> >> >> >> Not all networks would need policing. Some will. Policing > >> >> >> >> could be to Route header/R-URI content, but other > >> >criteria are possible. > >> >> >> >> > >> >> >> >> Not all networks will need resource priority for > >> >emergency calls. > >> >> >> >> Fine, ignore this marking/namespace. > >> >> >> >> > >> >> >> >> Brian > >> >> >> >> > -----Original Message----- > >> >> >> >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> >> >> > Sent: Wednesday, February 04, 2009 5:09 PM > >> >> >> >> > To: 'Brian Rosen'; 'James M. Polk'; Tschofenig, > >> >Hannes (NSN - > >> >> >> >> > FI/Espoo); 'ECRIT' > >> >> >> >> > Subject: RE: [Ecrit] ECRIT Virtual Interim Meeting: > >> >Agenda (my > >> >> >> >> > mistake) > >> >> >> >> > > >> >> >> >> > I don't even see the value in permitting the > >> >endpoint todo the > >> >> >> >> > RPH marking. > >> >> >> >> > In addition to the security concerns there is also the > >> >> >> >problem that > >> >> >> >> > there are more options to implement without an > >> >additional value. > >> >> >> >> > > >> >> >> >> > >-----Original Message----- > >> >> >> >> > >From: Brian Rosen [mailto:br@brianrosen.net] > >> >> >> >> > >Sent: 05 February, 2009 00:03 > >> >> >> >> > >To: 'James M. Polk'; 'Hannes Tschofenig'; 'Tschofenig, > >> >> >> >> Hannes (NSN - > >> >> >> >> > >FI/Espoo)'; 'ECRIT' > >> >> >> >> > >Subject: RE: [Ecrit] ECRIT Virtual Interim > >> Meeting: Agenda > >> >> >> >> > >(my > >> >> >> >> > mistake) > >> >> >> >> > > > >> >> >> >> > >Hannes > >> >> >> >> > > > >> >> >> >> > >This matches my understanding precisely. We wish to > >> >> >> >> permit endpoints > >> >> >> >> > >to mark. We do not require it, and don't > >> necessarily expect > >> >> >> >> > >it in many (even > >> >> >> >> > >most) cases. We don't wish to see the document > >> prohibit it. > >> >> >> >> > >We all seem to agree it has value within the Emergency > >> >> >> >Services IP > >> >> >> >> > >Networks. > >> >> >> >> > > > >> >> >> >> > >Brian > >> >> >> >> > > > >> >> >> >> > >> -----Original Message----- > >> >> >> >> > >> From: ecrit-bounces@ietf.org > >> >> >> >> > >> [mailto:ecrit-bounces@ietf.org] > >> >> >> >> > >On Behalf > >> >> >> >> > >> Of James M. Polk > >> >> >> >> > >> Sent: Wednesday, February 04, 2009 4:01 PM > >> >> >> >> > >> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - > >> >> >> >> FI/Espoo); 'ECRIT' > >> >> >> >> > >> Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: > >> >> >Agenda (my > >> >> >> >> > >> mistake) > >> >> >> >> > >> > >> >> >> >> > >> At 02:37 PM 2/4/2009, Hannes Tschofenig wrote: > >> >> >> >> > >> > > James wrote: > >> >> >> >> > >> > >> you are the _lone_ voice not supporting this ID, > >> >> >> >> > >> > > >> >> >> >> > >> >Listening to the audio recording of past > >> meetings I have > >> >> >> >> > >> >to > >> >> >> >> > >say that > >> >> >> >> > >> >I > >> >> >> >> > >> was > >> >> >> >> > >> >not the only persons raising concerns about > >> the document. > >> >> >> >> > >> >That was probably the reason why you agreed to > >> limit the > >> >> >> >> > >scope of the > >> >> >> >> > >> >document (which you didn't later do) to get > >> >folks to agree > >> >> >> >> > >to make it > >> >> >> >> > >> a WG > >> >> >> >> > >> >item. > >> >> >> >> > >> > >> >> >> >> > >> re-listen to the audio please > >> >> >> >> > >> > >> >> >> >> > >> Ted's concerns were consistent with most (all?) other > >> >> >> >> concerns -- > >> >> >> >> > >> which were based on the premise of whether or not the > >> >> >> >> UAC should be > >> >> >> >> > >> trusted to initiate the marking on the INVITE. > >> The most > >> >> >> >> > >> recent version has backed off this to a "can" > >> -- meaning > >> >> >> >> > >> not > >> >> >> >prohibited > >> >> >> >> > >> (i.e., no 2119 text). I also backed off the > >text in the > >> >> >> >> SP domain > >> >> >> >> > >> part to "can", such that there is no 2119 text > >> >> >> >mandating or even > >> >> >> >> > >> recommending its usage there. I also do not > >prohibit its > >> >> >> >> > >use, based on > >> >> >> >> > >> local policy. Keith has come forward with the > >specific > >> >> >> >> > >> request that non-ESInet networks be allowed to > >> >mark and pay > >> >> >> >attention to > >> >> >> >> > >> this priority indication -- with IMS as the specific > >> >> >> >> > >> example he wishes to have this valid for. > >> >> >> >> > >> > >> >> >> >> > >> Where there is no disagreement, save for your recent > >> >> >> >> > >pushback - is in > >> >> >> >> > >> the ESInet, which is where Brian has requested it's > >> >> >> >> > >definition in the > >> >> >> >> > >> IETF on behalf of NENA. He's the i3 WG chair within > >> >> >> >> NENA, and if > >> >> >> >> > >> he asks for it, are you going to say you know > >> >better than he? > >> >> >> >> > >> > >> >> >> >> > >> > >> >> >> >> > >> >Btw, I not disagreeing with the document as such. I > >> >> >> >just want to > >> >> >> >> > the > >> >> >> >> > >> scope > >> >> >> >> > >> >to change. The usage of RPH within the emergency > >> >> >> >> services network > >> >> >> >> > is > >> >> >> >> > >> fine > >> >> >> >> > >> >for me. I may get convinced to start the RPH > >> marking from > >> >> >> >> > >the the VSP > >> >> >> >> > >> >towards the PSAP. I feel uneasy about the end > >> host doing > >> >> >> >> > >the marking. > >> >> >> >> > >> > >> >> >> >> > >> please read what I wrote above, and then re-read the > >> >> >> >most recent > >> >> >> >> > >> version of the ID. I don't have endpoints that > >SHOULD or > >> >> >> >> MUST mark > >> >> >> >> > >> anything wrt RPH. I also don't want to prohibit it, > >> >> >> >> because there > >> >> >> >> > >> might be cases (that I don't know of) of valid uses > >> >> >> >> under certain > >> >> >> >> > >> circumstances. Figure 1 is very clear that there are 3 > >> >> >> >> networking > >> >> >> >> > >> parts to consider > >> >> >> >> > >> > >> >> >> >> > >> #1 - from the endpoint > >> >> >> >> > >> #2 - within the VSP > >> >> >> >> > >> #3 - within the ESInet > >> >> >> >> > >> > >> >> >> >> > >> the most recent ID version has "can" for #s 1 > >and 2, and > >> >> >> >> > >2119 language > >> >> >> >> > >> offering those supporting this specification will > >> >have RPH > >> >> >> >> > >> adherence within #3 (the ESInet). > >> >> >> >> > >> > >> >> >> >> > >> What other scope changes do you want, because I haven't > >> >> >> >> heard them. > >> >> >> >> > >> > >> >> >> >> > >> I only heard you claim in email during the last > >> >IETF and in > >> >> >> >> > >the ECRIT > >> >> >> >> > >> session that RPH should not be used for > >priority marking > >> >> >> >> requests. > >> >> >> >> > >> This is something Keith (SIP WG chair) voiced his > >> >> >> >> > >> opposition to your views regarding creating a > >> >second means > >> >> >> >> > >> for SIP to > >> >> >> >priority > >> >> >> >> > >> mark request "when SIP already has one > >> >interoperable way to > >> >> >> >> > >> accomplish this... it's call the RP header mechanism". > >> >> >> >> > >> > >> >> >> >> > >> >I don't see advantages -- only disadvantages. > >> >> >> >> > >> > > >> >> >> >> > >> >Ciao > >> >> >> >> > >> >Hannes > >> >> >> >> > >> > >> >> >> >> > >> _______________________________________________ > >> >> >> >> > >> Ecrit mailing list > >> >> >> >> > >> Ecrit@ietf.org > >> >> >> >> > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> >> > > > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Ecrit mailing list > >> >> >> >> Ecrit@ietf.org > >> >> >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> >> >> > >> >> >> > > >> >> > > >> > > >> > >> > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84483A6944; Mon, 9 Feb 2009 09:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUpiYyZVCoFC; Mon, 9 Feb 2009 09:20:53 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EC01E3A6AB3; Mon, 9 Feb 2009 09:20:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="133964773" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2009 17:20:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n19HKsLm017853; Mon, 9 Feb 2009 09:20:54 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19HKsb1014982; Mon, 9 Feb 2009 17:20:54 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:20:54 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:20:54 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 11:20:52 -0600 To: "Hannes Tschofenig" , "'Janet P Gunn'" From: "James M. Polk" In-Reply-To: <004801c989d2$65eb0b90$0201a8c0@nsnintra.net> References: <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> <004801c989d2$65eb0b90$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 17:20:54.0103 (UTC) FILETIME=[C34F5670:01C98ADA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3784; t=1234200054; x=1235064054; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Semantics=20=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=10UvIGfxunJkirSj9EEpywLN1mfR7mfgoRDJXRuuNzI=; b=E03KOsEFrU/sNVX1n1a8FhEVmLRFYn/hBxHZc4CozE0qv6MBqVcF715VYc 1cEf3+F+Hi8MmiftayfxhDsxP40EraTJODc/6PClnjX4M6N4FQr/j4b6Rrwr 71l/kuldfn; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:20:54 -0000 At 03:48 AM 2/8/2009, Hannes Tschofenig wrote: >Hi Janet, > >thanks for your text. I think I am getting a better understanding of the >scenarios you have in mind. > >Let me comment inline (search for [hannes]): > > Consider the hypothetical, but plausible, case of a network with an >explicit call/capacity admission process, in which both 911-type-emergency >calls and GETS calls get preferential admission treatment. By the time the >INVITE gets to this Functional Module/ block of code, all authentication, >authorization, and changes/confirmation of the destination have already >taken place. All this block of code deals with is call/capacity admission. > > For the sake of argument, suppose this is the nature of the >preference. > > 1) For INVITEs without RPH, or with an RPH this network does not >use/understand, if the admission process fails, the INVITE fails > >[hannes] This is the non-emergency case, I suspect. Section 4.6.2 of RFC >4412 discusses when to fail an INVITE if the RPH marking is not understood. >It does not always fail. > > 2) For INVITEs with RPH with the ets namespace, if the admission >process initially fails, the INVITE is put in queue until the resources >become available so it can be admitted. > > 3) For INVITEs with RPH with the esnet namespace, if the admission >process initially fails, the INVITE is put in queue, but at lower priority >than the calls with the ets namespace. > >[hannes] Is this an INVITE for an emergecy call? I suspect, yes. What >priority is given to the emergency call in relationship to the calls with >the ETS namespace is a local policy matter? this is always a local policy decision - and cannot go into any IETF doc, other than to remind everyone that "the relative priority order rules of section 8 of RFC 4412 MUST be maintained". >Or: would you like to put a >description of it into >draft-ietf-ecrit-local-emergency-rph-namespace-00.txt? > >What happens with an non-emergency call invite that has the esnet RPH >marking? Does it get the emergency call treatement? > > > With the esnet namespace, this block of code only needs to deal with >the RPH in determining which INVITEs to reject, and which to queue, and how. > > >[hannes] You talk about rejecting the INVITE: Emergency calls do not get >rejected regardless of the RPH marking. this statement is assuming all emergency calls do in fact get through -- and that is simply not the case today, so what basis are you making this argument from? > > But if there is no esnet namespace for RPH, then this block of code >would need to deal with BOTH the RPH and the URN. That would be a >completely unnecessary complication. > >[hannes] Are you saying that you wouldn't look at the Service URN / dial >string when the esnet RPH namespace is present? > > >I believe I now better understand what you (and maybe James and Keith) want >to accomplish. > > >You would like to allow the VSP to have two types of emergency calls: >* "normal" emergency calls that would be placed in a queue as they arrive > (These are the calls that are only marked as emergency calls using a >Service URN > or contain a special dial string.) >* esnet RPH marked emergency calls that would skip other calls in the queue >(if there is a queue and this queue contains non-emergency calls). These >calls are sort of better than the "normal" emergency calls. > >Did I correctly understand it? Is this the scenario you had in mind with the >esnet RPH mechanism? > >If someone would like to create two classes of emergency calls in that >fashion then additional marking would be justified. > >Ciao >Hannes > > Janet > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47AC33A6AF7 for ; Mon, 9 Feb 2009 09:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQAEIPENwS-P for ; Mon, 9 Feb 2009 09:36:19 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E31DE3A6B08 for ; Mon, 9 Feb 2009 09:36:18 -0800 (PST) Received: (qmail invoked by alias); 09 Feb 2009 17:36:06 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 09 Feb 2009 18:36:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18LdnlknSsLPtB6ClurYZt4etiupjdOZCfKx1Eov3 cOGACqQHoNgefk From: "Hannes Tschofenig" To: "'Ted Hardie'" , "'James M. Polk'" , "'DOLLY, MARTIN C, ATTLABS'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> Date: Mon, 9 Feb 2009 19:36:49 +0200 Message-ID: <01c701c98add$00aea1e0$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmK2FpXH9Qas32lRRuKLwzp946nKgABGHnw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:36:20 -0000 You captured the discussion quite well. Separating out the PSAP--first responder/organizations use case and define only a namespace for that sounds good to me and would reflect what James had agreed to a while ago. Ciao Hannes >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: 09 February, 2009 19:04 >To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C, >ATTLABS'; hgs@cs.columbia.edu; James.Winterbottom@andrew.com >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org >Subject: Re: [Ecrit] RPH > >Howdy, > After reading through the discussion through Monday >morning and seeing a remarkable lack of convergence, I began >wondering if the core of the issue isn't way back here: > >James Polk wrote: >>Along comes a new ID that defines a new RP namespaces in SIP >for ECRIT, >>called "esnet". >> >>This new namespace is needed because the 5 header-values >defined in RFC >>4412 do not match the usage for the ECRIT effort, therefore a new one >>needs to be created. >> >>RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of >>the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create >>5 IANA registered namespaces (and associated priority-values). > > >If the new RP namespace in SIP is only for ESNET, defining a >header for it and describing what to do is both relatively >trivial and, I would argue, pretty well understood. ESNET can >be understood for this purpose as a closed network or a >relatively tightly bound overlay. Defining the semantics for >what happens in that network/for that overlay is clearly only >up to those operating that network. The rest of us can ignore >it, as the spec allows. > >Where we seem to have wrapped ourselves around the axles is >whether this namespace is for *uses of ECRIT* rather than >*ESNET nodes*. If it is for any use of ECRIT, then the >semantics get a lot fuzzier (since there may be other >mechanisms at play) and the apparent intention seems to be >that every node that cares about ECRIT must understand ESNET markings. >When I go back and look at >draft-ietf-ecrit-local-emergency-rph-namespace-00, >this text seems a major part of that: > > This new namespace can be from a caller in > distress, or added at the entry server into an emergency services > managed network, towards a public safety answering point (PSAP), > i.e., the 911 or 112-based emergency services call taker. This > new namespace can be used between PSAPs, and between a PSAP and > first responders and their organizations. > >As a way forward, I suggest we separate out the PSAP--first >responder/organizations use case and define only a namespace >for that. If we need a second namespace for caller >insertion/entry server insertion, we can create that. Strings >are cheap. >But there seems to be a long road ahead in combining the two, >since the kinds of devices that have to care and the kinds of >networks they may have to traverse seem different enough to >hinder early consensus. > > regards, > Ted Hardie > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855FB3A6AF7 for ; Mon, 9 Feb 2009 09:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bda8B7R2PbnT for ; Mon, 9 Feb 2009 09:41:17 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 173C03A6AB3 for ; Mon, 9 Feb 2009 09:41:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="130066534" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2009 17:41:19 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19HfJeb024004; Mon, 9 Feb 2009 09:41:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19HfJ0S005584; Mon, 9 Feb 2009 17:41:19 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:41:18 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:41:18 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 11:41:17 -0600 To: "Hannes Tschofenig" , "'DOLLY, MARTIN C, ATTLABS'" , , From: "James M. Polk" In-Reply-To: <004901c989ef$302749c0$0201a8c0@nsnintra.net> References: <14C85D6CCBE92743AF33663BF5D24EBA01238F71@gaalpa1msgusr7e.ugd.att.com> <004901c989ef$302749c0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 17:41:18.0400 (UTC) FILETIME=[9D0C3C00:01C98ADD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9914; t=1234201279; x=1235065279; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=leOIFxuu2BxtY7M3KzbISqTRf3IUO1IY/GJrJOTd0p4=; b=Qw2SG58ZPR/siMMnQfRECplkYR5VX9vlo6X9f5eXL9FeS5Owe8csWFFFc9 CyO+lSnQSIaVIr1vF4NwXQsV2jQL14gj2yz/q6+8Kcv8O2Qtm6RTzhzFtyuE Y9pBmscK1E9MKVNuB4Wi7yqkSyPyrai6FbN6hE8v1T33prmJkpYFs=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:41:18 -0000 At 07:14 AM 2/8/2009, Hannes Tschofenig wrote: >Hi Martin, > >Thanks for the quick response. > >I am aware of these network access authentication and authorization >procedures (including the authentication and authorization procedure at the >SIP layer). They are clearly important for some of the RPH usage scenarios. > >For this specific case (the new esnet RPH mechanism) there are additional >facets that needs to be considered (beyond the above-mentioned security >aspects): > >* What does the esnet RPH usage mean in the context of an emergency call >(for example, in comparison to an emergency call without esnet RPH usage)? > >* For emergency calls the authorization procedures are different than with >regular calls. There are certainly differences to the GETS-alike calls as >well. (We ignore for a moment that there are these unauthenticated emergency >calls where even the authentication procedure is missing.) The current >security consideration section does not acknowledge these differences. > >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace >captures some of these aspects to allow those who implement and deploy the >esnet RPH mechanism to understand what it does and how to correctly >implement it. I wholly disagree with this desire. This draft-ietf-ecrit-local-emergency-rph-namespace creates the namespace, it does not create the associated semantics for use of this namespace that are specific to NENA or EENA. That is up to NENA or EENA to specify. It is also up to the AT&T's and Verizon's of the world to define what the exact semantics are within their respective networks are to satisfy whatever regulations they have in their local jurisdictions (which are different from each other -- and what the IETF knows nothing about). For example, each group of emergency callers thinks *their* type of emergency should get preferential treatment over other types of emergencies. To be specific, which type of emergency call is more important: a GETS type call or a 911/112 type call? It is not up to the IETF to decide that. It is up to the local policies of the jurisdiction and the SP to figure that out. This is not inconsistent with RFC 4412 - in fact, RFC 4412 built this aspect into its text. The esnet namespace should follow RFC 4412's guidelines in coordination with those from the local authorities and the local SPs to determine how they are going to configure their operations. At that point, it's up to the local SP to buy products from vendors that can meet the requirements of that local configuration. Therefore, draft-ietf-ecrit-local-emergency-rph-namespace should not have any additional text articulating guidance how to configure their networks. RFC 4412 defines all the guidance they need at this time. When operational experience proves something ought to be modified within that guidance, then a new doc should be written suggesting that/those modification(s). >Ciao >Hannes > >PS: There are details that also need to be discussed. For example, which >esnet value would the device use for an emergency call? "esnet.0", >"esnet.1", "esnet.2", "esnet.3", "esnet.4". Out-of-scope is a possible >answer but it will not help the implementer in doing it's job. see the very same explanation above as to why this isn't something that ought be in an IETF doc. >Is there a >specific default value (maybe the highest value, just to be sure)? there is not, and choosing one the highest or lowest value limits adjustments and the "what if we determine one day something else is actually more important" question. >Would the UA get provisioned to pick a specific value? if this were in scope of this doc, I'd suggest this be done through something like RFC 3841 "SIP Call Preferences" >What is the provisioning mechanism? this depends on the choice, but Caller Prefs has a mechanism. >Is there a relationship between the esnet values and the Service URN values? should there be? I don't know, and think this is a local (matrix) matter -- or a NENA/EENA matter >Do the urn:service:counseling:* services get a lower priority than >the urn:service:sos:* services? only if local policy gives urn:service:counseling:* any priority, then local policy will determine what priority in relation to sos. Remember - some of these decisions will be based on the capacity (BW and # of call takers) within the local jurisdiction -- which is again something the IETF cannot give guidance on at this point , if ever > >Hannes, > > > >We need to understand the attachment of the UE to the network. > >There is an AA process prior to allowing any use. Without this > >we would not trust the RPH, even for ETS, never mind 911 > > > >Martin > > > >----- Original Message ----- > >From: Hannes Tschofenig > >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >; jgunn6@csc.com > >Cc: ecrit@ietf.org > >Sent: Sun Feb 08 04:32:25 2009 > >Subject: RE: [Ecrit] Semantics Re: RPH > > > >Hi Martin, > > > >Your remarks are a bit a short. > > > >Clearly, authentication and authorization can come in different forms. > >This was actually one of the discussion we had so far that the > >authorization mechanisms for the GETS RPH and the proposed > >ECRIT RPH is different. > > > >So, could you elaborate a bit? > > > >Ciao > >Hannes > > > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >>Of DOLLY, MARTIN C, ATTLABS > >>Sent: 07 February, 2009 19:30 > >>To: hgs@cs.columbia.edu; jgunn6@csc.com > >>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org > >>Subject: Re: [Ecrit] Semantics Re: RPH > >> > >>Do you have a clue dude? A+A of an user comes in many forms. > >> > >>----- Original Message ----- > >>From: ecrit-bounces@ietf.org > >>To: Janet P Gunn > >>Cc: ECRIT ; ecrit-bounces@ietf.org > >> > >>Sent: Sat Feb 07 11:56:42 2009 > >>Subject: Re: [Ecrit] Semantics Re: RPH > >> > >>Please see my earlier message as to why your approach fails > >for the UA- > >>inserted case where not all emergency calls have RPH > >markings. I think > >>it would be a really bad idea if emergency calls with RPH are treated > >>differently than emergency calls without it. (Again, I'm > >talking about > >>the user-initiated calls. An ESNET can do whatever it wants and can > >>assign extra priority to calls from citizens that have bought PBA > >>stickers or zip codes that pay more taxes, but that's a separate > >>problem.) > >> > >>I also don't believe your implementation logic. A much better > >approach > >>is to semantically declare the class of call early on (e.g., based on > >>the URN or after authentication/authorization), and make that part of > >>the call state record, rather than hunt for headers each time a > >>handling decision needs to be made. Given the authorization > >>requirements, just looking at "has header X" is never going to be > >>sufficient anyway. > >> > >>Henning > >> > >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > >> > >>> > >>> > >>> . > >>> > >>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > >>> > >>> > PLEASE try to understand that the syntax is similar (header, new > >>> namespace, > >>> > new values) > >>> > BUT the semantic is different. > >>> > > >>> > For all message it is true that the sender can add whatever they > >>> want. The > >>> > big question is what does it mean for the recipient. > >>> > > >>> > This is what the discussion is about. > >>> > > >>> On the contrary, the semantic is, or at least can be, very similar. > >>> > >>> Consider the hypothetical, but plausible, case of a network with an > >>> explicit call/capacity admission process, in which both 911-type- > >>> emergency calls and GETS calls get preferential admission > >>treatment. > >>> By the time the INVITE gets to this Functional Module/ block > >>of code, > >>> all authentication, authorization, and changes/ confirmation of the > >>> destination have already taken place. All this block of code deals > >>> with is call/capacity admission. > >>> > >>> For the sake of argument, suppose this is the nature of the > >>> preference. > >>> > >>> 1) For INVITEs without RPH, or with an RPH this network does > >>not use/ > >>> understand, if the admission process fails, the INVITE fails > >>> > >>> 2) For INVITEs with RPH with the ets namespace, if the admission > >>> process initially fails, the INVITE is put in queue until the > >>> resources become available so it can be admitted. > >>> > >>> 3) For INVITEs with RPH with the esnet namespace, if the admission > >>> process initially fails, the INVITE is put in queue, but at lower > >>> priority than the calls with the ets namespace. > >>> > >>> With the esnet namespace, this block of code only needs to > >deal with > >>> the RPH in determining which INVITEs to reject, and which to queue, > >>> and how. > >>> > >>> But if there is no esnet namespace for RPH, then this block of code > >>> would need to deal with BOTH the RPH and the URN. That would be a > >>> completely unnecessary complication. > >>> > >>> Janet > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D753A68B9 for ; Mon, 9 Feb 2009 09:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVbNw4Y19BOY for ; Mon, 9 Feb 2009 09:49:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13FC83A67D4 for ; Mon, 9 Feb 2009 09:49:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="245927754" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2009 17:49:14 +0000 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 n19HnEpF010906; Mon, 9 Feb 2009 09:49:14 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19HnEQA018418; Mon, 9 Feb 2009 17:49:14 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:49:14 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:49:13 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 11:49:12 -0600 To: "Hannes Tschofenig" , "'DOLLY, MARTIN C, ATTLABS'" , , From: "James M. Polk" In-Reply-To: <005101c98a1d$686ba6e0$0201a8c0@nsnintra.net> References: <14C85D6CCBE92743AF33663BF5D24EBA01238F74@gaalpa1msgusr7e.ugd.att.com> <005101c98a1d$686ba6e0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 17:49:13.0916 (UTC) FILETIME=[B87A37C0:01C98ADE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8762; t=1234201754; x=1235065754; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=TFWg91MI53N5sLIQ9GhbubctIQJZRyS8h+hcN74TOcg=; b=lv63tKoIg7Q1ftTyMpSpk3ZEU7IqQrbTRl92e9yAQkF6rYFfNIpecNAehj DVguDOcjIR1chBHR0gcYTKP6r923PWJnVGn4YavySLbD/J18UVWB4xKfz0xa 34Aq80sNDB; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:49:13 -0000 At 12:45 PM 2/8/2009, Hannes Tschofenig wrote: >Not sure what you mean. > >Let me ask you a basic question that we have been struggling with for some >time in this discussion that Janet recently highlighted: > >How do you treat an esnet RPH marked 9-1-1 call in comparison to a 9-1-1 >call that does not have the esnet RPH marking? this is a local policy issue -- that might include a contractual aspect (i.e., all GETS SLAs will be based on contracts). It certainly isn't up to the IETF >In what sense does the >processing in the SIP proxy differ? > >Ciao >Hannes > > >-----Original Message----- > >From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > >Sent: 08 February, 2009 16:02 > >To: Hannes.Tschofenig@gmx.net; hgs@cs.columbia.edu; jgunn6@csc.com > >Cc: ecrit@ietf.org > >Subject: Re: [Ecrit] Semantics Re: RPH > > > >These are the rule, not the exception. I do not care about the > >internet free scenarios. > > > >----- Original Message ----- > >From: Hannes Tschofenig > >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >; jgunn6@csc.com > >Cc: ecrit@ietf.org > >Sent: Sun Feb 08 08:14:32 2009 > >Subject: RE: [Ecrit] Semantics Re: RPH > > > >Hi Martin, > > > >Thanks for the quick response. > > > >I am aware of these network access authentication and > >authorization procedures (including the authentication and > >authorization procedure at the SIP layer). They are clearly > >important for some of the RPH usage scenarios. > > > >For this specific case (the new esnet RPH mechanism) there are > >additional facets that needs to be considered (beyond the > >above-mentioned security > >aspects): > > > >* What does the esnet RPH usage mean in the context of an > >emergency call (for example, in comparison to an emergency > >call without esnet RPH usage)? > > > >* For emergency calls the authorization procedures are > >different than with regular calls. There are certainly > >differences to the GETS-alike calls as well. (We ignore for a > >moment that there are these unauthenticated emergency calls > >where even the authentication procedure is missing.) The > >current security consideration section does not acknowledge > >these differences. > > > >It would be helpful that draft-ietf-ecrit-local-emergency-rph-namespace > >captures some of these aspects to allow those who implement > >and deploy the esnet RPH mechanism to understand what it does > >and how to correctly implement it. > > > >Ciao > >Hannes > > > >PS: There are details that also need to be discussed. For > >example, which esnet value would the device use for an > >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", > >"esnet.4". Out-of-scope is a possible answer but it will not > >help the implementer in doing it's job. Is there a specific > >default value (maybe the highest value, just to be sure)? > >Would the UA get provisioned to pick a specific value? What is > >the provisioning mechanism? Is there a relationship between > >the esnet values and the Service URN values? Do the > >urn:service:counseling:* services get a lower priority > >than the urn:service:sos:* services? > > > >>Hannes, > >> > >>We need to understand the attachment of the UE to the network. > >>There is an AA process prior to allowing any use. Without > >this we would > >>not trust the RPH, even for ETS, never mind 911 > >> > >>Martin > >> > >>----- Original Message ----- > >>From: Hannes Tschofenig > >>To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >>; jgunn6@csc.com > >>Cc: ecrit@ietf.org > >>Sent: Sun Feb 08 04:32:25 2009 > >>Subject: RE: [Ecrit] Semantics Re: RPH > >> > >>Hi Martin, > >> > >>Your remarks are a bit a short. > >> > >>Clearly, authentication and authorization can come in > >different forms. > >>This was actually one of the discussion we had so far that the > >>authorization mechanisms for the GETS RPH and the proposed > >ECRIT RPH is > >>different. > >> > >>So, could you elaborate a bit? > >> > >>Ciao > >>Hannes > >> > >>>-----Original Message----- > >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>On Behalf > >>>Of DOLLY, MARTIN C, ATTLABS > >>>Sent: 07 February, 2009 19:30 > >>>To: hgs@cs.columbia.edu; jgunn6@csc.com > >>>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org > >>>Subject: Re: [Ecrit] Semantics Re: RPH > >>> > >>>Do you have a clue dude? A+A of an user comes in many forms. > >>> > >>>----- Original Message ----- > >>>From: ecrit-bounces@ietf.org > >>>To: Janet P Gunn > >>>Cc: ECRIT ; ecrit-bounces@ietf.org > >>> > >>>Sent: Sat Feb 07 11:56:42 2009 > >>>Subject: Re: [Ecrit] Semantics Re: RPH > >>> > >>>Please see my earlier message as to why your approach fails > >>for the UA- > >>>inserted case where not all emergency calls have RPH > >>markings. I think > >>>it would be a really bad idea if emergency calls with RPH > >are treated > >>>differently than emergency calls without it. (Again, I'm > >>talking about > >>>the user-initiated calls. An ESNET can do whatever it wants and can > >>>assign extra priority to calls from citizens that have bought PBA > >>>stickers or zip codes that pay more taxes, but that's a separate > >>>problem.) > >>> > >>>I also don't believe your implementation logic. A much better > >>approach > >>>is to semantically declare the class of call early on (e.g., > >based on > >>>the URN or after authentication/authorization), and make > >that part of > >>>the call state record, rather than hunt for headers each time a > >>>handling decision needs to be made. Given the authorization > >>>requirements, just looking at "has header X" is never going to be > >>>sufficient anyway. > >>> > >>>Henning > >>> > >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > >>> > >>>> > >>>> > >>>> . > >>>> > >>>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > >>>> > >>>> > PLEASE try to understand that the syntax is similar (header, new > >>>> namespace, > >>>> > new values) > >>>> > BUT the semantic is different. > >>>> > > >>>> > For all message it is true that the sender can add whatever they > >>>> want. The > >>>> > big question is what does it mean for the recipient. > >>>> > > >>>> > This is what the discussion is about. > >>>> > > >>>> On the contrary, the semantic is, or at least can be, very similar. > >>>> > >>>> Consider the hypothetical, but plausible, case of a > >network with an > >>>> explicit call/capacity admission process, in which both 911-type- > >>>> emergency calls and GETS calls get preferential admission > >>>treatment. > >>>> By the time the INVITE gets to this Functional Module/ block > >>>of code, > >>>> all authentication, authorization, and changes/ > >confirmation of the > >>>> destination have already taken place. All this block of > >code deals > >>>> with is call/capacity admission. > >>>> > >>>> For the sake of argument, suppose this is the nature of the > >>>> preference. > >>>> > >>>> 1) For INVITEs without RPH, or with an RPH this network does > >>>not use/ > >>>> understand, if the admission process fails, the INVITE fails > >>>> > >>>> 2) For INVITEs with RPH with the ets namespace, if the admission > >>>> process initially fails, the INVITE is put in queue until the > >>>> resources become available so it can be admitted. > >>>> > >>>> 3) For INVITEs with RPH with the esnet namespace, if the admission > >>>> process initially fails, the INVITE is put in queue, but at lower > >>>> priority than the calls with the ets namespace. > >>>> > >>>> With the esnet namespace, this block of code only needs to > >>deal with > >>>> the RPH in determining which INVITEs to reject, and which > >to queue, > >>>> and how. > >>>> > >>>> But if there is no esnet namespace for RPH, then this > >block of code > >>>> would need to deal with BOTH the RPH and the URN. That would be a > >>>> completely unnecessary complication. > >>>> > >>>> Janet > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31923A6A91 for ; Mon, 9 Feb 2009 09:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSx2UGDOUlVS for ; Mon, 9 Feb 2009 09:52:06 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 694823A6911 for ; Mon, 9 Feb 2009 09:52:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139842294" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 17:52:08 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19Hq5AE014850; Mon, 9 Feb 2009 09:52:05 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19Hq5EV022076; Mon, 9 Feb 2009 17:52:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:52:05 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:52:04 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 11:52:03 -0600 To: "Hannes Tschofenig" , "'Janet P Gunn'" From: "James M. Polk" In-Reply-To: <007901c98a88$e0c2add0$0201a8c0@nsnintra.net> References: <005101c98a1d$686ba6e0$0201a8c0@nsnintra.net> <007901c98a88$e0c2add0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 17:52:04.0760 (UTC) FILETIME=[1E4EF180:01C98ADF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11832; t=1234201928; x=1235065928; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=o2qKbQ+ki0o2rv7LzKN/f/nsUfI3irYVw8I3QCuSFjQ=; b=WFhf8AbdBItJ+p9Fj9Rx0Dlt/07inf1zOFKhGkkJF9jQHrvqcXoDJ6dq6B A2E+0Fo4UpiZ1cIviDdsySXWnYFke4jggtXRB1slxxemz3h733Bj0wWusSE9 Rp4BzkND6v/mxGSpDRZMwaaEf0W2bxi5gBDMx6ifPIiVl90umt3jQ=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:52:08 -0000 At 01:34 AM 2/9/2009, Hannes Tschofenig wrote: >I could have guessed the response already. > >I believe that the draft would benefit from a few sentences that describes >what "local policy" decisions the operator deploying this mechanism has to >make. how does that satisfy any, much less all operators' questions -- other than referring to the relative priority order section (8) - as well as other text contained within RFC 4412? >Ciao >Hannes > >________________________________ > > From: Janet P Gunn [mailto:jgunn6@csc.com] > Sent: 08 February, 2009 22:13 > To: Hannes Tschofenig > Cc: ecrit@ietf.org; hgs@cs.columbia.edu; 'DOLLY, MARTIN C, ATTLABS' > Subject: RE: [Ecrit] Semantics Re: RPH > > > > > > Up to local policy. > > Janet > > "Hannes Tschofenig" wrote on 02/08/2009 >01:45:21 PM: > > > Not sure what you mean. > > > > Let me ask you a basic question that we have been struggling with >for some > > time in this discussion that Janet recently highlighted: > > > > How do you treat an esnet RPH marked 9-1-1 call in comparison to a >9-1-1 > > call that does not have the esnet RPH marking? In what sense does >the > > processing in the SIP proxy differ? > > > > Ciao > > Hannes > > > > >-----Original Message----- > > >From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > >Sent: 08 February, 2009 16:02 > > >To: Hannes.Tschofenig@gmx.net; hgs@cs.columbia.edu; >jgunn6@csc.com > > >Cc: ecrit@ietf.org > > >Subject: Re: [Ecrit] Semantics Re: RPH > > > > > >These are the rule, not the exception. I do not care about the > > >internet free scenarios. > > > > > >----- Original Message ----- > > >From: Hannes Tschofenig > > >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > > >; jgunn6@csc.com > > >Cc: ecrit@ietf.org > > >Sent: Sun Feb 08 08:14:32 2009 > > >Subject: RE: [Ecrit] Semantics Re: RPH > > > > > >Hi Martin, > > > > > >Thanks for the quick response. > > > > > >I am aware of these network access authentication and > > >authorization procedures (including the authentication and > > >authorization procedure at the SIP layer). They are clearly > > >important for some of the RPH usage scenarios. > > > > > >For this specific case (the new esnet RPH mechanism) there are > > >additional facets that needs to be considered (beyond the > > >above-mentioned security > > >aspects): > > > > > >* What does the esnet RPH usage mean in the context of an > > >emergency call (for example, in comparison to an emergency > > >call without esnet RPH usage)? > > > > > >* For emergency calls the authorization procedures are > > >different than with regular calls. There are certainly > > >differences to the GETS-alike calls as well. (We ignore for a > > >moment that there are these unauthenticated emergency calls > > >where even the authentication procedure is missing.) The > > >current security consideration section does not acknowledge > > >these differences. > > > > > >It would be helpful that >draft-ietf-ecrit-local-emergency-rph-namespace > > >captures some of these aspects to allow those who implement > > >and deploy the esnet RPH mechanism to understand what it does > > >and how to correctly implement it. > > > > > >Ciao > > >Hannes > > > > > >PS: There are details that also need to be discussed. For > > >example, which esnet value would the device use for an > > >emergency call? "esnet.0", "esnet.1", "esnet.2", "esnet.3", > > >"esnet.4". Out-of-scope is a possible answer but it will not > > >help the implementer in doing it's job. Is there a specific > > >default value (maybe the highest value, just to be sure)? > > >Would the UA get provisioned to pick a specific value? What is > > >the provisioning mechanism? Is there a relationship between > > >the esnet values and the Service URN values? Do the > > >urn:service:counseling:* services get a lower priority > > >than the urn:service:sos:* services? > > > > > >>Hannes, > > >> > > >>We need to understand the attachment of the UE to the network. > > >>There is an AA process prior to allowing any use. Without > > >this we would > > >>not trust the RPH, even for ETS, never mind 911 > > >> > > >>Martin > > >> > > >>----- Original Message ----- > > >>From: Hannes Tschofenig > > >>To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > > >>; jgunn6@csc.com > > >>Cc: ecrit@ietf.org > > >>Sent: Sun Feb 08 04:32:25 2009 > > >>Subject: RE: [Ecrit] Semantics Re: RPH > > >> > > >>Hi Martin, > > >> > > >>Your remarks are a bit a short. > > >> > > >>Clearly, authentication and authorization can come in > > >different forms. > > >>This was actually one of the discussion we had so far that the > > >>authorization mechanisms for the GETS RPH and the proposed > > >ECRIT RPH is > > >>different. > > >> > > >>So, could you elaborate a bit? > > >> > > >>Ciao > > >>Hannes > > >> > > >>>-----Original Message----- > > >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > >>On Behalf > > >>>Of DOLLY, MARTIN C, ATTLABS > > >>>Sent: 07 February, 2009 19:30 > > >>>To: hgs@cs.columbia.edu; jgunn6@csc.com > > >>>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org > > >>>Subject: Re: [Ecrit] Semantics Re: RPH > > >>> > > >>>Do you have a clue dude? A+A of an user comes in many forms. > > >>> > > >>>----- Original Message ----- > > >>>From: ecrit-bounces@ietf.org > > >>>To: Janet P Gunn > > >>>Cc: ECRIT ; ecrit-bounces@ietf.org > > >>> > > >>>Sent: Sat Feb 07 11:56:42 2009 > > >>>Subject: Re: [Ecrit] Semantics Re: RPH > > >>> > > >>>Please see my earlier message as to why your approach fails > > >>for the UA- > > >>>inserted case where not all emergency calls have RPH > > >>markings. I think > > >>>it would be a really bad idea if emergency calls with RPH > > >are treated > > >>>differently than emergency calls without it. (Again, I'm > > >>talking about > > >>>the user-initiated calls. An ESNET can do whatever it wants and >can > > >>>assign extra priority to calls from citizens that have bought >PBA > > >>>stickers or zip codes that pay more taxes, but that's a >separate > > >>>problem.) > > >>> > > >>>I also don't believe your implementation logic. A much better > > >>approach > > >>>is to semantically declare the class of call early on (e.g., > > >based on > > >>>the URN or after authentication/authorization), and make > > >that part of > > >>>the call state record, rather than hunt for headers each time a > > > >>>handling decision needs to be made. Given the authorization > > >>>requirements, just looking at "has header X" is never going to >be > > >>>sufficient anyway. > > >>> > > >>>Henning > > >>> > > >>>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > > >>> > > >>>> > > >>>> > > >>>> . > > >>>> > > >>>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > > >>>> > > >>>> > PLEASE try to understand that the syntax is similar >(header, new > > >>>> namespace, > > >>>> > new values) > > >>>> > BUT the semantic is different. > > >>>> > > > >>>> > For all message it is true that the sender can add whatever >they > > >>>> want. The > > >>>> > big question is what does it mean for the recipient. > > >>>> > > > >>>> > This is what the discussion is about. > > >>>> > > > >>>> On the contrary, the semantic is, or at least can be, very >similar. > > >>>> > > >>>> Consider the hypothetical, but plausible, case of a > > >network with an > > >>>> explicit call/capacity admission process, in which both >911-type- > > >>>> emergency calls and GETS calls get preferential admission > > >>>treatment. > > >>>> By the time the INVITE gets to this Functional Module/ block > > >>>of code, > > >>>> all authentication, authorization, and changes/ > > >confirmation of the > > >>>> destination have already taken place. All this block of > > >code deals > > >>>> with is call/capacity admission. > > >>>> > > >>>> For the sake of argument, suppose this is the nature of the > > >>>> preference. > > >>>> > > >>>> 1) For INVITEs without RPH, or with an RPH this network does > > >>>not use/ > > >>>> understand, if the admission process fails, the INVITE fails > > >>>> > > >>>> 2) For INVITEs with RPH with the ets namespace, if the >admission > > >>>> process initially fails, the INVITE is put in queue until the > > > >>>> resources become available so it can be admitted. > > >>>> > > >>>> 3) For INVITEs with RPH with the esnet namespace, if the >admission > > >>>> process initially fails, the INVITE is put in queue, but at >lower > > >>>> priority than the calls with the ets namespace. > > >>>> > > >>>> With the esnet namespace, this block of code only needs to > > >>deal with > > >>>> the RPH in determining which INVITEs to reject, and which > > >to queue, > > >>>> and how. > > >>>> > > >>>> But if there is no esnet namespace for RPH, then this > > >block of code > > >>>> would need to deal with BOTH the RPH and the URN. That would >be a > > >>>> completely unnecessary complication. > > >>>> > > >>>> Janet > > >>> > > >>>_______________________________________________ > > >>>Ecrit mailing list > > >>>Ecrit@ietf.org > > >>>https://www.ietf.org/mailman/listinfo/ecrit > > >>>_______________________________________________ > > >>>Ecrit mailing list > > >>>Ecrit@ietf.org > > >>>https://www.ietf.org/mailman/listinfo/ecrit > > >>> > > >> > > >> > > > > > > > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA503A6911 for ; Mon, 9 Feb 2009 09:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psIQI5o33lGa for ; Mon, 9 Feb 2009 09:55:12 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C19EC3A6866 for ; Mon, 9 Feb 2009 09:55:11 -0800 (PST) Received: (qmail invoked by alias); 09 Feb 2009 17:48:19 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 09 Feb 2009 18:48:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Qymcx3n0QJruL51iBtbh31CpxCDrSBKjSbn6zbG jK16H4mX/Npe/x From: "Hannes Tschofenig" To: "'James M. Polk'" , "'Janet P Gunn'" References: <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> <004801c989d2$65eb0b90$0201a8c0@nsnintra.net> Date: Mon, 9 Feb 2009 19:48:56 +0200 Message-ID: <01c801c98ade$b59cba50$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmK2sY6eEDu4BOuTyKjI3BYqucowAAAnQFA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:55:12 -0000 >>[hannes] You talk about rejecting the INVITE: Emergency calls do not >>get rejected regardless of the RPH marking. > >this statement is assuming all emergency calls do in fact get through >-- and that is simply not the case today, so what basis are >you making this argument from? > I would always mark my emergency calls with the highest priority (currently "esnet.4") since they are really important to me (hopefully the software marks without asking me as a caller in stress). If they still don't get through then the marking was not of much help either. Maybe we need more priority levels. We could serve the highest values just for us :-) (This is a joke!) Seriously, you need to explain how RPH marking would help against rejected emergency calls. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186583A6AFE for ; Mon, 9 Feb 2009 10:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrspBzps0egc for ; Mon, 9 Feb 2009 10:06:14 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 12A4F3A6AF7 for ; Mon, 9 Feb 2009 10:06:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="130075792" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2009 18:06:16 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19I6Ggk018479; Mon, 9 Feb 2009 10:06:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19I6Glb022510; Mon, 9 Feb 2009 18:06:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 10:06:16 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 10:06:15 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 12:06:14 -0600 To: Ted Hardie , Hannes Tschofenig , "'DOLLY, MARTIN C, ATTLABS'" , "hgs@cs.columbia.edu" , "James.Winterbottom@andrew.com" From: "James M. Polk" In-Reply-To: References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 18:06:15.0900 (UTC) FILETIME=[19A099C0:01C98AE1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3631; t=1234202776; x=1235066776; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=IJbhf16k1R59lr7mmZBt6qH3ucBS3Su1cxsBiELPc1o=; b=XzniXQ3EVrWfIa9Oppp3ZeM9xjDG+5i0yN6Iud3gPPShwqoRuGxD70YRwo LThYV9OKUbJ28pmj7tbns8eDswDveKj9WryiTMVmBJ8wUxVD2UfNWgHdrT3h fxtkMGa1Nkp+Onloy2ASgGMtpdej5wfaGmnvGjcI2t4X04H0aGKWw=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ecrit@ietf.org" Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:06:15 -0000 Ted -- comments at the bottom At 11:03 AM 2/9/2009, Ted Hardie wrote: >Howdy, > After reading through the discussion through Monday morning >and seeing a remarkable lack of convergence, I began wondering if >the core of the issue isn't way back here: > >James Polk wrote: > >Along comes a new ID that defines a new RP namespaces in SIP for > >ECRIT, called "esnet". > > > >This new namespace is needed because the 5 header-values defined in > >RFC 4412 do not match the usage for the ECRIT effort, therefore a new > >one needs to be created. > > > >RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of > >the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create > >5 IANA registered namespaces (and associated priority-values). > > >If the new RP namespace in SIP is only for ESNET, defining a header for it >and describing what to do is both relatively trivial and, I would argue, >pretty well understood. ESNET can be understood for this purpose as >a closed network or a relatively tightly bound overlay. Defining the >semantics for what happens in that network/for that overlay is clearly >only up to those operating that network. The rest of us can ignore it, >as the spec allows. > >Where we seem to have wrapped ourselves around the axles is whether >this namespace is for *uses of ECRIT* rather than *ESNET nodes*. If >it is for any use of ECRIT, then the semantics get a lot fuzzier (since there >may be other mechanisms at play) and the apparent intention seems to >be that every node that cares about ECRIT must understand ESNET markings. >When I go back and look at draft-ietf-ecrit-local-emergency-rph-namespace-00, >this text seems a major part of that: > > This new namespace can be from a caller in > distress, or added at the entry server into an emergency services > managed network, towards a public safety answering point (PSAP), > i.e., the 911 or 112-based emergency services call taker. This > new namespace can be used between PSAPs, and between a PSAP and > first responders and their organizations. > >As a way forward, I suggest we separate out the PSAP--first >responder/organizations >use case and define only a namespace for that. If we need a second namespace >for caller insertion/entry server insertion, we can create >that. Strings are cheap. >But there seems to be a long road ahead in combining the two, since the kinds >of devices that have to care and the kinds of networks they may have >to traverse >seem different enough to hinder early consensus. While I generally agree with you -- until you imply that the two namespaces ought go be in separate docs that have to meet somewhere future somewhere in the middle of the network. Please let me know if I've misread what you meant to say. On this, I have two thoughts: #1 - that several vendors and SPs have already asked for this namespace to be possible in their respective VSP products and service offerings - and your implied solution blows that up. and #2 - that creating (in the future) a second namespace to map directly to the esnet (and it's 5 priority-values) from the UAC or VSP seems like it might be begging for a lack of interoperability waiting to happen type of problem. I can definitely rewrite the text emphasizing the esnet namespace is for the ESInet first, with the possibility of having it come in from a reliable VSP, and even a reliable UAC/UE off that reliable VSP. > regards, > Ted Hardie Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD68F28C12D for ; Mon, 9 Feb 2009 10:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqkNGqhhPQcK for ; Mon, 9 Feb 2009 10:07:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E22943A6B8D for ; Mon, 9 Feb 2009 10:07:23 -0800 (PST) Received: (qmail invoked by alias); 09 Feb 2009 18:07:24 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp007) with SMTP; 09 Feb 2009 19:07:24 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19x2Lwwa4Nx2Mugg3lT2jWbtrEQss3uOO6x32h5Yu vqXdWhE0QHWfzD From: "Hannes Tschofenig" To: "'James M. Polk'" , "'DOLLY, MARTIN C, ATTLABS'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F71@gaalpa1msgusr7e.ugd.att.com> <004901c989ef$302749c0$0201a8c0@nsnintra.net> Date: Mon, 9 Feb 2009 20:08:01 +0200 Message-ID: <01cc01c98ae1$60518640$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmK3Z6YOPNg9SbnQSOK+npHcOJXcQAAQ/3Q X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:07:26 -0000 >>It would be helpful that >draft-ietf-ecrit-local-emergency-rph-namespace >>captures some of these aspects to allow those who implement >and deploy >>the esnet RPH mechanism to understand what it does and how to >correctly >>implement it. > >I wholly disagree with this desire. This >draft-ietf-ecrit-local-emergency-rph-namespace creates the >namespace, it does not create the associated semantics for use >of this namespace that are specific to NENA or EENA. That is >up to NENA or EENA to specify. It is also up to the AT&T's >and Verizon's of the world to define what the exact semantics >are within their respective networks are to satisfy whatever >regulations they have in their local jurisdictions (which are >different from each other -- and what the IETF knows nothing about). > >For example, each group of emergency callers thinks *their* >type of emergency should get preferential treatment over other >types of emergencies. To be specific, which type of emergency >call is more >important: a GETS type call or a 911/112 type call? I agree that this is a policy decision (as long as my emergency call with an inappropriate marking does not get dropped). What I was asking for is to describe the difference in authorization handling. > >It is not up to the IETF to decide that. It is up to the local >policies of the jurisdiction and the SP to figure that out. >This is not inconsistent with RFC 4412 - in fact, RFC 4412 >built this aspect into its text. > >The esnet namespace should follow RFC 4412's guidelines in >coordination with those from the local authorities and the >local SPs to determine how they are going to configure their >operations. At that point, it's up to the local SP to buy >products from vendors that can meet the requirements of that >local configuration. This does not work when you have end points doing this stuff since these end devices can be used everywhere. An operator can for sure decide to buy a box that does fancy marking techniques and offers different ways to configure the box todo so. No doubt. > >Therefore, draft-ietf-ecrit-local-emergency-rph-namespace >should not have any additional text articulating guidance how >to configure their networks. RFC 4412 defines all the guidance >they need at this time. > >When operational experience proves something ought to be >modified within that guidance, then a new doc should be >written suggesting that/those modification(s). When I wrote, for example, the following sentence: #* What does the esnet RPH usage mean in the context of an emergency #call (for example, in comparison to an emergency call without esnet RPH usage)? I was hoping that someone would think about the possible "local policy settings" that could make sense. If an emergency call with the esnet RPH marking gets treated better than an emergency call without such a marking then someone might come up with the idea of marking every emergency call with the highest priority. If everyone does this then the purpose of the priority system is lost. Treating an emergency call with an esnet RPH marking worse than one without it wouldn't make a lot of sense since otherwise nobody would do the marking anymore. Treating an emergency call with an esnet RPH marking in the same fashion as other emergency calls would defeat the purpose of the additional marking. The above-mentioned cases assume that the SIP UA vendor (or someone else configuring the marking) knows the local policy at the VSP. If it is not known at all and all the above cases are equally likely then it does not make sense to mark the call. Not so trivial to come up with something useful. Ciao Hannes >>Ciao >>Hannes >> >>PS: There are details that also need to be discussed. For example, >>which esnet value would the device use for an emergency call? >>"esnet.0", "esnet.1", "esnet.2", "esnet.3", "esnet.4". >Out-of-scope is >>a possible answer but it will not help the implementer in >doing it's job. > >see the very same explanation above as to why this isn't >something that ought be in an IETF doc. > >>Is there a >>specific default value (maybe the highest value, just to be sure)? > >there is not, and choosing one the highest or lowest value >limits adjustments and the "what if we determine one day >something else is actually more important" question. > >>Would the UA get provisioned to pick a specific value? > >if this were in scope of this doc, I'd suggest this be done >through something like RFC 3841 "SIP Call Preferences" > >>What is the provisioning mechanism? > >this depends on the choice, but Caller Prefs has a mechanism. > >>Is there a relationship between the esnet values and the >Service URN values? > >should there be? > >I don't know, and think this is a local (matrix) matter -- or >a NENA/EENA matter > >>Do the urn:service:counseling:* services get a lower priority >than the >>urn:service:sos:* services? > >only if local policy gives urn:service:counseling:* any >priority, then local policy will determine what priority in >relation to sos. > >Remember - some of these decisions will be based on the >capacity (BW and # of call takers) within the local >jurisdiction -- which is again something the IETF cannot give >guidance on at this point , if ever > > >> >Hannes, >> > >> >We need to understand the attachment of the UE to the network. >> >There is an AA process prior to allowing any use. Without this we >> >would not trust the RPH, even for ETS, never mind 911 >> > >> >Martin >> > >> >----- Original Message ----- >> >From: Hannes Tschofenig >> >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu >> >; jgunn6@csc.com >> >Cc: ecrit@ietf.org >> >Sent: Sun Feb 08 04:32:25 2009 >> >Subject: RE: [Ecrit] Semantics Re: RPH >> > >> >Hi Martin, >> > >> >Your remarks are a bit a short. >> > >> >Clearly, authentication and authorization can come in >different forms. >> >This was actually one of the discussion we had so far that the >> >authorization mechanisms for the GETS RPH and the proposed >ECRIT RPH >> >is different. >> > >> >So, could you elaborate a bit? >> > >> >Ciao >> >Hannes >> > >> >>-----Original Message----- >> >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >>Of DOLLY, MARTIN C, ATTLABS >> >>Sent: 07 February, 2009 19:30 >> >>To: hgs@cs.columbia.edu; jgunn6@csc.com >> >>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org >> >>Subject: Re: [Ecrit] Semantics Re: RPH >> >> >> >>Do you have a clue dude? A+A of an user comes in many forms. >> >> >> >>----- Original Message ----- >> >>From: ecrit-bounces@ietf.org >> >>To: Janet P Gunn >> >>Cc: ECRIT ; ecrit-bounces@ietf.org >> >> >> >>Sent: Sat Feb 07 11:56:42 2009 >> >>Subject: Re: [Ecrit] Semantics Re: RPH >> >> >> >>Please see my earlier message as to why your approach fails >> >for the UA- >> >>inserted case where not all emergency calls have RPH >> >markings. I think >> >>it would be a really bad idea if emergency calls with RPH are >> >>treated differently than emergency calls without it. (Again, I'm >> >talking about >> >>the user-initiated calls. An ESNET can do whatever it >wants and can >> >>assign extra priority to calls from citizens that have bought PBA >> >>stickers or zip codes that pay more taxes, but that's a separate >> >>problem.) >> >> >> >>I also don't believe your implementation logic. A much better >> >approach >> >>is to semantically declare the class of call early on (e.g., based >> >>on the URN or after authentication/authorization), and make that >> >>part of the call state record, rather than hunt for headers each >> >>time a handling decision needs to be made. Given the authorization >> >>requirements, just looking at "has header X" is never going to be >> >>sufficient anyway. >> >> >> >>Henning >> >> >> >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: >> >> >> >>> >> >>> >> >>> . >> >>> >> >>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: >> >>> >> >>> > PLEASE try to understand that the syntax is similar >(header, new >> >>> namespace, >> >>> > new values) >> >>> > BUT the semantic is different. >> >>> > >> >>> > For all message it is true that the sender can add >whatever they >> >>> want. The >> >>> > big question is what does it mean for the recipient. >> >>> > >> >>> > This is what the discussion is about. >> >>> > >> >>> On the contrary, the semantic is, or at least can be, >very similar. >> >>> >> >>> Consider the hypothetical, but plausible, case of a network with >> >>> an explicit call/capacity admission process, in which both >> >>> 911-type- emergency calls and GETS calls get preferential >> >>> admission >> >>treatment. >> >>> By the time the INVITE gets to this Functional Module/ block >> >>of code, >> >>> all authentication, authorization, and changes/ confirmation of >> >>> the destination have already taken place. All this >block of code >> >>> deals with is call/capacity admission. >> >>> >> >>> For the sake of argument, suppose this is the nature of the >> >>> preference. >> >>> >> >>> 1) For INVITEs without RPH, or with an RPH this network does >> >>not use/ >> >>> understand, if the admission process fails, the INVITE fails >> >>> >> >>> 2) For INVITEs with RPH with the ets namespace, if the admission >> >>> process initially fails, the INVITE is put in queue until the >> >>> resources become available so it can be admitted. >> >>> >> >>> 3) For INVITEs with RPH with the esnet namespace, if the >admission >> >>> process initially fails, the INVITE is put in queue, but >at lower >> >>> priority than the calls with the ets namespace. >> >>> >> >>> With the esnet namespace, this block of code only needs to >> >deal with >> >>> the RPH in determining which INVITEs to reject, and which to >> >>> queue, and how. >> >>> >> >>> But if there is no esnet namespace for RPH, then this block of >> >>> code would need to deal with BOTH the RPH and the URN. >That would >> >>> be a completely unnecessary complication. >> >>> >> >>> Janet >> >> >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > >> > >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1B728C120 for ; Mon, 9 Feb 2009 10:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq3ufPXWMFG5 for ; Mon, 9 Feb 2009 10:17:53 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7E12D28C118 for ; Mon, 9 Feb 2009 10:17:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139855487" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 18:17:56 +0000 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 n19IHuZ0014804; Mon, 9 Feb 2009 10:17:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19IHtpN027286; Mon, 9 Feb 2009 18:17:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 10:17:55 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 10:17:55 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 12:17:51 -0600 To: "Hannes Tschofenig" , "'Ted Hardie'" , "'DOLLY, MARTIN C, ATTLABS'" , , From: "James M. Polk" In-Reply-To: <01c701c98add$00aea1e0$0201a8c0@nsnintra.net> References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> <01c701c98add$00aea1e0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 18:17:55.0322 (UTC) FILETIME=[BA83EDA0:01C98AE2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3627; t=1234203476; x=1235067476; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20RPH |Sender:=20; bh=67axeFuLWoZePi2If6y4FnyIvxcFEtJMxZ6gf2DxvLM=; b=avnH1WhViOV86+AZ0Fb8sgzwIKhZooyKBpto6vUrJntcZUGATtYBqlABsb 03OdjM2PRoBD+/XSAE4HprTdDSAQT5f8OlRaPBKbuLWFlQOX6D7+Ak6+E5d+ I7bRq9ayYb; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:17:54 -0000 At 11:36 AM 2/9/2009, Hannes Tschofenig wrote: >You captured the discussion quite well. > >Separating out the PSAP--first responder/organizations use case and define >only a namespace for that sounds good to me and would reflect what James had >agreed to a while ago. When I agree to it, several folks asked me not to limit this namespace's usage to just within the ESInet -- and that's why it remains a possibility in the VSP (though not a SHOULD or a MUST implement, but a "can"), and whatever UAC/UE the VSP wants to vouch for. >Ciao >Hannes > > >-----Original Message----- > >From: Ted Hardie [mailto:hardie@qualcomm.com] > >Sent: 09 February, 2009 19:04 > >To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C, > >ATTLABS'; hgs@cs.columbia.edu; James.Winterbottom@andrew.com > >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > >Subject: Re: [Ecrit] RPH > > > >Howdy, > > After reading through the discussion through Monday > >morning and seeing a remarkable lack of convergence, I began > >wondering if the core of the issue isn't way back here: > > > >James Polk wrote: > >>Along comes a new ID that defines a new RP namespaces in SIP > >for ECRIT, > >>called "esnet". > >> > >>This new namespace is needed because the 5 header-values > >defined in RFC > >>4412 do not match the usage for the ECRIT effort, therefore a new one > >>needs to be created. > >> > >>RFCV 4412 is not tied to GETS and MLPP, it is tied to the creation of > >>the idea of "RESOURCE-PRIORITY" in SIP, *and* - it happens to create > >>5 IANA registered namespaces (and associated priority-values). > > > > > >If the new RP namespace in SIP is only for ESNET, defining a > >header for it and describing what to do is both relatively > >trivial and, I would argue, pretty well understood. ESNET can > >be understood for this purpose as a closed network or a > >relatively tightly bound overlay. Defining the semantics for > >what happens in that network/for that overlay is clearly only > >up to those operating that network. The rest of us can ignore > >it, as the spec allows. > > > >Where we seem to have wrapped ourselves around the axles is > >whether this namespace is for *uses of ECRIT* rather than > >*ESNET nodes*. If it is for any use of ECRIT, then the > >semantics get a lot fuzzier (since there may be other > >mechanisms at play) and the apparent intention seems to be > >that every node that cares about ECRIT must understand ESNET markings. > >When I go back and look at > >draft-ietf-ecrit-local-emergency-rph-namespace-00, > >this text seems a major part of that: > > > > This new namespace can be from a caller in > > distress, or added at the entry server into an emergency services > > managed network, towards a public safety answering point (PSAP), > > i.e., the 911 or 112-based emergency services call taker. This > > new namespace can be used between PSAPs, and between a PSAP and > > first responders and their organizations. > > > >As a way forward, I suggest we separate out the PSAP--first > >responder/organizations use case and define only a namespace > >for that. If we need a second namespace for caller > >insertion/entry server insertion, we can create that. Strings > >are cheap. > >But there seems to be a long road ahead in combining the two, > >since the kinds of devices that have to care and the kinds of > >networks they may have to traverse seem different enough to > >hinder early consensus. > > > > regards, > > Ted Hardie > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1D93A6866 for ; Mon, 9 Feb 2009 10:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6gZojJE4gn7 for ; Mon, 9 Feb 2009 10:23:38 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id C69A83A67D4 for ; Mon, 9 Feb 2009 10:23:37 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n19INNc7012348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2009 19:23:23 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 9 Feb 2009 19:23:23 +0100 From: "DRAGE, Keith (Keith)" To: "James M. Polk" , Hannes Tschofenig , "'DOLLY, MARTIN C, ATTLABS'" , "hgs@cs.columbia.edu" , "jgunn6@csc.com" Date: Mon, 9 Feb 2009 19:23:21 +0100 Thread-Topic: [Ecrit] Semantics Re: RPH Thread-Index: AcmK3bIJkLXqXXkBSoijeFuxWxTttgABcVTA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6749D6976@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <14C85D6CCBE92743AF33663BF5D24EBA01238F71@gaalpa1msgusr7e.ugd.att.com> <004901c989ef$302749c0$0201a8c0@nsnintra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:23:39 -0000 Concur with James. Keith=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of James M. Polk > Sent: Monday, February 09, 2009 5:41 PM > To: Hannes Tschofenig; 'DOLLY, MARTIN C, ATTLABS';=20 > hgs@cs.columbia.edu; jgunn6@csc.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Semantics Re: RPH >=20 > At 07:14 AM 2/8/2009, Hannes Tschofenig wrote: > >Hi Martin, > > > >Thanks for the quick response. > > > >I am aware of these network access authentication and authorization=20 > >procedures (including the authentication and authorization=20 > procedure at=20 > >the SIP layer). They are clearly important for some of the=20 > RPH usage scenarios. > > > >For this specific case (the new esnet RPH mechanism) there are=20 > >additional facets that needs to be considered (beyond the=20 > >above-mentioned security > >aspects): > > > >* What does the esnet RPH usage mean in the context of an emergency=20 > >call (for example, in comparison to an emergency call=20 > without esnet RPH usage)? > > > >* For emergency calls the authorization procedures are=20 > different than=20 > >with regular calls. There are certainly differences to the=20 > GETS-alike=20 > >calls as well. (We ignore for a moment that there are these=20 > >unauthenticated emergency calls where even the=20 > authentication procedure=20 > >is missing.) The current security consideration section does=20 > not acknowledge these differences. > > > >It would be helpful that=20 > draft-ietf-ecrit-local-emergency-rph-namespace > >captures some of these aspects to allow those who implement=20 > and deploy=20 > >the esnet RPH mechanism to understand what it does and how=20 > to correctly=20 > >implement it. >=20 > I wholly disagree with this desire. This=20 > draft-ietf-ecrit-local-emergency-rph-namespace creates the=20 > namespace, it does not create the associated semantics for=20 > use of this namespace that are specific to NENA or EENA. That=20 > is up to NENA or EENA to specify. It is also up to the=20 > AT&T's and Verizon's of the world to define what the exact=20 > semantics are within their respective networks are to satisfy=20 > whatever regulations they have in their local jurisdictions=20 > (which are different from each other -- and what the IETF=20 > knows nothing about). >=20 > For example, each group of emergency callers thinks *their*=20 > type of emergency should get preferential treatment over=20 > other types of emergencies. To be specific, which type of=20 > emergency call is more > important: a GETS type call or a 911/112 type call? >=20 > It is not up to the IETF to decide that. It is up to the=20 > local policies of the jurisdiction and the SP to figure that=20 > out. This is not inconsistent with RFC 4412 - in fact, RFC=20 > 4412 built this aspect into its text. >=20 > The esnet namespace should follow RFC 4412's guidelines in=20 > coordination with those from the local authorities and the=20 > local SPs to determine how they are going to configure their=20 > operations. At that point, it's up to the local SP to buy=20 > products from vendors that can meet the requirements of that=20 > local configuration. >=20 > Therefore, draft-ietf-ecrit-local-emergency-rph-namespace=20 > should not have any additional text articulating guidance how=20 > to configure their networks. RFC 4412 defines all the=20 > guidance they need at this time. >=20 > When operational experience proves something ought to be=20 > modified within that guidance, then a new doc should be=20 > written suggesting that/those modification(s). >=20 >=20 > >Ciao > >Hannes > > > >PS: There are details that also need to be discussed. For example,=20 > >which esnet value would the device use for an emergency call?=20 > >"esnet.0", "esnet.1", "esnet.2", "esnet.3", "esnet.4".=20 > Out-of-scope is=20 > >a possible answer but it will not help the implementer in=20 > doing it's job. >=20 > see the very same explanation above as to why this isn't=20 > something that ought be in an IETF doc. >=20 > >Is there a > >specific default value (maybe the highest value, just to be sure)? >=20 > there is not, and choosing one the highest or lowest value=20 > limits adjustments and the "what if we determine one day=20 > something else is actually more important" question. >=20 > >Would the UA get provisioned to pick a specific value? >=20 > if this were in scope of this doc, I'd suggest this be done=20 > through something like RFC 3841 "SIP Call Preferences" >=20 > >What is the provisioning mechanism? >=20 > this depends on the choice, but Caller Prefs has a mechanism. >=20 > >Is there a relationship between the esnet values and the=20 > Service URN values? >=20 > should there be? >=20 > I don't know, and think this is a local (matrix) matter -- or=20 > a NENA/EENA matter >=20 > >Do the urn:service:counseling:* services get a lower=20 > priority than the=20 > >urn:service:sos:* services? >=20 > only if local policy gives urn:service:counseling:* any=20 > priority, then local policy will determine what priority in=20 > relation to sos. >=20 > Remember - some of these decisions will be based on the=20 > capacity (BW and # of call takers) within the local=20 > jurisdiction -- which is again something the IETF cannot give=20 > guidance on at this point , if ever >=20 >=20 > > >Hannes, > > > > > >We need to understand the attachment of the UE to the network. > > >There is an AA process prior to allowing any use. Without this we=20 > > >would not trust the RPH, even for ETS, never mind 911 > > > > > >Martin > > > > > >----- Original Message ----- > > >From: Hannes Tschofenig > > >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu=20 > > >; jgunn6@csc.com > > >Cc: ecrit@ietf.org > > >Sent: Sun Feb 08 04:32:25 2009 > > >Subject: RE: [Ecrit] Semantics Re: RPH > > > > > >Hi Martin, > > > > > >Your remarks are a bit a short. > > > > > >Clearly, authentication and authorization can come in=20 > different forms. > > >This was actually one of the discussion we had so far that the=20 > > >authorization mechanisms for the GETS RPH and the proposed=20 > ECRIT RPH=20 > > >is different. > > > > > >So, could you elaborate a bit? > > > > > >Ciao > > >Hannes > > > > > >>-----Original Message----- > > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > >On Behalf > > >>Of DOLLY, MARTIN C, ATTLABS > > >>Sent: 07 February, 2009 19:30 > > >>To: hgs@cs.columbia.edu; jgunn6@csc.com > > >>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org > > >>Subject: Re: [Ecrit] Semantics Re: RPH > > >> > > >>Do you have a clue dude? A+A of an user comes in many forms. > > >> > > >>----- Original Message ----- > > >>From: ecrit-bounces@ietf.org > > >>To: Janet P Gunn > > >>Cc: ECRIT ; ecrit-bounces@ietf.org=20 > > >> > > >>Sent: Sat Feb 07 11:56:42 2009 > > >>Subject: Re: [Ecrit] Semantics Re: RPH > > >> > > >>Please see my earlier message as to why your approach fails > > >for the UA- > > >>inserted case where not all emergency calls have RPH > > >markings. I think > > >>it would be a really bad idea if emergency calls with RPH are=20 > > >>treated differently than emergency calls without it. (Again, I'm > > >talking about > > >>the user-initiated calls. An ESNET can do whatever it=20 > wants and can=20 > > >>assign extra priority to calls from citizens that have bought PBA=20 > > >>stickers or zip codes that pay more taxes, but that's a separate > > >>problem.) > > >> > > >>I also don't believe your implementation logic. A much better > > >approach > > >>is to semantically declare the class of call early on=20 > (e.g., based=20 > > >>on the URN or after authentication/authorization), and make that=20 > > >>part of the call state record, rather than hunt for headers each=20 > > >>time a handling decision needs to be made. Given the=20 > authorization=20 > > >>requirements, just looking at "has header X" is never going to be=20 > > >>sufficient anyway. > > >> > > >>Henning > > >> > > >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > > >> > > >>> > > >>> > > >>> . > > >>> > > >>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > > >>> > > >>> > PLEASE try to understand that the syntax is similar=20 > (header, new > > >>> namespace, > > >>> > new values) > > >>> > BUT the semantic is different. > > >>> > > > >>> > For all message it is true that the sender can add=20 > whatever they > > >>> want. The > > >>> > big question is what does it mean for the recipient. > > >>> > > > >>> > This is what the discussion is about. > > >>> > > > >>> On the contrary, the semantic is, or at least can be,=20 > very similar. > > >>> > > >>> Consider the hypothetical, but plausible, case of a=20 > network with=20 > > >>> an explicit call/capacity admission process, in which both=20 > > >>> 911-type- emergency calls and GETS calls get preferential=20 > > >>> admission > > >>treatment. > > >>> By the time the INVITE gets to this Functional Module/ block > > >>of code, > > >>> all authentication, authorization, and changes/ confirmation of=20 > > >>> the destination have already taken place. All this=20 > block of code=20 > > >>> deals with is call/capacity admission. > > >>> > > >>> For the sake of argument, suppose this is the nature of the=20 > > >>> preference. > > >>> > > >>> 1) For INVITEs without RPH, or with an RPH this network does > > >>not use/ > > >>> understand, if the admission process fails, the INVITE fails > > >>> > > >>> 2) For INVITEs with RPH with the ets namespace, if the=20 > admission=20 > > >>> process initially fails, the INVITE is put in queue until the=20 > > >>> resources become available so it can be admitted. > > >>> > > >>> 3) For INVITEs with RPH with the esnet namespace, if=20 > the admission=20 > > >>> process initially fails, the INVITE is put in queue,=20 > but at lower=20 > > >>> priority than the calls with the ets namespace. > > >>> > > >>> With the esnet namespace, this block of code only needs to > > >deal with > > >>> the RPH in determining which INVITEs to reject, and which to=20 > > >>> queue, and how. > > >>> > > >>> But if there is no esnet namespace for RPH, then this block of=20 > > >>> code would need to deal with BOTH the RPH and the URN. =20 > That would=20 > > >>> be a completely unnecessary complication. > > >>> > > >>> Janet > > >> > > >>_______________________________________________ > > >>Ecrit mailing list > > >>Ecrit@ietf.org > > >>https://www.ietf.org/mailman/listinfo/ecrit > > >>_______________________________________________ > > >>Ecrit mailing list > > >>Ecrit@ietf.org > > >>https://www.ietf.org/mailman/listinfo/ecrit > > >> > > > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043D328C140 for ; Mon, 9 Feb 2009 10:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1LbJw65rtB7 for ; Mon, 9 Feb 2009 10:28:46 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 0FBEB28C121 for ; Mon, 9 Feb 2009 10:28:45 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n19ISQs0001981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2009 13:28:26 -0500 (EST) Message-Id: From: Henning Schulzrinne To: "James M. Polk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 13:28:26 -0500 References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> <01c701c98add$00aea1e0$0201a8c0@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:28:47 -0000 And for all the reasons that Hannes keeps pointing out and that nobody else seems to be addressing, this remains a fundamentally bad idea for customer-to-ESNET calls. I look forward to serving as expert witness during the class action trial when a provider has to explain why their customers got better emergency service since they somehow included the right magic token that was only given to "privileged" VSPs and ISPs. On a more prosaic level: The last thing we need in SIP is more user agent configuration that adds exactly zero value and adds more failure scenarios. ("Oops, forgot to configure that option - now your emergency calls get treated like calls for pizza delivery.") We don't want NENA-specific phones - a standards-compliant phone needs to work out of the box, literally, anywhere in the world and get the same emergency call treatment as other such phones. Beyond vague allusions to catch-all terms like "local policy" or "could be useful", nobody has answered Hannes' question as to *why* somebody would treat a customer-originated emergency call with RPH differently than one without and why this would be a good idea if one did. If they are always treated the same, it's just needless complexity and an additional failure mode. Given the damage this can do in customer-originated calls, this is not just a harmless "why not" idea, it is a seriously bad idea. In general, in the IETF, including a protocol feature requires a convincing functional argument. It is not up to the detractors to convince the proponents of a solution that it is useless, but the other way around. Henning On Feb 9, 2009, at 1:17 PM, James M. Polk wrote: > At 11:36 AM 2/9/2009, Hannes Tschofenig wrote: >> You captured the discussion quite well. >> >> Separating out the PSAP--first responder/organizations use case and >> define >> only a namespace for that sounds good to me and would reflect what >> James had >> agreed to a while ago. > > When I agree to it, several folks asked me not to limit this > namespace's usage to just within the ESInet -- and that's why it > remains a possibility in the VSP (though not a SHOULD or a MUST > implement, but a "can"), and whatever UAC/UE the VSP wants to vouch > for. > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13CD3A6B58 for ; Mon, 9 Feb 2009 10:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RADPUdbSRaJG for ; Mon, 9 Feb 2009 10:31:35 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id D21E03A6AF4 for ; Mon, 9 Feb 2009 10:31:34 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n19IVaXK002865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2009 13:31:36 -0500 (EST) Message-Id: From: Henning Schulzrinne To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 13:31:36 -0500 References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:31:35 -0000 > I agree with Ted on the first part. We can then discuss whether the second part is really helpful. > As a way forward, I suggest we separate out the PSAP--first > responder/organizations > use case and define only a namespace for that. If we need a second > namespace > for caller insertion/entry server insertion, we can create that. > Strings are cheap. > But there seems to be a long road ahead in combining the two, since > the kinds > of devices that have to care and the kinds of networks they may have > to traverse > seem different enough to hinder early consensus. > > regards, > Ted Hardie > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE493A699F; Mon, 9 Feb 2009 10:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwB1fTxfBFZY; Mon, 9 Feb 2009 10:36:27 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D4A0E3A68B1; Mon, 9 Feb 2009 10:36:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139863670" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 18:36:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19IaUKw022023; Mon, 9 Feb 2009 10:36:30 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19IaU4I027243; Mon, 9 Feb 2009 18:36:30 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, 9 Feb 2009 10:36:30 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 10:36:29 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 12:36:28 -0600 To: "Hannes Tschofenig" , "'Janet P Gunn'" From: "James M. Polk" In-Reply-To: <01c801c98ade$b59cba50$0201a8c0@nsnintra.net> References: <007201c988fc$2aab5f20$0201a8c0@nsnintra.net> <004801c989d2$65eb0b90$0201a8c0@nsnintra.net> <01c801c98ade$b59cba50$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 18:36:29.0806 (UTC) FILETIME=[52CCB0E0:01C98AE5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3360; t=1234204590; x=1235068590; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Semantics=20=20Re=3A=20[Ecrit]=20RPH |Sender:=20; bh=m3+zZLoVJpIJYbzjGOJ87h7Mkzbjxd+skfK7P0sBWWc=; b=aImiesPZPmXlQgdYo2hgVoc1aEKhncBbMTQ4u+8zyIudm2ivLGytYMj37Z 1SS5jUeU4DCNjPYqkBZ5hBlWcfDev9IzY6i16/09YMnTWhwqSuNVgOV6V6nE fzXTrxj1Jqri6tHJCE/ZiCu/ex6KGJl2eG4F3m/gpBDeCZCsfnrLM=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:36:28 -0000 At 11:48 AM 2/9/2009, Hannes Tschofenig wrote: > >>[hannes] You talk about rejecting the INVITE: Emergency calls do not > >>get rejected regardless of the RPH marking. > > > >this statement is assuming all emergency calls do in fact get through > >-- and that is simply not the case today, so what basis are > >you making this argument from? > > > >I would always mark my emergency calls with the highest priority (currently >"esnet.4") since they are really important to me (hopefully the software >marks without asking me as a caller in stress). This is the other type of "relative importance" -- i.e., yours. And while I'm not saying your wrong here, I'm saying 911 or 112 calls aren't always the most important calls in the network. For example, is the police chief's call to the fire chief more or less important than a citizen's call into a PSAP? Be careful when you answer this -- because this is a local policy decision -- and not all jurisdictions will have the same policy. Therefore choosing to mark the 911/112 calls with the highest indication is already wrong for some jurisdictions. There are other examples that I can offer. I, personally, believe the 911/112 calls should be marked - as a default - as "esnet.1" with only 1 other level below it for non-emergency communications -- to be used for things such as IM between call centers (which is an existing requirement - and therefore needs a priority mark). Politics will have the chiefs of various departments have the highest level. That's "esnet.4" I, personally, believe the next level ought to go to the first responders that are currently in a fire or gun fight. This is currently handled over radio links, but we don't know these are going to stay on RF over the next 10 years (and in fact have several vendors working on solutions over IP right now). So that's "esnet.3" I, personally, believe the next level ("esnet.2") ought to go to the command centers for inter-command communications, including the on-site supervisors of a larger than normal incident (like a large fire or SWAT). Nearly all of this will not take the same path as the citizen to authority calls, but has to get marked differently because they are just different level of events. >If they still don't get through then the marking was not of much help either. > >Maybe we need more priority levels. We could serve the highest values just >for us :-) >(This is a joke!) well... to bring up flexibility, I've just listed 5 uses (i.e., the 5 proposed levels) and that doesn't allow too much else to be inserted that I haven't talked about. Perhaps there should be more available to the PSAP/first responder community? It doesn't mean they have to use them all -- and 4412 does say the number of priority levels SHOULD NOT change over time, for interoperability reasons... >Seriously, you need to explain how RPH marking would help against rejected >emergency calls. it isn't a question about whether or not RPH would help with rejection of calls, you asserted that emergency calls weren't rejected - and I am correcting you with the fact that in today's networks, 911 and 112 calls are rejected all the time. RPH cannot address all of the situations in which the calls would otherwise be rejected. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7705528C160 for ; Mon, 9 Feb 2009 10:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP42T3GL1isZ for ; Mon, 9 Feb 2009 10:45:50 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EA40E28C144 for ; Mon, 9 Feb 2009 10:45:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="133994010" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2009 18:45:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n19IjrwF023508; Mon, 9 Feb 2009 10:45:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19IjrVX001427; Mon, 9 Feb 2009 18:45:53 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, 9 Feb 2009 10:45:53 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 10:45:52 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 12:45:51 -0600 To: "Hannes Tschofenig" , "'DOLLY, MARTIN C, ATTLABS'" , , From: "James M. Polk" In-Reply-To: <01cc01c98ae1$60518640$0201a8c0@nsnintra.net> References: <14C85D6CCBE92743AF33663BF5D24EBA01238F71@gaalpa1msgusr7e.ugd.att.com> <004901c989ef$302749c0$0201a8c0@nsnintra.net> <01cc01c98ae1$60518640$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 18:45:52.0525 (UTC) FILETIME=[A234CBD0:01C98AE6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12607; t=1234205153; x=1235069153; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Semantics=20=20Re=3A=20=20RPH |Sender:=20; bh=3dBsvPh/oqmH3BAd4fkCv7Gt6YpTKBINNUw0z5w4HVI=; b=XCKT4OrmKV0KM2fAXdEIdaskCuH32xOJ2DSxXT8wOaXVQmQW/ICpSmyFzg Id1sEFFH+4tsYRis6nHvRNdcSbrfwPj6u7IUY2ZgEnah/gGzu1G1S68ITqUs m80Nq5p5Gr; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Semantics Re: RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:45:52 -0000 At 12:08 PM 2/9/2009, Hannes Tschofenig wrote: > >>It would be helpful that > >draft-ietf-ecrit-local-emergency-rph-namespace > >>captures some of these aspects to allow those who implement > >and deploy > >>the esnet RPH mechanism to understand what it does and how to > >correctly > >>implement it. > > > >I wholly disagree with this desire. This > >draft-ietf-ecrit-local-emergency-rph-namespace creates the > >namespace, it does not create the associated semantics for use > >of this namespace that are specific to NENA or EENA. That is > >up to NENA or EENA to specify. It is also up to the AT&T's > >and Verizon's of the world to define what the exact semantics > >are within their respective networks are to satisfy whatever > >regulations they have in their local jurisdictions (which are > >different from each other -- and what the IETF knows nothing about). > > > >For example, each group of emergency callers thinks *their* > >type of emergency should get preferential treatment over other > >types of emergencies. To be specific, which type of emergency > >call is more > >important: a GETS type call or a 911/112 type call? > >I agree that this is a policy decision (as long as my emergency call with an >inappropriate marking does not get dropped). > >What I was asking for is to describe the difference in authorization >handling. I firmly believe that is out of scope for this doc (that just creates the namespace) > > > >It is not up to the IETF to decide that. It is up to the local > >policies of the jurisdiction and the SP to figure that out. > >This is not inconsistent with RFC 4412 - in fact, RFC 4412 > >built this aspect into its text. > > > >The esnet namespace should follow RFC 4412's guidelines in > >coordination with those from the local authorities and the > >local SPs to determine how they are going to configure their > >operations. At that point, it's up to the local SP to buy > >products from vendors that can meet the requirements of that > >local configuration. > >This does not work when you have end points doing this stuff since these end >devices can be used everywhere. but the endpoint that is attached to the VSP is going to be challenged by that VSP for the correct marking. the endpoints that aren't attached to any VSP are going to be challenged by the ESInet ESRP, which will quickly determine this SIP request didn't come from an authorized VSP (I say authorized here because I believe each local or regional ESInet is going to have a trust relationship with VSPs - ensuring the VSP does the primary filtering of messages instead of the ESRP having to do it all, all the time. >An operator can for sure decide to buy a box that does fancy marking >techniques and offers different ways to configure the box todo so. No doubt. yep -- that's one reason I don't want to forbid the marking outside of the ESInet, where VSPs can make that choice to get 'more engaged' with the program. > > > >Therefore, draft-ietf-ecrit-local-emergency-rph-namespace > >should not have any additional text articulating guidance how > >to configure their networks. RFC 4412 defines all the guidance > >they need at this time. > > > >When operational experience proves something ought to be > >modified within that guidance, then a new doc should be > >written suggesting that/those modification(s). > >When I wrote, for example, the following sentence: > > #* What does the esnet RPH usage mean in the context of an emergency > #call (for example, in comparison to an emergency call without esnet RPH >usage)? > >I was hoping that someone would think about the possible "local policy >settings" that could make sense. Read my last message (I just sent it) and see if this is something that you want me to put into an appendix as a non-binding guidance or format... obviously this is something that we can modify >If an emergency call with the esnet RPH marking gets treated better than an >emergency call without such a marking then someone might come up with the >idea of marking every emergency call with the highest priority. If everyone >does this then the purpose of the priority system is lost. hopefully the VSPs will engage at some point and start marking down those priority values that are too high (down to the normal esnet marking). >Treating an emergency call with an esnet RPH marking worse than one without >it wouldn't make a lot of sense since otherwise nobody would do the marking >anymore. > >Treating an emergency call with an esnet RPH marking in the same fashion as >other emergency calls would defeat the purpose of the additional marking. > >The above-mentioned cases assume that the SIP UA vendor (or someone else >configuring the marking) knows the local policy at the VSP. If it is not >known at all and all the above cases are equally likely then it does not >make sense to mark the call. > >Not so trivial to come up with something useful. > >Ciao >Hannes > > >>Ciao > >>Hannes > >> > >>PS: There are details that also need to be discussed. For example, > >>which esnet value would the device use for an emergency call? > >>"esnet.0", "esnet.1", "esnet.2", "esnet.3", "esnet.4". > >Out-of-scope is > >>a possible answer but it will not help the implementer in > >doing it's job. > > > >see the very same explanation above as to why this isn't > >something that ought be in an IETF doc. > > > >>Is there a > >>specific default value (maybe the highest value, just to be sure)? > > > >there is not, and choosing one the highest or lowest value > >limits adjustments and the "what if we determine one day > >something else is actually more important" question. > > > >>Would the UA get provisioned to pick a specific value? > > > >if this were in scope of this doc, I'd suggest this be done > >through something like RFC 3841 "SIP Call Preferences" > > > >>What is the provisioning mechanism? > > > >this depends on the choice, but Caller Prefs has a mechanism. > > > >>Is there a relationship between the esnet values and the > >Service URN values? > > > >should there be? > > > >I don't know, and think this is a local (matrix) matter -- or > >a NENA/EENA matter > > > >>Do the urn:service:counseling:* services get a lower priority > >than the > >>urn:service:sos:* services? > > > >only if local policy gives urn:service:counseling:* any > >priority, then local policy will determine what priority in > >relation to sos. > > > >Remember - some of these decisions will be based on the > >capacity (BW and # of call takers) within the local > >jurisdiction -- which is again something the IETF cannot give > >guidance on at this point , if ever > > > > > >> >Hannes, > >> > > >> >We need to understand the attachment of the UE to the network. > >> >There is an AA process prior to allowing any use. Without this we > >> >would not trust the RPH, even for ETS, never mind 911 > >> > > >> >Martin > >> > > >> >----- Original Message ----- > >> >From: Hannes Tschofenig > >> >To: DOLLY, MARTIN C, ATTLABS; hgs@cs.columbia.edu > >> >; jgunn6@csc.com > >> >Cc: ecrit@ietf.org > >> >Sent: Sun Feb 08 04:32:25 2009 > >> >Subject: RE: [Ecrit] Semantics Re: RPH > >> > > >> >Hi Martin, > >> > > >> >Your remarks are a bit a short. > >> > > >> >Clearly, authentication and authorization can come in > >different forms. > >> >This was actually one of the discussion we had so far that the > >> >authorization mechanisms for the GETS RPH and the proposed > >ECRIT RPH > >> >is different. > >> > > >> >So, could you elaborate a bit? > >> > > >> >Ciao > >> >Hannes > >> > > >> >>-----Original Message----- > >> >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf > >> >>Of DOLLY, MARTIN C, ATTLABS > >> >>Sent: 07 February, 2009 19:30 > >> >>To: hgs@cs.columbia.edu; jgunn6@csc.com > >> >>Cc: ecrit@ietf.org; ecrit-bounces@ietf.org > >> >>Subject: Re: [Ecrit] Semantics Re: RPH > >> >> > >> >>Do you have a clue dude? A+A of an user comes in many forms. > >> >> > >> >>----- Original Message ----- > >> >>From: ecrit-bounces@ietf.org > >> >>To: Janet P Gunn > >> >>Cc: ECRIT ; ecrit-bounces@ietf.org > >> >> > >> >>Sent: Sat Feb 07 11:56:42 2009 > >> >>Subject: Re: [Ecrit] Semantics Re: RPH > >> >> > >> >>Please see my earlier message as to why your approach fails > >> >for the UA- > >> >>inserted case where not all emergency calls have RPH > >> >markings. I think > >> >>it would be a really bad idea if emergency calls with RPH are > >> >>treated differently than emergency calls without it. (Again, I'm > >> >talking about > >> >>the user-initiated calls. An ESNET can do whatever it > >wants and can > >> >>assign extra priority to calls from citizens that have bought PBA > >> >>stickers or zip codes that pay more taxes, but that's a separate > >> >>problem.) > >> >> > >> >>I also don't believe your implementation logic. A much better > >> >approach > >> >>is to semantically declare the class of call early on (e.g., based > >> >>on the URN or after authentication/authorization), and make that > >> >>part of the call state record, rather than hunt for headers each > >> >>time a handling decision needs to be made. Given the authorization > >> >>requirements, just looking at "has header X" is never going to be > >> >>sufficient anyway. > >> >> > >> >>Henning > >> >> > >> >>On Feb 7, 2009, at 11:27 AM, Janet P Gunn wrote: > >> >> > >> >>> > >> >>> > >> >>> . > >> >>> > >> >>> ecrit-bounces@ietf.org wrote on 02/07/2009 03:14:57 AM: > >> >>> > >> >>> > PLEASE try to understand that the syntax is similar > >(header, new > >> >>> namespace, > >> >>> > new values) > >> >>> > BUT the semantic is different. > >> >>> > > >> >>> > For all message it is true that the sender can add > >whatever they > >> >>> want. The > >> >>> > big question is what does it mean for the recipient. > >> >>> > > >> >>> > This is what the discussion is about. > >> >>> > > >> >>> On the contrary, the semantic is, or at least can be, > >very similar. > >> >>> > >> >>> Consider the hypothetical, but plausible, case of a network with > >> >>> an explicit call/capacity admission process, in which both > >> >>> 911-type- emergency calls and GETS calls get preferential > >> >>> admission > >> >>treatment. > >> >>> By the time the INVITE gets to this Functional Module/ block > >> >>of code, > >> >>> all authentication, authorization, and changes/ confirmation of > >> >>> the destination have already taken place. All this > >block of code > >> >>> deals with is call/capacity admission. > >> >>> > >> >>> For the sake of argument, suppose this is the nature of the > >> >>> preference. > >> >>> > >> >>> 1) For INVITEs without RPH, or with an RPH this network does > >> >>not use/ > >> >>> understand, if the admission process fails, the INVITE fails > >> >>> > >> >>> 2) For INVITEs with RPH with the ets namespace, if the admission > >> >>> process initially fails, the INVITE is put in queue until the > >> >>> resources become available so it can be admitted. > >> >>> > >> >>> 3) For INVITEs with RPH with the esnet namespace, if the > >admission > >> >>> process initially fails, the INVITE is put in queue, but > >at lower > >> >>> priority than the calls with the ets namespace. > >> >>> > >> >>> With the esnet namespace, this block of code only needs to > >> >deal with > >> >>> the RPH in determining which INVITEs to reject, and which to > >> >>> queue, and how. > >> >>> > >> >>> But if there is no esnet namespace for RPH, then this block of > >> >>> code would need to deal with BOTH the RPH and the URN. > >That would > >> >>> be a completely unnecessary complication. > >> >>> > >> >>> Janet > >> >> > >> >>_______________________________________________ > >> >>Ecrit mailing list > >> >>Ecrit@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/ecrit > >> >>_______________________________________________ > >> >>Ecrit mailing list > >> >>Ecrit@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > > >> > > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82233A6B82 for ; Mon, 9 Feb 2009 11:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73LP7ayAGbTH for ; Mon, 9 Feb 2009 11:06:39 -0800 (PST) Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by core3.amsl.com (Postfix) with ESMTP id 14C8B3A6A0A for ; Mon, 9 Feb 2009 11:06:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-8.tower-64.messagelabs.com!1234206397!100047261!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 14145 invoked from network); 9 Feb 2009 19:06:39 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-8.tower-64.messagelabs.com with AES256-SHA encrypted SMTP; 9 Feb 2009 19:06:39 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n19J6bWC015266 for ; Mon, 9 Feb 2009 14:06:39 -0500 To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Anthony D Pike Message-ID: Date: Mon, 9 Feb 2009 14:06:37 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/09/2009 02:08:59 PM, Serialize complete at 02/09/2009 02:08:59 PM Content-Type: multipart/alternative; boundary="=_alternative 0068981485257558_=" Cc: "ecrit@ietf.org" Subject: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:06:39 -0000 This is a multipart message in MIME format. --=_alternative 0068981485257558_= Content-Type: text/plain; charset="US-ASCII" Hi James as I have been following emails on RPH I noticed that the Priority for esnet namespace is defined as (lowest) esnet.0 esnet.1 esnet.2 esnet.3 (highest) esnet.4 Where the numerical order flows from (lowest=0) to (Highest=4) Where as in RFC 4412 the numerical order for wps, q735 and ets namespaces is the other way around (Highest=0 to Lowest=4) (lowest) wps.4 q735.4 ets.4 wps.3 q735.3 est.3 wps.2 q735.2 ets.2 wps.1 q735.1 ets.1 (highest) wps.0 q736.0 est.0 I'm not sure if there is any reason for the reverse numerical odering of the esnet namespace, but it would seem good practice to keep them consistent? Tony This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 0068981485257558_= Content-Type: text/html; charset="US-ASCII"
Hi James

as I have been following emails on RPH I noticed that the Priority for esnet namespace is defined as

(lowest)  esnet.0
                  esnet.1
                  esnet.2
                  esnet.3
(highest) esnet.4
                 
Where the numerical order flows from (lowest=0) to (Highest=4)

Where as in RFC 4412 the numerical order for wps, q735 and ets namespaces is the other way around (Highest=0 to Lowest=4)

(lowest)  wps.4   q735.4   ets.4
                  wps.3   q735.3  est.3
                  wps.2   q735.2  ets.2
                  wps.1   q735.1        ets.1
(highest) wps.0   q736.0  est.0

I'm not sure if there is any reason for the reverse numerical odering of the esnet namespace, but it would seem good practice to keep them consistent?

Tony

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 0068981485257558_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418553A6BBE for ; Mon, 9 Feb 2009 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQYEt1Ec-HhB for ; Mon, 9 Feb 2009 11:13:29 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 380153A6A8F for ; Mon, 9 Feb 2009 11:13:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139887344" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 19:13:31 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n19JDVLv031449; Mon, 9 Feb 2009 11:13:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19JDVo5006204; Mon, 9 Feb 2009 19:13:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 11:13:31 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 11:13:31 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 13:13:29 -0600 To: Henning Schulzrinne , Ted Hardie From: "James M. Polk" In-Reply-To: References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 19:13:31.0072 (UTC) FILETIME=[7EC6FC00:01C98AEA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2721; t=1234206811; x=1235070811; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RPH=20=22esnet=22=20in=20the=203=20areas=20of=2 0the=20network |Sender:=20; bh=HJBLkZROSEXcutPNnujwm5Verrq7ivkhQc3Qpo4ll/4=; b=G72tQwtKDCNk2LF2pSJna3zw8MLcINhGJW2D1srnwazTH/w/8gcVODDSr0 6boEHXH4qwvYCsSHuF6GefdnUqskmZ+QP1iQpBSKtvAdWWxkMJ1GwEICkiMX 75ST5FY3m0; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ECRIT Subject: [Ecrit] RPH "esnet" in the 3 areas of the network X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:13:30 -0000 I'd like to focus on one part of the network, and it's not from the endpoint, for a moment to attempt to break this thread up to discussion each of the 3 parts of the overall e2e emergency call. Figure 1 within this ID gives 3 parts of the network, - from the UAC/UE, - within the VSP, and - within the ESInet. I think everyone (currently voicing opinions on these threads) agree with allowing the "esnet" RPH namespace within the ESInet - so I won't talk about that part any further. That leaves the first two parts still open for discussion even though we've already been hashing this out pretty brutally for some time now. Addressing what Henning agreed to (Ted's message) below, it appears each sees not benefit to VSPs processing the esnet namespace, and Henning is less enthusiastic about allowing a UAC or UE setting the namespace -- to the point of calling this pointless and dangerous. I think Hannes is close to this opinion. Keith, Brian, Martin Dolly, Janet, Marc and I want to allow the UAC/UE to set the namespace (i.e., not prohibit it), and want the VSP to mark emergency SIP requests (or remark if done so incorrectly) with the "esnet" RPH namespace. Some VSPs are going to directly attach to entry points to a ESInet, and there can be a relationship there, off-loading the ESRP within the ESInet from being the first entity from doing any checks on incoming emergency calls. Is there contention from Ted, Henning or Hannes (or anyone else) to disallow or *NOT* have text (or a diagram) in this ID from showing a VSP being able to either marking or remarking an RPH esnet namespace? I think the is more resistance to NOT allowing this than from the UAC/UE - which is why I want to ask about only this piece of the puzzle. James At 12:31 PM 2/9/2009, Henning Schulzrinne wrote: >I agree with Ted on the first part. We can then discuss whether the >second part is really helpful. > >>As a way forward, I suggest we separate out the PSAP--first >>responder/organizations use case and define only a namespace for that. >>If we need a second >>namespace >>for caller insertion/entry server insertion, we can create that. >>Strings are cheap. >>But there seems to be a long road ahead in combining the two, since >>the kinds >>of devices that have to care and the kinds of networks they may have >>to traverse >>seem different enough to hinder early consensus. >> >> regards, >> Ted Hardie > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E7F28C15B for ; Mon, 9 Feb 2009 11:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.474 X-Spam-Level: X-Spam-Status: No, score=-7.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwOnVpJSN45h for ; Mon, 9 Feb 2009 11:30:47 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 308B83A69A8 for ; Mon, 9 Feb 2009 11:30:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="245997154" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2009 19:29:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n19JTqkH001943; Mon, 9 Feb 2009 11:29:52 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19JTqlP027615; Mon, 9 Feb 2009 19:29:52 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 11:29:52 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 11:29:51 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Feb 2009 13:29:50 -0600 To: Anthony D Pike From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2009 19:29:51.0572 (UTC) FILETIME=[C7336940:01C98AEC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3313; t=1234207792; x=1235071792; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20RPH=20Priority=20order=20for=20ESNET=20 observation=20against=20Priority=0A=20=20of=20other=20namesp aces=20defined=20in=20RFC=204412 |Sender:=20; bh=1CeTO0AmXfiJ2q1AD4divX6i8vjBaLTVS07v/PcPhug=; b=a3mUNpVb7BSi2M3FQuCz5XGemN9i5kmaf6NsD5tfrfLV7va+du8NSZXgua UibJKmGzI7OkhgqsQWh4Y5w8iYNWbqykWociE6+csvI1Im9/3LpvMX6jD/9D UWPme/qwfe; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:30:48 -0000 Tony Actually, granting higher priority to higher numbers is more the practice of everyone, and existing MLPP folks set the tone for the ets and wps namespaces. For example, RSVP has 2^32 priority values, with the highest number having the highest priority. This reverse order was a struggle for a lot of folks when RFC 4412 was still draft... but the idea was for that very mature system, they knew exactly what they wanted, and didn't want anything to receive greater priority than priority zero (0), as would have been the case if the highest priority were something like 5, and someone wanted a new priority level, with the next available number being 6. In this case, would 6 have had greater priority than 5? What if the President of the US were already 5, who would implement a system that gave anyone greater priority than the highest ranking official within any country? Answer => no one. So they made the Prez priority 0. (Janet - go with the flow here!) Now, each namespace is going to have its own priority list, and it can be letters or numbers or strings. It's up to the namespace owner to set the order, and its up to the operators that choose to implement more than one namespace to work out the details of the relative priority order between more than one namespace. See section 8 of RFC 4412 for this critical detail. Given that the concept of prioritizing emergency communications will be new to PSAPs and first responders, they do not have a mature system like MLPP has. So locking them into a ceiling that's in descending order will undoubtedly cause some problems for some jurisdictions that either underestimate which type of communication ought to have which priority-value, or end up - down the road - using or needing more priority-levels than they originally planned. Either way, it's a pain to reset all devices to a new map of what priority levels go with what type of emergency communication. Does this make sense? James At 01:06 PM 2/9/2009, Anthony D Pike wrote: >Hi James > >as I have been following emails on RPH I noticed that the Priority >for esnet namespace is defined as > >(lowest) esnet.0 > esnet.1 > esnet.2 > esnet.3 >(highest) esnet.4 > >Where the numerical order flows from (lowest=0) to (Highest=4) > >Where as in RFC 4412 the numerical order for wps, q735 and ets >namespaces is the other way around (Highest=0 to Lowest=4) > >(lowest) wps.4 q735.4 ets.4 > wps.3 q735.3 est.3 > wps.2 q735.2 ets.2 > wps.1 q735.1 ets.1 >(highest) wps.0 q736.0 est.0 > >I'm not sure if there is any reason for the reverse numerical >odering of the esnet namespace, but it would seem good practice to >keep them consistent? > >Tony > >This is a PRIVATE message. If you are not the intended recipient, >please delete without copying and kindly advise us by e-mail of the >mistake in delivery. >NOTE: Regardless of content, this e-mail shall not operate to bind >CSC to any order or other contract unless pursuant to explicit >written agreement or government initiative expressly permitting the >use of e-mail for such purpose. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A303A6B78 for ; Mon, 9 Feb 2009 11:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aghJ3B9Tc76G for ; Mon, 9 Feb 2009 11:56:52 -0800 (PST) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id E88CE3A69A7 for ; Mon, 9 Feb 2009 11:56:51 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-2.tower-164.messagelabs.com!1234209410!14988589!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 2010 invoked from network); 9 Feb 2009 19:56:52 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-164.messagelabs.com with AES256-SHA encrypted SMTP; 9 Feb 2009 19:56:52 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n19Juni5032276 for ; Mon, 9 Feb 2009 14:56:51 -0500 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Anthony D Pike Message-ID: Date: Mon, 9 Feb 2009 14:56:48 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 02/09/2009 02:59:12 PM, Serialize complete at 02/09/2009 02:59:12 PM Content-Type: multipart/alternative; boundary="=_alternative 006D1F9085257558_=" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:56:53 -0000 This is a multipart message in MIME format. --=_alternative 006D1F9085257558_= Content-Type: text/plain; charset="US-ASCII" Yes that makes sense, I figured there was a good explanation. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. "James M. Polk" 02/09/2009 02:29 PM To Anthony D Pike/ESI/CSC@CSC cc "ecrit@ietf.org" Subject Re: RPH Priority order for ESNET observation against Priority of other namespaces defined in RFC 4412 Tony Actually, granting higher priority to higher numbers is more the practice of everyone, and existing MLPP folks set the tone for the ets and wps namespaces. For example, RSVP has 2^32 priority values, with the highest number having the highest priority. This reverse order was a struggle for a lot of folks when RFC 4412 was still draft... but the idea was for that very mature system, they knew exactly what they wanted, and didn't want anything to receive greater priority than priority zero (0), as would have been the case if the highest priority were something like 5, and someone wanted a new priority level, with the next available number being 6. In this case, would 6 have had greater priority than 5? What if the President of the US were already 5, who would implement a system that gave anyone greater priority than the highest ranking official within any country? Answer => no one. So they made the Prez priority 0. (Janet - go with the flow here!) Now, each namespace is going to have its own priority list, and it can be letters or numbers or strings. It's up to the namespace owner to set the order, and its up to the operators that choose to implement more than one namespace to work out the details of the relative priority order between more than one namespace. See section 8 of RFC 4412 for this critical detail. Given that the concept of prioritizing emergency communications will be new to PSAPs and first responders, they do not have a mature system like MLPP has. So locking them into a ceiling that's in descending order will undoubtedly cause some problems for some jurisdictions that either underestimate which type of communication ought to have which priority-value, or end up - down the road - using or needing more priority-levels than they originally planned. Either way, it's a pain to reset all devices to a new map of what priority levels go with what type of emergency communication. Does this make sense? James At 01:06 PM 2/9/2009, Anthony D Pike wrote: >Hi James > >as I have been following emails on RPH I noticed that the Priority >for esnet namespace is defined as > >(lowest) esnet.0 > esnet.1 > esnet.2 > esnet.3 >(highest) esnet.4 > >Where the numerical order flows from (lowest=0) to (Highest=4) > >Where as in RFC 4412 the numerical order for wps, q735 and ets >namespaces is the other way around (Highest=0 to Lowest=4) > >(lowest) wps.4 q735.4 ets.4 > wps.3 q735.3 est.3 > wps.2 q735.2 ets.2 > wps.1 q735.1 ets.1 >(highest) wps.0 q736.0 est.0 > >I'm not sure if there is any reason for the reverse numerical >odering of the esnet namespace, but it would seem good practice to >keep them consistent? > >Tony > >This is a PRIVATE message. If you are not the intended recipient, >please delete without copying and kindly advise us by e-mail of the >mistake in delivery. >NOTE: Regardless of content, this e-mail shall not operate to bind >CSC to any order or other contract unless pursuant to explicit >written agreement or government initiative expressly permitting the >use of e-mail for such purpose. --=_alternative 006D1F9085257558_= Content-Type: text/html; charset="US-ASCII"
Yes that makes sense, I figured there was a good explanation.

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


"James M. Polk" <jmpolk@cisco.com>

02/09/2009 02:29 PM

To
Anthony D Pike/ESI/CSC@CSC
cc
"ecrit@ietf.org" <ecrit@ietf.org>
Subject
Re: RPH Priority order for ESNET observation against Priority  of other namespaces defined in RFC 4412





Tony

Actually, granting higher priority to higher numbers is more the
practice of everyone, and existing MLPP folks set the tone for the
ets and wps namespaces.  For example, RSVP has 2^32 priority values,
with the highest number having the highest priority.

This reverse order was a struggle for a lot of folks when RFC 4412
was still draft... but the idea was for that very mature system, they
knew exactly what they wanted, and didn't want anything to receive
greater priority than priority zero (0), as would have been the case
if the highest priority were something like 5, and someone wanted a
new priority level, with the next available number being 6. In this
case, would 6 have had greater priority than 5?  What if the
President of the US were already 5, who would implement a system that
gave anyone greater priority than the highest ranking official within
any country?  Answer => no one.  So they made the Prez priority 0.

(Janet - go with the flow here!)

Now, each namespace is going to have its own priority list, and it
can be letters or numbers or strings.  It's up to the namespace owner
to set the order, and its up to the operators that choose to
implement more than one namespace to work out the details of the
relative priority order between more than one namespace. See section
8 of RFC 4412 for this critical detail.

Given that the concept of prioritizing emergency communications will
be new to PSAPs and first responders, they do not have a mature
system like MLPP has.  So locking them into a ceiling that's in
descending order will undoubtedly cause some problems for some
jurisdictions that either underestimate which type of communication
ought to have which priority-value, or end up - down the road - using
or needing more priority-levels than they originally planned.  Either
way, it's a pain to reset all devices to a new map of what priority
levels go with what type of emergency communication.

Does this make sense?

James

At 01:06 PM 2/9/2009, Anthony D Pike wrote:

>Hi James
>
>as I have been following emails on RPH I noticed that the Priority
>for esnet namespace is defined as
>
>(lowest)  esnet.0
>                   esnet.1
>                   esnet.2
>                   esnet.3
>(highest) esnet.4
>
>Where the numerical order flows from (lowest=0) to (Highest=4)
>
>Where as in RFC 4412 the numerical order for wps, q735 and ets
>namespaces is the other way around (Highest=0 to Lowest=4)
>
>(lowest)  wps.4   q735.4   ets.4
>                   wps.3   q735.3  est.3
>                   wps.2   q735.2  ets.2
>                   wps.1   q735.1        ets.1
>(highest) wps.0   q736.0  est.0
>
>I'm not sure if there is any reason for the reverse numerical
>odering of the esnet namespace, but it would seem good practice to
>keep them consistent?
>
>Tony
>
>This is a PRIVATE message. If you are not the intended recipient,
>please delete without copying and kindly advise us by e-mail of the
>mistake in delivery.
>NOTE: Regardless of content, this e-mail shall not operate to bind
>CSC to any order or other contract unless pursuant to explicit
>written agreement or government initiative expressly permitting the
>use of e-mail for such purpose.
--=_alternative 006D1F9085257558_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4D03A6BDE for ; Mon, 9 Feb 2009 14:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.211 X-Spam-Level: X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLoP8e6Wvode for ; Mon, 9 Feb 2009 14:03:44 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DCF283A6830 for ; Mon, 9 Feb 2009 14:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1234217026; x=1265753026; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20<14C85D6CCB E92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.co m>=0D=0A=20<000101c988ad$8ac92e90$0201a8c0@nsnintra.net> =0D=0A=20=0D=0A=20 =0D=0A=20|Date:=20Mon,=209=20Feb=202009=2014:03:27=20-0800 |To:=20"James=20M.=20Polk"=20,=0D=0A=20 =20=20=20=20=20=20=20Hannes=20Tschofenig=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'DOLLY ,=20MARTIN=20C,=20=20ATTLABS'"=20,=0D=0A =20=20=20=20=20=20=20=20"hgs@cs.columbia.edu"=20,=0D=0A=20=20=20=20=20=20=20=20"James.Winterb ottom@andrew.com"=0D=0A=09 |From:=20Ted=20Hardie=20|Subject:=20 Re:=20[Ecrit]=20RPH|CC:=20"Tschofenig,=20Hannes=20(NSN=20 -=20FI/Espoo)"=20,=0D=0A=20=20 =20=20=20=20=20=20"ecrit@ietf.org"=20 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5521"=3B=20a =3D"15340323"; bh=QjSfmX31oHl41TUNNlLdi63PkPNQuqKK/lUsOuPmN28=; b=oGLMA6WVvhF3FRRD/8y2sN5lCL7aerKRPAxFGcIYxXSPmjX7PRbZ0yyw hwtwzIUzw1ln7FSqvTbRjPoBVdvp87H07+0Tf1LVQ7iOzBZWnG63KLm6c X9S1xiYVWytVgtNxOxfupW6nhEEGE9FB1COyjOK44a5pQOit6QWHvQL29 E=; X-IronPort-AV: E=McAfee;i="5100,188,5521"; a="15340323" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2009 14:03:33 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19M3XZD028471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Feb 2009 14:03:33 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n19M3UVx028424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2009 14:03:30 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 14:03:29 -0800 Received: from [10.227.68.59] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 14:03:29 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> Date: Mon, 9 Feb 2009 14:03:27 -0800 To: "James M. Polk" , Hannes Tschofenig , "'DOLLY, MARTIN C, ATTLABS'" , "hgs@cs.columbia.edu" , "James.Winterbottom@andrew.com" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ecrit@ietf.org" Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 22:03:45 -0000 At 10:06 AM -0800 2/9/09, James M. Polk wrote: >Ted -- comments at the bottom > >While I generally agree with you -- until you imply that the two >namespaces ought go be in separate docs that have to meet somewhere >future somewhere in the middle of the network. I am not sure that they do have to meet somewhere. If ESNET internal communications are marked with priority values from foo and customer-to-ESNET communications are marked with values from the bar namespace, then any system that might handle both will eventually have to have a mapping that says something like foo3 is above bar2 but below bar1 (assuming 0 high for both). But I actually suspect, honestly, that the ESNET internal communication is really either a private network or an overlay. If that's the case (and I could be way off here), the number of times these traffic markings will be evaluated against each other seems likely to be pretty small. Maybe even 0 in some deployment scenarios. > Please let me know if I've misread what you meant to say. > >On this, I have two thoughts: > >#1 - that several vendors and SPs have already asked for this >namespace to be possible in their respective VSP products and service >offerings - and your implied solution blows that up. Well, I think it's already blown up, as I think the chance of consensus on a customer-to-ESNET namespace seems likely to be slow to emerge. I'm trying to see if there is a way to get something out without waiting for that consensus. >and > >#2 - that creating (in the future) a second namespace to map directly >to the esnet (and it's 5 priority-values) from the UAC or VSP seems >like it might be begging for a lack of interoperability waiting to >happen type of problem. First, this presumes that there will be a second namespace. Fair enough, you see a customer need here. But I am not at all sure that it would be a one-to-one correspondence. I think some folks might well argue that customer-to-ESNET should have only two values: "not an emergency" and "emergency", to simplify the discussions of how big an emergency deserves to go higher than some other emergency. But I think that's part of the discussion of this that makes customer-to-ESNET much harder to work through than ESNET where who gets to decide is crystal, crystal clear. >I can definitely rewrite the text emphasizing the esnet namespace is >for the ESInet first, with the possibility of having it come in from >a reliable VSP, and even a reliable UAC/UE off that reliable VSP. And here is where I think the same syntax is being used for two semantics. If the syntax of value 1 within intra-ESINET communications isn't exactly the same as value one in customer to-ESINET communications, we look to be in a very long discussion indeed. And finding some way of satisfying everyone that this is the case seems long and drawn out indeed. Maybe I just more conflict avoidant these days, but I'd like to get something out and tackle the more difficult things with a sense of accomplishment than to bog down. But I'm not really coding this myself, so it's a suggestion from the sidelines. Ted > >> regards, >> Ted Hardie Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD303A689E for ; Mon, 9 Feb 2009 19:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cessWhbHusgu for ; Mon, 9 Feb 2009 19:12:42 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4BAC53A6875 for ; Mon, 9 Feb 2009 19:12:41 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_09_21_31_58 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 09 Feb 2009 21:31:57 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 21:12:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 9 Feb 2009 21:12:40 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwDpN2/QAAVj3AA= From: "Thomson, Martin" To: "Edge, Stephen" X-OriginalArrivalTime: 10 Feb 2009 03:12:43.0057 (UTC) FILETIME=[704BBA10:01C98B2D] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 03:12:44 -0000 SGkgU3RlcGhlbiwNCg0KSSBiZWxpZXZlIHRoYXQgeW91ciBhbmFseXNpcyBpcyBpbiBwYXJ0IGNv cnJlY3QgYW5kIGluIHBhcnQgYmFzZWQgb24gc29tZSBtaXNjb25jZXB0aW9ucyBhYm91dCB3aGF0 IEVDUklUIGlzIG9yIHNob3VsZCBiZSBkb2luZy4gIFdoZXRoZXIgb3Igbm90IHRoaXMgaXMgYW4g aXNzdWUgZm9yIHNvbWVvbmUgZGVwbG95aW5nIDNHUFAgbmV0d29ya3MgaXMgZW50aXJlbHkgYSBz ZXBhcmF0ZSBjb25zaWRlcmF0aW9uLg0KDQpFQ1JJVCBpcyB3b3JraW5nIHVuZGVyIGEgZGlmZmVy ZW50IHNldCBvZiBjb25zdHJhaW50cyB0aGFuIHRob3NlIHRoYXQgc2hhcGVkIHRoZSBleGlzdGlu ZyAzR1BQIGVtZXJnZW5jeSBhcmNoaXRlY3R1cmUuICBJdCBpcyBub3QgdGhlIHN0YXRlZCBidXNp bmVzcyBvZiBJRVRGIHRvIGRldmVsb3Agc29sdXRpb25zIGZvciBwcm9wcmlldGFyeSBuZXR3b3Jr IGFjY2Vzcy4gIEVDUklUIGhhcyBkZXZlbG9wZWQgYW4gZ2VuZXJhbCBhcmNoaXRlY3R1cmUgdGhh dCB3b3JrcyBmb3IgYW55IEludGVybmV0IGRldmljZS4NCg0KVGhlIHByb2JsZW0gZm9yIEVDUklU IGlzIHRvIGVuc3VyZSBvcGVyYXRpb24gYWNyb3NzIGhldGVyb2dlbmVvdXMgYWNjZXNzLiAgSW4g cGFydGljdWxhciwgdGhlIEVDUklUIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBtYWtlIGFueSBhc3N1 bXB0aW9uIGFib3V0IGEgcmVsYXRpb25zaGlwIGJldHdlZW4gYWNjZXNzIHByb3ZpZGVyIGFuZCAo dm9pY2UpIHNlcnZpY2UgcHJvdmlkZXItLWFuIGFzc3VtcHRpb24gdGhhdCBpcyBuZWl0aGVyIHZh bGlkLCBub3IgbmVjZXNzYXJ5IHdoZW4gYSBnZW5lcmFsIHNvbHV0aW9uIGlzIGRldmVsb3BlZCBm b3IgdGhlIEludGVybmV0LiAgT25lIGxpbWl0YXRpb24gb2YgM0dQUCBzb2x1dGlvbnMgaXMgdGhh dCB0aGV5IGRvIG5vdCB3b3JrIGZvciBhbnkgSW50ZXJuZXQgZGV2aWNlIG9uIGFyYml0cmFyeSBh Y2Nlc3MuDQoNCkl0IHdvdWxkIGJlIGRpc2luZ2VudW91cyB0byByZXByZXNlbnQgdGhlIEVDUklU IGFyY2hpdGVjdHVyZSBhcyBpbmNvbXBhdGlibGUgd2l0aCAzR1BQIGFyY2hpdGVjdHVyZXMuICBD b250cmFyeSB0byB3aGF0IHlvdXIgZW1haWwgaW1wbGllcywgdGhlIG1vZGVscyBkZXZlbG9wZWQg Zm9yIEVDUklUIGNhbiBiZSBlcXVhbGx5IGFwcGxpZWQgdG8gYW55IEludGVybmV0IGFjY2Vzcy4g IFdoYXQgSSBjYW4gc2VlIGlzIHJlYWwgY29uY2VybiBpcyB0aGUgZXh0ZW50IHRvIHdoaWNoIHRo ZSAzR1BQIGVtZXJnZW5jeSBpbmZyYXN0cnVjdHVyZSBpbnRlZ3JhdGVzIGludG8gdGhlIG92ZXJh bGwgYXJjaGl0ZWN0dXJlLg0KDQpJbiBmYWN0LCB0aGUgM0dQUCBhbmQgSU1TIGFyY2hpdGVjdHVy ZSBjYW4gYmUgcmVjYXN0IHRvIGZpdCB0aGUgRUNSSVQgYXJjaGl0ZWN0dXJlIHdpdGhvdXQgdG9v IG1hbnkgY29udG9ydGlvbnMuICBGb3IgaW5zdGFuY2UsIHRoZSBMUkYgZW5jb21wYXNzZXMgTElT IGFuZCBMb1NUIHNlcnZlciByb2xlcywgYW5kIGNhbGwgcm91dGluZyBmdW5jdGlvbnMgYXNzaWdu ZWQgdG8gYSBWU1AgaW4gRUNSSVQgY2FuIGJlIGFsbG9jYXRlZCB0byBhbnkgQ1NDRi4NCg0KT2Yg Y291cnNlLCB0aGUgaW5jb21wYXRpYmlsaXR5IG9mIHRoZSB0d28gYXJjaGl0ZWN0dXJlcyBjYW4g YmUgZGlzcmVnYXJkZWQgYXMgbG9uZyBhcyB5b3UgYXJlIHdpbGxpbmcgdG8gYWNjZXB0IHRoYXQg ZGV2aWNlcyBhcmUgb25seSBhYmxlIHRvIG9wZXJhdGUgd2l0aGluIDNHUFAgYWNjZXNzIHdpdGgg aW50ZWdyYXRlZCBJTVMvVm9JUCBzZXJ2aWNlLiAgVGhlIGFsdGVybmF0aXZlIG9mZmVyZWQgYnkg RUNSSVQgZG9lcyBub3QgaGF2ZSB0aGlzIGxpbWl0YXRpb24gYmVjYXVzZSBpdCBpcyBkZXNpZ25l ZCB0byBiZSB1bml2ZXJzYWxseSBhcHBsaWNhYmxlLg0KDQoNCllvdSBjb3ZlciBhIGxvdCBvZiBn cm91bmQgaW4gdmVyeSBmZXcgd29yZHMsIEknbGwgYWRkcmVzcyBhIGZldyBvZiB5b3VyIGluZGl2 aWR1YWwgcG9pbnRzIGJlbG93Li4uDQoNCihBKSBUaGlzIGlzIGEgZmFpciBzdGF0ZW1lbnQsIGJ1 dCBJIGRvbid0IHRoaW5rIHRoYXQgeW91ciBjb25jbHVzaW9uLS10aGF0IHRoZSAzR1BQIHNvbHV0 aW9ucyBzaG91bGQgYmUgaWRlbnRpZmllZCBhcyB2YWxpZCBhbHRlcm5hdGl2ZXMtLWlzIG5lY2Vz c2FyaWx5IGNvcnJlY3QuICBXaXRoaW4gcHJvcHJpZXRhcnkgYWNjZXNzLCBhIHByb3ByaWV0YXJ5 IHNvbHV0aW9uIGlzIGFsd2F5cyBhIHBvdGVudGlhbCBjaG9pY2UuICBXaXRoaW4gM0dQUCBhY2Nl c3MsIGFsbCB0aGUgbmVjZXNzYXJ5IGNvbnN0cmFpbnRzIGNhbiBiZSBlbmZvcmNlZC4gIEludGVy b3BlcmFiaWxpdHkgb24gdGhlIEludGVybmV0IGRlbWFuZHMgdGhhdCBhbnkgc29sdXRpb24gaW4g dGhhdCBzcGFjZSBpcyB1bmlmb3JtLg0KDQpUbyBhc3N1bWUgdGhhdCBkZXZpY2VzIGF0dGFjaGVk IHRvIHRoZSBpbnRlcm5ldCB0aHJvdWdoIGEgM0dQUCBuZXR3b3JrIGFyZSBuZWNlc3NhcmlseSBh d2FyZSBvZiAzR1BQIGVtZXJnZW5jeSBwcm9jZWR1cmVzIGRvZXMgbm90IHJlY29nbmlzZSB0aGUg ZnVsbCBkaXZlcnNpdHkgb2YgSW50ZXJuZXQtZW5hYmxlZCBkZXZpY2VzLiAgVU1UUyByYWRpbyBp cyB3aWRlbHkgdXNlZCBmb3IgYnJvYWRiYW5kIGFjY2Vzcywgc28gaW1hZ2luZSBhIFdpRmkgcm91 dGVyIHdpdGggYSAzRyBjb25uZWN0aW9uLiAgRGV2aWNlcyBjb25uZWN0ZWQgdG8gdGhhdCByb3V0 ZXIgaGF2ZSBubyBtb3JlIG9mIGEgdmlldyBvZiB0aGUgM0cgbmV0d29yayB0aGFuIHRoZXkgd291 bGQgaGF2ZSBpZiB0aGUgcm91dGVyIHdlcmUgYSBEU0wgb25lLiAgQW4gRUNSSVQtY2FwYWJsZSBk ZXZpY2UgaW4gdGhhdCBuZXR3b3JrIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGJlIHVzZWQgaWYgdGhl IDNHIG5ldHdvcmsgZGlkIG5vdCBzdXBwb3J0IEVDUklUIHByb2NlZHVyZXMuDQoNCkl0J3MgdXAg dG8gdGhlIG5ldHdvcmsgb3BlcmF0b3IgdG8gZGVjaWRlIHdoZXRoZXIgdGhpcyBpcyBzb21ldGhp bmcgdGhleSBhIGNvbmNlcm5lZCBhYm91dC4gIEl0J3MgY2VydGFpbmx5IG5vdCB0aGUgcmVzcG9u c2liaWxpdHkgb2YgRUNSSVQgdG8gcG9pbnQgb3V0IGhvdyBhbiBvcGVyYXRvciBtaWdodCB1c2Ug M0dQUCBJTVMgZW1lcmdlbmN5IHNlcnZpY2VzLS1vciBhbnkgb3RoZXIgc3RhbmRhcmQtLWNlcnRh aW5seSBub3QgdG8gdGhlIGV4Y2x1c2lvbiBvZiBFQ1JJVCBjb21wYXRpYmlsaXR5Lg0KDQoNCkJl Zm9yZSBhZGRyZXNzaW5nIChCKSBpdCdzIGNsZWFyIHRoYXQgeW91IGhhdmUgc29tZSBtaXNjb25j ZXB0aW9ucyBhYm91dCB0aGUgRUNSSVQgYXJjaGl0ZWN0dXJlLiAgSSdsbCBhZGRyZXNzIHRob3Nl IGZpcnN0LiAgRm9yIGluc3RhbmNlOg0KDQo+IChjKSB0aGUNCj4gcmVxdWlyZW1lbnQgdGhhdCBh IHRlcm1pbmFsIG9yIGF0IGxlYXN0IGEgTElTIHdpbGwgdXBkYXRlIHRoZSBQU0FQDQo+IHdoZW5l dmVyIGxvY2F0aW9uIGNoYW5nZXMuDQoNClRoZSBwcm9jZXNzIGJ5IHdoaWNoIGEgUFNBUCBhY3F1 aXJlcyBsb2NhdGlvbiBpcyBxdWl0ZSBmbGV4aWJsZS4gIFRoZSBhYm92ZSByZWZsZWN0cyBhbiBh c3N1bXB0aW9uIHRpZWQgdG8gY29udmV5YW5jZSBvZiBsb2NhdGlvbiAiYnkgdmFsdWUiLiAgVXNl IG9mIGxvY2F0aW9uICJieSByZWZlcmVuY2UiIChJJ2xsIHJlZmVyIHlvdSBkbyB0aGUgR0VPUFJJ ViB3b3JrIG9uIHRoaXMgc3ViamVjdCksIHByb3ZpZGVzIGEgbWVhbnMgZm9yIGEgUFNBUCB0byBh Y3F1aXJlIGxvY2F0aW9uIGF0IGl0cyBkaXNjcmV0aW9uLg0KDQpUaGlzIGxlYWRzIHlvdSB0byBp bmZlciB0aGF0IGVuZHBvaW50LWRlcml2ZWQgbG9jYXRpb24gaXMgInVuc3VpdGFibGUgZm9yIHdp cmVsZXNzIG5ldHdvcmtzIi4gIFdoaWxlIHRoZSBwb2ludCBpcyBkZWJhdGFibGUgb2YgaXRzZWxm LCBsb2NhdGlvbiBieSByZWZlcmVuY2UgcHJvdmlkZXMgYSBtZWFucyBmb3Igd2lyZWxlc3MgbmV0 d29yayBvcGVyYXRvcnMgdG8gc2F2ZSB0aGUgZW5kcG9pbnQgZnJvbSBhbnkgY29zdHMgYXNzb2Np YXRlZCB3aXRoIGRlcml2YXRpb24gb2YgbG9jYXRpb24uICBGdXJ0aGVybW9yZSwgYXMgSGFubmVz IG5vdGVkLCBpZiAzR1BQIGFkb3B0ZWQgdGhpcyBhcmNoaXRlY3R1cmUsIHRoZSBQLUNTQ0YgY291 bGQgYmUgZGVsZWdhdGVkIHJlc3BvbnNpYmlsaXR5IGZvciB0aG9zZSBhc3BlY3RzIGFzc2lnbmVk IHRvIHRoZSBlbmRwb2ludC4gIFRoaXMgaW5jbHVkZXMgZGVyaXZhdGlvbiBvZiBsb2NhdGlvbiBh bmQgcm91dGUgZGV0ZXJtaW5hdGlvbi4gIEFnYWluLCBvZmZsb2FkIHRvIGFuIExSRiBhcyB5b3Ug c2VlIGZpdC4NCg0KSG93ZXZlciwgaXQncyBpbXBvcnRhbnQgdG8gdW5kZXJzdGFuZCB0aGF0IHRo aXMgbGluZSBvZiBhcmd1bWVudCBpcyBwcmVkaWNhdGVkIG9uIGFuIGFzc3VtcHRpb24gdGhhdCBh Y2Nlc3MgYW5kIHNlcnZpY2UgYXJlIHByb3ZpZGVkIGJ5IHRoZSBzYW1lIGVudGl0eSwgb3IgdGhh dCB0aGUgdHdvIGVudGl0aWVzIGhhdmUgYSBzdHJvbmcgcmVsYXRpb25zaGlwLiAgRUNSSVQgZG9l c24ndCBoYXZlIHRoZSBsdXh1cnkgb2YgYmVpbmcgYWJsZSB0byBtYWtlIHRoaXMgYXNzdW1wdGlv bjsgaWYgeW91IGRvLCB0aGVuIGFsdGVybmF0aXZlcyBsaWtlIDNHUFAgSU1TIG9wZW4gdXAuDQoN Cj4gKGIpIHJlc3RyaWN0aW9uIG9mIExDUHMgdG8gcHJvdG9jb2xzDQo+IHRoYXQgcmVxdWlyZSB0 ZXJtaW5hbCBpbml0aWF0aW9uIChub3QgYWxsb3dpbmcgZm9yIG5ldHdvcmsgaW5pdGlhdGlvbg0K PiBhcyBmYXIgYXMgd2UgY2FuIHRlbGwpDQoNClRoZSB2ZXJ5IGRlZmluaXRpb24gb2YgYW4gIkxD UCIgaXMgYSBwcm90b2NvbCBmb3IgYSBkZXZpY2UgdG8gZ2V0IGl0cyBvd24gbG9jYXRpb24uICBX aGF0IHlvdSBhcmUgdGFsa2luZyBhYm91dCBpcyBzb21ldGhpbmcgdGhhdCBHRU9QUklWIGFyZSB3 b3JraW5nIG9uLiAgZHJhZnQtd2ludGVyYm90dG9tLWdlb3ByaXYtaGVsZC1pZGVudGl0eS1leHRl bnNpb25zIGFkZHMgdGhlIGlkZW50aWZpZXJzIG5lY2Vzc2FyeSB0byB0dXJuIGFuIExDUCBpbnRv IHdoYXQgeW91IG1pZ2h0IHVzZSBmb3IgbmV0d29yayBpbml0aWF0aW9uLg0KDQpPbiB3aGF0IHlv dSBjbGFpbSBpcyBtaXNzaW5nOg0KDQooQikoYSkoaSkgSSBjYW5ub3QgYWdyZWUgdGhhdCB0aGUg bmV0d29yayBhbmQgdGVybWluYWwgbG9hZGluZyBjb25zZXF1ZW5jZXMgYXJlIGFzIGRpcmUgYXMg aW1wbGllZC4gIE9uIHRoZSBjb250cmFyeSwgSSBiZWxpZXZlIHRoZSBFQ1JJVCBhcmNoaXRlY3R1 cmUgaXMgaW5oZXJlbnRseSBtb3JlIHNjYWxhYmxlLiAgQnV0IHdpdGhvdXQgZXZpZGVuY2UgZWl0 aGVyIHdheSwgdGhhdCBhcmd1bWVudCBpcyBwb2ludGxlc3MuICBMZXQgdXMgYWdyZWUgdG8gbm90 IG1ha2Ugc3VjaCBkZWZpbml0aXZlIHN0YXRlbWVudCBvbiB0aGVzZSBpc3N1ZXMgd2l0aG91dCBz dWJzdGFudGlhdGlvbi4NCg0KKEIpKGEpKGlpKSBJZiB5b3UgYXJlIGNvbmNlcm5lZCBhYm91dCBu b24tSVAgUFNBUHMsIGNvbnNpZGVyIHRoZSBORU5BIGkyIGFyY2hpdGVjdHVyZS4gIEFzIHN0YXRl ZCwgRUNSSVQgaXMgY29uY2VybmVkIHdpdGggdGhlIEludGVybmV0LiAgT3IsIG1vcmUgY29uc3Ry dWN0aXZlbHksIHlvdSBjYW4gZWFzaWx5IGluamVjdCBhbiBJUC1lbmFibGVkIGdhdGV3YXkgYW5k IHRoZSBhcmNoaXRlY3R1cmUgd29ya3MgYWdhaW4uICBCdXQgdGhlbiwgdGhhdCdzIHdoYXQgaTIg ZG9lcy4NCg0KVG8gdHVybiB0aGlzIGFib3V0LCBpdCBpcyByZWFzb25hYmxlIHRvIGFzayBpbiB0 dXJuIHdoYXQgM0dQUCBpcyBkb2luZyB0byBlbnN1cmUgdGhhdCBJTVMgZW1lcmdlbmN5IHNwZWNp ZmljYXRpb25zIHdvcmsgaW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgUFNBUHMgYXNzdW1lIGkyIG9y IEVDUklUIGFyY2hpdGVjdHVyZXMuICBZb3UgbWVudGlvbiBwb3RlbnRpYWwgcHJvdmlzaW9uIGZv ciBsb2NhdGlvbiBieSByZWZlcmVuY2UgLSBpcyB0aGF0IGluIFJlbGVhc2UgOT8gIEhhcyAzR1BQ IGFkb3B0ZWQgU0lQIGxvY2F0aW9uIGNvbnZleWFuY2UgZm9yIGVtZXJnZW5jeT8NCg0KKEIpKGIp IEFzIG1lbnRpb25lZCwgdXBkYXRlcyBhcmUgcG9zc2libGUuICBZb3UnbGwgbmVlZCB0byBiZSBt b3JlIGV4cGxpY2l0IGFib3V0IHdoYXQgZ29hbHMgeW91IHNlZSAidmVyaWZpY2F0aW9uIiBhY2Nv bXBsaXNoaW5nIGJlZm9yZSBJIGNhbiBkZWZpbml0aXZlbHkgcmVzcG9uZC4NCg0KKEIpKGMpIGFu ZCAoQikoZCkgc2VlIGFib3ZlIHN0YXRlbWVudHMgd2l0aCByZWdhcmQgdG8gbmV0d29yay1kZXRl cm1pbmVkIGxvY2F0aW9uLg0KDQooQikoZSkgSGFuZG92ZXIgaW50byBjaXJjdWl0IHN3aXRjaGVk IGRvbWFpbiBpcyBtb3N0IGRlZmluaXRlbHkgbm90IGEgc3RhdGVkIGdvYWwuDQoNCihCKShmKSBV bmF1dGhlbnRpY2F0ZWQgYWNjZXNzIGlzIGEgbXVsdGktbGF5ZXJlZCBpc3N1ZS4gIEV4dGVuc2l2 ZSBkZWJhdGUgb24gdGhlIHN1YmplY3QgaGFzIGluZXZpdGFibHkgbGVhZCB0byB0aGUgY29uY2x1 c2lvbiB0aGF0IHRoaXMgaXMgYSByZXF1aXJlbWVudCB0aGF0IEVDUklUIGRvZXNuJ3Qgd2FudCB0 byBzb2x2ZSwgdGhvdWdoIHRoYXQgY29uY2x1c2lvbiBpc24ndCBkZWZpbml0aXZlLiAgSSdkIHJl ZmVyIHlvdSB0byB0aGUgbGlzdCBhcmNoaXZlcy4NCg0KKEIpKGNvbmNsdXNpb24pIEFzIGxvbmcg YXMgY2VsbHVsYXIgbmV0d29ya3MgcHJvdmlkZSBJbnRlcm5ldCBhY2Nlc3MsIHRoZXkgYXJlIHBv dGVudGlhbGx5IGNvdmVyZWQgYnkgdGhlIEVDUklUIGFyY2hpdGVjdHVyZS4gIEZvciBhbiBhY2Nl c3MgbmV0d29yaywgYWxsIHRoYXQgaXMgbmVjZXNzYXJ5IGlzIHRoYXQgaXQgc3VwcG9ydCB0aGUg cHJvdmlzaW9uIG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KDQpBcyBmYXIgYXMgdGhlIHZvaWNl IHNlcnZpY2UgZ29lcywgY2FsbCByb3V0aW5nIGZ1bmN0aW9ucyBhbmQgdGhlIGxpa2UgY291bGQg ZWFzaWx5IHVzZSB0aGUgbWV0aG9kcyBkZXNjcmliZWQgYnkgRUNSSVQuICBJIGRvbid0IGhhdmUg YSBnb29kIHZpZXcgb2YgaG93IHRoZSBiaXRzIGFuZCBieXRlcyBhbGlnbiB3aXRoIHdoYXQgaXMg aW4gSU1TOyBvYnZpb3VzbHkgdGhlcmUgd2lsbCBiZSBtaW5vciBkaWZmZXJlbmNlcywgYnV0IEkg Y2FuJ3QgaW1hZ2luZSB0aGF0IGl0IHdvdWxkIGJlIGltcG9zc2libGUgdG8gc3VwcG9ydCBzdWNo IHRoaW5ncyBhcyBzZXJ2aWNlIFVSTnMsIExvU1QgYW5kIGxvY2F0aW9uIGNvbnZleWFuY2UuLi5h cyBuZWNlc3NhcnkuDQoNCkNpcmN1aXQtc3dpdGNoZWQgY2FsbHMgcmVtYWluIGVudGlyZWx5IHRo ZSBwdXJ2aWV3IG9mIDNHUFAuDQoNCk5vIGRpc2NsYWltZXIvYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgaXMgbmVjZXNzYXJ5LiAgVGhlIDNHUFAgZW1lcmdlbmN5IGFyY2hpdGVjdHVyZSBkb2VzIG5v dCBhZGRyZXNzIGFsbCBvZiB0aGUgc3RhdGVkIGdvYWxzIG9mIEVDUklULCB3aGljaCBpbmNsdWRl IG9wZXJhdGlvbiBhbmQgaW50ZXJvcGVyYXRpb24gZm9yIGFsbCBJbnRlcm5ldCBkZXZpY2VzLg0K DQpFQ1JJVCBjYW4gaGFyZGx5IGJlIGZhdWx0ZWQgZm9yIGZhaWxpbmcgdG8gYWNjb21tb2RhdGUg b25lIHBhcnRpY3VsYXIgdmVydGljYWwgc29sdXRpb24uICBFeGlzdGVuY2UgaXMgbm90IGEgdmly dHVlIHRoYXQgbmVjZXNzaXRhdGVzIHRoZSBraW5kIG9mIHNwZWNpYWwgdHJlYXRtZW50IHlvdSBz ZWVtIHRvIGV4cGVjdC4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCnAucy4gT24gcG9pbnQgKEMpOiBX ZSBjYW4ndCBjb25jZXJuIG91cnNlbHZlcyB3aXRoIHdoYXQgbWlnaHQgYmUsIGJ1dCBhcyBmb3Ig d2hhdCBpcyBvciBpcyBub3QgY29tcGF0aWJsZSwgSSB0aGluayB0aGF0IHRoZSByZXN0IG9mIG15 IGVtYWlsIGhhcyBhZGRyZXNzZWQgdGhhdC4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgRWRnZSwgU3RlcGhlbg0KPiBTZW50OiBUaHVyc2Rh eSwgNSBGZWJydWFyeSAyMDA5IDY6NTAgUE0NCj4gVG86ICdFQ1JJVCcNCj4gU3ViamVjdDogW0Vj cml0XSBDb21tZW50cyBvbiBGcmFtZXdvcmsgRHJhZnQNCj4gDQo+IEFsbA0KPiANCj4gZHJhZnQt aWV0Zi1lY3JpdC1mcmFtZXdvcmstMDcgaXMgKGFzIHdlIHNlZSBpdCkgYSBtb3N0bHkgaW5mb3Jt YXRpdmUNCj4gZGVzY3JpcHRpb24gb2YgaG93IHRlcm1pbmFscyBhbmQgbmV0d29ya3Mgc2hvdWxk IHN1cHBvcnQgZW1lcmdlbmN5DQo+IGNhbGxzIG1hZGUgb3ZlciBJUCBjYXBhYmxlIGZhY2lsaXRp ZXMgdG8gSVAgY2FwYWJsZSBQU0FQcy4gSXQgYXBwZWFycw0KPiBpbnRlbmRlZCB0byBjb3ZlciBh bGwgdHlwZXMgb2YgYWNjZXNzIG5ldHdvcmsgLSBpbmNsdWRpbmcgZml4ZWQgbGluZSwNCj4gV2lG aSBhbmQgY2VsbHVsYXIgKGUuZy4gZXhhbXBsZXMgaW52b2x2aW5nIGVhY2ggY2FuIGJlIGZvdW5k IHRocm91Z2hvdXQNCj4gdGhlIGRyYWZ0KS4NCj4gDQo+IFdoZW4gd2UgZXZhbHVhdGVkIHRoaXMg d2l0aCByZXNwZWN0IHRvIHN1cHBvcnQgb2Ygd2lyZWxlc3MgY2VsbHVsYXINCj4gYWNjZXNzIGFu ZCBXaUZpIGFjY2VzcyBhc3NvY2lhdGVkIHdpdGggYSBjZWxsdWxhciBvcGVyYXRvciAoZS5nLiBX TEFODQo+IG9yIEZlbXRvIGNlbGxzIGludGVncmF0ZWQgaW50byBhIGNlbGx1bGFyIG5ldHdvcmsp LCB3ZSBmb3VuZCB0aGF0DQo+IGNlcnRhaW4gcG9ydGlvbnMgb2YgdGhlIGRyYWZ0IGV4aGliaXRl ZCBvbmUgb3IgbW9yZSBvZiB0aGUgZm9sbG93aW5nDQo+IGNoYXJhY3RlcmlzdGljczoNCj4gDQo+ IMKgwqDCoCAoQSkgSW5jb25zaXN0ZW50IHdpdGggYWxyZWFkeSBzdGFuZGFyZGl6ZWQgd2lyZWxl c3Mgc29sdXRpb25zDQo+IA0KPiDCoMKgwqAgKEIpIEluY29uc2lzdGVudCB3aXRoIGVzc2VudGlh bCB3aXJlbGVzcyByZXF1aXJlbWVudHMgYW5kDQo+IGNvbnZlbnRpb25zDQo+IA0KPiDCoMKgwqAg KEMpIEFscmVhZHkgcGFydCBvZiB3aXJlbGVzcyBzdGFuZGFyZHMgb3IgcG90ZW50aWFsbHkgcGFy dCBvZg0KPiBmdXR1cmUgc3RhbmRhcmRzDQo+IA0KPiAoQSkgcmVmZXJzIHRvIGFsbCBwb3J0aW9u cyBvZiB0aGUgZHJhZnQgZnJhbWV3b3JrIHRoYXQgZGlmZmVyIGZyb20gdGhlDQo+IHJlcXVpcmVt ZW50cyBhbmQgcHJvY2VkdXJlcyBjdXJyZW50bHkgc3RhbmRhcmRpemVkIGZvciB3aXJlbGVzcw0K PiBlbWVyZ2VuY3kgYWNjZXNzIGJ5IDNHUFAsIDNHUFAyIGFuZCBPTUEuIFRoaXMgaXMgYSBwbGFp biBkaWZmZXJlbmNlIG9mDQo+IHNvbHV0aW9uIGFuZCBjb3VsZCBiZSByZXNvbHZlZCB0aHJvdWdo IHN1cHBvcnQgb2YgYm90aCBzb2x1dGlvbnMgYnkNCj4gdGVybWluYWxzICh3aXRoIGVhY2ggc29s dXRpb24gYmVpbmcgdXNlZCBhY2NvcmRpbmcgdG8gdGhlIHR5cGUgb2YNCj4gYWNjZXNzIG5ldHdv cmsgYW5kIFZTUCkgb3IgY291bGQgYmUgcmVzb2x2ZWQgYnkgc3VwcG9ydGluZyBvbmx5IG9uZQ0K PiBzb2x1dGlvbiBhbmQgYWNjZXNzaW5nIG9ubHkgdGhlIHR5cGVzIG9mIG5ldHdvcmsgc3VwcG9y dGluZyB0aGF0DQo+IHNvbHV0aW9uLiBUbyBhY2tub3dsZWRnZSB0aGlzIGNhdGVnb3J5LCB0aGUg ZnJhbWV3b3JrIGRvY3VtZW50IGNvdWxkDQo+IHJlZmVyZW5jZSB0aGUgYXBwbGljYWJsZSB3aXJl bGVzcyBzdGFuZGFyZHMgYW5kIHBvaW50IG91dCB0aGF0IHRoZXNlDQo+IGFyZSB2YWxpZCBhbHRl cm5hdGl2ZXMgZm9yIHdpcmVsZXNzIGNlbGx1bGFyIGJhc2VkIGFjY2Vzcy4NCj4gDQo+IChCKSBy ZWZlcnMgdG8gcG9ydGlvbnMgb2YgdGhlIGRyYWZ0IHRoYXQgd291bGQgYmUgdW5zdWl0YWJsZSBm b3INCj4gd2lyZWxlc3MgbmV0d29ya3MgZXZlbiBpZiBubyBhbHRlcm5hdGl2ZSBzb2x1dGlvbiBl eGlzdGVkIHRvZ2V0aGVyIHdpdGgNCj4gb3RoZXIgcG9ydGlvbnMgbWlzc2luZyBmcm9tIHRoZSBk cmFmdCB0aGF0IHdvdWxkIGJlIG5lZWRlZCB0byBmdWxseQ0KPiBzdXBwb3J0IHdpcmVsZXNzIG5l dHdvcmtzLiBFeGFtcGxlcyBvZiB0aGUgZm9ybWVyIGluY2x1ZGU6IChhKSBlbXBoYXNpcw0KPiBv biBlbmRwb2ludCBkZXJpdmF0aW9uIG9mIGxvY2F0aW9uLCBwZXJmb3JtYW5jZSBvZiBMb3N0IHF1 ZXJ5IGFuZA0KPiByZWNlaXB0IG9mIGxvY2FsIGRpYWwgc3RyaW5nczsgKGIpIHJlc3RyaWN0aW9u IG9mIExDUHMgdG8gcHJvdG9jb2xzDQo+IHRoYXQgcmVxdWlyZSB0ZXJtaW5hbCBpbml0aWF0aW9u IChub3QgYWxsb3dpbmcgZm9yIG5ldHdvcmsgaW5pdGlhdGlvbg0KPiBhcyBmYXIgYXMgd2UgY2Fu IHRlbGwpIGFuZCB0aGF0IGluY2x1ZGUgdHdvIExDUHMgKERIQ1AgYW5kIExMRFApIHRoYXQNCj4g YXJlIG5vdCBhcHBsaWNhYmxlIHRvIChub3QgZGVmaW5lZCBmb3IpIGNlbGx1bGFyIGFjY2Vzczsg YW5kIChjKSB0aGUNCj4gcmVxdWlyZW1lbnQgdGhhdCBhIHRlcm1pbmFsIG9yIGF0IGxlYXN0IGEg TElTIHdpbGwgdXBkYXRlIHRoZSBQU0FQDQo+IHdoZW5ldmVyIGxvY2F0aW9uIGNoYW5nZXMuIChh KSBpcyBpbXByYWN0aWNhbCBkdWUgdG8gbmV0d29yayBhbmQNCj4gdGVybWluYWwgbG9hZGluZyBj b25zZXF1ZW5jZXMgYW5kIGZhaWx1cmUgdG8gc3VwcG9ydCBub24tSVAgY2FwYWJsZQ0KPiBQU0FQ czsgKGIpIG1ha2VzIGxvY2F0aW9uIHZlcmlmaWNhdGlvbiBhbmQgdXBkYXRlZCBsb2NhdGlvbiBw cm92aXNpb24NCj4gdG8gUFNBUHMgZGlmZmljdWx0IG9yIGltcG9zc2libGU7IHdoaWxlIChjKSBp cyBhbHNvIGluY29tcGF0aWJsZSB3aXRoDQo+IHN1cHBvcnQgb2YgZXhpc3Rpbmcgbm9uLUlQIGNh cGFibGUgUFNBUHMgYmVzaWRlcyBpbmNyZWFzaW5nIHRlcm1pbmFsDQo+IGxvYWQgYW5kIHBvc3Np Ymx5IGludGVyZmVyaW5nIHdpdGggb3B0aW11bSBtYWludGVuYW5jZSBvZiB0aGUgUkYNCj4gY29u bmVjdGlvbiAoZS5nLiBpZiBhIHRlcm1pbmFsIGhhcyB0byB0dW5lIGF3YXkgZnJvbSB0aGUgc2Vy dmluZyBiYXNlDQo+IHN0YXRpb24gb3IgV0xBTiBwZXJpb2RpY2FsbHkgdG8gbWFrZSBsb2NhdGlv biBtZWFzdXJlbWVudHMpLiBFeGFtcGxlcw0KPiBvZiB0aGUgbGF0dGVyIGluY2x1ZGUgKGQpIGFi c2VuY2Ugb2Ygc3VwcG9ydCBmb3IgYWNjZXNzIHRvIG5vbi1JUA0KPiBjYXBhYmxlIFBTQVBzIGFz IGFscmVhZHkgbWVudGlvbmVkIChlLmcuIHRvIHN1cHBvcnQgRTkxMSBwaGFzZSAyIGluIHRoZQ0K PiBVUyk7IChlKSBubyBzdXBwb3J0IGZvciBoYW5kb3ZlciBmcm9tIHRoZSBJUCB0byB0aGUgY2ly Y3VpdCBkb21haW4gd2hlbg0KPiBhIHRlcm1pbmFsIGxvc2VzIChlLmcuIG1vdmVzIG91dCBvZikg UkYgY292ZXJhZ2UgaW4gdGhlIElQIGRvbWFpbjsgYW5kDQo+IChmKSBubyBhbGxvd2FuY2UgZm9y IGxpbWl0ZWQgYWNjZXNzIG1vZGVzIHdoZXJlaW4gYSB0ZXJtaW5hbCBtYXkgYWNjZXNzDQo+IGEg bmV0d29yayBvbmx5IHRvIHBsYWNlIGFuIGVtZXJnZW5jeSBjYWxsIHdpdGggZW5zdWluZyByZXN0 cmljdGlvbnMgb24NCj4gKGZvciBleGFtcGxlKSBsb2NhdGlvbiBhY3F1aXNpdGlvbiwgUFNBUCBj YWxsYmFjayBhbmQgY2FsbGVyDQo+IHZlcmlmaWNhdGlvbiBhbmQgaWRlbnRpZmljYXRpb24gdG8g dGhlIFBTQVAuIFRvIHJlc29sdmUgdGhpcyBjYXRlZ29yeQ0KPiBlaXRoZXIgc2lnbmlmaWNhbnQg Y2hhbmdlcyB0byB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGNvdWxkIGJlIG1hZGUgb3IgYQ0KPiBk aXNjbGFpbWVyL2FwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGNvdWxkIGJlIGFkZGVkIHN0YXRpbmcg dGhhdCBzdXBwb3J0DQo+IG9mIGNlbGx1bGFyIHdpcmVsZXNzIG5ldHdvcmtzIGFuZCB0aGVpciBh c3NvY2lhdGVkIFdMQU4gYW5kIEZlbXRvDQo+IGFjY2VzcyBwb2ludHMgaXMgbm90IGNvdmVyZWQu DQo+IA0KPiBDYXRlZ29yeSAoQykgY29tcHJpc2VzIGNvbmNlcHRzIGFuZCBjYXBhYmlsaXRpZXMg aW4gdGhlIGRyYWZ0IHRoYXQgYXJlDQo+IGVpdGhlciBhbHJlYWR5IHBhcnQgb2YgdGhlIHN0YW5k YXJkaXplZCBzb2x1dGlvbiBmb3Igd2lyZWxlc3MgbmV0d29ya3MNCj4gb3IgdGhhdCBtaWdodCBi ZSBhZGRlZCBhdCBhIGxhdGVyIHRpbWUuIEV4YW1wbGVzIG9mIHRoZSBmb3JtZXIgaW5jbHVkZQ0K PiBMb1NULCBTSVAgbG9jYXRpb24gY29udmV5YW5jZSwgZ2VuZXJhbCB1c2Ugb2YgU0lQLCBsb2Nh dGlvbiBmb3Igcm91dGluZw0KPiB2ZXJzdXMgZm9yIGRpc3BhdGNoLCBjZWxsdWxhciBwb3NpdGlv bmluZyBtZXRob2RzLiBFeGFtcGxlcyBvZiB0aGUNCj4gbGF0dGVyIGluY2x1ZGUgdXNlIG9mIGxv Y2F0aW9uIHJlZmVyZW5jZXMgYW5kIGRlcmVmZXJlbmNpbmcgYW5kDQo+IHBvc3NpYmxlIGludGVy d29ya2luZyBiZXR3ZWVuIHRoZSBjdXJyZW50IHdpcmVsZXNzIG5ldHdvcmsgc29sdXRpb25zDQo+ IChpbiAzR1BQLCAzR1BQMiBhbmQgT01BKSBhbmQgdGhlIHNvbHV0aW9uIGRlc2NyaWJlZCBpbiB0 aGlzIGRyYWZ0LiBUaGUNCj4gcHJlc2VuY2Ugb2YgdGhpcyBjYXRlZ29yeSBjb3VsZCBiZSBhY2tu b3dsZWRnZWQgYnkgZm9sbG93aW5nIHRoZQ0KPiBkaXNjbGFpbWVyIGZvciAoQikgd2l0aCBhIHN0 YXRlbWVudCB0aGF0IGNlcnRhaW4gcG9ydGlvbnMgb2YgdGhlDQo+IHNvbHV0aW9uIGFyZSBleHBl Y3RlZCB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byB3aXJlbGVzcyBuZXR3b3JrcyBub3cNCj4gYW5k L29yIGluIHRoZSBmdXR1cmUuDQo+IA0KPiBXZSBob3BlIHRoYXQgdGhlc2UgY29tbWVudHMgd2ls bCBiZSBzZWVuIHRvIGJlIGEgdXNlZnVsIGFkZGl0aW9uIHRvDQo+IHRoaXMgcmV2aWV3IGluIHRo ZSBzZW5zZSBvZiBlbmFibGluZyBhIG1vcmUgcHJlY2lzZSBzY29waW5nIGZvciB0aGUNCj4gZnJh bWV3b3JrIGRvY3VtZW50IGFuZCB3ZSBhcmUgd2lsbGluZyB0byBhc3Npc3QgaW4gcHJvdmlkaW5n IHdvcmRpbmcNCj4gZm9yIGFueSBkaXNjbGFpbWVyL2FwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHRo YXQgdGhlIEVjcml0IHdvcmtpbmcgZ3JvdXANCj4gbWF5IG5vdyBkZWVtIGZpdCB0byBpbmNsdWRl Lg0KPiANCj4gS2luZCBSZWdhcmRzDQo+IA0KPiBTdGVwaGVuIEVkZ2UgKFF1YWxjb21tIDNHUFAg U0EyIHBhcnRpY2lwYW50KSwgS2lyayBCdXJyb3VnaHMgKFF1YWxjb21tDQo+IDNHUFAyIFRTRy1Y IGFuZCBUU0ctQyBwYXJ0aWNpcGFudCkNCj4gDQo+IFBTICB0aGlzIGJlaW5nIHNlbnQgb24gMi80 LzA5IGF0IDExOjUwcG0gUFNUDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhl IGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBw cm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBo YXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVk aWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YN CnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KW21mMl0NCg== Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A66B28C13A for ; Thu, 12 Feb 2009 04:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed8FSU3GRyK0 for ; Thu, 12 Feb 2009 04:08:25 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CF34928C139 for ; Thu, 12 Feb 2009 04:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1234440510; x=1265976510; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20H annes=20Tschofenig=20,=20"'ECR IT'"=20|Date:=20Thu,=2012=20Feb=202009=20 04:08:22=20-0800|Subject:=20RE:=20[Ecrit]=20Comments=20on =20Framework=20Draft|Thread-Topic:=20[Ecrit]=20Comments =20on=20Framework=20Draft|Thread-Index:=20AcmHZkcFqEtDIGT NRMy2Xqm0XoWoXwAAnQ6gAWY1w+A=3D|Message-ID:=20<1288E74A73 964940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.co m>|References:=20<1288E74A73964940B132A0B9EA8D8ABC535F030 5@NASANEXMB04.na.qualcomm.com>=0D=0A=20<003901c98772$b4cc 7710$0201a8c0@nsnintra.net>|In-Reply-To:=20<003901c98772$ b4cc7710$0201a8c0@nsnintra.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5523"=3B=20a=3D"15422782"; bh=Jb9Kwv/tkguzfbSXxgvSOi7IFLsx0mLztznBcj743n0=; b=ZBNwUESSmnrrYH41WDCfAALNsKZJyYsGEmOom5q/it93JJMErfGpeL0N z3L0LNuOi00VSalVKJveLN+SMpWXKQE4arY6pVhmINd5BksNwLT+26Qw5 8FnE6xB27IuefddlDV0zJ0wvr8ndReVa9RNriANWP2g8aIizlORwmYXq5 0=; X-IronPort-AV: E=McAfee;i="5100,188,5523"; a="15422782" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2009 04:08:29 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CC8Tmt027966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2009 04:08:30 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CC8TJU009606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2009 04:08:29 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Thu, 12 Feb 2009 04:08:28 -0800 From: "Edge, Stephen" To: Hannes Tschofenig , "'ECRIT'" Date: Thu, 12 Feb 2009 04:08:22 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+A= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <003901c98772$b4cc7710$0201a8c0@nsnintra.net> In-Reply-To: <003901c98772$b4cc7710$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 12:08:27 -0000 Hi Hannes Thanks for all these comments. I have embedded below a number of responses = (look for [SE: .... ]). The previous suggestions remain, however, unchanged= from our perspective. Whether it is worth attempting to align the two solu= tions more at this stage seems questionable. By including appropriate discl= aimers, the Framework (and phoneBCP) spec.s can continue to define an optim= um solution for exactly the call scenarios for which they were really inten= ded leaving it clearer than before that an alternative solution exists for = a good portion of the missing cases. Merging part of one solution into the = other might not create anything very useful and changing one solution or th= e other risks losing some of its current optimality. But I agree that this = could still be looked at on one or both sides and in fact in 3GPP we have m= ade some limited attempts at this already to create a more generic solution= with fewer restrictions on AN and VSP combinations. Kind Regards Stephen -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, February 05, 2009 1:18 AM To: Edge, Stephen; 'ECRIT' Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen,=20 Thanks for your review. A few minor comments.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Edge, Stephen >Sent: 05 February, 2009 09:50 >To: 'ECRIT' >Subject: [Ecrit] Comments on Framework Draft > >All >=A0 >draft-ietf-ecrit-framework-07 is (as we see it) a mostly=20 >informative description of how terminals and networks should=20 >support emergency calls made over IP capable facilities to IP=20 >capable PSAPs. It appears intended to cover all types of=20 >access network - including fixed line, WiFi and cellular (e.g.=20 >examples involving each can be found throughout the draft). Correct. The framework document is the informative description where=20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt provides the normative part.=20 We thought that this would make it easy for the reader to follow the entire story best.=20 >=A0 >When we evaluated this with respect to support of wireless=20 >cellular access and WiFi access associated with a cellular=20 >operator (e.g. WLAN or Femto cells integrated into a cellular=20 >network), we found that certain portions of the draft=20 >exhibited one or more of the following characteristics: >=A0 >=A0=A0=A0 (A) Inconsistent with already standardized wireless solutions >=A0 >=A0=A0=A0 (B) Inconsistent with essential wireless requirements and=20 >conventions >=A0 >=A0=A0=A0 (C) Already part of wireless standards or potentially part=20 >of future standards >=A0 >(A) refers to all portions of the draft framework that differ=20 >from the requirements and procedures currently standardized=20 >for wireless emergency access by 3GPP, 3GPP2 and OMA. This is=20 >a plain difference of solution and could be resolved through=20 >support of both solutions by terminals (with each solution=20 >being used according to the type of access network and VSP) or=20 >could be resolved by supporting only one solution and=20 >accessing only the types of network supporting that solution.=20 >To acknowledge this category, the framework document could=20 >reference the applicable wireless standards and point out that=20 >these are valid alternatives for wireless cellular based access. You know that we have tried hard over the past few years to harmonize the work done by different SDOs, including 3GPP. You were involved in some of these activities.=20 For some reason, various companies did not like such an alignment and hence we are left with the situation that IMS emergency calling and emergency calling for everything else works differently.=20 This is unfortunate. Your company was always a big fan of developing a harmonized solution, right?=20 I doubt that the situation is improved by summarizing other standardization efforts in this document nor by describing the content of this document in 3GPP, 3GPP2 or OMA documents.=20 [SE: our proposal is only to acknowledge the existence of this other soluti= on by reference not to try to summarize it.]=20 >(B) refers to portions of the draft that would be unsuitable=20 >for wireless networks even if no alternative solution existed=20 >together with other portions missing from the draft that would=20 >be needed to fully support wireless networks. Please note that we make a differentiation between wireless and cellular. I guess you refer to cellular.=20 [SE: mainly yes. And in fact this is just the type of applicability stateme= nt that we are looking for - i.e. an acknowledgement that the Framework sol= ution is mainly designed for wireline and non-cellular associated wireless = access and is not intended to apply in its entirety to cellular associated = wireless access.] Examples of the=20 >former include: (a) emphasis on endpoint derivation of=20 >location, performance of Lost query and receipt of local dial=20 >strings; Please note that we are talking about location for 2 different purposes here:=20 * Location for routing=20 * Location for dispatch It is true that the document puts a focus on the end point obtaining location (at least for routing). There is, however, a story in there for th= e case where the end point does not have access to location at all.=20 Having access to local dial strings at the end point is a very useful thing= , if you think about it.=20 Regarding LoST: Please note that LoST can also be executed by the VoIP provider when routing is required.=20 [SE: yes I was aware of this, but it is treated as something of an exceptio= n whereas for cellular networks, it is the norm.] >(b) restriction of LCPs to protocols that require=20 >terminal initiation (not allowing for network initiation as=20 >far as we can tell) and that include two LCPs (DHCP and LLDP)=20 >that are not applicable to (not defined for) cellular access;=20 These two LCPs are only required for devices that can also be used in a fixed / wireless (but not cellular) environment. In environments where the end host is expected to only ever use a cellular system these two LCPs need not to be implemented.=20 Network initiation has never found huge excitement within the members of th= e GEOPRIV group. I don't see this is a limitation, to be honest.=20 [SE: there is no problem if the proper cellular disclaimer gets added. Othe= rwise, I would see the need for some significant change to admit other type= s of LCP - e.g. OMA SUPL and 3GPP control plane solution.] >and (c) the requirement that a terminal or at least a LIS will=20 >update the PSAP whenever location changes. I guess the items below refer to the dynamic location change. (a) is impractical=20 >due to network and terminal loading consequences I guess you see it as more dramatic than it is. The LIS and the PSAP can control the rate of information disclosure, see http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt.= =20 Specifying at what rate the terminal would send up-to-date information is policy and implementation dependent. =20 and failure=20 >to support non-IP capable PSAPs; The IETF ECRIT solution is an IP-based solution and hence the Internet ends where the last IP node is located.=20 For interworking with non-IP capable PSAPs please take a look at the NENA i2/i2.5 work, which is the most advanced of its kind.=20 [SE: A problem is that the latest i2.5 draft states that "This issue of the= i2 standard supports E9-1-1 for fixed and nomadic VoIP services. Support f= or mobile VoIP services will be covered in a future release of this documen= t." We expect that the missing mobile VoIP support will be provided by inco= rporating the 3GPP/3GPP2 solution as has already occurred for the i3 draft.= Whether it may also be supported by extending what is already in the i2.5 = draft independently of the 3GPP/3GPP2 solution remains to be seen.] (b) makes location=20 >verification and updated location provision to PSAPs difficult=20 >or impossible; Could you elaborate a bit? Not sure I understood the "verification" and the "updated location provisioning" part.=20 [SE: with terminal initiated location, the terminal can provide location va= lues that are unreliable or deliberately false (and cannot be verified as s= uch by the network) and may not provide location updates as needed by a PSA= P. Even using location by reference (which I agree should be better), the V= SP plays no part though may be held liable by the PSAP or regulatory bodies= for any mistakes.] while (c) is also incompatible with support of=20 >existing non-IP capable PSAPs besides increasing terminal load=20 >and possibly interfering with optimum maintenance of the RF=20 >connection (e.g. if a terminal has to tune away from the=20 >serving base station or WLAN periodically to make location=20 >measurements). I guess you are hunting an academic problem. The document does not say that you provide a continues stream of location information. We are more concerned about getting rough location as fast as possible to make the emergency call routing to happen to the right PSAP and then provide up-to-date location available to the PSAP for dispatch, when available.=20 Sure, there are corner cases when the emergency caller happens to be in a fast car driving down the highway and location is constantly changing.=20 [SE: it just seems less efficient to be obtaining and sending a stream of l= ocation updates rather than obtaining a location update only when the PSAP = wants it. But I agree that feasibility need not be in question here.] Examples of the latter include (d) absence of=20 >support for access to non-IP capable PSAPs as already=20 >mentioned (e.g. to support E911 phase 2 in the US);=20 This is excluded by our charter and, as I said, possible with the solution NENA has worked out with i2 and i2.5.=20 Please also note that today fixed (and wireless -- but not cellular) operators are looking for VoIP emergency solutions as they are somewhat ahead with VoIP deployment compared to cellular operators. Hence, this will give PSAP operators more time to migrate to an IP-based environment and these things are happening as we speak. Sure, this all need= s time but the cost savings for an IP-based solution (as it was reported to use at the emergency services workshops) seems to speak in favor of IP.=20 [SE: cellular operators have to support legacy PSAPs so this cannot be out = of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer to the = Framework would clarify that.] (e) no=20 >support for handover from the IP to the circuit domain when a=20 >terminal loses (e.g. moves out of) RF coverage in the IP=20 >domain;=20 Correct. Our charter does not allow us to work on VCC.=20 [SE: also seems a suitable item for a disclaimer.] and (f) no allowance for limited access modes wherein=20 >a terminal may access a network only to place an emergency=20 >call with ensuing restrictions on (for example) location=20 >acquisition, PSAP callback and caller verification and=20 >identification to the PSAP. To resolve this category either=20 >significant changes to the framework document could be made or=20 >a disclaimer/applicability statement could be added stating=20 >that support of cellular wireless networks and their=20 >associated WLAN and Femto access points is not covered. This issue in under consideration in the ECRIT working group, see http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-04.= t xt.=20 The reason for us to separate this aspect from the main document is simply it's complexity and the uncertainty from a regulatory point of view.=20 When you look at the document you will quickly realize that "unauthenticate= d emergency calls" in an IP-based context mean much more than they do today.= =20 We have also discussed this topic at the emergency services workshops and the different views about this topic are interesting to observe but leave a lot of fuzziness behind.=20 [SE: can also disclaim this.] >=A0 >Category (C) comprises concepts and capabilities in the draft=20 >that are either already part of the standardized solution for=20 >wireless networks or that might be added at a later time.=20 >Examples of the former include LoST, SIP location conveyance,=20 >general use of SIP, location for routing versus for dispatch,=20 >cellular positioning methods. Examples of the latter include=20 >use of location references and dereferencing and possible=20 >interworking between the current wireless network solutions=20 >(in 3GPP, 3GPP2 and OMA) and the solution described in this=20 >draft. The presence of this category could be acknowledged by=20 >following the disclaimer for (B) with a statement that certain=20 >portions of the solution are expected to be incorporated into=20 >wireless networks now and/or in the future. I am not sure I got your point. It is true that we have produced a couple o= f specifications and, in case of SIP Location Conveyance, the standardization effort is not yet completed.=20 [SE: I thought this might show that 3GPP/3GPP2 have been quite diligent in = attempting to incorporate applicable parts of the IETF solution. This seems= actually more a story of success (on both sides).] >=A0 >We hope that these comments will be seen to be a useful=20 >addition to this review in the sense of enabling a more=20 >precise scoping for the framework document and we are willing=20 >to assist in providing wording for any=20 >disclaimer/applicability statement that the Ecrit working=20 >group may now deem fit to include. Thanks for your help.=20 >=A0 >Kind Regards >=A0 Thanks for your detailed review and for trying to help us ensuring that the document does not raise wrong expectations.=20 Ciao Hannes >Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs=20 >(Qualcomm 3GPP2 TSG-X and TSG-C participant) > >PS this being sent on 2/4/09 at 11:50pm PST > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D3828C14B for ; Thu, 12 Feb 2009 04:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoyFF0idcCHu for ; Thu, 12 Feb 2009 04:28:09 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1C7A028C139 for ; Thu, 12 Feb 2009 04:28:08 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_12_06_47_31 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, 12 Feb 2009 06:47:31 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 06:28:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 06:28:11 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sA== References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net> <1288E74A73964940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 12 Feb 2009 12:28:13.0389 (UTC) FILETIME=[5F8C47D0:01C98D0D] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 12:28:14 -0000 Hello Stephen,=0D=0A=0D=0AThe bulk of your commentary appears to be based o= n the following tenet - in your words:=0D=0A=0D=0A[SE: mainly yes. And in f= act this is just the type of applicability statement that we are looking fo= r - i.e. an acknowledgement that the Framework solution is mainly designed = for wireline and non-cellular associated wireless access and is not intende= d to apply in its entirety to cellular associated wireless access.]=0D=0A=0D= =0AThis is quite untrue. The framework is not mainly designed for Wireline = and non-cellular associated wireless access. The framework is designed for = any form of Internet access. You could qualify it as broadband Internet acc= ess if you want - but even that isn't necessary. To assume that public mobi= le Internet access networks are somehow different is to miss the point of c= onvergence.=0D=0A=0D=0A3GPP can define walled garden architectures such as = IMS if it likes - it is, of course, completely up to that SDO. However, it = doesn't really have anything to do with the IETF and doesn't, qualitatively= , warrant a special mention from ECRIT any more than, say, maritime radio a= nd emergency calling does.=0D=0A=0D=0AWith respect to the following:=0D=0A=0D= =0A[SE: with terminal initiated location, the terminal can provide location= values that are unreliable or deliberately false (and cannot be verified a= s such by the network) and may not provide location updates as needed by a = PSAP. Even using location by reference (which I agree should be better), th= e VSP plays no part though may be held liable by the PSAP or regulatory bod= ies for any mistakes.]=0D=0A=0D=0AThe VSP plays no part in the location det= ermination; it is the AN operator that takes this responsibility. This is, = in fact, the same case today - even in 2G. It's the AN provider that takes = responsibility for location determination. I cannot see a sensible judgemen= t being made of a VSP for a piece of information for which they are not res= ponsible. With all due respect, that sounds like FUD.=0D=0A=0D=0AWith respe= ct to your point about location-spoofing, you're quite correct and, indeed,= that is one reason that LbyR is such a valuable mechanism. There's also a = draft that describes how the LIS can digitally sign the PIDF-LO. It hasn't = proved necessary yet but may at some point. It certainly makes one wonder h= ow 3GPP2 can be so determined to use SUPL when there does not appear to be = any practical means to validate SET-provided measurements when the RAN is c= ompletely bypassed.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.= org] On Behalf Of Edge, Stephen=0D=0ASent: Thursday, 12 February 2009 11:08= PM=0D=0ATo: Hannes Tschofenig; 'ECRIT'=0D=0ASubject: Re: [Ecrit] Comments = on Framework Draft=0D=0A=0D=0AHi Hannes=0D=0A=0D=0AThanks for all these com= ments. I have embedded below a number of responses (look for [SE: .... ]). = The previous suggestions remain, however, unchanged from our perspective. W= hether it is worth attempting to align the two solutions more at this stage= seems questionable. By including appropriate disclaimers, the Framework (a= nd phoneBCP) spec.s can continue to define an optimum solution for exactly = the call scenarios for which they were really intended leaving it clearer t= han before that an alternative solution exists for a good portion of the mi= ssing cases. Merging part of one solution into the other might not create a= nything very useful and changing one solution or the other risks losing som= e of its current optimality. But I agree that this could still be looked at= on one or both sides and in fact in 3GPP we have made some limited attempt= s at this already to create a more generic solution with fewer restrictions= on AN and VSP combinations.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A= -----Original Message-----=0D=0AFrom: Hannes Tschofenig [mailto:Hannes.Tsch= ofenig@gmx.net]=20=0D=0ASent: Thursday, February 05, 2009 1:18 AM=0D=0ATo: = Edge, Stephen; 'ECRIT'=0D=0ASubject: RE: [Ecrit] Comments on Framework Draf= t=0D=0A=0D=0AHi Stephen,=20=0D=0A=0D=0AThanks for your review. A few minor = comments.=20=0D=0A=0D=0A>-----Original Message-----=0D=0A>From: ecrit-bounc= es@ietf.org [mailto:ecrit-bounces@ietf.org]=20=0D=0A>On Behalf Of Edge, Ste= phen=0D=0A>Sent: 05 February, 2009 09:50=0D=0A>To: 'ECRIT'=0D=0A>Subject: [= Ecrit] Comments on Framework Draft=0D=0A>=0D=0A>All=0D=0A>=A0=0D=0A>draft-i= etf-ecrit-framework-07 is (as we see it) a mostly=20=0D=0A>informative desc= ription of how terminals and networks should=20=0D=0A>support emergency cal= ls made over IP capable facilities to IP=20=0D=0A>capable PSAPs. It appears= intended to cover all types of=20=0D=0A>access network - including fixed l= ine, WiFi and cellular (e.g.=20=0D=0A>examples involving each can be found = throughout the draft).=0D=0A=0D=0ACorrect. The framework document is the in= formative description where=20=0D=0Ahttp://www.ietf.org/internet-drafts/dra= ft-ietf-ecrit-phonebcp-07.txt=0D=0Aprovides the normative part.=20=0D=0A=0D= =0AWe thought that this would make it easy for the reader to follow the ent= ire=0D=0Astory best.=20=0D=0A=0D=0A>=A0=0D=0A>When we evaluated this with r= espect to support of wireless=20=0D=0A>cellular access and WiFi access asso= ciated with a cellular=20=0D=0A>operator (e.g. WLAN or Femto cells integrat= ed into a cellular=20=0D=0A>network), we found that certain portions of the= draft=20=0D=0A>exhibited one or more of the following characteristics:=0D=0A= >=A0=0D=0A>=A0=A0=A0 (A) Inconsistent with already standardized wireless so= lutions=0D=0A>=A0=0D=0A>=A0=A0=A0 (B) Inconsistent with essential wireless = requirements and=20=0D=0A>conventions=0D=0A>=A0=0D=0A>=A0=A0=A0 (C) Already= part of wireless standards or potentially part=20=0D=0A>of future standard= s=0D=0A>=A0=0D=0A>(A) refers to all portions of the draft framework that di= ffer=20=0D=0A>from the requirements and procedures currently standardized =0D= =0A>for wireless emergency access by 3GPP, 3GPP2 and OMA. This is=20=0D=0A>= a plain difference of solution and could be resolved through=20=0D=0A>suppo= rt of both solutions by terminals (with each solution=20=0D=0A>being used a= ccording to the type of access network and VSP) or=20=0D=0A>could be resolv= ed by supporting only one solution and=20=0D=0A>accessing only the types of= network supporting that solution.=20=0D=0A>To acknowledge this category, t= he framework document could=20=0D=0A>reference the applicable wireless stan= dards and point out that=20=0D=0A>these are valid alternatives for wireless= cellular based access.=0D=0A=0D=0AYou know that we have tried hard over th= e past few years to harmonize the=0D=0Awork done by different SDOs, includi= ng 3GPP. You were involved in some of=0D=0Athese activities.=20=0D=0A=0D=0A= For some reason, various companies did not like such an alignment and hence=0D= =0Awe are left with the situation that IMS emergency calling and emergency=0D= =0Acalling for everything else works differently.=20=0D=0A=0D=0AThis is unf= ortunate. Your company was always a big fan of developing a=0D=0Aharmonized= solution, right=3F=20=0D=0A=0D=0AI doubt that the situation is improved by= summarizing other standardization=0D=0Aefforts in this document nor by des= cribing the content of this document in=0D=0A3GPP, 3GPP2 or OMA documents. =0D= =0A=0D=0A[SE: our proposal is only to acknowledge the existence of this oth= er solution by reference not to try to summarize it.]=20=0D=0A=0D=0A>(B) re= fers to portions of the draft that would be unsuitable=20=0D=0A>for wireles= s networks even if no alternative solution existed=20=0D=0A>together with o= ther portions missing from the draft that would=20=0D=0A>be needed to fully= support wireless networks.=0D=0A=0D=0APlease note that we make a different= iation between wireless and cellular. I=0D=0Aguess you refer to cellular. =0D= =0A=0D=0A[SE: mainly yes. And in fact this is just the type of applicabilit= y statement that we are looking for - i.e. an acknowledgement that the Fram= ework solution is mainly designed for wireline and non-cellular associated = wireless access and is not intended to apply in its entirety to cellular as= sociated wireless access.]=0D=0A=0D=0A Examples of the=20=0D=0A>former incl= ude: (a) emphasis on endpoint derivation of=20=0D=0A>location, performance = of Lost query and receipt of local dial=20=0D=0A>strings;=0D=0A=0D=0APlease= note that we are talking about location for 2 different purposes=0D=0Ahere= :=20=0D=0A* Location for routing=20=0D=0A* Location for dispatch=0D=0A=0D=0A= It is true that the document puts a focus on the end point obtaining=0D=0Al= ocation (at least for routing). There is, however, a story in there for the=0D= =0Acase where the end point does not have access to location at all.=20=0D=0A=0D= =0AHaving access to local dial strings at the end point is a very useful th= ing,=0D=0Aif you think about it.=20=0D=0A=0D=0ARegarding LoST: Please note = that LoST can also be executed by the VoIP=0D=0Aprovider when routing is re= quired.=20=0D=0A=0D=0A[SE: yes I was aware of this, but it is treated as so= mething of an exception whereas for cellular networks, it is the norm.]=0D=0A=0D= =0A>(b) restriction of LCPs to protocols that require=20=0D=0A>terminal ini= tiation (not allowing for network initiation as=20=0D=0A>far as we can tell= ) and that include two LCPs (DHCP and LLDP)=20=0D=0A>that are not applicabl= e to (not defined for) cellular access;=20=0D=0A=0D=0AThese two LCPs are on= ly required for devices that can also be used in a=0D=0Afixed / wireless (b= ut not cellular) environment. In environments where the=0D=0Aend host is ex= pected to only ever use a cellular system these two LCPs need=0D=0Anot to b= e implemented.=20=0D=0A=0D=0ANetwork initiation has never found huge excite= ment within the members of the=0D=0AGEOPRIV group. I don't see this is a li= mitation, to be honest.=20=0D=0A=0D=0A[SE: there is no problem if the prope= r cellular disclaimer gets added. Otherwise, I would see the need for some = significant change to admit other types of LCP - e.g. OMA SUPL and 3GPP con= trol plane solution.]=0D=0A=0D=0A>and (c) the requirement that a terminal o= r at least a LIS will=20=0D=0A>update the PSAP whenever location changes.=0D= =0A=0D=0AI guess the items below refer to the dynamic location change.=0D=0A=0D= =0A=0D=0A (a) is impractical=20=0D=0A>due to network and terminal loading c= onsequences=0D=0A=0D=0AI guess you see it as more dramatic than it is. The = LIS and the PSAP can=0D=0Acontrol the rate of information disclosure, see=0D= =0Ahttp://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.tx= t.=20=0D=0A=0D=0ASpecifying at what rate the terminal would send up-to-date= information is=0D=0Apolicy and implementation dependent. =20=0D=0A=0D=0A a= nd failure=20=0D=0A>to support non-IP capable PSAPs;=0D=0A=0D=0AThe IETF EC= RIT solution is an IP-based solution and hence the Internet ends=0D=0Awhere= the last IP node is located.=20=0D=0AFor interworking with non-IP capable = PSAPs please take a look at the NENA=0D=0Ai2/i2.5 work, which is the most a= dvanced of its kind.=20=0D=0A=0D=0A[SE: A problem is that the latest i2.5 d= raft states that "This issue of the i2 standard supports E9-1-1 for fixed a= nd nomadic VoIP services. Support for mobile VoIP services will be covered = in a future release of this document." We expect that the missing mobile Vo= IP support will be provided by incorporating the 3GPP/3GPP2 solution as has= already occurred for the i3 draft. Whether it may also be supported by ext= ending what is already in the i2.5 draft independently of the 3GPP/3GPP2 so= lution remains to be seen.]=0D=0A=0D=0A (b) makes location=20=0D=0A>verific= ation and updated location provision to PSAPs difficult=20=0D=0A>or impossi= ble;=0D=0A=0D=0ACould you elaborate a bit=3F Not sure I understood the "ver= ification" and the=0D=0A"updated location provisioning" part.=20=0D=0A=0D=0A= [SE: with terminal initiated location, the terminal can provide location va= lues that are unreliable or deliberately false (and cannot be verified as s= uch by the network) and may not provide location updates as needed by a PSA= P. Even using location by reference (which I agree should be better), the V= SP plays no part though may be held liable by the PSAP or regulatory bodies= for any mistakes.]=0D=0A=0D=0A while (c) is also incompatible with support= of=20=0D=0A>existing non-IP capable PSAPs besides increasing terminal load= =20=0D=0A>and possibly interfering with optimum maintenance of the RF=20=0D= =0A>connection (e.g. if a terminal has to tune away from the=20=0D=0A>servi= ng base station or WLAN periodically to make location=20=0D=0A>measurements= ).=0D=0A=0D=0AI guess you are hunting an academic problem. The document doe= s not say that=0D=0Ayou provide a continues stream of location information.= We are more=0D=0Aconcerned about getting rough location as fast as possibl= e to make the=0D=0Aemergency call routing to happen to the right PSAP and t= hen provide=0D=0Aup-to-date location available to the PSAP for dispatch, wh= en available.=20=0D=0A=0D=0ASure, there are corner cases when the emergency= caller happens to be in a=0D=0Afast car driving down the highway and locat= ion is constantly changing.=20=0D=0A=0D=0A[SE: it just seems less efficient= to be obtaining and sending a stream of location updates rather than obtai= ning a location update only when the PSAP wants it. But I agree that feasib= ility need not be in question here.]=0D=0A=0D=0A Examples of the latter inc= lude (d) absence of=20=0D=0A>support for access to non-IP capable PSAPs as = already=20=0D=0A>mentioned (e.g. to support E911 phase 2 in the US);=20=0D=0A=0D= =0AThis is excluded by our charter and, as I said, possible with the soluti= on=0D=0ANENA has worked out with i2 and i2.5.=20=0D=0A=0D=0APlease also not= e that today fixed (and wireless -- but not cellular)=0D=0Aoperators are lo= oking for VoIP emergency solutions as they are somewhat=0D=0Aahead with VoI= P deployment compared to cellular operators.=0D=0A=0D=0AHence, this will gi= ve PSAP operators more time to migrate to an IP-based=0D=0Aenvironment and = these things are happening as we speak. Sure, this all needs=0D=0Atime but = the cost savings for an IP-based solution (as it was reported to=0D=0Ause a= t the emergency services workshops) seems to speak in favor of IP.=20=0D=0A=0D= =0A[SE: cellular operators have to support legacy PSAPs so this cannot be o= ut of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer to t= he Framework would clarify that.]=0D=0A=0D=0A(e) no=20=0D=0A>support for ha= ndover from the IP to the circuit domain when a=20=0D=0A>terminal loses (e.= g. moves out of) RF coverage in the IP=20=0D=0A>domain;=20=0D=0A=0D=0ACorre= ct. Our charter does not allow us to work on VCC.=20=0D=0A=0D=0A[SE: also s= eems a suitable item for a disclaimer.]=0D=0A=0D=0Aand (f) no allowance for= limited access modes wherein=20=0D=0A>a terminal may access a network only= to place an emergency=20=0D=0A>call with ensuing restrictions on (for exam= ple) location=20=0D=0A>acquisition, PSAP callback and caller verification a= nd=20=0D=0A>identification to the PSAP. To resolve this category either=20=0D= =0A>significant changes to the framework document could be made or=20=0D=0A= >a disclaimer/applicability statement could be added stating=20=0D=0A>that = support of cellular wireless networks and their=20=0D=0A>associated WLAN an= d Femto access points is not covered.=0D=0A=0D=0AThis issue in under consid= eration in the ECRIT working group, see=0D=0Ahttp://tools.ietf.org/id/draft= -schulzrinne-ecrit-unauthenticated-access-04.t=0D=0Axt.=20=0D=0AThe reason = for us to separate this aspect from the main document is simply=0D=0Ait's c= omplexity and the uncertainty from a regulatory point of view.=20=0D=0AWhen= you look at the document you will quickly realize that "unauthenticated=0D= =0Aemergency calls" in an IP-based context mean much more than they do toda= y.=20=0D=0A=0D=0AWe have also discussed this topic at the emergency service= s workshops and=0D=0Athe different views about this topic are interesting t= o observe but leave a=0D=0Alot of fuzziness behind.=20=0D=0A=0D=0A[SE: can = also disclaim this.]=0D=0A=0D=0A>=A0=0D=0A>Category (C) comprises concepts = and capabilities in the draft=20=0D=0A>that are either already part of the = standardized solution for=20=0D=0A>wireless networks or that might be added= at a later time.=20=0D=0A>Examples of the former include LoST, SIP locatio= n conveyance,=20=0D=0A>general use of SIP, location for routing versus for = dispatch,=20=0D=0A>cellular positioning methods. Examples of the latter inc= lude=20=0D=0A>use of location references and dereferencing and possible=20=0D= =0A>interworking between the current wireless network solutions=20=0D=0A>(i= n 3GPP, 3GPP2 and OMA) and the solution described in this=20=0D=0A>draft. T= he presence of this category could be acknowledged by=20=0D=0A>following th= e disclaimer for (B) with a statement that certain=20=0D=0A>portions of the= solution are expected to be incorporated into=20=0D=0A>wireless networks n= ow and/or in the future.=0D=0A=0D=0AI am not sure I got your point. It is t= rue that we have produced a couple of=0D=0Aspecifications and, in case of S= IP Location Conveyance, the standardization=0D=0Aeffort is not yet complete= d.=20=0D=0A=0D=0A[SE: I thought this might show that 3GPP/3GPP2 have been q= uite diligent in attempting to incorporate applicable parts of the IETF sol= ution. This seems actually more a story of success (on both sides).]=0D=0A=0D= =0A>=A0=0D=0A>We hope that these comments will be seen to be a useful=20=0D= =0A>addition to this review in the sense of enabling a more=20=0D=0A>precis= e scoping for the framework document and we are willing=20=0D=0A>to assist = in providing wording for any=20=0D=0A>disclaimer/applicability statement th= at the Ecrit working=20=0D=0A>group may now deem fit to include.=0D=0A=0D=0A= Thanks for your help.=20=0D=0A=0D=0A>=A0=0D=0A>Kind Regards=0D=0A>=A0=0D=0A=0D= =0A=0D=0AThanks for your detailed review and for trying to help us ensuring= that the=0D=0Adocument does not raise wrong expectations.=20=0D=0A=0D=0ACi= ao=0D=0AHannes=0D=0A=0D=0A=0D=0A>Stephen Edge (Qualcomm 3GPP SA2 participan= t), Kirk Burroughs=20=0D=0A>(Qualcomm 3GPP2 TSG-X and TSG-C participant)=0D= =0A>=0D=0A>PS this being sent on 2/4/09 at 11:50pm PST=0D=0A>=0D=0A>______= _________________________________________=0D=0A>Ecrit mailing list=0D=0A>Ec= rit@ietf.org=0D=0A>https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A=0D= =0A_______________________________________________=0D=0AEcrit mailing list=0D= =0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0943A6AD9 for ; Thu, 12 Feb 2009 05:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww0APIqsyMiw for ; Thu, 12 Feb 2009 05:50:46 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 26CAD3A6902 for ; Thu, 12 Feb 2009 05:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1234446651; x=1265982651; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Dawson,=20Martin"=20,=0D=0A=20 =20=20=20=20=20=20=20Hannes=20Tschofenig=0D=0A=09,=20ECRIT=20|Date:=20T hu,=2012=20Feb=202009=2005:50:46=20-0800|Subject:=20RE: =20[Ecrit]=20Comments=20on=20Framework=20Draft |Thread-Topic:=20[Ecrit]=20Comments=20on=20Framework=20Dr aft|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gA WY1w+AAAmT/sAABhntA|Message-ID:=20<1288E74A73964940B132A0 B9EA8D8ABC535F075F@NASANEXMB04.na.qualcomm.com> |References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8 c0@nsnintra.net>=0D=0A=20<1288E74A73964940B132A0B9EA8D8AB C535F075B@NASANEXMB04.na.qualcomm.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5523"=3B=20a=3D"15424004"; bh=PsLaGc+lLCQIHSKCJwoMzVp6sKCe8MvK1EMClhMswB4=; b=IwGyPn9fOlQ2dhOyEfrYE7h2p+XNSlIBfFj1HntkhMX542FGgJUYDLBz 562aEoWLwV25iQmaEZWcO/I6HWu1bOUOQclqm7jPa5iIuH5CX+RNE0Mpo BOneHSIRVNcyggpdqWkA1EItWnuL2Z+54VcqujXxR3ANbjEckYIVyjr57 A=; X-IronPort-AV: E=McAfee;i="5100,188,5523"; a="15424004" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2009 05:50:51 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CDopLQ002780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2009 05:50:51 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1CDomEp002562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2009 05:50:50 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 12 Feb 2009 05:50:48 -0800 From: "Edge, Stephen" To: "Dawson, Martin" , Hannes Tschofenig , ECRIT Date: Thu, 12 Feb 2009 05:50:46 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntA Message-ID: <1288E74A73964940B132A0B9EA8D8ABC535F075F@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net> <1288E74A73964940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 13:50:48 -0000 Hi Martin Thanks for these comments (and the previous ones which I probably still nee= d to respond to). We are discussing two somewhat different, though not totally different, sol= utions here each with its own particular set of limitations. Neither soluti= on can currently and legitimately claim to be entirely global. You can call= one set of limitations a walled garden if you like (or maybe a more accura= te description would be one side of a wall) and the other as temporarily ou= t of scope but that changes nothing. The real issue is how terminals and ne= twork operators will support IP initiated emergency calls in the most econo= mic and effective manner in the real world where, for example, IP capable P= SAPs will initially be quite rare, where circuit capable cellular networks = will persist for a long time and where support for unauthenticated users ma= y be mandated in some countries by regulators. An applicability statement i= n the Framework and phoneBCP spec.s would provide valuable guidance to both= operators and vendors - and maybe it will not be quite the one we are prop= osing either. I assume (and hope) anyhow that this issue will be discussed within Ecrit -= e.g. maybe at the next IETF meeting - and that some consensus will emerge = as to whether anything in the current drafts needs to be changed or added. = We are willing to provide further input to that discussion if needed. Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Thursday, February 12, 2009 4:28 AM To: Edge, Stephen; Hannes Tschofenig; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hello Stephen, The bulk of your commentary appears to be based on the following tenet - in= your words: [SE: mainly yes. And in fact this is just the type of applicability stateme= nt that we are looking for - i.e. an acknowledgement that the Framework sol= ution is mainly designed for wireline and non-cellular associated wireless = access and is not intended to apply in its entirety to cellular associated = wireless access.] This is quite untrue. The framework is not mainly designed for Wireline and= non-cellular associated wireless access. The framework is designed for any= form of Internet access. You could qualify it as broadband Internet access= if you want - but even that isn't necessary. To assume that public mobile = Internet access networks are somehow different is to miss the point of conv= ergence. 3GPP can define walled garden architectures such as IMS if it likes - it is= , of course, completely up to that SDO. However, it doesn't really have any= thing to do with the IETF and doesn't, qualitatively, warrant a special men= tion from ECRIT any more than, say, maritime radio and emergency calling do= es. With respect to the following: [SE: with terminal initiated location, the terminal can provide location va= lues that are unreliable or deliberately false (and cannot be verified as s= uch by the network) and may not provide location updates as needed by a PSA= P. Even using location by reference (which I agree should be better), the V= SP plays no part though may be held liable by the PSAP or regulatory bodies= for any mistakes.] The VSP plays no part in the location determination; it is the AN operator = that takes this responsibility. This is, in fact, the same case today - eve= n in 2G. It's the AN provider that takes responsibility for location determ= ination. I cannot see a sensible judgement being made of a VSP for a piece = of information for which they are not responsible. With all due respect, th= at sounds like FUD. With respect to your point about location-spoofing, you're quite correct an= d, indeed, that is one reason that LbyR is such a valuable mechanism. There= 's also a draft that describes how the LIS can digitally sign the PIDF-LO. = It hasn't proved necessary yet but may at some point. It certainly makes on= e wonder how 3GPP2 can be so determined to use SUPL when there does not app= ear to be any practical means to validate SET-provided measurements when th= e RAN is completely bypassed. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of E= dge, Stephen Sent: Thursday, 12 February 2009 11:08 PM To: Hannes Tschofenig; 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft Hi Hannes Thanks for all these comments. I have embedded below a number of responses = (look for [SE: .... ]). The previous suggestions remain, however, unchanged= from our perspective. Whether it is worth attempting to align the two solu= tions more at this stage seems questionable. By including appropriate discl= aimers, the Framework (and phoneBCP) spec.s can continue to define an optim= um solution for exactly the call scenarios for which they were really inten= ded leaving it clearer than before that an alternative solution exists for = a good portion of the missing cases. Merging part of one solution into the = other might not create anything very useful and changing one solution or th= e other risks losing some of its current optimality. But I agree that this = could still be looked at on one or both sides and in fact in 3GPP we have m= ade some limited attempts at this already to create a more generic solution= with fewer restrictions on AN and VSP combinations. Kind Regards Stephen -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Thursday, February 05, 2009 1:18 AM To: Edge, Stephen; 'ECRIT' Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, Thanks for your review. A few minor comments. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Edge, Stephen >Sent: 05 February, 2009 09:50 >To: 'ECRIT' >Subject: [Ecrit] Comments on Framework Draft > >All > >draft-ietf-ecrit-framework-07 is (as we see it) a mostly >informative description of how terminals and networks should >support emergency calls made over IP capable facilities to IP >capable PSAPs. It appears intended to cover all types of >access network - including fixed line, WiFi and cellular (e.g. >examples involving each can be found throughout the draft). Correct. The framework document is the informative description where http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt provides the normative part. We thought that this would make it easy for the reader to follow the entire story best. > >When we evaluated this with respect to support of wireless >cellular access and WiFi access associated with a cellular >operator (e.g. WLAN or Femto cells integrated into a cellular >network), we found that certain portions of the draft >exhibited one or more of the following characteristics: > > (A) Inconsistent with already standardized wireless solutions > > (B) Inconsistent with essential wireless requirements and >conventions > > (C) Already part of wireless standards or potentially part >of future standards > >(A) refers to all portions of the draft framework that differ >from the requirements and procedures currently standardized >for wireless emergency access by 3GPP, 3GPP2 and OMA. This is >a plain difference of solution and could be resolved through >support of both solutions by terminals (with each solution >being used according to the type of access network and VSP) or >could be resolved by supporting only one solution and >accessing only the types of network supporting that solution. >To acknowledge this category, the framework document could >reference the applicable wireless standards and point out that >these are valid alternatives for wireless cellular based access. You know that we have tried hard over the past few years to harmonize the work done by different SDOs, including 3GPP. You were involved in some of these activities. For some reason, various companies did not like such an alignment and hence we are left with the situation that IMS emergency calling and emergency calling for everything else works differently. This is unfortunate. Your company was always a big fan of developing a harmonized solution, right? I doubt that the situation is improved by summarizing other standardization efforts in this document nor by describing the content of this document in 3GPP, 3GPP2 or OMA documents. [SE: our proposal is only to acknowledge the existence of this other soluti= on by reference not to try to summarize it.] >(B) refers to portions of the draft that would be unsuitable >for wireless networks even if no alternative solution existed >together with other portions missing from the draft that would >be needed to fully support wireless networks. Please note that we make a differentiation between wireless and cellular. I guess you refer to cellular. [SE: mainly yes. And in fact this is just the type of applicability stateme= nt that we are looking for - i.e. an acknowledgement that the Framework sol= ution is mainly designed for wireline and non-cellular associated wireless = access and is not intended to apply in its entirety to cellular associated = wireless access.] Examples of the >former include: (a) emphasis on endpoint derivation of >location, performance of Lost query and receipt of local dial >strings; Please note that we are talking about location for 2 different purposes here: * Location for routing * Location for dispatch It is true that the document puts a focus on the end point obtaining location (at least for routing). There is, however, a story in there for th= e case where the end point does not have access to location at all. Having access to local dial strings at the end point is a very useful thing= , if you think about it. Regarding LoST: Please note that LoST can also be executed by the VoIP provider when routing is required. [SE: yes I was aware of this, but it is treated as something of an exceptio= n whereas for cellular networks, it is the norm.] >(b) restriction of LCPs to protocols that require >terminal initiation (not allowing for network initiation as >far as we can tell) and that include two LCPs (DHCP and LLDP) >that are not applicable to (not defined for) cellular access; These two LCPs are only required for devices that can also be used in a fixed / wireless (but not cellular) environment. In environments where the end host is expected to only ever use a cellular system these two LCPs need not to be implemented. Network initiation has never found huge excitement within the members of th= e GEOPRIV group. I don't see this is a limitation, to be honest. [SE: there is no problem if the proper cellular disclaimer gets added. Othe= rwise, I would see the need for some significant change to admit other type= s of LCP - e.g. OMA SUPL and 3GPP control plane solution.] >and (c) the requirement that a terminal or at least a LIS will >update the PSAP whenever location changes. I guess the items below refer to the dynamic location change. (a) is impractical >due to network and terminal loading consequences I guess you see it as more dramatic than it is. The LIS and the PSAP can control the rate of information disclosure, see http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt. Specifying at what rate the terminal would send up-to-date information is policy and implementation dependent. and failure >to support non-IP capable PSAPs; The IETF ECRIT solution is an IP-based solution and hence the Internet ends where the last IP node is located. For interworking with non-IP capable PSAPs please take a look at the NENA i2/i2.5 work, which is the most advanced of its kind. [SE: A problem is that the latest i2.5 draft states that "This issue of the= i2 standard supports E9-1-1 for fixed and nomadic VoIP services. Support f= or mobile VoIP services will be covered in a future release of this documen= t." We expect that the missing mobile VoIP support will be provided by inco= rporating the 3GPP/3GPP2 solution as has already occurred for the i3 draft.= Whether it may also be supported by extending what is already in the i2.5 = draft independently of the 3GPP/3GPP2 solution remains to be seen.] (b) makes location >verification and updated location provision to PSAPs difficult >or impossible; Could you elaborate a bit? Not sure I understood the "verification" and the "updated location provisioning" part. [SE: with terminal initiated location, the terminal can provide location va= lues that are unreliable or deliberately false (and cannot be verified as s= uch by the network) and may not provide location updates as needed by a PSA= P. Even using location by reference (which I agree should be better), the V= SP plays no part though may be held liable by the PSAP or regulatory bodies= for any mistakes.] while (c) is also incompatible with support of >existing non-IP capable PSAPs besides increasing terminal load >and possibly interfering with optimum maintenance of the RF >connection (e.g. if a terminal has to tune away from the >serving base station or WLAN periodically to make location >measurements). I guess you are hunting an academic problem. The document does not say that you provide a continues stream of location information. We are more concerned about getting rough location as fast as possible to make the emergency call routing to happen to the right PSAP and then provide up-to-date location available to the PSAP for dispatch, when available. Sure, there are corner cases when the emergency caller happens to be in a fast car driving down the highway and location is constantly changing. [SE: it just seems less efficient to be obtaining and sending a stream of l= ocation updates rather than obtaining a location update only when the PSAP = wants it. But I agree that feasibility need not be in question here.] Examples of the latter include (d) absence of >support for access to non-IP capable PSAPs as already >mentioned (e.g. to support E911 phase 2 in the US); This is excluded by our charter and, as I said, possible with the solution NENA has worked out with i2 and i2.5. Please also note that today fixed (and wireless -- but not cellular) operators are looking for VoIP emergency solutions as they are somewhat ahead with VoIP deployment compared to cellular operators. Hence, this will give PSAP operators more time to migrate to an IP-based environment and these things are happening as we speak. Sure, this all need= s time but the cost savings for an IP-based solution (as it was reported to use at the emergency services workshops) seems to speak in favor of IP. [SE: cellular operators have to support legacy PSAPs so this cannot be out = of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer to the = Framework would clarify that.] (e) no >support for handover from the IP to the circuit domain when a >terminal loses (e.g. moves out of) RF coverage in the IP >domain; Correct. Our charter does not allow us to work on VCC. [SE: also seems a suitable item for a disclaimer.] and (f) no allowance for limited access modes wherein >a terminal may access a network only to place an emergency >call with ensuing restrictions on (for example) location >acquisition, PSAP callback and caller verification and >identification to the PSAP. To resolve this category either >significant changes to the framework document could be made or >a disclaimer/applicability statement could be added stating >that support of cellular wireless networks and their >associated WLAN and Femto access points is not covered. This issue in under consideration in the ECRIT working group, see http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-04.= t xt. The reason for us to separate this aspect from the main document is simply it's complexity and the uncertainty from a regulatory point of view. When you look at the document you will quickly realize that "unauthenticate= d emergency calls" in an IP-based context mean much more than they do today. We have also discussed this topic at the emergency services workshops and the different views about this topic are interesting to observe but leave a lot of fuzziness behind. [SE: can also disclaim this.] > >Category (C) comprises concepts and capabilities in the draft >that are either already part of the standardized solution for >wireless networks or that might be added at a later time. >Examples of the former include LoST, SIP location conveyance, >general use of SIP, location for routing versus for dispatch, >cellular positioning methods. Examples of the latter include >use of location references and dereferencing and possible >interworking between the current wireless network solutions >(in 3GPP, 3GPP2 and OMA) and the solution described in this >draft. The presence of this category could be acknowledged by >following the disclaimer for (B) with a statement that certain >portions of the solution are expected to be incorporated into >wireless networks now and/or in the future. I am not sure I got your point. It is true that we have produced a couple o= f specifications and, in case of SIP Location Conveyance, the standardization effort is not yet completed. [SE: I thought this might show that 3GPP/3GPP2 have been quite diligent in = attempting to incorporate applicable parts of the IETF solution. This seems= actually more a story of success (on both sides).] > >We hope that these comments will be seen to be a useful >addition to this review in the sense of enabling a more >precise scoping for the framework document and we are willing >to assist in providing wording for any >disclaimer/applicability statement that the Ecrit working >group may now deem fit to include. Thanks for your help. > >Kind Regards > Thanks for your detailed review and for trying to help us ensuring that the document does not raise wrong expectations. Ciao Hannes >Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >(Qualcomm 3GPP2 TSG-X and TSG-C participant) > >PS this being sent on 2/4/09 at 11:50pm PST > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F92C3A67B2 for ; Thu, 12 Feb 2009 06:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hzxbc7SNd4y for ; Thu, 12 Feb 2009 06:17:24 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BD1463A6803 for ; Thu, 12 Feb 2009 06:17:23 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_12_08_36_45 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, 12 Feb 2009 08:36:45 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 08:17:27 -0600 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: Thu, 12 Feb 2009 08:17:26 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC535F075F@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntAAAIxaxA= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><1288E74A73964940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC535F075F@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , "Dawson, Martin" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 12 Feb 2009 14:17:27.0577 (UTC) FILETIME=[A2260090:01C98D1C] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:17:26 -0000 Hi Stephen,=0D=0A=0D=0AThe notion of unauthenticated users even in the cell= ular space is=0D=0Atechnology constrained. If I have an CDMA phone I don't = expect it to be=0D=0Aable to make emergency calls on a GSM network.=0D=0A=0D= =0AIn all seriousness, if 3GPP is really concerned about have a solution=0D= =0Athat will work everywhere, then they need to make the clear separation=0D= =0Abetween access and application service providers and provide an=0D=0Aarc= hitecture that fits that. Independent access providers are a reality,=0D=0A= look at the number of wifi hotspots that exist today=3F Independent voice=0D= =0Aservice providers are also a reality. Services and applications being=0D= =0Aintroduced on 3G cell-phones are increasingly become independent of the=0D= =0Anetwork provider, facebook applications are a good example. To continue=0D= =0Ato promote achitectures that force an unnecessary binding is doing=0D=0A= everyone a disservice.=0D=0A=0D=0AI am confident that the ECRIT architectur= e could be employed in a 3GPP=0D=0Anetwork. As you have said below, aspects= that ECRIT does cover are=0D=0Adeemed out of scope for 3GPP. Perhaps expan= ding the 3GPP scope to=0D=0Ainclude the aspects that it can't currently add= ress would be a better=0D=0Away to gain alignment with ECRIT. I would also = be surprised if the=0D=0Asolution were as simple and elegant was what is cu= rrently on the table.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Friday, 13 = February 2009 12:51 AM=0D=0ATo: Dawson, Martin; Hannes Tschofenig; ECRIT=0D= =0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHi Martin=0D= =0A=0D=0AThanks for these comments (and the previous ones which I probably = still=0D=0Aneed to respond to).=0D=0A=0D=0AWe are discussing two somewhat d= ifferent, though not totally different,=0D=0Asolutions here each with its o= wn particular set of limitations. Neither=0D=0Asolution can currently and l= egitimately claim to be entirely global. You=0D=0Acan call one set of limit= ations a walled garden if you like (or maybe a=0D=0Amore accurate descripti= on would be one side of a wall) and the other as=0D=0Atemporarily out of sc= ope but that changes nothing. The real issue is how=0D=0Aterminals and netw= ork operators will support IP initiated emergency=0D=0Acalls in the most ec= onomic and effective manner in the real world where,=0D=0Afor example, IP c= apable PSAPs will initially be quite rare, where=0D=0Acircuit capable cellu= lar networks will persist for a long time and where=0D=0Asupport for unauth= enticated users may be mandated in some countries by=0D=0Aregulators. An ap= plicability statement in the Framework and phoneBCP=0D=0Aspec.s would provi= de valuable guidance to both operators and vendors -=0D=0Aand maybe it will= not be quite the one we are proposing either.=0D=0A=0D=0AI assume (and hop= e) anyhow that this issue will be discussed within=0D=0AEcrit - e.g. maybe = at the next IETF meeting - and that some consensus=0D=0Awill emerge as to w= hether anything in the current drafts needs to be=0D=0Achanged or added. We= are willing to provide further input to that=0D=0Adiscussion if needed.=0D= =0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Original Message-----=0D= =0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0ASent: Thursd= ay, February 12, 2009 4:28 AM=0D=0ATo: Edge, Stephen; Hannes Tschofenig; EC= RIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHello = Stephen,=0D=0A=0D=0AThe bulk of your commentary appears to be based on the = following tenet -=0D=0Ain your words:=0D=0A=0D=0A[SE: mainly yes. And in fa= ct this is just the type of applicability=0D=0Astatement that we are lookin= g for - i.e. an acknowledgement that the=0D=0AFramework solution is mainly = designed for wireline and non-cellular=0D=0Aassociated wireless access and = is not intended to apply in its entirety=0D=0Ato cellular associated wirele= ss access.]=0D=0A=0D=0AThis is quite untrue. The framework is not mainly de= signed for Wireline=0D=0Aand non-cellular associated wireless access. The f= ramework is designed=0D=0Afor any form of Internet access. You could qualif= y it as broadband=0D=0AInternet access if you want - but even that isn't ne= cessary. To assume=0D=0Athat public mobile Internet access networks are som= ehow different is to=0D=0Amiss the point of convergence.=0D=0A=0D=0A3GPP ca= n define walled garden architectures such as IMS if it likes - it=0D=0Ais, = of course, completely up to that SDO. However, it doesn't really=0D=0Ahave = anything to do with the IETF and doesn't, qualitatively, warrant a=0D=0Aspe= cial mention from ECRIT any more than, say, maritime radio and=0D=0Aemergen= cy calling does.=0D=0A=0D=0AWith respect to the following:=0D=0A=0D=0A[SE: = with terminal initiated location, the terminal can provide location=0D=0Ava= lues that are unreliable or deliberately false (and cannot be verified=0D=0A= as such by the network) and may not provide location updates as needed=0D=0A= by a PSAP. Even using location by reference (which I agree should be=0D=0Ab= etter), the VSP plays no part though may be held liable by the PSAP or=0D=0A= regulatory bodies for any mistakes.]=0D=0A=0D=0AThe VSP plays no part in th= e location determination; it is the AN=0D=0Aoperator that takes this respon= sibility. This is, in fact, the same case=0D=0Atoday - even in 2G. It's the= AN provider that takes responsibility for=0D=0Alocation determination. I c= annot see a sensible judgement being made of=0D=0Aa VSP for a piece of info= rmation for which they are not responsible.=0D=0AWith all due respect, that= sounds like FUD.=0D=0A=0D=0AWith respect to your point about location-spoo= fing, you're quite correct=0D=0Aand, indeed, that is one reason that LbyR i= s such a valuable mechanism.=0D=0AThere's also a draft that describes how t= he LIS can digitally sign the=0D=0APIDF-LO. It hasn't proved necessary yet = but may at some point. It=0D=0Acertainly makes one wonder how 3GPP2 can be = so determined to use SUPL=0D=0Awhen there does not appear to be any practic= al means to validate=0D=0ASET-provided measurements when the RAN is complet= ely bypassed.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Messa= ge-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] O= n Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Thursday, 12 February 2009 11:08 = PM=0D=0ATo: Hannes Tschofenig; 'ECRIT'=0D=0ASubject: Re: [Ecrit] Comments o= n Framework Draft=0D=0A=0D=0AHi Hannes=0D=0A=0D=0AThanks for all these comm= ents. I have embedded below a number of=0D=0Aresponses (look for [SE: .... = ]). The previous suggestions remain,=0D=0Ahowever, unchanged from our persp= ective. Whether it is worth attempting=0D=0Ato align the two solutions more= at this stage seems questionable. By=0D=0Aincluding appropriate disclaimer= s, the Framework (and phoneBCP) spec.s=0D=0Acan continue to define an optim= um solution for exactly the call=0D=0Ascenarios for which they were really = intended leaving it clearer than=0D=0Abefore that an alternative solution e= xists for a good portion of the=0D=0Amissing cases. Merging part of one sol= ution into the other might not=0D=0Acreate anything very useful and changin= g one solution or the other risks=0D=0Alosing some of its current optimalit= y. But I agree that this could still=0D=0Abe looked at on one or both sides= and in fact in 3GPP we have made some=0D=0Alimited attempts at this alread= y to create a more generic solution with=0D=0Afewer restrictions on AN and = VSP combinations.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Orig= inal Message-----=0D=0AFrom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gm= x.net]=0D=0ASent: Thursday, February 05, 2009 1:18 AM=0D=0ATo: Edge, Stephe= n; 'ECRIT'=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A= Hi Stephen,=0D=0A=0D=0AThanks for your review. A few minor comments.=0D=0A=0D= =0A>-----Original Message-----=0D=0A>From: ecrit-bounces@ietf.org [mailto:e= crit-bounces@ietf.org]=0D=0A>On Behalf Of Edge, Stephen=0D=0A>Sent: 05 Febr= uary, 2009 09:50=0D=0A>To: 'ECRIT'=0D=0A>Subject: [Ecrit] Comments on Frame= work Draft=0D=0A>=0D=0A>All=0D=0A>=0D=0A>draft-ietf-ecrit-framework-07 is (= as we see it) a mostly=0D=0A>informative description of how terminals and n= etworks should=0D=0A>support emergency calls made over IP capable facilitie= s to IP=0D=0A>capable PSAPs. It appears intended to cover all types of=0D=0A= >access network - including fixed line, WiFi and cellular (e.g.=0D=0A>examp= les involving each can be found throughout the draft).=0D=0A=0D=0ACorrect. = The framework document is the informative description where=0D=0Ahttp://www= =2Eietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt=0D=0Aprovides = the normative part.=0D=0A=0D=0AWe thought that this would make it easy for = the reader to follow the=0D=0Aentire=0D=0Astory best.=0D=0A=0D=0A>=0D=0A>Wh= en we evaluated this with respect to support of wireless=0D=0A>cellular acc= ess and WiFi access associated with a cellular=0D=0A>operator (e.g. WLAN or= Femto cells integrated into a cellular=0D=0A>network), we found that certa= in portions of the draft=0D=0A>exhibited one or more of the following chara= cteristics:=0D=0A>=0D=0A> (A) Inconsistent with already standardized wir= eless solutions=0D=0A>=0D=0A> (B) Inconsistent with essential wireless r= equirements and=0D=0A>conventions=0D=0A>=0D=0A> (C) Already part of wire= less standards or potentially part=0D=0A>of future standards=0D=0A>=0D=0A>(= A) refers to all portions of the draft framework that differ=0D=0A>from the= requirements and procedures currently standardized=0D=0A>for wireless emer= gency access by 3GPP, 3GPP2 and OMA. This is=0D=0A>a plain difference of so= lution and could be resolved through=0D=0A>support of both solutions by ter= minals (with each solution=0D=0A>being used according to the type of access= network and VSP) or=0D=0A>could be resolved by supporting only one solutio= n and=0D=0A>accessing only the types of network supporting that solution.=0D= =0A>To acknowledge this category, the framework document could=0D=0A>refere= nce the applicable wireless standards and point out that=0D=0A>these are va= lid alternatives for wireless cellular based access.=0D=0A=0D=0AYou know th= at we have tried hard over the past few years to harmonize=0D=0Athe=0D=0Awo= rk done by different SDOs, including 3GPP. You were involved in some=0D=0Ao= f=0D=0Athese activities.=0D=0A=0D=0AFor some reason, various companies did = not like such an alignment and=0D=0Ahence=0D=0Awe are left with the situati= on that IMS emergency calling and emergency=0D=0Acalling for everything els= e works differently.=0D=0A=0D=0AThis is unfortunate. Your company was alway= s a big fan of developing a=0D=0Aharmonized solution, right=3F=0D=0A=0D=0AI= doubt that the situation is improved by summarizing other=0D=0Astandardiza= tion=0D=0Aefforts in this document nor by describing the content of this do= cument=0D=0Ain=0D=0A3GPP, 3GPP2 or OMA documents.=0D=0A=0D=0A[SE: our propo= sal is only to acknowledge the existence of this other=0D=0Asolution by ref= erence not to try to summarize it.]=0D=0A=0D=0A>(B) refers to portions of t= he draft that would be unsuitable=0D=0A>for wireless networks even if no al= ternative solution existed=0D=0A>together with other portions missing from = the draft that would=0D=0A>be needed to fully support wireless networks.=0D= =0A=0D=0APlease note that we make a differentiation between wireless and=0D= =0Acellular. I=0D=0Aguess you refer to cellular.=0D=0A=0D=0A[SE: mainly yes= =2E And in fact this is just the type of applicability=0D=0Astatement that = we are looking for - i.e. an acknowledgement that the=0D=0AFramework soluti= on is mainly designed for wireline and non-cellular=0D=0Aassociated wireles= s access and is not intended to apply in its entirety=0D=0Ato cellular asso= ciated wireless access.]=0D=0A=0D=0A Examples of the=0D=0A>former include: = (a) emphasis on endpoint derivation of=0D=0A>location, performance of Lost = query and receipt of local dial=0D=0A>strings;=0D=0A=0D=0APlease note that = we are talking about location for 2 different purposes=0D=0Ahere:=0D=0A* Lo= cation for routing=0D=0A* Location for dispatch=0D=0A=0D=0AIt is true that = the document puts a focus on the end point obtaining=0D=0Alocation (at leas= t for routing). There is, however, a story in there for=0D=0Athe=0D=0Acase = where the end point does not have access to location at all.=0D=0A=0D=0AHav= ing access to local dial strings at the end point is a very useful=0D=0Athi= ng,=0D=0Aif you think about it.=0D=0A=0D=0ARegarding LoST: Please note that= LoST can also be executed by the VoIP=0D=0Aprovider when routing is requir= ed.=0D=0A=0D=0A[SE: yes I was aware of this, but it is treated as something= of an=0D=0Aexception whereas for cellular networks, it is the norm.]=0D=0A=0D= =0A>(b) restriction of LCPs to protocols that require=0D=0A>terminal initia= tion (not allowing for network initiation as=0D=0A>far as we can tell) and = that include two LCPs (DHCP and LLDP)=0D=0A>that are not applicable to (not= defined for) cellular access;=0D=0A=0D=0AThese two LCPs are only required = for devices that can also be used in a=0D=0Afixed / wireless (but not cellu= lar) environment. In environments where=0D=0Athe=0D=0Aend host is expected = to only ever use a cellular system these two LCPs=0D=0Aneed=0D=0Anot to be = implemented.=0D=0A=0D=0ANetwork initiation has never found huge excitement = within the members of=0D=0Athe=0D=0AGEOPRIV group. I don't see this is a li= mitation, to be honest.=0D=0A=0D=0A[SE: there is no problem if the proper c= ellular disclaimer gets added.=0D=0AOtherwise, I would see the need for som= e significant change to admit=0D=0Aother types of LCP - e.g. OMA SUPL and 3= GPP control plane solution.]=0D=0A=0D=0A>and (c) the requirement that a ter= minal or at least a LIS will=0D=0A>update the PSAP whenever location change= s.=0D=0A=0D=0AI guess the items below refer to the dynamic location change.=0D= =0A=0D=0A=0D=0A (a) is impractical=0D=0A>due to network and terminal loadin= g consequences=0D=0A=0D=0AI guess you see it as more dramatic than it is. T= he LIS and the PSAP can=0D=0Acontrol the rate of information disclosure, se= e=0D=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-0= 3.tx=0D=0At.=0D=0A=0D=0ASpecifying at what rate the terminal would send up-= to-date information=0D=0Ais=0D=0Apolicy and implementation dependent.=0D=0A=0D= =0A and failure=0D=0A>to support non-IP capable PSAPs;=0D=0A=0D=0AThe IETF = ECRIT solution is an IP-based solution and hence the Internet=0D=0Aends=0D=0A= where the last IP node is located.=0D=0AFor interworking with non-IP capabl= e PSAPs please take a look at the=0D=0ANENA=0D=0Ai2/i2.5 work, which is the= most advanced of its kind.=0D=0A=0D=0A[SE: A problem is that the latest i2= =2E5 draft states that "This issue of=0D=0Athe i2 standard supports E9-1-1 = for fixed and nomadic VoIP services.=0D=0ASupport for mobile VoIP services = will be covered in a future release of=0D=0Athis document." We expect that = the missing mobile VoIP support will be=0D=0Aprovided by incorporating the = 3GPP/3GPP2 solution as has already=0D=0Aoccurred for the i3 draft. Whether = it may also be supported by extending=0D=0Awhat is already in the i2.5 draf= t independently of the 3GPP/3GPP2=0D=0Asolution remains to be seen.]=0D=0A=0D= =0A (b) makes location=0D=0A>verification and updated location provision to= PSAPs difficult=0D=0A>or impossible;=0D=0A=0D=0ACould you elaborate a bit=3F= Not sure I understood the "verification" and=0D=0Athe=0D=0A"updated locati= on provisioning" part.=0D=0A=0D=0A[SE: with terminal initiated location, th= e terminal can provide location=0D=0Avalues that are unreliable or delibera= tely false (and cannot be verified=0D=0Aas such by the network) and may not= provide location updates as needed=0D=0Aby a PSAP. Even using location by = reference (which I agree should be=0D=0Abetter), the VSP plays no part thou= gh may be held liable by the PSAP or=0D=0Aregulatory bodies for any mistake= s.]=0D=0A=0D=0A while (c) is also incompatible with support of=0D=0A>existi= ng non-IP capable PSAPs besides increasing terminal load=0D=0A>and possibly= interfering with optimum maintenance of the RF=0D=0A>connection (e.g. if a= terminal has to tune away from the=0D=0A>serving base station or WLAN peri= odically to make location=0D=0A>measurements).=0D=0A=0D=0AI guess you are h= unting an academic problem. The document does not say=0D=0Athat=0D=0Ayou pr= ovide a continues stream of location information. We are more=0D=0Aconcerne= d about getting rough location as fast as possible to make the=0D=0Aemergen= cy call routing to happen to the right PSAP and then provide=0D=0Aup-to-dat= e location available to the PSAP for dispatch, when available.=0D=0A=0D=0AS= ure, there are corner cases when the emergency caller happens to be in=0D=0A= a=0D=0Afast car driving down the highway and location is constantly changin= g.=0D=0A=0D=0A[SE: it just seems less efficient to be obtaining and sending= a stream=0D=0Aof location updates rather than obtaining a location update = only when=0D=0Athe PSAP wants it. But I agree that feasibility need not be = in question=0D=0Ahere.]=0D=0A=0D=0A Examples of the latter include (d) abse= nce of=0D=0A>support for access to non-IP capable PSAPs as already=0D=0A>me= ntioned (e.g. to support E911 phase 2 in the US);=0D=0A=0D=0AThis is exclud= ed by our charter and, as I said, possible with the=0D=0Asolution=0D=0ANENA= has worked out with i2 and i2.5.=0D=0A=0D=0APlease also note that today fi= xed (and wireless -- but not cellular)=0D=0Aoperators are looking for VoIP = emergency solutions as they are somewhat=0D=0Aahead with VoIP deployment co= mpared to cellular operators.=0D=0A=0D=0AHence, this will give PSAP operato= rs more time to migrate to an IP-based=0D=0Aenvironment and these things ar= e happening as we speak. Sure, this all=0D=0Aneeds=0D=0Atime but the cost s= avings for an IP-based solution (as it was reported=0D=0Ato=0D=0Ause at the= emergency services workshops) seems to speak in favor of IP.=0D=0A=0D=0A[S= E: cellular operators have to support legacy PSAPs so this cannot be=0D=0Ao= ut of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer=0D=0A= to the Framework would clarify that.]=0D=0A=0D=0A(e) no=0D=0A>support for h= andover from the IP to the circuit domain when a=0D=0A>terminal loses (e.g.= moves out of) RF coverage in the IP=0D=0A>domain;=0D=0A=0D=0ACorrect. Our = charter does not allow us to work on VCC.=0D=0A=0D=0A[SE: also seems a suit= able item for a disclaimer.]=0D=0A=0D=0Aand (f) no allowance for limited ac= cess modes wherein=0D=0A>a terminal may access a network only to place an e= mergency=0D=0A>call with ensuing restrictions on (for example) location=0D=0A= >acquisition, PSAP callback and caller verification and=0D=0A>identificatio= n to the PSAP. To resolve this category either=0D=0A>significant changes to= the framework document could be made or=0D=0A>a disclaimer/applicability s= tatement could be added stating=0D=0A>that support of cellular wireless net= works and their=0D=0A>associated WLAN and Femto access points is not covere= d.=0D=0A=0D=0AThis issue in under consideration in the ECRIT working group,= see=0D=0Ahttp://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-= access-=0D=0A04.t=0D=0Axt.=0D=0AThe reason for us to separate this aspect f= rom the main document is=0D=0Asimply=0D=0Ait's complexity and the uncertain= ty from a regulatory point of view.=0D=0AWhen you look at the document you = will quickly realize that=0D=0A"unauthenticated=0D=0Aemergency calls" in an= IP-based context mean much more than they do=0D=0Atoday.=0D=0A=0D=0AWe hav= e also discussed this topic at the emergency services workshops=0D=0Aand=0D= =0Athe different views about this topic are interesting to observe but=0D=0A= leave a=0D=0Alot of fuzziness behind.=0D=0A=0D=0A[SE: can also disclaim thi= s.]=0D=0A=0D=0A>=0D=0A>Category (C) comprises concepts and capabilities in = the draft=0D=0A>that are either already part of the standardized solution f= or=0D=0A>wireless networks or that might be added at a later time.=0D=0A>Ex= amples of the former include LoST, SIP location conveyance,=0D=0A>general u= se of SIP, location for routing versus for dispatch,=0D=0A>cellular positio= ning methods. Examples of the latter include=0D=0A>use of location referenc= es and dereferencing and possible=0D=0A>interworking between the current wi= reless network solutions=0D=0A>(in 3GPP, 3GPP2 and OMA) and the solution de= scribed in this=0D=0A>draft. The presence of this category could be acknowl= edged by=0D=0A>following the disclaimer for (B) with a statement that certa= in=0D=0A>portions of the solution are expected to be incorporated into=0D=0A= >wireless networks now and/or in the future.=0D=0A=0D=0AI am not sure I got= your point. It is true that we have produced a=0D=0Acouple of=0D=0Aspecifi= cations and, in case of SIP Location Conveyance, the=0D=0Astandardization=0D= =0Aeffort is not yet completed.=0D=0A=0D=0A[SE: I thought this might show t= hat 3GPP/3GPP2 have been quite diligent=0D=0Ain attempting to incorporate a= pplicable parts of the IETF solution. This=0D=0Aseems actually more a story= of success (on both sides).]=0D=0A=0D=0A>=0D=0A>We hope that these comment= s will be seen to be a useful=0D=0A>addition to this review in the sense of= enabling a more=0D=0A>precise scoping for the framework document and we ar= e willing=0D=0A>to assist in providing wording for any=0D=0A>disclaimer/app= licability statement that the Ecrit working=0D=0A>group may now deem fit to= include.=0D=0A=0D=0AThanks for your help.=0D=0A=0D=0A>=0D=0A>Kind Regards=0D= =0A>=0D=0A=0D=0A=0D=0AThanks for your detailed review and for trying to hel= p us ensuring that=0D=0Athe=0D=0Adocument does not raise wrong expectations= =2E=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0A=0D=0A>Stephen Edge (Qualcomm 3G= PP SA2 participant), Kirk Burroughs=0D=0A>(Qualcomm 3GPP2 TSG-X and TSG-C p= articipant)=0D=0A>=0D=0A>PS this being sent on 2/4/09 at 11:50pm PST=0D=0A= >=0D=0A>_______________________________________________=0D=0A>Ecrit mailing= list=0D=0A>Ecrit@ietf.org=0D=0A>https://www.ietf.org/mailman/listinfo/ecri= t=0D=0A>=0D=0A=0D=0A_______________________________________________=0D=0AEc= rit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/list= info/ecrit=0D=0A=0D=0A-----------------------------------------------------= -------------------=0D=0A------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information.=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------=0D=0A--------------------= ----=0D=0A[mf2]=0D=0A=0D=0A_______________________________________________=0D= =0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman= /listinfo/ecrit=0D=0A=0D=0A------------------------------------------------= ------------------------------------------------=0D=0AThis message is for t= he designated recipient only and may=0D=0Acontain privileged, proprietary, = or otherwise private information. =20=0D=0AIf you have received it in error= , please notify the sender=0D=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0A[mf2]=0D=0A Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5633A67D6 for ; Thu, 12 Feb 2009 17:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PjQMHYoaV3e for ; Thu, 12 Feb 2009 17:15:09 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 425973A672F for ; Thu, 12 Feb 2009 17:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1234487715; x=1266023715; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20"Dawson,=20Martin"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20=20=20 Hannes=20Tschofenig=20,=20ECRI T=20|Date:=20Thu,=2012=20Feb=202009=2017: 15:12=20-0800|Subject:=20RE:=20[Ecrit]=20Comments=20on=20 Framework=20Draft|Thread-Topic:=20[Ecrit]=20Comments=20on =20Framework=20Draft|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2 Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntAAAIxaxAAFvw30A=3D=3D |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC535F080A@ NASANEXMB04.na.qualcomm.com>|References:=20<1288E74A73964 940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com>< 003901c98772$b4cc7710$0201a8c0@nsnintra.net><1288E74A7396 4940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.com> =0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC535F075F@NAS ANEXMB04.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5524"=3B=20a=3D"15447316"; bh=qYQRHy3fLFEsESoKgfOBcjqrV9IPvcaCh+iL2hf0ZBM=; b=VWjqVUtOlSEKlMB8E/PIG+hZpdzEOjwCHa8Vle7dL1716oARgZvnKGEU 9C6mrPv1KhbixNoM9thnQIA31dL//br3vX/w964ZwZkdaBxPjbCGhK/PA vs11ejd9ZKyzAB8r1+jxner5fpT/fdz+rb5Dtud/hxroU7XYjrYm2LdXg s=; X-IronPort-AV: E=McAfee;i="5100,188,5524"; a="15447316" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2009 17:15:15 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1D1FEAN031060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2009 17:15:14 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1D1FEPL019120 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Feb 2009 17:15:14 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 12 Feb 2009 17:15:13 -0800 From: "Edge, Stephen" To: "Winterbottom, James" , "Dawson, Martin" , Hannes Tschofenig , ECRIT Date: Thu, 12 Feb 2009 17:15:12 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwAAnQ6gAWY1w+AAAmT/sAABhntAAAIxaxAAFvw30A== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC535F080A@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><1288E74A73964940B132A0B9EA8D8ABC535F075B@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC535F075F@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 01:15:11 -0000 Hi James Thanks for these further comments. To try to clarify a bit, 3GPP does not c= laim to have a global solution nor currently is there much interest in atte= mpting to create one. That is because the primary focus is on supporting ac= cess to cellular operators offering voice and data service in licensed radi= o spectrum and subject to specific regulatory requirements concerning emerg= ency calls. Other access and voice providers are also subject to the same o= r similar requirements of course and that is why the Ecrit solution is also= valuable. One could say that supporting both solutions would be a good ste= p towards global coverage although many operators and terminal vendors can = probably get by with just one solution or the other. I agree that the Ecrit solution probably could be adapted and extended for = a 3GPP/3GPP2 operator - but it would not be the exact solution that is defi= ned now because that has too many limitations from a cellular perspective, = a number of which we have already listed. The result of this discussion so far seems to be to further reinforce our o= riginal point (A) and in some ways to substantiate our point (B). The next = step is simply to acknowledge this more explicitly which is all we are prop= osing. Kind Regards Stephen -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Thursday, February 12, 2009 6:17 AM To: Edge, Stephen; Dawson, Martin; Hannes Tschofenig; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, The notion of unauthenticated users even in the cellular space is technology constrained. If I have an CDMA phone I don't expect it to be able to make emergency calls on a GSM network. In all seriousness, if 3GPP is really concerned about have a solution that will work everywhere, then they need to make the clear separation between access and application service providers and provide an architecture that fits that. Independent access providers are a reality, look at the number of wifi hotspots that exist today? Independent voice service providers are also a reality. Services and applications being introduced on 3G cell-phones are increasingly become independent of the network provider, facebook applications are a good example. To continue to promote achitectures that force an unnecessary binding is doing everyone a disservice. I am confident that the ECRIT architecture could be employed in a 3GPP network. As you have said below, aspects that ECRIT does cover are deemed out of scope for 3GPP. Perhaps expanding the 3GPP scope to include the aspects that it can't currently address would be a better way to gain alignment with ECRIT. I would also be surprised if the solution were as simple and elegant was what is currently on the table. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Friday, 13 February 2009 12:51 AM To: Dawson, Martin; Hannes Tschofenig; ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Hi Martin Thanks for these comments (and the previous ones which I probably still need to respond to). We are discussing two somewhat different, though not totally different, solutions here each with its own particular set of limitations. Neither solution can currently and legitimately claim to be entirely global. You can call one set of limitations a walled garden if you like (or maybe a more accurate description would be one side of a wall) and the other as temporarily out of scope but that changes nothing. The real issue is how terminals and network operators will support IP initiated emergency calls in the most economic and effective manner in the real world where, for example, IP capable PSAPs will initially be quite rare, where circuit capable cellular networks will persist for a long time and where support for unauthenticated users may be mandated in some countries by regulators. An applicability statement in the Framework and phoneBCP spec.s would provide valuable guidance to both operators and vendors - and maybe it will not be quite the one we are proposing either. I assume (and hope) anyhow that this issue will be discussed within Ecrit - e.g. maybe at the next IETF meeting - and that some consensus will emerge as to whether anything in the current drafts needs to be changed or added. We are willing to provide further input to that discussion if needed. Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Thursday, February 12, 2009 4:28 AM To: Edge, Stephen; Hannes Tschofenig; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hello Stephen, The bulk of your commentary appears to be based on the following tenet - in your words: [SE: mainly yes. And in fact this is just the type of applicability statement that we are looking for - i.e. an acknowledgement that the Framework solution is mainly designed for wireline and non-cellular associated wireless access and is not intended to apply in its entirety to cellular associated wireless access.] This is quite untrue. The framework is not mainly designed for Wireline and non-cellular associated wireless access. The framework is designed for any form of Internet access. You could qualify it as broadband Internet access if you want - but even that isn't necessary. To assume that public mobile Internet access networks are somehow different is to miss the point of convergence. 3GPP can define walled garden architectures such as IMS if it likes - it is, of course, completely up to that SDO. However, it doesn't really have anything to do with the IETF and doesn't, qualitatively, warrant a special mention from ECRIT any more than, say, maritime radio and emergency calling does. With respect to the following: [SE: with terminal initiated location, the terminal can provide location values that are unreliable or deliberately false (and cannot be verified as such by the network) and may not provide location updates as needed by a PSAP. Even using location by reference (which I agree should be better), the VSP plays no part though may be held liable by the PSAP or regulatory bodies for any mistakes.] The VSP plays no part in the location determination; it is the AN operator that takes this responsibility. This is, in fact, the same case today - even in 2G. It's the AN provider that takes responsibility for location determination. I cannot see a sensible judgement being made of a VSP for a piece of information for which they are not responsible. With all due respect, that sounds like FUD. With respect to your point about location-spoofing, you're quite correct and, indeed, that is one reason that LbyR is such a valuable mechanism. There's also a draft that describes how the LIS can digitally sign the PIDF-LO. It hasn't proved necessary yet but may at some point. It certainly makes one wonder how 3GPP2 can be so determined to use SUPL when there does not appear to be any practical means to validate SET-provided measurements when the RAN is completely bypassed. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Thursday, 12 February 2009 11:08 PM To: Hannes Tschofenig; 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft Hi Hannes Thanks for all these comments. I have embedded below a number of responses (look for [SE: .... ]). The previous suggestions remain, however, unchanged from our perspective. Whether it is worth attempting to align the two solutions more at this stage seems questionable. By including appropriate disclaimers, the Framework (and phoneBCP) spec.s can continue to define an optimum solution for exactly the call scenarios for which they were really intended leaving it clearer than before that an alternative solution exists for a good portion of the missing cases. Merging part of one solution into the other might not create anything very useful and changing one solution or the other risks losing some of its current optimality. But I agree that this could still be looked at on one or both sides and in fact in 3GPP we have made some limited attempts at this already to create a more generic solution with fewer restrictions on AN and VSP combinations. Kind Regards Stephen -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Thursday, February 05, 2009 1:18 AM To: Edge, Stephen; 'ECRIT' Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, Thanks for your review. A few minor comments. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Edge, Stephen >Sent: 05 February, 2009 09:50 >To: 'ECRIT' >Subject: [Ecrit] Comments on Framework Draft > >All > >draft-ietf-ecrit-framework-07 is (as we see it) a mostly >informative description of how terminals and networks should >support emergency calls made over IP capable facilities to IP >capable PSAPs. It appears intended to cover all types of >access network - including fixed line, WiFi and cellular (e.g. >examples involving each can be found throughout the draft). Correct. The framework document is the informative description where http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt provides the normative part. We thought that this would make it easy for the reader to follow the entire story best. > >When we evaluated this with respect to support of wireless >cellular access and WiFi access associated with a cellular >operator (e.g. WLAN or Femto cells integrated into a cellular >network), we found that certain portions of the draft >exhibited one or more of the following characteristics: > > (A) Inconsistent with already standardized wireless solutions > > (B) Inconsistent with essential wireless requirements and >conventions > > (C) Already part of wireless standards or potentially part >of future standards > >(A) refers to all portions of the draft framework that differ >from the requirements and procedures currently standardized >for wireless emergency access by 3GPP, 3GPP2 and OMA. This is >a plain difference of solution and could be resolved through >support of both solutions by terminals (with each solution >being used according to the type of access network and VSP) or >could be resolved by supporting only one solution and >accessing only the types of network supporting that solution. >To acknowledge this category, the framework document could >reference the applicable wireless standards and point out that >these are valid alternatives for wireless cellular based access. You know that we have tried hard over the past few years to harmonize the work done by different SDOs, including 3GPP. You were involved in some of these activities. For some reason, various companies did not like such an alignment and hence we are left with the situation that IMS emergency calling and emergency calling for everything else works differently. This is unfortunate. Your company was always a big fan of developing a harmonized solution, right? I doubt that the situation is improved by summarizing other standardization efforts in this document nor by describing the content of this document in 3GPP, 3GPP2 or OMA documents. [SE: our proposal is only to acknowledge the existence of this other solution by reference not to try to summarize it.] >(B) refers to portions of the draft that would be unsuitable >for wireless networks even if no alternative solution existed >together with other portions missing from the draft that would >be needed to fully support wireless networks. Please note that we make a differentiation between wireless and cellular. I guess you refer to cellular. [SE: mainly yes. And in fact this is just the type of applicability statement that we are looking for - i.e. an acknowledgement that the Framework solution is mainly designed for wireline and non-cellular associated wireless access and is not intended to apply in its entirety to cellular associated wireless access.] Examples of the >former include: (a) emphasis on endpoint derivation of >location, performance of Lost query and receipt of local dial >strings; Please note that we are talking about location for 2 different purposes here: * Location for routing * Location for dispatch It is true that the document puts a focus on the end point obtaining location (at least for routing). There is, however, a story in there for the case where the end point does not have access to location at all. Having access to local dial strings at the end point is a very useful thing, if you think about it. Regarding LoST: Please note that LoST can also be executed by the VoIP provider when routing is required. [SE: yes I was aware of this, but it is treated as something of an exception whereas for cellular networks, it is the norm.] >(b) restriction of LCPs to protocols that require >terminal initiation (not allowing for network initiation as >far as we can tell) and that include two LCPs (DHCP and LLDP) >that are not applicable to (not defined for) cellular access; These two LCPs are only required for devices that can also be used in a fixed / wireless (but not cellular) environment. In environments where the end host is expected to only ever use a cellular system these two LCPs need not to be implemented. Network initiation has never found huge excitement within the members of the GEOPRIV group. I don't see this is a limitation, to be honest. [SE: there is no problem if the proper cellular disclaimer gets added. Otherwise, I would see the need for some significant change to admit other types of LCP - e.g. OMA SUPL and 3GPP control plane solution.] >and (c) the requirement that a terminal or at least a LIS will >update the PSAP whenever location changes. I guess the items below refer to the dynamic location change. (a) is impractical >due to network and terminal loading consequences I guess you see it as more dramatic than it is. The LIS and the PSAP can control the rate of information disclosure, see http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.tx t. Specifying at what rate the terminal would send up-to-date information is policy and implementation dependent. and failure >to support non-IP capable PSAPs; The IETF ECRIT solution is an IP-based solution and hence the Internet ends where the last IP node is located. For interworking with non-IP capable PSAPs please take a look at the NENA i2/i2.5 work, which is the most advanced of its kind. [SE: A problem is that the latest i2.5 draft states that "This issue of the i2 standard supports E9-1-1 for fixed and nomadic VoIP services. Support for mobile VoIP services will be covered in a future release of this document." We expect that the missing mobile VoIP support will be provided by incorporating the 3GPP/3GPP2 solution as has already occurred for the i3 draft. Whether it may also be supported by extending what is already in the i2.5 draft independently of the 3GPP/3GPP2 solution remains to be seen.] (b) makes location >verification and updated location provision to PSAPs difficult >or impossible; Could you elaborate a bit? Not sure I understood the "verification" and the "updated location provisioning" part. [SE: with terminal initiated location, the terminal can provide location values that are unreliable or deliberately false (and cannot be verified as such by the network) and may not provide location updates as needed by a PSAP. Even using location by reference (which I agree should be better), the VSP plays no part though may be held liable by the PSAP or regulatory bodies for any mistakes.] while (c) is also incompatible with support of >existing non-IP capable PSAPs besides increasing terminal load >and possibly interfering with optimum maintenance of the RF >connection (e.g. if a terminal has to tune away from the >serving base station or WLAN periodically to make location >measurements). I guess you are hunting an academic problem. The document does not say that you provide a continues stream of location information. We are more concerned about getting rough location as fast as possible to make the emergency call routing to happen to the right PSAP and then provide up-to-date location available to the PSAP for dispatch, when available. Sure, there are corner cases when the emergency caller happens to be in a fast car driving down the highway and location is constantly changing. [SE: it just seems less efficient to be obtaining and sending a stream of location updates rather than obtaining a location update only when the PSAP wants it. But I agree that feasibility need not be in question here.] Examples of the latter include (d) absence of >support for access to non-IP capable PSAPs as already >mentioned (e.g. to support E911 phase 2 in the US); This is excluded by our charter and, as I said, possible with the solution NENA has worked out with i2 and i2.5. Please also note that today fixed (and wireless -- but not cellular) operators are looking for VoIP emergency solutions as they are somewhat ahead with VoIP deployment compared to cellular operators. Hence, this will give PSAP operators more time to migrate to an IP-based environment and these things are happening as we speak. Sure, this all needs time but the cost savings for an IP-based solution (as it was reported to use at the emergency services workshops) seems to speak in favor of IP. [SE: cellular operators have to support legacy PSAPs so this cannot be out of scope for the 3GPP/3GPP2 solution. But again, a short disclaimer to the Framework would clarify that.] (e) no >support for handover from the IP to the circuit domain when a >terminal loses (e.g. moves out of) RF coverage in the IP >domain; Correct. Our charter does not allow us to work on VCC. [SE: also seems a suitable item for a disclaimer.] and (f) no allowance for limited access modes wherein >a terminal may access a network only to place an emergency >call with ensuing restrictions on (for example) location >acquisition, PSAP callback and caller verification and >identification to the PSAP. To resolve this category either >significant changes to the framework document could be made or >a disclaimer/applicability statement could be added stating >that support of cellular wireless networks and their >associated WLAN and Femto access points is not covered. This issue in under consideration in the ECRIT working group, see http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access- 04.t xt. The reason for us to separate this aspect from the main document is simply it's complexity and the uncertainty from a regulatory point of view. When you look at the document you will quickly realize that "unauthenticated emergency calls" in an IP-based context mean much more than they do today. We have also discussed this topic at the emergency services workshops and the different views about this topic are interesting to observe but leave a lot of fuzziness behind. [SE: can also disclaim this.] > >Category (C) comprises concepts and capabilities in the draft >that are either already part of the standardized solution for >wireless networks or that might be added at a later time. >Examples of the former include LoST, SIP location conveyance, >general use of SIP, location for routing versus for dispatch, >cellular positioning methods. Examples of the latter include >use of location references and dereferencing and possible >interworking between the current wireless network solutions >(in 3GPP, 3GPP2 and OMA) and the solution described in this >draft. The presence of this category could be acknowledged by >following the disclaimer for (B) with a statement that certain >portions of the solution are expected to be incorporated into >wireless networks now and/or in the future. I am not sure I got your point. It is true that we have produced a couple of specifications and, in case of SIP Location Conveyance, the standardization effort is not yet completed. [SE: I thought this might show that 3GPP/3GPP2 have been quite diligent in attempting to incorporate applicable parts of the IETF solution. This seems actually more a story of success (on both sides).] > >We hope that these comments will be seen to be a useful >addition to this review in the sense of enabling a more >precise scoping for the framework document and we are willing >to assist in providing wording for any >disclaimer/applicability statement that the Ecrit working >group may now deem fit to include. Thanks for your help. > >Kind Regards > Thanks for your detailed review and for trying to help us ensuring that the document does not raise wrong expectations. Ciao Hannes >Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >(Qualcomm 3GPP2 TSG-X and TSG-C participant) > >PS this being sent on 2/4/09 at 11:50pm PST > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFF03A6B42 for ; Fri, 13 Feb 2009 13:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8OabhfrVPV1 for ; Fri, 13 Feb 2009 13:18:10 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 245913A6AB3 for ; Fri, 13 Feb 2009 13:18:05 -0800 (PST) Received: by fxm13 with SMTP id 13so3985917fxm.13 for ; Fri, 13 Feb 2009 13:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=GPQmNnta+Z9uMAvpVOaDFPOWuyqWkPlwyP3RdfR9Qe8=; b=n0CUSYIv25BelSwMbBnpLBGudfAPYMlXMhXimxXY4quBT86CWHIodVtGAPyFzwHk86 5rsgZOiMqRRk9zg9y6j+06Ihbd8rDRMaiy/rF/vnZz+1GRYoybF/s2PLuYDQEm9clDAo N2u/0IE+nSMGIkLXbZ8Haw27ZxYCE8vX+C7sU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=QnmbB2Ghgq5BAV2LwvdDkjSMIcUG8zR3gWJ3yd4r57IV8K8k194DothNFqFrMr1VA1 +oyH41hoWCfTkBPu8DTcziQhzd3660F4y0bC/K2SnG7HVfMdN5Z+1PuIS53LFqjToM9u 34/Hz7/YUeGovubMYyhFgpfeN1YRTslLXHeQw= MIME-Version: 1.0 Received: by 10.181.222.5 with SMTP id z5mr853230bkq.151.1234559892327; Fri, 13 Feb 2009 13:18:12 -0800 (PST) Date: Fri, 13 Feb 2009 22:18:12 +0100 Message-ID: From: Karl Heinz Wolf To: loc-imp@googlegroups.com, ECRIT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Ecrit] code sprint @ IETF 74? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 21:18:11 -0000 are there plans for an ECRIT/GEOPRIV code sprint at the next IETF meeting? thanks, karl heinz Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EC6183A687C; Sun, 15 Feb 2009 09:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090215173001.EC6183A687C@core3.amsl.com> Date: Sun, 15 Feb 2009 09:30:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 17:30:02 -0000 --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 : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-03.txt Pages : 26 Date : 2009-02-15 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the XML element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service URI or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. As motived in the Location-to-URL Mapping Architecture document this mechanism is useful for the synchronization of top-level LoST Forest Guides. This document is, however, even useful in a deployment that does not make use of the LoST protocol but purely wants to distribute service boundaries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ecrit-lost-sync-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-15091536.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117AD3A6AEF for ; Sun, 15 Feb 2009 12:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a8OukF98JZF for ; Sun, 15 Feb 2009 12:16:47 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E3E4D3A6A83 for ; Sun, 15 Feb 2009 12:16:46 -0800 (PST) Received: (qmail invoked by alias); 15 Feb 2009 20:16:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp046) with SMTP; 15 Feb 2009 21:16:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX192hvckDc52WjeFrTqXOlJEgd9Yh+ZPkfufDadGo+ Qzl5xZo2xdIf6w From: "Hannes Tschofenig" To: Date: Sun, 15 Feb 2009 22:17:48 +0200 Message-ID: <004a01c98faa$791129b0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C98FBB.3C99F9B0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmPqnhUYOBdoJ2XS761ffMlH2J+cg== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8,0.8 Subject: [Ecrit] LoST Sync X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 20:16:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C98FBB.3C99F9B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Based on the feedback from Richard and Karl Heinz I have updated the document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-03.txt Ciao Hannes ------=_NextPart_000_004B_01C98FBB.3C99F9B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LoST Sync

Based on the feedback from = Richard and Karl Heinz I have updated the document:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-03.tx= t

Ciao
Hannes

------=_NextPart_000_004B_01C98FBB.3C99F9B0-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481C83A6989 for ; Mon, 16 Feb 2009 01:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41r-dJi6XhoH for ; Mon, 16 Feb 2009 01:26:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 388A43A679F for ; Mon, 16 Feb 2009 01:26:01 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1G9Q88g014612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Feb 2009 10:26:08 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1G9Q8RV023272; Mon, 16 Feb 2009 10:26:08 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Feb 2009 10:26:06 +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 Date: Mon, 16 Feb 2009 11:26:55 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45010DB237@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: code sprint @ IETF 74? Thread-Index: AcmOIJXyVCQEZBLjTdu6gfc2ON2mIQB9jbXg References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , "ECRIT" X-OriginalArrivalTime: 16 Feb 2009 09:26:06.0818 (UTC) FILETIME=[9874DC20:01C99018] Subject: Re: [Ecrit] code sprint @ IETF 74? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 09:26:03 -0000 Hi Karl Heinz,=20 I am available on Saturday before the IETF meeting.=20 I would be interested in reviewing / testing the RFC 4776 and RFC 3825/draft-thomson-geopriv-3825bis code.=20 I could also test the RADIUS GEOPRIV stuff.=20 I wonder whether it would be possible to test the LoST Sync mechanism.=20 Ciao Hannes >-----Original Message----- >From: loc-imp@googlegroups.com=20 >[mailto:loc-imp@googlegroups.com] On Behalf Of ext Karl Heinz Wolf >Sent: 13 February, 2009 23:18 >To: loc-imp@googlegroups.com; ECRIT >Subject: code sprint @ IETF 74? > > >are there plans for an ECRIT/GEOPRIV code sprint at the next=20 >IETF meeting? > >thanks, > >karl heinz > >--~--~---------~--~----~------------~-------~--~----~ >You received this message because you are subscribed to the=20 >Google Groups "Location Implementation" group. >To post to this group, send email to loc-imp@googlegroups.com=20 >To unsubscribe from this group, send email to=20 >loc-imp+unsubscribe@googlegroups.com >For more options, visit this group at=20 >http://groups.google.com/group/loc-imp?hl=3Den >-~----------~----~----~----~------~----~------~--~--- > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63EFD3A6813 for ; Wed, 18 Feb 2009 11:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeXWoxNI-os4 for ; Wed, 18 Feb 2009 11:09:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 407EC3A67AF for ; Wed, 18 Feb 2009 11:09:15 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2009 19:09:26 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 18 Feb 2009 20:09:26 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Ys1k8fb4Y49kYGMST71OoG5qtetOdgw1K62arYl bL4kRp9MVNZmK7 From: "Hannes Tschofenig" To: "ECRIT" Date: Wed, 18 Feb 2009 21:10:13 +0200 Message-ID: <008501c991fc$8cb889a0$93b4b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmR/IZQrr1FA6IaQDWHgQTUwU8jvg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Subject: [Ecrit] PROTO shepherd for RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:09:17 -0000 In a discussion with Marc we decided that Marc is going to be the PROTO shepherd for the document. I believe that I would not do a good job with this document. Marc is also going to brainstorm on how to move forward with it. Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9C23A6917 for ; Wed, 18 Feb 2009 11:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONGfhUa4D+6Y for ; Wed, 18 Feb 2009 11:34:51 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 8BC033A677D for ; Wed, 18 Feb 2009 11:34:51 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LZsAm-0006KW-OU; Wed, 18 Feb 2009 13:34:54 -0600 From: "Brian Rosen" To: "'Edge, Stephen'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> Date: Wed, 18 Feb 2009 14:07:21 -0500 Message-ID: <0a8d01c991ff$fd063420$f7129c60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+g Content-Language: en-us 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: Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:34:52 -0000 I have bit my tongue on this one for a long time. Stephen, with respect, please go talk to 3GPP management and ask them = why there has been no participation in the ecrit effort despite multiple = YEARS of begging them to get involved. To put it frankly, 3GPP is quite = willing to bully IETF into doing its work on its schedule, but cannot be = bothered to get work done it knows it will eventually have to do when the IETF asks = it to do so. 3GPP understands the mess that is being created by not participating. = They know full well that when they finally get around to dealing with PS terminated emergency calls, that there will be a lot of resistance to changing fully specified and implemented standards to more closely align with 3GPP standards. I expect you will have several interworking = functions to define and build. So, politely, please go away, we're finishing work we dearly wanted you = all to be involved with for years, but you refused to do anything. It's too late for this rev. Now, having said that, there are quite a few people who have = participated in the IETF work who are IMS aware and I believe that despite your fears, everything you need is in the specs. The mechanisms we have defined = provide the ability for the network to insert location, recognize and mark = emergency calls, and route on behalf of endpoints. An E-CSCF could quite straightforwardly provide a SIP call towards an ecrit compatible PSAP. = The only not-quite-nice interwork would be from SUPL to HELD (or SIP), but = it's pretty easy to do that. I'll also note that we have tried to get OMA = and IETF to cooperate on location protocols, but we have been spectacularly unsuccessful at that effort also. Brian =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Edge, Stephen > Sent: Thursday, February 05, 2009 2:50 AM > To: 'ECRIT' > Subject: [Ecrit] Comments on Framework Draft >=20 > All >=20 > draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative > description of how terminals and networks should support emergency > calls made over IP capable facilities to IP capable PSAPs. It appears > intended to cover all types of access network - including fixed line, > WiFi and cellular (e.g. examples involving each can be found = throughout > the draft). >=20 > When we evaluated this with respect to support of wireless cellular > access and WiFi access associated with a cellular operator (e.g. WLAN > or Femto cells integrated into a cellular network), we found that > certain portions of the draft exhibited one or more of the following > characteristics: >=20 > =A0=A0=A0 (A) Inconsistent with already standardized wireless = solutions >=20 > =A0=A0=A0 (B) Inconsistent with essential wireless requirements and > conventions >=20 > =A0=A0=A0 (C) Already part of wireless standards or potentially part = of > future standards >=20 > (A) refers to all portions of the draft framework that differ from the > requirements and procedures currently standardized for wireless > emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of > solution and could be resolved through support of both solutions by > terminals (with each solution being used according to the type of > access network and VSP) or could be resolved by supporting only one > solution and accessing only the types of network supporting that > solution. To acknowledge this category, the framework document could > reference the applicable wireless standards and point out that these > are valid alternatives for wireless cellular based access. >=20 > (B) refers to portions of the draft that would be unsuitable for > wireless networks even if no alternative solution existed together = with > other portions missing from the draft that would be needed to fully > support wireless networks. Examples of the former include: (a) = emphasis > on endpoint derivation of location, performance of Lost query and > receipt of local dial strings; (b) restriction of LCPs to protocols > that require terminal initiation (not allowing for network initiation > as far as we can tell) and that include two LCPs (DHCP and LLDP) that > are not applicable to (not defined for) cellular access; and (c) the > requirement that a terminal or at least a LIS will update the PSAP > whenever location changes. (a) is impractical due to network and > terminal loading consequences and failure to support non-IP capable > PSAPs; (b) makes location verification and updated location provision > to PSAPs difficult or impossible; while (c) is also incompatible with > support of existing non-IP capable PSAPs besides increasing terminal > load and possibly interfering with optimum maintenance of the RF > connection (e.g. if a terminal has to tune away from the serving base > station or WLAN periodically to make location measurements). Examples > of the latter include (d) absence of support for access to non-IP > capable PSAPs as already mentioned (e.g. to support E911 phase 2 in = the > US); (e) no support for handover from the IP to the circuit domain = when > a terminal loses (e.g. moves out of) RF coverage in the IP domain; and > (f) no allowance for limited access modes wherein a terminal may = access > a network only to place an emergency call with ensuing restrictions on > (for example) location acquisition, PSAP callback and caller > verification and identification to the PSAP. To resolve this category > either significant changes to the framework document could be made or = a > disclaimer/applicability statement could be added stating that support > of cellular wireless networks and their associated WLAN and Femto > access points is not covered. >=20 > Category (C) comprises concepts and capabilities in the draft that are > either already part of the standardized solution for wireless networks > or that might be added at a later time. Examples of the former include > LoST, SIP location conveyance, general use of SIP, location for = routing > versus for dispatch, cellular positioning methods. Examples of the > latter include use of location references and dereferencing and > possible interworking between the current wireless network solutions > (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The > presence of this category could be acknowledged by following the > disclaimer for (B) with a statement that certain portions of the > solution are expected to be incorporated into wireless networks now > and/or in the future. >=20 > We hope that these comments will be seen to be a useful addition to > this review in the sense of enabling a more precise scoping for the > framework document and we are willing to assist in providing wording > for any disclaimer/applicability statement that the Ecrit working = group > may now deem fit to include. >=20 > Kind Regards >=20 > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm > 3GPP2 TSG-X and TSG-C participant) >=20 > PS this being sent on 2/4/09 at 11:50pm PST >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDE53A6A28 for ; Wed, 18 Feb 2009 11:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRqmFFoXOkOR for ; Wed, 18 Feb 2009 11:36:32 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4C04A3A6866 for ; Wed, 18 Feb 2009 11:36:32 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LZsD3-0006KW-PG; Wed, 18 Feb 2009 13:36:32 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'James M. Polk'" , "'Hannes Tschofenig'" , "'DOLLY, MARTIN C, ATTLABS'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA01238F61@gaalpa1msgusr7e.ugd.att.com> <000101c988ad$8ac92e90$0201a8c0@nsnintra.net> In-Reply-To: Date: Wed, 18 Feb 2009 14:07:21 -0500 Message-ID: <0a9701c99200$37181430$a5483c90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcmLAkWPG3AFTHqiQImqvHFJBJwcpgGsL99A Content-Language: en-us 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: Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , ecrit@ietf.org Subject: Re: [Ecrit] RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:36:33 -0000 I have deliberately stayed out of this for a while, not even reading the thread while I did some other things, but I am back now. There are a couple of uses for multiple levels of priority from the endpoint to the network. Most of them are for things other than voice calls. For example, a device that sends an "alert" or data-only message may have a notion of importance of the alert. A serious building fire which tripped multiple alarms is higher priority than a possible intruder. In most jurisdictions, alerts may not have as high priority than voice calls. One example of a voice call with an endpoint notion of multiple priority is a situation where the caller is supplying supplemental information ("did you know that there is a wheel on the road 1/4" mile down the road from that multiple car accident?"). I'm not suggesting we know how to recommend how to use this in a UI for example, but there are use cases. In those examples, there is no other marking an intermediary could use to determine priority. It makes sense to use the resource priority header to request resource priority. It does not make sense for the IETF to define usage specific markings for resource priority, even at the cost of some additional work, or the possibility that the end device may not follow the recommendations. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Ted Hardie > Sent: Monday, February 09, 2009 5:03 PM > To: James M. Polk; Hannes Tschofenig; 'DOLLY, MARTIN C, ATTLABS'; > hgs@cs.columbia.edu; James.Winterbottom@andrew.com > Cc: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > Subject: Re: [Ecrit] RPH > > At 10:06 AM -0800 2/9/09, James M. Polk wrote: > >Ted -- comments at the bottom > > > >While I generally agree with you -- until you imply that the two > >namespaces ought go be in separate docs that have to meet somewhere > >future somewhere in the middle of the network. > > I am not sure that they do have to meet somewhere. If ESNET internal > communications are marked with priority values from foo and customer- > to-ESNET > communications are marked with values from the bar namespace, then > any system that might handle both will eventually have to have a > mapping > that says something like foo3 is above bar2 but below bar1 (assuming 0 > high > for both). But I actually suspect, honestly, that the ESNET internal > communication > is really either a private network or an overlay. If that's the case > (and > I could be way off here), the number of times these traffic markings > will > be evaluated against each other seems likely to be pretty small. Maybe > even 0 in some deployment scenarios. > > > Please let me know if I've misread what you meant to say. > > > >On this, I have two thoughts: > > > >#1 - that several vendors and SPs have already asked for this > >namespace to be possible in their respective VSP products and service > >offerings - and your implied solution blows that up. > > Well, I think it's already blown up, as I think the chance of consensus > on a customer-to-ESNET namespace seems likely to be slow to emerge. > I'm trying to see if there is a way to get something out without > waiting > for that consensus. > > >and > > > >#2 - that creating (in the future) a second namespace to map directly > >to the esnet (and it's 5 priority-values) from the UAC or VSP seems > >like it might be begging for a lack of interoperability waiting to > >happen type of problem. > > First, this presumes that there will be a second namespace. Fair > enough, > you see a customer need here. But I am not at all sure that it would > be a one-to-one correspondence. I think some folks might well argue > that customer-to-ESNET should have only two values: "not an emergency" > and "emergency", to simplify the discussions of how big an emergency > deserves to go higher than some other emergency. But I think that's > part of the discussion of this that makes customer-to-ESNET much harder > to work through than ESNET where who gets to decide is crystal, crystal > clear. > > >I can definitely rewrite the text emphasizing the esnet namespace is > >for the ESInet first, with the possibility of having it come in from > >a reliable VSP, and even a reliable UAC/UE off that reliable VSP. > > And here is where I think the same syntax is being used for two > semantics. > If the syntax of value 1 within intra-ESINET communications isn't > exactly > the same as value one in customer to-ESINET communications, we look > to be in a very long discussion indeed. And finding some way of > satisfying > everyone that this is the case seems long and drawn out indeed. > > Maybe I just more conflict avoidant these days, but I'd like to get > something out and tackle the more difficult things with a sense of > accomplishment than to bog down. But I'm not really coding this > myself, so it's a suggestion from the sidelines. > > Ted > > > > > > > >> regards, > >> Ted Hardie > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E8CEC3A6950; Thu, 19 Feb 2009 18:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090220023001.E8CEC3A6950@core3.amsl.com> Date: Thu, 19 Feb 2009 18:30:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-local-emergency-rph-namespace-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 02:30:02 -0000 --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 : IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications Author(s) : J. Polk Filename : draft-ietf-ecrit-local-emergency-rph-namespace-01.txt Pages : 7 Date : 2009-02-19 This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ecrit-local-emergency-rph-namespace-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-19182426.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA133A67A1 for ; Thu, 19 Feb 2009 18:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqW0VwmvcJq7 for ; Thu, 19 Feb 2009 18:32:32 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EB7073A6784 for ; Thu, 19 Feb 2009 18:32:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,238,1233532800"; d="scan'208";a="136522265" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2009 02:32:46 +0000 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 n1K2Wk5Y008307 for ; Thu, 19 Feb 2009 18:32:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1K2Wjhc013928 for ; Fri, 20 Feb 2009 02:32:46 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); Thu, 19 Feb 2009 18:32:45 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.18.42]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 18:32:45 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Feb 2009 20:32:44 -0600 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Feb 2009 02:32:45.0583 (UTC) FILETIME=[836BB9F0:01C99303] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1775; t=1235097166; x=1235961166; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20draft-ietf-ecrit-local-emergency-rph-namespace- 01=20submitted |Sender:=20; bh=nCeou/ZJ+xWhVl07xcoGXUp/YG+srtXSb8juooyNBnQ=; b=B8zPOZL4ogtX76Tzd9hx/M9jDVU1fY7ByQv/PibiVE6t7bd2NKecu1q9Dn SPjpdMbd0vGcaMWc8ne+RWuxyUGceGv3R6i7di1/tmTRirYCP5bP9Sowqq+M wR2oeY3tqF; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 02:32:32 -0000 ECRIT I've just submitted a rev of the "esnet" Resource-Prioriy header draft. I've removed all mention of UAs from the draft, but leave in the possibility for adjacent VSPs to have a trust relationship with the local ESInet and mark these SIP requests accordingly through the VSP's domain. I offer that the ESRP at the ESInet edge will be tasked with mapping the esnet.priority-values from outside the ESInet to the indications used inside the ESInet. The ID gives no guidance on what the priority-values should be in either case - as that is a matter for other documents (and I'd argue - for other SDOs or consortia such as NENA and EENA, though I don't mention either organization in the ID). Comments are welcome James >From: IETF I-D Submission Tool >To: jmpolk@cisco.com >Subject: New Version Notification for > draft-ietf-ecrit-local-emergency-rph-namespace-01 >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST) > > >A new version of I-D, >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been >successfuly submitted by James Polk and posted to the IETF repository. > >Filename: draft-ietf-ecrit-local-emergency-rph-namespace >Revision: 01 >Title: IANA Registering a SIP Resource Priority Header >Namespace for Local Emergency Communications >Creation_date: 2009-02-19 >WG ID: ecrit >Number_of_pages: 7 > >Abstract: >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > > > > >The IETF Secretariat. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BE83A6A26 for ; Thu, 19 Feb 2009 18:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh1x-MELujb5 for ; Thu, 19 Feb 2009 18:34:28 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 191E23A6832 for ; Thu, 19 Feb 2009 18:34:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,238,1233532800"; d="scan'208";a="30132112" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 20 Feb 2009 02:34:36 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1K2YaQL005647 for ; Thu, 19 Feb 2009 18:34:36 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1K2YZVK014928 for ; Fri, 20 Feb 2009 02:34:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 18:34:36 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.18.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 18:34:35 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Feb 2009 20:34:34 -0600 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Feb 2009 02:34:35.0770 (UTC) FILETIME=[C518EDA0:01C99303] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1725; t=1235097276; x=1235961276; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Fwd=3A=20I-D=0A=20=20Action=3Adraft-polk-ecrit- local-emergency-rph-namespace-04.txt=20 |Sender:=20; bh=A9TFq4bVp5upge8eGgl3/NBVw+IZID+sIg4vhuQfP1o=; b=CjPCQKpBG3EMtJL+q8Cwqq2RkxuBh7++peotq1Z+pHgCKNzi4n6NT/lt8C exrJxZiRdzkACBgH0ifHL+Tx7D067zL5TZrtosqFrCGjqz9mJWeyUCNLGwt6 mAXwlrUpkY; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Ecrit] Fwd: I-D Action:draft-polk-ecrit-local-emergency-rph-namespace-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 02:34:29 -0000 please ignore this ID announcement -- I uploaded the wrong file initially. sorry >From: Internet-Drafts@ietf.org >To: i-d-announce@ietf.org >Subject: I-D Action:draft-polk-ecrit-local-emergency-rph-namespace-04.txt >Date: Thu, 19 Feb 2009 18:30:01 -0800 (PST) > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : IANA Registering a SIP Resource Priority > Header Namespace for Local Emergency Communications > Author(s) : J. Polk > Filename : > draft-polk-ecrit-local-emergency-rph-namespace-04.txt > Pages : 7 > Date : 2009-02-19 > >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-04.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F1C3A6A6E for ; Fri, 20 Feb 2009 07:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IQxGs55OoFq for ; Fri, 20 Feb 2009 07:14:30 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8EF8B3A69E5 for ; Fri, 20 Feb 2009 07:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1235142885; x=1266678885; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<003901c98772$b4cc7710$0201a8c0@nsnintra. net>|References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0 305@NASANEXMB04.na.qualcomm.com>=0D=0A=20<003901c98772$b4 cc7710$0201a8c0@nsnintra.net>|X-Mailer:=20Eudora=20for=20 Mac=20OS=20X|X-message-flag:=20Warning:=20Outlook=20in=20 use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Fri,=2020=20Feb=202009=2007:08:07=20-0800|To: =20Hannes=20Tschofenig=20,=0D =0A=20=20=20=20=20=20=20=20"'Edge,=20Stephen'"=0D=0A=09,=20"'ECRIT'"=20|From: =20Randall=20Gellens=20|Subject:=20Re :=20[Ecrit]=20Comments=20on=20Framework=20Draft |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,553 0"=3B=20a=3D"15650601"; bh=p2RpUnZ8Xf+8jtEjVrIPfh0uFYJUa1nu5t/8yI5SdRs=; b=VAkCJHQdLWgOxpzMahBcansAlSXQUObSeUk3sEW8uoBk0UwaWhvMbSJA HZg9zcI9/DMt6GuSNGtBpeDAztgRxFViyW/xPzr0vRYlyJWgvnYMM/BGk uDEkWUykQgfkZ/FRGn1jnXKYx0DjyFX9r8LtfXIhsXSE66ea3563P5eEZ U=; X-IronPort-AV: E=McAfee;i="5100,188,5530"; a="15650601" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Feb 2009 07:14:44 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KFEiRq009377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Feb 2009 07:14:44 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KFEhOb028770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Feb 2009 07:14:44 -0800 (PST) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 20 Feb 2009 07:14:43 -0800 Received: from [10.67.63.47] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 20 Feb 2009 07:14:43 -0800 Message-ID: In-Reply-To: <003901c98772$b4cc7710$0201a8c0@nsnintra.net> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <003901c98772$b4cc7710$0201a8c0@nsnintra.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 20 Feb 2009 07:08:07 -0800 To: Hannes Tschofenig , "'Edge, Stephen'" , "'ECRIT'" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:14:31 -0000 At 11:18 AM +0200 2/5/09, Hannes Tschofenig wrote: > The framework document is the informative description where > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt > provides the normative part. As an aside, since the framework is informative and doesn't contain any normative language, maybe it should be Informational instead of Proposed Standard. > we are left with the situation that IMS emergency calling and emergency > calling for everything else works differently. > > This is unfortunate. Your company was always a big fan of developing a > harmonized solution, right? > > I doubt that the situation is improved by summarizing other standardization > efforts in this document nor by describing the content of this document in > 3GPP, 3GPP2 or OMA documents. Since the reality is that cellular emergency calling uses different protocols and procedures, in the interest of clarity and avoiding misunderstandings, it seems a good idea for this document to have an applicability statement that says, in effect, "Cellular networks work differently than what is described here"? Doing so wouldn't in any way detract from, or be a demerit on, the solution described here, it would simply clarify reality. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- You see, wire telegraph is a kind of very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates in exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. --Albert Einstein Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1620D3A6959 for ; Fri, 20 Feb 2009 08:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XObkFJepWpTL for ; Fri, 20 Feb 2009 08:07:14 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AA4413A69B0 for ; Fri, 20 Feb 2009 08:07:13 -0800 (PST) Received: (qmail invoked by alias); 20 Feb 2009 16:07:26 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp047) with SMTP; 20 Feb 2009 17:07:26 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18wEN4YtXQweP0PnC+WC1OHHiqTu/sacWYYid+zwj L814dno1Obh5vK From: "Hannes Tschofenig" To: "'Randall Gellens'" , "'Edge, Stephen'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <003901c98772$b4cc7710$0201a8c0@nsnintra.net> Date: Fri, 20 Feb 2009 18:08:20 +0200 Message-ID: <00a701c99375$757e2db0$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmTbflMgC/OsqzlSgSSgJHyC6Sv5gABxINQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 16:07:15 -0000 Hi Randy, >At 11:18 AM +0200 2/5/09, Hannes Tschofenig wrote: > >> The framework document is the informative description where >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.txt >> provides the normative part. > >As an aside, since the framework is informative and doesn't >contain any normative language, maybe it should be >Informational instead of Proposed Standard. Good catch. This is certainly a correct observation. > >> we are left with the situation that IMS emergency calling and >> emergency calling for everything else works differently. >> >> This is unfortunate. Your company was always a big fan of >developing >> a harmonized solution, right? >> >> I doubt that the situation is improved by summarizing other >> standardization efforts in this document nor by describing the >> content of this document in 3GPP, 3GPP2 or OMA documents. > >Since the reality is that cellular emergency calling uses >different protocols and procedures, in the interest of clarity >and avoiding misunderstandings, it seems a good idea for this >document to have an applicability statement that says, in >effect, "Cellular networks work differently than what is >described here"? Doing so wouldn't in any way detract from, >or be a demerit on, the solution described here, it would >simply clarify reality. Some organizations think that cellular networks are different and hence they need completely different protocols and procedures. Example: WAP I am not sure that many folks in the RAI area share the same view. Ciao Hannes >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- You see, >wire telegraph is a kind of very, very long cat. You pull his >tail in New York and his head is meowing in Los Angeles. >Do you understand this? And radio operates in exactly the same >way: you send signals here, they receive them there. The only >difference is that there is no cat. --Albert Einstein > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49EC3A6A78 for ; Fri, 20 Feb 2009 08:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFiciFNEncK5 for ; Fri, 20 Feb 2009 08:28:55 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5BC883A63D3 for ; Fri, 20 Feb 2009 08:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1235147350; x=1266683350; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<00a701c99375$757e2db0$0201a8c0@nsnintra. net>|References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0 305@NASANEXMB04.na.qualcomm.com>=0D=0A=20<003901c98772$b4 cc7710$0201a8c0@nsnintra.net>=0D=0A=20=0D=0A=20<00a701c99375$757e2db0$0201a8 c0@nsnintra.net>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-flag:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Fr i,=2020=20Feb=202009=2008:28:58=20-0800|To:=20Hannes=20Ts chofenig=20,=0D=0A=20=20=20=20 =20=20=20=20"'Randall=20Gellens'"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'Edge,=20Stephen'" =20,=20"'ECRIT'"=0D=0A=09|From:=20Randall=20Gellens=20 |Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework=20D raft|MIME-Version:=201.0|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5530"=3B=20a=3D"15670749"; bh=AK2iqqzWNrfUtmdDOB9+jxcqdvTp4iZ8tXDVtSv60Dg=; b=DKlVFd8ZAErZn8/ZYKj/e3dBAKeyK+NFGPGe3yulH7DI0trOwhcS226C EYj5IAAfqivKxmU2RLGkkCyXYVjIsK5Zs3i8VXpcN1cvdEF1EbaHJ4dYk 4dn0b/NpOyvTqjVafUn0eOhuspJHJTrDXNFGQiJ7EyXKE/YPzWjP/7R2f M=; X-IronPort-AV: E=McAfee;i="5300,2777,5530"; a="15670749" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Feb 2009 08:29:07 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KGT76k016858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Feb 2009 08:29:07 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1KGT6XV026420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Feb 2009 08:29:07 -0800 (PST) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 20 Feb 2009 08:29:06 -0800 Received: from [10.67.63.47] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 20 Feb 2009 08:29:06 -0800 Message-ID: In-Reply-To: <00a701c99375$757e2db0$0201a8c0@nsnintra.net> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <003901c98772$b4cc7710$0201a8c0@nsnintra.net> <00a701c99375$757e2db0$0201a8c0@nsnintra.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 20 Feb 2009 08:28:58 -0800 To: Hannes Tschofenig , "'Randall Gellens'" , "'Edge, Stephen'" , "'ECRIT'" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 16:28:56 -0000 Hi Hannes, At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote: > >Since the reality is that cellular emergency calling uses >>different protocols and procedures, in the interest of clarity >>and avoiding misunderstandings, it seems a good idea for this >>document to have an applicability statement that says, in >>effect, "Cellular networks work differently than what is >>described here"? Doing so wouldn't in any way detract from, >>or be a demerit on, the solution described here, it would >>simply clarify reality. > > Some organizations think that cellular networks are different and hence they > need completely different protocols and procedures. Example: WAP > > I am not sure that many folks in the RAI area share the same view. Putting aside the question of what cellular networks *should* use, the issue is: what *will* they use. Given that there is a large installed base and momentum for current protocols, I think it's unreasonable to expect that cellular networks will ditch what they have in favor of what's here (especially in view of the specific issues that Stephen raised). Hence, to avoid confusion, it makes sense for this document to say that cellular networks use different protocols and procedures. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Any given program, when running, is obsolete. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED1228C210 for ; Fri, 20 Feb 2009 08:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NjmZeYMZzjW for ; Fri, 20 Feb 2009 08:59:27 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9BBF828C154 for ; Fri, 20 Feb 2009 08:59:26 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_20_11_18_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); Fri, 20 Feb 2009 11:18:01 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 10:58:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 10:54:28 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8W References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><00a701c99375$757e2db0$0201a8c0@nsnintra.net> From: "Winterbottom, James" To: "Randall Gellens" , "Hannes Tschofenig" , "Edge, Stephen" , "ECRIT" X-OriginalArrivalTime: 20 Feb 2009 16:58:33.0344 (UTC) FILETIME=[76B30000:01C9937C] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 16:59:28 -0000 I actually don't see what benefit adding this statement does to the documen= t.=0D=0AI do however see some harm in providing.=0D=0A=0D=0AIf as a potenti= al 3G or 4G operator I wish to offer a broadband service and, rather than p= roviding a SUPL service I wish to provide some other service so that it is = compatible with ECRIT, then I can't, because ECRIT has a clear applicabilit= y statement saying that it is not appropriate.=0D=0A=0D=0AIf operators of c= ellular networks wish to continue to deploy networks based on 3GPP architec= tures then are entitled to do so. It would however, be doing them a disserv= ice to suggest that there is not a viable alternative.=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounc= es@ietf.org on behalf of Randall Gellens=0D=0ASent: Fri 2/20/2009 10:28 AM=0D= =0ATo: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'=0D=0A= Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A=20=0D=0AHi Hannes,=0D= =0A=0D=0AAt 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:=0D=0A=0D=0A> = >Since the reality is that cellular emergency calling uses=0D=0A>>different= protocols and procedures, in the interest of clarity=0D=0A>>and avoiding m= isunderstandings, it seems a good idea for this=0D=0A>>document to have an = applicability statement that says, in=0D=0A>>effect, "Cellular networks wor= k differently than what is=0D=0A>>described here"=3F Doing so wouldn't in = any way detract from,=0D=0A>>or be a demerit on, the solution described her= e, it would=0D=0A>>simply clarify reality.=0D=0A>=0D=0A> Some organization= s think that cellular networks are different and hence they=0D=0A> need co= mpletely different protocols and procedures. Example: WAP=0D=0A>=0D=0A> I = am not sure that many folks in the RAI area share the same view.=0D=0A=0D=0A= Putting aside the question of what cellular networks *should* use,=20=0D=0A= the issue is: what *will* they use. Given that there is a large=20=0D=0Ain= stalled base and momentum for current protocols, I think it's=20=0D=0Aunrea= sonable to expect that cellular networks will ditch what they=20=0D=0Ahave = in favor of what's here (especially in view of the specific=20=0D=0Aissues = that Stephen raised). Hence, to avoid confusion, it makes=20=0D=0Asense fo= r this document to say that cellular networks use different=20=0D=0Aprotoco= ls and procedures.=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D=0AOpinions are = personal; facts are suspect; I speak for myself only=0D=0A-----------= --- Randomly selected tag: ---------------=0D=0AAny given program, when run= ning, is obsolete.=0D=0A_______________________________________________=0D=0A= Ecrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/li= stinfo/ecrit=0D=0A=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 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D2A28C12B for ; Fri, 20 Feb 2009 09:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haGHRRkiro3D for ; Fri, 20 Feb 2009 09:07:07 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 64EFD28C110 for ; Fri, 20 Feb 2009 09:07:07 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n1KH6x35021418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Feb 2009 12:07:07 -0500 (EST) Message-Id: <0789FB31-C793-4DEE-99DD-3D3F3F4D5D11@cs.columbia.edu> From: Henning Schulzrinne To: Randall Gellens In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 12:06:59 -0500 References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <003901c98772$b4cc7710$0201a8c0@nsnintra.net> <00a701c99375$757e2db0$0201a8c0@nsnintra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 17:07:08 -0000 > > Putting aside the question of what cellular networks *should* use, > the issue is: what *will* they use. Given that there is a large > installed base and momentum for current protocols, I think it's > unreasonable to expect that cellular networks will ditch what they > have in favor of what's here (especially in view of the specific > issues that Stephen raised). Hence, to avoid confusion, it makes > sense for this document to say that cellular networks use different > protocols and procedures. > We're not trying to write survey papers here, and this information may well be incorrect a few years from now, so I don't see much value in adding a statement that may well be (and we hope to be) out of date soon. Plus, it is quite possible that cellular-like networks, such as WiMax, will use the framework mechanisms. In addition, VSPs operating over EVDO, HSPA or LTE may well also use these mechanisms, so the statement, unless heavily qualified, may be wrong almost from the day the RFC is published. Henning Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5E43A6A5C for ; Fri, 20 Feb 2009 09:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOLCtGMBKh7o for ; Fri, 20 Feb 2009 09:20:03 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5170E3A6872 for ; Fri, 20 Feb 2009 09:20:02 -0800 (PST) Received: (qmail invoked by alias); 20 Feb 2009 17:20:16 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 20 Feb 2009 18:20:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+P0kxLb76P2pW3wpjc3npnmzVKFC5o0/BCnsnX5c 5cUh7Lqd7cQ569 From: "Hannes Tschofenig" To: "'Randall Gellens'" , "'Edge, Stephen'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <003901c98772$b4cc7710$0201a8c0@nsnintra.net> <00a701c99375$757e2db0$0201a8c0@nsnintra.net> Date: Fri, 20 Feb 2009 19:21:12 +0200 Message-ID: <00c101c9937f$a2bcc660$0201a8c0@nsnintra.net> 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.3350 In-Reply-To: Thread-Index: AcmTeFzbdvBjJ00eTn6YXJ8jHRk8pgABnerw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 17:20:04 -0000 >> Some organizations think that cellular networks are different and >> hence they need completely different protocols and procedures. >> Example: WAP >> >> I am not sure that many folks in the RAI area share the same view. > >Putting aside the question of what cellular networks *should* >use, the issue is: what *will* they use. Nobody knows what the future will bring us. >Given that there is >a large installed base We are talking about future systems -- not about past systems. >and momentum for current protocols, Momentum for what protocols in this context? > I >think it's unreasonable to expect that cellular networks will >ditch what they have in favor of what's here (especially in >view of the specific issues that Stephen raised). I am not sure what they have to ditch. >Hence, to >avoid confusion, it makes sense for this document to say that >cellular networks use different protocols and procedures. I am sure you have your reason to make these claims but I don't understand them. Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE643A6BF6 for ; Fri, 20 Feb 2009 10:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l93j5Ximnx48 for ; Fri, 20 Feb 2009 10:39:03 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 186B63A680E for ; Fri, 20 Feb 2009 10:39:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,242,1233532800"; d="scan'208";a="37833277" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2009 18:39:17 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1KIdHKc021464; Fri, 20 Feb 2009 13:39:17 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1KIdHXo025506; Fri, 20 Feb 2009 18:39:17 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Feb 2009 13:39:17 -0500 Received: from [10.67.63.181] ([10.82.253.207]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Feb 2009 13:39:16 -0500 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 20 Feb 2009 13:39:15 -0500 From: Marc Linsner To: Randall Gellens , "'ECRIT'" Message-ID: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmTiofOlBHQSl5S10SIhyaYj6WI3g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Feb 2009 18:39:16.0716 (UTC) FILETIME=[88D462C0:01C9938A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1612; t=1235155157; x=1236019157; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Comments=20on=20Framework=20D raft |Sender:=20 |To:=20Randall=20Gellens=20,=20=22'ECRI T'=22=20; bh=XbzpMH5ZUX45C7RcXgeSMpqjLZfv0GmT/QCJ5IJJDAk=; b=MvOHPEj1ujAvlF/ZYlTEhhYYHXRvYGm8kJGd0YBpZsnYzB4uRMRhrj1PZk M8EUtjDRgbgfJ8UK4ocmXCYrszDIGkhoC4yNrXpUTG2WW3M41xfrsbow9gZS lJSbM3yY94; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 18:39:05 -0000 Randy, I'm curious if there are people that believe the IETF writes cellular standards? I'm not sure the confusion you are trying to correct exists...(but that's my view, subject to change via more information). -Marc- On 2/20/09 11:28 AM, "Randall Gellens" wrote: > Hi Hannes, > > At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote: > >>> Since the reality is that cellular emergency calling uses >>> different protocols and procedures, in the interest of clarity >>> and avoiding misunderstandings, it seems a good idea for this >>> document to have an applicability statement that says, in >>> effect, "Cellular networks work differently than what is >>> described here"? Doing so wouldn't in any way detract from, >>> or be a demerit on, the solution described here, it would >>> simply clarify reality. >> >> Some organizations think that cellular networks are different and hence they >> need completely different protocols and procedures. Example: WAP >> >> I am not sure that many folks in the RAI area share the same view. > > Putting aside the question of what cellular networks *should* use, > the issue is: what *will* they use. Given that there is a large > installed base and momentum for current protocols, I think it's > unreasonable to expect that cellular networks will ditch what they > have in favor of what's here (especially in view of the specific > issues that Stephen raised). Hence, to avoid confusion, it makes > sense for this document to say that cellular networks use different > protocols and procedures. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E80B3A67B4 for ; Fri, 20 Feb 2009 13:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VewjwMTderV4 for ; Fri, 20 Feb 2009 13:39:59 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id DA9C43A67A4 for ; Fri, 20 Feb 2009 13:39:59 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1235166013!27739275!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 5607 invoked from network); 20 Feb 2009 21:40:14 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-13.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 20 Feb 2009 21:40:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1KLeBSc020647; Fri, 20 Feb 2009 16:40:13 -0500 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n1KLe8Jj020601; Fri, 20 Feb 2009 16:40:08 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Feb 2009 16:40:08 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Feb 2009 16:40:08 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 16:39:59 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0D1FB88C@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft thread-index: AcmTeGJsoBLvJ+6vTOqN4erzE4y2FgAKGNtA References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><00a701c99375$757e2db0$0201a8c0@nsnintra.net> From: "Stark, Barbara" To: "Randall Gellens" , "Hannes Tschofenig" , "Edge, Stephen" , "ECRIT" X-OriginalArrivalTime: 20 Feb 2009 21:40:08.0316 (UTC) FILETIME=[CCE323C0:01C993A3] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:40:01 -0000 My 2 cents. Service Providers and vendors of all ilk (cellular or otherwise) will always only implement an IETF RFC (or any other standard) because they either want to or have to. That goes without saying. So why say it? Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Friday, February 20, 2009 11:29 AM To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft Hi Hannes, At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote: > >Since the reality is that cellular emergency calling uses >>different protocols and procedures, in the interest of clarity >>and avoiding misunderstandings, it seems a good idea for this >>document to have an applicability statement that says, in >>effect, "Cellular networks work differently than what is >>described here"? Doing so wouldn't in any way detract from, >>or be a demerit on, the solution described here, it would >>simply clarify reality. > > Some organizations think that cellular networks are different and hence they > need completely different protocols and procedures. Example: WAP > > I am not sure that many folks in the RAI area share the same view. Putting aside the question of what cellular networks *should* use,=20 the issue is: what *will* they use. Given that there is a large=20 installed base and momentum for current protocols, I think it's=20 unreasonable to expect that cellular networks will ditch what they=20 have in favor of what's here (especially in view of the specific=20 issues that Stephen raised). Hence, to avoid confusion, it makes=20 sense for this document to say that cellular networks use different=20 protocols and procedures. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Any given program, when running, is obsolete. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E06D28C217 for ; Fri, 20 Feb 2009 16:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfQUv201ODpz for ; Fri, 20 Feb 2009 16:28:32 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3F59428C18A for ; Fri, 20 Feb 2009 16:28:31 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_20_18_48_14 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 20 Feb 2009 18:48:14 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 18:28:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 18:28:43 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmTeF5hx4WNojVNQTy60SBtFJN2ewAQmK5A References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><00a701c99375$757e2db0$0201a8c0@nsnintra.net> From: "Dawson, Martin" To: "Randall Gellens" , "Hannes Tschofenig" , "Edge, Stephen" , "ECRIT" X-OriginalArrivalTime: 21 Feb 2009 00:28:46.0588 (UTC) FILETIME=[5BD8EBC0:01C993BB] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:28:33 -0000 A very small qualification - related to the scope of the working group=0D=0A= task, not its actual output - was used to put a statement in the NENA i2=0D= =0Aspecification that it didn't address mobile networks. This was despite=0D= =0Athe fact that the architecture works perfectly well for mobile networks.=0D= =0A=0D=0AIt's been used deliberately or unconsciously ever since then to ma= ke=0D=0Afallacious arguments about the applicability of that architecture f= or=0D=0Amobile.=0D=0A=0D=0AThe problem with putting the requested statement= in the ECRIT documents=0D=0Ais that, again, it will be used to fallaciousl= y argue that the ECRIT=0D=0Aarchitecture does not apply to mobile. Surely n= ot=3F Yeah - right.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.= org] On Behalf=0D=0AOf Randall Gellens=0D=0ASent: Saturday, 21 February 200= 9 3:29 AM=0D=0ATo: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; '= ECRIT'=0D=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHi = Hannes,=0D=0A=0D=0AAt 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:=0D=0A=0D= =0A> >Since the reality is that cellular emergency calling uses=0D=0A>>di= fferent protocols and procedures, in the interest of clarity=0D=0A>>and avo= iding misunderstandings, it seems a good idea for this=0D=0A>>document to h= ave an applicability statement that says, in=0D=0A>>effect, "Cellular netwo= rks work differently than what is=0D=0A>>described here"=3F Doing so would= n't in any way detract from,=0D=0A>>or be a demerit on, the solution descri= bed here, it would=0D=0A>>simply clarify reality.=0D=0A>=0D=0A> Some organ= izations think that cellular networks are different and=0D=0Ahence they=0D=0A= > need completely different protocols and procedures. Example: WAP=0D=0A>=0D= =0A> I am not sure that many folks in the RAI area share the same view.=0D= =0A=0D=0APutting aside the question of what cellular networks *should* use,= =20=0D=0Athe issue is: what *will* they use. Given that there is a large =0D= =0Ainstalled base and momentum for current protocols, I think it's=20=0D=0A= unreasonable to expect that cellular networks will ditch what they=20=0D=0A= have in favor of what's here (especially in view of the specific=20=0D=0Ais= sues that Stephen raised). Hence, to avoid confusion, it makes=20=0D=0Asen= se for this document to say that cellular networks use different=20=0D=0Apr= otocols and procedures.=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D=0AOpinions= are personal; facts are suspect; I speak for myself only=0D=0A------= -------- Randomly selected tag: ---------------=0D=0AAny given program, whe= n running, is obsolete.=0D=0A______________________________________________= _=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mai= lman/listinfo/ecrit=0D=0A=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0AThis message is f= or the designated recipient only and may=0D=0Acontain privileged, proprieta= ry, or otherwise private information. =20=0D=0AIf you have received it in e= rror, please notify the sender=0D=0Aimmediately and delete the original. A= ny unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0A[mf2]=0D=0A Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4238B3A6836 for ; Thu, 19 Feb 2009 05:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 338txHTM7yor for ; Thu, 19 Feb 2009 05:56:53 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5AB893A6AD8 for ; Thu, 19 Feb 2009 05:56:53 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6FBAE21642; Thu, 19 Feb 2009 14:57:05 +0100 (CET) X-AuditID: c1b4fb3e-ab0b9bb000001315-7a-499d653156b5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 57EEF2162A; Thu, 19 Feb 2009 14:57:05 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 14:57:04 +0100 Received: from [153.88.44.232] ([153.88.44.232]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 14:57:04 +0100 Message-ID: <499D6530.9040208@ericsson.com> Date: Thu, 19 Feb 2009 15:57:04 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Feb 2009 13:57:04.0583 (UTC) FILETIME=[F2142D70:01C99299] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sun, 22 Feb 2009 11:26:05 -0800 Subject: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 13:56:54 -0000 Folks, I have been asked to perform an expert review of the following draft: http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt The approach taken by the draft seems OK in general. I have a few comments though: The requirement in Section 3 is too specific because it already assumes that the solution will be an indication in the SIP header fields. The requirement does not need to make that assumption. I would remove "by providing an appropriate indication in the SIP header fields". In Section 5, the reference to RFC 2234 should be replaced with one to RFC 5234. Also in Section 5, the formal syntax should be rewritten so that it is compatible with the ABNF in RFC 3261. RFC 3261 already defines uri-parameter as follows: uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar This document should simply define a new value for pname. The document does not talk about backwards compatibility. What happens if the registrar does not understand the 'sos' parameter? Will it do the right thing? Will the UAC detect the failure? Is there a need to define an option tag?... the document should address these points. Cheers, Gonzalo Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D563A6B18 for ; Mon, 23 Feb 2009 03:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqO2nz9YJxby for ; Mon, 23 Feb 2009 03:25:07 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 6A7793A6874 for ; Mon, 23 Feb 2009 03:25:06 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1NBPJO6007953 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Feb 2009 12:25:19 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 23 Feb 2009 12:25:19 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , Randall Gellens , Hannes Tschofenig , "Edge, Stephen" , ECRIT Date: Mon, 23 Feb 2009 12:25:17 +0100 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A4C6D3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><00a701c99375$757e2db0$0201a8c0@nsnintra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:25:09 -0000 My understanding so far is that it is an IMS issue, rather than directly an= access technology one. You wish to offer IMS according to 3GPP standards, whether you are DSL, 3G,= 4G or whatever, then you follow the IMS standards which lays down a specif= ic architecture for handling emergency calls. If you want to offer SIP over 3G or 4G not in accordance with IMS, then you= can do what you like in terms of the emergency calling as well.=20 Further, I suspect that the operator does not have complete freedom of choi= ce, because the operator will not be able to negotiate the appropriate roam= ing agreements if they go the path you are suggesting. And roaming agreemen= ts for some strange financial reason which I can well understand IETF faili= ng to appreciate are important to these operators. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Winterbottom, James > Sent: Friday, February 20, 2009 4:54 PM > To: Randall Gellens; Hannes Tschofenig; Edge, Stephen; ECRIT > Subject: Re: [Ecrit] Comments on Framework Draft >=20 > I actually don't see what benefit adding this statement does=20 > to the document. > I do however see some harm in providing. >=20 > If as a potential 3G or 4G operator I wish to offer a=20 > broadband service and, rather than providing a SUPL service I=20 > wish to provide some other service so that it is compatible=20 > with ECRIT, then I can't, because ECRIT has a clear=20 > applicability statement saying that it is not appropriate. >=20 > If operators of cellular networks wish to continue to deploy=20 > networks based on 3GPP architectures then are entitled to do=20 > so. It would however, be doing them a disservice to suggest=20 > that there is not a viable alternative. >=20 > Cheers > James >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Randall Gellens > Sent: Fri 2/20/2009 10:28 AM > To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT' > Subject: Re: [Ecrit] Comments on Framework Draft > =20 > Hi Hannes, >=20 > At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote: >=20 > > >Since the reality is that cellular emergency calling uses > >>different protocols and procedures, in the interest of clarity and=20 > >>avoiding misunderstandings, it seems a good idea for this=20 > document to=20 > >>have an applicability statement that says, in effect, "Cellular=20 > >>networks work differently than what is described here"? Doing so=20 > >>wouldn't in any way detract from, or be a demerit on, the solution=20 > >>described here, it would simply clarify reality. > > > > Some organizations think that cellular networks are different and=20 > > hence they need completely different protocols and procedures.=20 > > Example: WAP > > > > I am not sure that many folks in the RAI area share the same view. >=20 > Putting aside the question of what cellular networks *should*=20 > use, the issue is: what *will* they use. Given that there is=20 > a large installed base and momentum for current protocols, I=20 > think it's unreasonable to expect that cellular networks will=20 > ditch what they have in favor of what's here (especially in=20 > view of the specific issues that Stephen raised). Hence, to=20 > avoid confusion, it makes sense for this document to say that=20 > cellular networks use different protocols and procedures. >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for=20 > myself only > -------------- Randomly selected tag: --------------- Any=20 > given program, when running, is obsolete. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87913A6861 for ; Mon, 23 Feb 2009 03:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.422 X-Spam-Level: X-Spam-Status: No, score=-5.422 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 548ARzXFE8xY for ; Mon, 23 Feb 2009 03:58:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 52B0F3A67A1 for ; Mon, 23 Feb 2009 03:58:44 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1NBws3U026295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Feb 2009 12:58:54 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1NBws96007907; Mon, 23 Feb 2009 12:58:54 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 12:58:54 +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 Date: Mon, 23 Feb 2009 13:59:51 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450112E43C@FIESEXC015.nsn-intra.net> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A4C6D3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHAAALu1AA== References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><00a701c99375$757e2db0$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D674A4C6D3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Winterbottom, James" , "Randall Gellens" , "Hannes Tschofenig" , "Edge,Stephen" , "ECRIT" X-OriginalArrivalTime: 23 Feb 2009 11:58:54.0170 (UTC) FILETIME=[198403A0:01C995AE] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:58:45 -0000 Hi all,=20 I believe it does not make a lot of sense to use the ECRIT mailing list to speculate about the success or failure of IMS.=20 What matters at this point is trying to figure out what Randy and Stephen are actually trying to tell us. I suspect that it boils down to a few issues but so far I was not able to capture them correctly.=20 I suspect that most of the discussion actually relates to location rather than to the emergency services architecture as such. To me this appears to be the SUPL vs. other location protocol story. Ciao Hannes PS: Keith, I liked this statement:=20 "You wish to offer IMS ***according to 3GPP standards***, whether you=20 are DSL, 3G, 4G or whatever, then you follow ***the IMS standards***=20 which lays down a specific architecture for handling emergency calls. " This sounds like: "If you want to follow the 3GPP IMS standards then follow the 3GPP IMS standards." >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext DRAGE, Keith (Keith) >Sent: 23 February, 2009 13:25 >To: Winterbottom, James; Randall Gellens; Hannes Tschofenig;=20 >Edge,Stephen; ECRIT >Subject: Re: [Ecrit] Comments on Framework Draft > >My understanding so far is that it is an IMS issue, rather=20 >than directly an access technology one. > >You wish to offer IMS according to 3GPP standards, whether you=20 >are DSL, 3G, 4G or whatever, then you follow the IMS standards=20 >which lays down a specific architecture for handling emergency calls. > >If you want to offer SIP over 3G or 4G not in accordance with=20 >IMS, then you can do what you like in terms of the emergency=20 >calling as well.=20 > >Further, I suspect that the operator does not have complete=20 >freedom of choice, because the operator will not be able to=20 >negotiate the appropriate roaming agreements if they go the=20 >path you are suggesting. And roaming agreements for some=20 >strange financial reason which I can well understand IETF=20 >failing to appreciate are important to these operators. > >regards > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Winterbottom, James >> Sent: Friday, February 20, 2009 4:54 PM >> To: Randall Gellens; Hannes Tschofenig; Edge, Stephen; ECRIT >> Subject: Re: [Ecrit] Comments on Framework Draft >>=20 >> I actually don't see what benefit adding this statement does to the=20 >> document. >> I do however see some harm in providing. >>=20 >> If as a potential 3G or 4G operator I wish to offer a broadband=20 >> service and, rather than providing a SUPL service I wish to provide=20 >> some other service so that it is compatible with ECRIT, then=20 >I can't,=20 >> because ECRIT has a clear applicability statement saying that it is=20 >> not appropriate. >>=20 >> If operators of cellular networks wish to continue to deploy=20 >networks=20 >> based on 3GPP architectures then are entitled to do so. It would=20 >> however, be doing them a disservice to suggest that there is not a=20 >> viable alternative. >>=20 >> Cheers >> James >>=20 >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org on behalf of Randall Gellens >> Sent: Fri 2/20/2009 10:28 AM >> To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> =20 >> Hi Hannes, >>=20 >> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote: >>=20 >> > >Since the reality is that cellular emergency calling uses >> >>different protocols and procedures, in the interest of clarity and=20 >> >>avoiding misunderstandings, it seems a good idea for this >> document to >> >>have an applicability statement that says, in effect, "Cellular=20 >> >>networks work differently than what is described here"? Doing so=20 >> >>wouldn't in any way detract from, or be a demerit on, the solution=20 >> >>described here, it would simply clarify reality. >> > >> > Some organizations think that cellular networks are different and=20 >> > hence they need completely different protocols and procedures. >> > Example: WAP >> > >> > I am not sure that many folks in the RAI area share the same view. >>=20 >> Putting aside the question of what cellular networks=20 >*should* use, the=20 >> issue is: what *will* they use. Given that there is a large=20 >installed=20 >> base and momentum for current protocols, I think it's=20 >unreasonable to=20 >> expect that cellular networks will ditch what they have in favor of=20 >> what's here (especially in view of the specific issues that Stephen=20 >> raised). Hence, to avoid confusion, it makes sense for this=20 >document=20 >> to say that cellular networks use different protocols and procedures. >>=20 >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for=20 >> myself only >> -------------- Randomly selected tag: --------------- Any given=20 >> program, when running, is obsolete. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=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=20 >immediately=20 >> and delete the original. Any unauthorized use of this email is=20 >> prohibited. >> -------------------------------------------------------------- >> ---------------------------------- >> [mf2] >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EC53A69F1 for ; Mon, 23 Feb 2009 11:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asnec2D1SHoC for ; Mon, 23 Feb 2009 11:47:40 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C35743A69DF for ; Mon, 23 Feb 2009 11:47:39 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_23_14_07_27 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 23 Feb 2009 14:07:27 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 13:47:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2009 13:47:54 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHAAALu1AAAQ3aW7 References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><00a701c99375$757e2db0$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D674A4C6D3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3D3C75174CB95F42AD6BCC56E5555B450112E43C@FIESEXC015.nsn-intra.net> From: "Winterbottom, James" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext DRAGE, Keith (Keith)" , "Randall Gellens" , "Hannes Tschofenig" , "Edge,Stephen" , "ECRIT" X-OriginalArrivalTime: 23 Feb 2009 19:47:55.0461 (UTC) FILETIME=[9F083F50:01C995EF] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:47:41 -0000 Actually Hannes, I think it is an network architecture difference.=0D=0A=0D= =0AIMS REQUIRES the access and service providers to have a direct business = relationship in the form or a roaming agreement. This serves to provide con= nectivity between the location function in the access network and the call = server. This happens whether you are talking control-plane or user-plane.=0D= =0A=0D=0AThe linkage between access and service in IMS is largely artificia= l, as Keith points out, it is done for financial reasons rather than techni= cal merit. So the real question that is being asked, is whether ECRIT is ap= propriate to architectures that do not make a formal separation between acc= ess and application. I would argue that yes, ECRIT will work in those envir= onment but that the converse is likely not the case without considerable tr= ouble.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original Message-= ----=0D=0AFrom: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofen= ig@nsn.com]=0D=0ASent: Mon 2/23/2009 5:59 AM=0D=0ATo: ext DRAGE, Keith (Kei= th); Winterbottom, James; Randall Gellens; Hannes Tschofenig; Edge,Stephen;= ECRIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=20=0D=0A= Hi all,=20=0D=0A=0D=0AI believe it does not make a lot of sense to use the = ECRIT mailing list=0D=0Ato speculate about the success or failure of IMS. =0D= =0A=0D=0AWhat matters at this point is trying to figure out what Randy and=0D= =0AStephen are actually trying to tell us. I suspect that it boils down to=0D= =0Aa few issues but so far I was not able to capture them correctly.=20=0D=0A=0D= =0AI suspect that most of the discussion actually relates to location=0D=0A= rather than to the emergency services architecture as such. To me this=0D=0A= appears to be the SUPL vs. other location protocol story.=0D=0A=0D=0ACiao=0D= =0AHannes=0D=0A=0D=0APS: Keith, I liked this statement:=20=0D=0A"You wish t= o offer IMS ***according to 3GPP standards***, whether you=20=0D=0Aare DSL,= 3G, 4G or whatever, then you follow ***the IMS standards***=20=0D=0Awhich = lays down a specific architecture for handling emergency calls.=0D=0A"=0D=0A=0D= =0AThis sounds like: "If you want to follow the 3GPP IMS standards then=0D=0A= follow the 3GPP IMS standards."=0D=0A=0D=0A=0D=0A>-----Original Message----= -=0D=0A>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20=0D=0A= >On Behalf Of ext DRAGE, Keith (Keith)=0D=0A>Sent: 23 February, 2009 13:25=0D= =0A>To: Winterbottom, James; Randall Gellens; Hannes Tschofenig;=20=0D=0A>E= dge,Stephen; ECRIT=0D=0A>Subject: Re: [Ecrit] Comments on Framework Draft=0D= =0A>=0D=0A>My understanding so far is that it is an IMS issue, rather=20=0D= =0A>than directly an access technology one.=0D=0A>=0D=0A>You wish to offer = IMS according to 3GPP standards, whether you=20=0D=0A>are DSL, 3G, 4G or wh= atever, then you follow the IMS standards=20=0D=0A>which lays down a specif= ic architecture for handling emergency calls.=0D=0A>=0D=0A>If you want to o= ffer SIP over 3G or 4G not in accordance with=20=0D=0A>IMS, then you can do= what you like in terms of the emergency=20=0D=0A>calling as well.=20=0D=0A= >=0D=0A>Further, I suspect that the operator does not have complete=20=0D=0A= >freedom of choice, because the operator will not be able to=20=0D=0A>negot= iate the appropriate roaming agreements if they go the=20=0D=0A>path you ar= e suggesting. And roaming agreements for some=20=0D=0A>strange financial re= ason which I can well understand IETF=20=0D=0A>failing to appreciate are im= portant to these operators.=0D=0A>=0D=0A>regards=0D=0A>=0D=0A>Keith=0D=0A>=0D= =0A>> -----Original Message-----=0D=0A>> From: ecrit-bounces@ietf.org [mail= to:ecrit-bounces@ietf.org]=20=0D=0A>On Behalf=20=0D=0A>> Of Winterbottom, J= ames=0D=0A>> Sent: Friday, February 20, 2009 4:54 PM=0D=0A>> To: Randall Ge= llens; Hannes Tschofenig; Edge, Stephen; ECRIT=0D=0A>> Subject: Re: [Ecrit]= Comments on Framework Draft=0D=0A>>=20=0D=0A>> I actually don't see what b= enefit adding this statement does to the=20=0D=0A>> document.=0D=0A>> I do = however see some harm in providing.=0D=0A>>=20=0D=0A>> If as a potential 3G= or 4G operator I wish to offer a broadband=20=0D=0A>> service and, rather = than providing a SUPL service I wish to provide=20=0D=0A>> some other servi= ce so that it is compatible with ECRIT, then=20=0D=0A>I can't,=20=0D=0A>> b= ecause ECRIT has a clear applicability statement saying that it is=20=0D=0A= >> not appropriate.=0D=0A>>=20=0D=0A>> If operators of cellular networks wi= sh to continue to deploy=20=0D=0A>networks=20=0D=0A>> based on 3GPP archite= ctures then are entitled to do so. It would=20=0D=0A>> however, be doing th= em a disservice to suggest that there is not a=20=0D=0A>> viable alternativ= e.=0D=0A>>=20=0D=0A>> Cheers=0D=0A>> James=0D=0A>>=20=0D=0A>>=20=0D=0A>> --= ---Original Message-----=0D=0A>> From: ecrit-bounces@ietf.org on behalf of = Randall Gellens=0D=0A>> Sent: Fri 2/20/2009 10:28 AM=0D=0A>> To: Hannes Tsc= hofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT'=0D=0A>> Subject: Re: [= Ecrit] Comments on Framework Draft=0D=0A>> =20=0D=0A>> Hi Hannes,=0D=0A>> =0D= =0A>> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote:=0D=0A>>=20=0D=0A>>= > >Since the reality is that cellular emergency calling uses=0D=0A>> >>d= ifferent protocols and procedures, in the interest of clarity and=20=0D=0A>= > >>avoiding misunderstandings, it seems a good idea for this=0D=0A>> docum= ent to=0D=0A>> >>have an applicability statement that says, in effect, "Cel= lular=20=0D=0A>> >>networks work differently than what is described here"=3F= Doing so=20=0D=0A>> >>wouldn't in any way detract from, or be a demerit o= n, the solution=20=0D=0A>> >>described here, it would simply clarify realit= y.=0D=0A>> >=0D=0A>> > Some organizations think that cellular networks are= different and=20=0D=0A>> > hence they need completely different protocols= and procedures.=0D=0A>> > Example: WAP=0D=0A>> >=0D=0A>> > I am not sure = that many folks in the RAI area share the same view.=0D=0A>>=20=0D=0A>> Put= ting aside the question of what cellular networks=20=0D=0A>*should* use, th= e=20=0D=0A>> issue is: what *will* they use. Given that there is a large =0D= =0A>installed=20=0D=0A>> base and momentum for current protocols, I think i= t's=20=0D=0A>unreasonable to=20=0D=0A>> expect that cellular networks will = ditch what they have in favor of=20=0D=0A>> what's here (especially in view= of the specific issues that Stephen=20=0D=0A>> raised). Hence, to avoid c= onfusion, it makes sense for this=20=0D=0A>document=20=0D=0A>> to say that = cellular networks use different protocols and procedures.=0D=0A>>=20=0D=0A>= > --=0D=0A>> Randall Gellens=0D=0A>> Opinions are personal; facts are su= spect; I speak for=20=0D=0A>> myself only=0D=0A>> -------------- Randoml= y selected tag: --------------- Any given=20=0D=0A>> program, when running,= is obsolete.=0D=0A>> _______________________________________________=0D=0A= >> Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>> https://www.ietf.org/m= ailman/listinfo/ecrit=0D=0A>>=20=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= =2E=0D=0A>> If you have received it in error, please notify the sender=20=0D= =0A>immediately=20=0D=0A>> and delete the original. Any unauthorized use o= f this email is=20=0D=0A>> prohibited.=0D=0A>> ----------------------------= ----------------------------------=0D=0A>> --------------------------------= --=0D=0A>> [mf2]=0D=0A>>=20=0D=0A>> _______________________________________= ________=0D=0A>> Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>> https://= www.ietf.org/mailman/listinfo/ecrit=0D=0A>>=20=0D=0A>______________________= _________________________=0D=0A>Ecrit mailing list=0D=0A>Ecrit@ietf.org=0D=0A= >https://www.ietf.org/mailman/listinfo/ecrit=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 information.= =20=0D=0AIf you have received it in error, please notify the sender=0D=0Ai= mmediately and delete the original. Any unauthorized use of=0D=0Athis emai= l is prohibited.=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0A[mf2]=0D=0A Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297733A6914 for ; Mon, 23 Feb 2009 23:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x91MV7KUe9TE for ; Mon, 23 Feb 2009 23:14:06 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4C9C13A679C for ; Mon, 23 Feb 2009 23:14:05 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1O7EIIl005460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Feb 2009 08:14:18 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1O7EIC8015381; Tue, 24 Feb 2009 08:14:18 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 08:14: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 Date: Tue, 24 Feb 2009 09:15:16 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450112E84F@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmTeF5Dl31nt99SQqiNTStSkM555AAA4a8WAIskkHAAALu1AAAQ3aW7ABgwGwA= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><003901c98772$b4cc7710$0201a8c0@nsnintra.net><00a701c99375$757e2db0$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D674A4C6D3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3D3C75174CB95F42AD6BCC56E5555B450112E43C@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Winterbottom, James" , "ext DRAGE, Keith (Keith)" , "Randall Gellens" , "Hannes Tschofenig" , "Edge,Stephen" , "ECRIT" X-OriginalArrivalTime: 24 Feb 2009 07:14:18.0289 (UTC) FILETIME=[81E91A10:01C9964F] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:14:08 -0000 I agree with your statement, James.=20 =20 >-----Original Message----- >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 >Sent: 23 February, 2009 21:48 >To: Tschofenig, Hannes (NSN - FI/Espoo); ext DRAGE, Keith=20 >(Keith); Randall Gellens; Hannes Tschofenig; Edge,Stephen; ECRIT >Subject: RE: [Ecrit] Comments on Framework Draft > >Actually Hannes, I think it is an network architecture difference. > >IMS REQUIRES the access and service providers to have a direct=20 >business relationship in the form or a roaming agreement. This=20 >serves to provide connectivity between the location function=20 >in the access network and the call server. This happens=20 >whether you are talking control-plane or user-plane. > >The linkage between access and service in IMS is largely=20 >artificial, as Keith points out, it is done for financial=20 >reasons rather than technical merit. So the real question that=20 >is being asked, is whether ECRIT is appropriate to=20 >architectures that do not make a formal separation between=20 >access and application. I would argue that yes, ECRIT will=20 >work in those environment but that the converse is likely not=20 >the case without considerable trouble. > >Cheers >James > > >-----Original Message----- >From: Tschofenig, Hannes (NSN - FI/Espoo)=20 >[mailto:hannes.tschofenig@nsn.com] >Sent: Mon 2/23/2009 5:59 AM >To: ext DRAGE, Keith (Keith); Winterbottom, James; Randall=20 >Gellens; Hannes Tschofenig; Edge,Stephen; ECRIT >Subject: RE: [Ecrit] Comments on Framework Draft >=20 >Hi all,=20 > >I believe it does not make a lot of sense to use the ECRIT=20 >mailing list to speculate about the success or failure of IMS.=20 > >What matters at this point is trying to figure out what Randy=20 >and Stephen are actually trying to tell us. I suspect that it=20 >boils down to a few issues but so far I was not able to=20 >capture them correctly.=20 > >I suspect that most of the discussion actually relates to=20 >location rather than to the emergency services architecture as=20 >such. To me this appears to be the SUPL vs. other location=20 >protocol story. > >Ciao >Hannes > >PS: Keith, I liked this statement:=20 >"You wish to offer IMS ***according to 3GPP standards***,=20 >whether you are DSL, 3G, 4G or whatever, then you follow=20 >***the IMS standards*** which lays down a specific=20 >architecture for handling emergency calls. >" > >This sounds like: "If you want to follow the 3GPP IMS=20 >standards then follow the 3GPP IMS standards." > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of ext DRAGE, Keith (Keith) >>Sent: 23 February, 2009 13:25 >>To: Winterbottom, James; Randall Gellens; Hannes Tschofenig;=20 >>Edge,Stephen; ECRIT >>Subject: Re: [Ecrit] Comments on Framework Draft >> >>My understanding so far is that it is an IMS issue, rather than=20 >>directly an access technology one. >> >>You wish to offer IMS according to 3GPP standards, whether=20 >you are DSL,=20 >>3G, 4G or whatever, then you follow the IMS standards which=20 >lays down a=20 >>specific architecture for handling emergency calls. >> >>If you want to offer SIP over 3G or 4G not in accordance with=20 >IMS, then=20 >>you can do what you like in terms of the emergency calling as well. >> >>Further, I suspect that the operator does not have complete=20 >freedom of=20 >>choice, because the operator will not be able to negotiate the=20 >>appropriate roaming agreements if they go the path you are=20 >suggesting.=20 >>And roaming agreements for some strange financial reason which I can=20 >>well understand IETF failing to appreciate are important to these=20 >>operators. >> >>regards >> >>Keith >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf >>> Of Winterbottom, James >>> Sent: Friday, February 20, 2009 4:54 PM >>> To: Randall Gellens; Hannes Tschofenig; Edge, Stephen; ECRIT >>> Subject: Re: [Ecrit] Comments on Framework Draft >>>=20 >>> I actually don't see what benefit adding this statement does to the=20 >>> document. >>> I do however see some harm in providing. >>>=20 >>> If as a potential 3G or 4G operator I wish to offer a broadband=20 >>> service and, rather than providing a SUPL service I wish to provide=20 >>> some other service so that it is compatible with ECRIT, then >>I can't, >>> because ECRIT has a clear applicability statement saying that it is=20 >>> not appropriate. >>>=20 >>> If operators of cellular networks wish to continue to deploy >>networks >>> based on 3GPP architectures then are entitled to do so. It would=20 >>> however, be doing them a disservice to suggest that there is not a=20 >>> viable alternative. >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org on behalf of Randall Gellens >>> Sent: Fri 2/20/2009 10:28 AM >>> To: Hannes Tschofenig; 'Randall Gellens'; 'Edge, Stephen'; 'ECRIT' >>> Subject: Re: [Ecrit] Comments on Framework Draft >>> =20 >>> Hi Hannes, >>>=20 >>> At 6:08 PM +0200 2/20/09, Hannes Tschofenig wrote: >>>=20 >>> > >Since the reality is that cellular emergency calling uses >>> >>different protocols and procedures, in the interest of=20 >clarity and=20 >>> >>avoiding misunderstandings, it seems a good idea for this >>> document to >>> >>have an applicability statement that says, in effect, "Cellular=20 >>> >>networks work differently than what is described here"? Doing so=20 >>> >>wouldn't in any way detract from, or be a demerit on, the=20 >solution=20 >>> >>described here, it would simply clarify reality. >>> > >>> > Some organizations think that cellular networks are=20 >different and=20 >>> > hence they need completely different protocols and procedures. >>> > Example: WAP >>> > >>> > I am not sure that many folks in the RAI area share the=20 >same view. >>>=20 >>> Putting aside the question of what cellular networks >>*should* use, the >>> issue is: what *will* they use. Given that there is a large >>installed >>> base and momentum for current protocols, I think it's >>unreasonable to >>> expect that cellular networks will ditch what they have in favor of=20 >>> what's here (especially in view of the specific issues that Stephen=20 >>> raised). Hence, to avoid confusion, it makes sense for this >>document >>> to say that cellular networks use different protocols and=20 >procedures. >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for=20 >>> myself only >>> -------------- Randomly selected tag: --------------- Any given=20 >>> program, when running, is obsolete. >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=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 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >> > > >--------------------------------------------------------------- >--------------------------------- >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] > > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C4F3A6982 for ; Tue, 24 Feb 2009 06:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd+L9nWryBrS for ; Tue, 24 Feb 2009 05:59:59 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7B80C3A6966 for ; Tue, 24 Feb 2009 05:59:59 -0800 (PST) Received: from col-dhcp33-244-189.bbn.com ([128.33.244.189]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LbxpW-0005c1-DE for ecrit@ietf.org; Tue, 24 Feb 2009 09:00:14 -0500 Message-ID: <49A3FD6D.9010805@bbn.com> Date: Tue, 24 Feb 2009 09:00:13 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-rough-loc-02] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:00:00 -0000 In anticipation of the virtual interim, here's a new draft of rough-loc. -- Added a requirement that the rough location MUST contain the precise location of the endpoint (when known) -- Added considerations for civic addresses -- Extended security considerations to note the necessity of URIs that allow PSAPs to access precise location -- Fixed several editorial nits -------- Original Message -------- Subject: New Version Notification for draft-barnes-ecrit-rough-loc-02 Date: Mon, 23 Feb 2009 19:22:51 -0800 (PST) From: IETF I-D Submission Tool To: rbarnes@bbn.com CC: mlepinski@bbn.com A new version of I-D, draft-barnes-ecrit-rough-loc-02.txt has been successfuly submitted by Richard Barnes and posted to the IETF repository. Filename: draft-barnes-ecrit-rough-loc Revision: 02 Title: Using Imprecise Location for Emergency Context Resolution Creation_date: 2009-02-24 WG ID: Independent Submission Number_of_pages: 14 Abstract: Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. The IETF Secretariat. Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322133A6A1E; Tue, 24 Feb 2009 13:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+bY+kj+w9EK; Tue, 24 Feb 2009 13:10:04 -0800 (PST) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by core3.amsl.com (Postfix) with ESMTP id 3CC3B3A6981; Tue, 24 Feb 2009 13:10:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-170.messagelabs.com!1235509821!16311231!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 7637 invoked from network); 24 Feb 2009 21:10:22 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-170.messagelabs.com with AES256-SHA encrypted SMTP; 24 Feb 2009 21:10:22 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n1OLAKhI012039; Tue, 24 Feb 2009 16:10:21 -0500 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 24 Feb 2009 16:10:16 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 02/24/2009 04:12:40 PM, Serialize complete at 02/24/2009 04:12:40 PM Content-Type: multipart/alternative; boundary="=_alternative 00744BD985257567_=" Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:10:07 -0000 This is a multipart message in MIME format. --=_alternative 00744BD985257567_= Content-Type: text/plain; charset="US-ASCII" James Some of this is editorial, some is substantive and technical, and some repeats my comments on 00 that do not seem to have been addressed. 2nd paragraph of section 1, this sentence doesn't make sense. " Within controlled environments, such as an IMS infrastructure or Emergency Services network (ESInet), where misuse can be reduced to a minimum where possible, this namespace is to be to provide an explicit priority indication facilitates treatment of emergency SIP messages according to local policy." Perhaps you mean " Within controlled environments, such as an IMS infrastructure or Emergency Services network (ESInet), where misuse can be reduced to a minimum, this namespace is expected to be used to provide an explicit priority indication, facilitating treatment of emergency SIP messages according to local policy." But I am not sure if that is what you meant. Same para "This indication is used to differentiate SIP requests, or dialogs, from other requests or dialogs that do not have the need for priority treatment." sounds as if you are differentiating SIP requests form non-SIP requests. Perhaps what you mean is "This indication is used to differentiate Emergency Services related SIP requests, or dialogs, from other (non Emergency Services related) SIP requests or dialogs. Note that "do not have the need for priority treatment" is not correct. The esnet RPH would distinguish ES related messages from GETS related messages (ets and wps namespaces), but they would each get their own particular flavor of "priority treatment". 5th para of section 1 "From this fact about RFC 4412, and the possibility that within emergency services networks, a Multilevel Precedence and Preemption (MLPP)-like behavior can be achieved - ensuring more important calls are established or retained, the "esnet" namespace is given 5 priority-levels." What is "this fact"? Perhaps "Because we can't add new values later..." I don't understand the "can be achieved". Do you mean "MLPP-like behavior may be desired"? I fully agree with assigning 5 levels, and the underlying logic. It is only the description that is problematic. Perhaps "Because we can't add new values later, and because Multilevel Precedence and Preemption (MLPP)-like behavior may be desired the "esnet" namespace is given 5 priority-levels." 2nd to last paragraph of section 1 "Within the ESINet, there will be emergency calls requiring different treatments, according to the type of call. " We don't know if they will require different treatment or not. I would prefer "Within the ESINet, there may be emergency calls requiring different treatments, according to the type of call. " or if the use of "may" will be confused with normative language, "Within the ESINet, there could be emergency calls requiring different treatments, according to the type of call. " This sentence at the end of sec 1 doesn't quite work. "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just of those from citizens to PSAPs." (no clear antecedent for "those") Perhaps "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just for calls or sessions from citizens to PSAPs." (same comment applied to 00) Section 2 first para says "This document updates the behaviors of the SIP Resource Priority header, defined in [RFC4412], during the treatment options surrounding this new "esnet" namespace only. The usage of the "esnet" namespace does not have a normal, or routine call level. Every use of this namespace will be in times of an emergency, where at least one end of the signaling is with a local emergency organization." I don't see this as an "update of the behavior of 4412". Neither the ets namespace not the wps namespace have a "normal" or "routine" call level. Every use of the wps and ets namespaces will have priority over calls without RPH. Suggest changing text to say " Like the ets and wps namespaces defined in [RFC4412], the "esnet" namespace does not have a normal, or routine call level. Every use of this namespace will be in times of an emergency, where at least one end of the signaling is with a local emergency organization." Section 2, para immediately below Figure 1 " Because the more important usage of the "esnet" namespace occurs within the ESInet, the edge proxy, called an Emergency Services Routing Proxy (ESRP) can modify or delete this namespace. This is a normative change to the allowed behavior within [RFC4412], but MUST only be considered valid in this usage at the ESInet boundary for this one RP namespace (and associated priority-value). " I have major (content, not editorial) concerns with this, more for what it says about 4412 than about esnet First of all, it is not clear to me why this is "a normative change to the allowed behavior within [RFC4412]". For one thing I see nothing in 4412 that would prohibit a "SIP actor that understands the name space" from modifying or deleting the namespace. It is certainly anticipated that at least some of the namespaces described in 4412 will be modified or deleted, (e.g., when there is reason to believe it is unauthorized). 4412 says "Existing implementations of RFC 3261 that do not participate in the resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message". " But I do not see anywhere that is says that a UAS that DOES understand the namespace is forbidden from deleting it. For instance, sec 4.7.1 of 4412 says that "the UAC MAY attempt a subsequent request with the same or different resource value." This certainly implies the ability to overwrite or delete an RPH namespace. (See also, for instance the PTSC SAC document on the use of the ets and wps namespaces.) I would suggest rewording this to say " Because the more important usage of the "esnet" namespace occurs within the ESInet, the edge proxy, called an Emergency Services Routing Proxy (ESRP) can modify or delete this namespace. This is consistent with [RFC4412]. " Section 3.2,para after the relative priority order. " The "esnet" namespace will be assigned into the priority queuing algorithm (Section 4.5.2 of [RFC4412]) from the public user to the PSAP. This does not limit its usage to only the priority queue algorithm; meaning the preemption algorithm can be used where the local jurisdiction preferred to preempt normal calls in lieu of completing emergency calls. This document is not RECOMMENDING this usage, merely pointing out those behaviors are a matter of local policy." My concern here is the reference to "preempt normal calls". Since you have already said that there is no "normal" level in the esnet priority value set, I have to assume that you mean "preempt calls with no RPH" (or perhaps "preempt calls with a different RPH namespace"). This WOULD BE a normative change to 4412, which says in 4.7.2.1 "A UAS compliant with this specification MUST terminate a session established with a valid namespace and lower-priority value in favor of a new session set up with a valid namespace and higher relative priority value, unless local policy has some form of call-waiting capability enabled." Note that the only sessions that can be preempted are ones "with a valid namespace and a lower priority value". A "normal" call has neither a "valid namespace", nor a "priority value" (higher or lower), and thus cannot be preempted under 4412. Furthermore, RFC4411 (which focuses on "preemption") repeatedly refers to the pre-empted call/session having an RPH with a lower priority value. The circuit switched versions of preemption ( both MLPP for landlines, and 3GPP e-MLPP for GSM) are even more restrictive. In those schemes, a call can only preempt a lower priority call IN THE SAME PREEMPTION DOMAIN (there is a rough correspondence between "preemption domain" and "RPH namespace"). So I take serious objection to any suggestion of preempting "normal" calls. If you want to have high priority esnet calls preempt low priority esnet calls, I don't object as strenuously. (But no preempting "normal" calls.) Section 5, 3rd para " A simple means of preventing this usage is to not allow marked traffic preferential treatment unless the destination is towards the local/regional ESInet. " This seems to contradict the text in section 1 "This new namespace can be used for inbound calls to PSAPs, between PSAPs, and between a PSAP and first responders and their organizations." and section 3 " This namespace will also be used for communications between emergency authorities, and MAY be used for emergency authorities calling public citizens. An example of the later is a PSAP operator calling back someone who previously called 9111/112/999 and the communication was terminated before it should have been (in the operator's judgment)." Finally, at IETF 73 you assured me that you would insert strong language pointing to section 8 of RFC4412 addressing the relative priority of the different namespaces. This is to eliminate any possible suggestion (that some people - not me- read into the 00 version) that an esnet namespace would have higher priority than an ets namespace. I find no such reference to section 8 of 4412. Thanks, and please note that I strongly support the creation of the esnet namespace. None of my comment should be interpreted as being "against" esnet. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. "James M. Polk" Sent by: ecrit-bounces@ietf.org 02/19/2009 09:32 PM To "'ECRIT'" cc Subject [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted ECRIT I've just submitted a rev of the "esnet" Resource-Prioriy header draft. I've removed all mention of UAs from the draft, but leave in the possibility for adjacent VSPs to have a trust relationship with the local ESInet and mark these SIP requests accordingly through the VSP's domain. I offer that the ESRP at the ESInet edge will be tasked with mapping the esnet.priority-values from outside the ESInet to the indications used inside the ESInet. The ID gives no guidance on what the priority-values should be in either case - as that is a matter for other documents (and I'd argue - for other SDOs or consortia such as NENA and EENA, though I don't mention either organization in the ID). Comments are welcome James >From: IETF I-D Submission Tool >To: jmpolk@cisco.com >Subject: New Version Notification for > draft-ietf-ecrit-local-emergency-rph-namespace-01 >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST) > > >A new version of I-D, >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been >successfuly submitted by James Polk and posted to the IETF repository. > >Filename: draft-ietf-ecrit-local-emergency-rph-namespace >Revision: 01 >Title: IANA Registering a SIP Resource Priority Header >Namespace for Local Emergency Communications >Creation_date: 2009-02-19 >WG ID: ecrit >Number_of_pages: 7 > >Abstract: >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > > > > >The IETF Secretariat. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 00744BD985257567_= Content-Type: text/html; charset="US-ASCII"
James
Some of this is editorial, some is substantive and technical, and some repeats my comments on 00 that do not seem to have been addressed.

2nd paragraph of section 1, this sentence doesn't make sense.
"   Within controlled environments, such as an IMS infrastructure or
   Emergency Services network (ESInet), where misuse can be reduced to
   a minimum where possible, this namespace is to be to provide an
   explicit priority indication facilitates treatment of emergency SIP
   messages according to local policy."

Perhaps you mean
"   Within controlled environments, such as an IMS infrastructure or
   Emergency Services network (ESInet), where misuse can be reduced to
   a minimum, this namespace is expected to be used to provide an
   explicit priority indication, facilitating treatment of emergency SIP
   messages according to local policy."  But I am not sure if that is what you meant.


Same para
"This indication is used to
   differentiate SIP requests, or dialogs, from other requests or
   dialogs that do not have the need for priority treatment."
sounds as if you are differentiating SIP requests form non-SIP requests.  Perhaps what you mean is
"This indication is used to
   differentiate Emergency Services related  SIP requests, or dialogs, from other (non Emergency
Services related) SIP requests or  dialogs.

Note that "do not have the need for priority treatment" is not correct.  The esnet RPH would
distinguish ES related messages from GETS related messages (ets and wps namespaces), but they
would each get their own particular flavor of "priority treatment".


5th para of section 1

"From this fact about RFC 4412, and the possibility that within
   emergency services networks, a Multilevel Precedence and Preemption
   (MLPP)-like behavior can be achieved - ensuring more important calls
   are established or retained, the "esnet" namespace is given 5
   priority-levels."
What is "this fact"?  Perhaps "Because we can't add new values later..."

I don't understand the "can be achieved".  Do you mean "MLPP-like behavior may be desired"?

I fully agree with assigning 5 levels, and the underlying logic. It is only the description that is problematic.

Perhaps
"Because we can't add new values later, and because  Multilevel Precedence and Preemption
   (MLPP)-like behavior may be desired the "esnet" namespace is given 5 priority-levels."

2nd to last paragraph of section 1
"Within the ESINet, there will be emergency calls requiring different
   treatments, according to the type of call. "
We don't know if they will require different treatment or not.

I would prefer
"Within the ESINet, there may be emergency calls requiring different
   treatments, according to the type of call. "

or if the use of "may" will be confused with normative language,
"Within the ESINet, there could be emergency calls requiring different
   treatments, according to the type of call. "


This sentence at the end of sec 1 doesn't quite work.
"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just
   of those from citizens to PSAPs." (no clear antecedent for "those")

Perhaps
"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just for calls or sessions
    from citizens to PSAPs."
(same comment applied to 00)



Section 2  first para says
 "This document updates the behaviors of the SIP Resource Priority
   header, defined in [RFC4412], during the treatment options
   surrounding this new "esnet" namespace only. The usage of the
   "esnet" namespace does not have a normal, or routine call level.  
   Every use of this namespace will be in times of an emergency, where
   at least one end of the signaling is with a local emergency
   organization."

I don't see this as an "update of the behavior of 4412".  Neither the ets namespace not the wps namespace have a "normal" or "routine" call level.  Every use of the wps and ets namespaces will have priority over calls without RPH.

Suggest changing text to say
"   Like the ets and wps namespaces defined in [RFC4412], the
   "esnet" namespace does not have a normal, or routine call level.
    Every use of this namespace will be in times of an emergency, where
   at least one end of the signaling is with a local emergency
   organization."


Section 2, para immediately below Figure 1
"   Because the more important usage of the
   "esnet" namespace occurs within the ESInet, the edge proxy, called
   an Emergency Services Routing Proxy (ESRP) can modify or delete this
   namespace. This is a normative change to the allowed behavior within
   [RFC4412], but MUST only be considered valid in this usage at the
   ESInet boundary for this one RP namespace (and associated
   priority-value). "

I have major (content, not editorial) concerns with this, more for what it says about 4412 than about esnet


First of all, it is not clear to me why this is "a normative change to the allowed behavior within [RFC4412]".

For one thing I see nothing in 4412 that would prohibit a "SIP actor that understands the name space"
from modifying or deleting the namespace.


It is certainly anticipated that at least some of the namespaces described in 4412 will be
modified or deleted, (e.g., when there is reason to  believe it is unauthorized).

4412 says "Existing implementations of RFC 3261 that do not participate in the
   resource priority mechanism follow the normal rules of RFC 3261,
   Section 8.2.2: "If a UAS does not understand a header field in a
   request (that is, the header field is not defined in this
   specification or in any supported extension), the server MUST ignore
   that header field and continue processing the message". "

But I do not see anywhere that is says that a UAS that DOES understand the namespace is
forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says that "the UAC
   MAY attempt a subsequent request with the same or different resource
   value."  This certainly implies the ability to overwrite or delete an RPH namespace.  (See
also, for instance the PTSC SAC document on the use of the ets and wps namespaces.)

I would suggest rewording this to say
"   Because the more important usage of the
   "esnet" namespace occurs within the ESInet, the edge proxy, called
   an Emergency Services Routing Proxy (ESRP) can modify or delete this
   namespace. This is consistent with [RFC4412]. "




Section 3.2,para after the relative priority order.

"  The "esnet" namespace will be assigned into the priority queuing
   algorithm (Section 4.5.2 of [RFC4412]) from the public user to the
   PSAP.  This does not limit its usage to only the priority queue
   algorithm; meaning the preemption algorithm can be used where the
   local jurisdiction preferred to preempt normal calls in lieu of
   completing emergency calls.  This document is not RECOMMENDING this
   usage, merely pointing out those behaviors are a matter of local
   policy."

My concern here is the reference to "preempt normal calls".  Since you have already said that
there is no "normal" level in the esnet priority value set, I have to assume that you mean
"preempt calls with no RPH" (or perhaps "preempt calls  with a different RPH namespace").

This WOULD BE a normative change to 4412, which says in 4.7.2.1
"A UAS compliant with this specification MUST terminate a session
   established with a valid namespace and lower-priority value in favor
   of a new session set up with a valid namespace and higher relative
   priority value, unless local policy has some form of call-waiting
   capability enabled."

Note that the only sessions that can be preempted are ones "with a valid namespace and a lower
priority value".  A "normal" call has neither a "valid namespace", nor a "priority value"
(higher or lower), and thus cannot be preempted under 4412.

Furthermore, RFC4411 (which focuses on "preemption") repeatedly refers to the pre-empted
call/session having an RPH with a lower priority value.

The circuit switched versions of preemption ( both MLPP for landlines, and 3GPP e-MLPP for GSM)
are even more restrictive.  In those schemes, a call can only preempt a lower priority call IN
THE SAME PREEMPTION DOMAIN (there is a rough correspondence between "preemption domain" and "RPH
namespace").

So I take serious objection to any suggestion of preempting "normal" calls.

If you want to have high priority esnet calls preempt low priority esnet calls, I don't object as
strenuously. (But no preempting "normal" calls.)


Section 5, 3rd para
"  A simple means of preventing this usage is to not allow marked
   traffic preferential treatment unless the destination is towards the
   local/regional ESInet. "

This seems to contradict the text in section 1
"This new namespace can
   be used for inbound calls to PSAPs, between PSAPs, and between a
   PSAP and first responders and their organizations."
and section 3
" This namespace will also be used
   for communications between emergency authorities, and MAY be used
   for emergency authorities calling public citizens.  An example of
   the later is a PSAP operator calling back someone who previously
   called 9111/112/999 and the communication was terminated before it
   should have been (in the operator's judgment)."

Finally, at IETF 73 you assured me that you would insert strong language pointing to section 8 of
RFC4412 addressing the relative priority of the different namespaces.  This is to eliminate any
possible suggestion (that some people - not me- read into the 00 version) that an esnet
namespace would have higher priority than an ets namespace.  I find no such reference to section
8 of 4412.

Thanks, and please note that I strongly support the creation of the esnet namespace.  None of my comment should be interpreted as being "against" esnet.

Janet









This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


"James M. Polk" <jmpolk@cisco.com>
Sent by: ecrit-bounces@ietf.org

02/19/2009 09:32 PM

To
"'ECRIT'" <ecrit@ietf.org>
cc
Subject
[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted





ECRIT

I've just submitted a rev of the "esnet" Resource-Prioriy header draft.

I've removed all mention of UAs from the draft, but leave in the
possibility for adjacent VSPs to have a trust relationship with the
local ESInet and mark these SIP requests accordingly through the
VSP's domain.  I offer that the ESRP at the ESInet edge will be
tasked with mapping the esnet.priority-values from outside the ESInet
to the indications used inside the ESInet.  The ID gives no guidance
on what the priority-values should be in either case - as that is a
matter for other documents (and I'd argue - for other SDOs or
consortia such as NENA and EENA, though I don't mention either
organization in the ID).

Comments are welcome

James

>From: IETF I-D Submission Tool <idsubmission@ietf.org>
>To: jmpolk@cisco.com
>Subject: New Version Notification for
>          draft-ietf-ecrit-local-emergency-rph-namespace-01
>Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
>
>
>A new version of I-D,
>draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been
>successfuly submitted by James Polk and posted to the IETF repository.
>
>Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
>Revision:       01
>Title:          IANA Registering a SIP Resource Priority Header
>Namespace for Local Emergency Communications
>Creation_date:  2009-02-19
>WG ID:          ecrit
>Number_of_pages: 7
>
>Abstract:
>This document creates and IANA registers the new Session Initiation
>Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
>local emergency usage to a public safety answering point (PSAP),
>between PSAPs, and between a PSAP and first responders and their
>organizations.
>
>
>
>
>The IETF Secretariat.

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--=_alternative 00744BD985257567_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C893A67B2 for ; Tue, 24 Feb 2009 19:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDo66uGY2ohx for ; Tue, 24 Feb 2009 19:23:58 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 76D733A68FF for ; Tue, 24 Feb 2009 19:23:53 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFL0022DQS6HW@szxga01-in.huawei.com> for ecrit@ietf.org; Wed, 25 Feb 2009 11:24:06 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFL004BDQS655@szxga01-in.huawei.com> for ecrit@ietf.org; Wed, 25 Feb 2009 11:24:06 +0800 (CST) Received: from [10.85.203.87] by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFL00FZ9QS6RS@szxml04-in.huawei.com> for ecrit@ietf.org; Wed, 25 Feb 2009 11:24:06 +0800 (CST) Date: Wed, 25 Feb 2009 11:24:06 +0800 From: Robins George To: ECRIT IETF Message-id: <49A4B9D6.9040805@huawei.com> Organization: Huawei Technologies Co. Ltd MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Subject: [Ecrit] draft-george-ecrit-lamp-post-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:23:58 -0000 Hi All, I have submitted a draft which describes an extension to civic location format and adds new element PN (pole number). PN carries utility and lamp post number information which can identify a civic location. http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00 Comments are appreciated. Regards, Robins. -- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B2A3A6A07 for ; Tue, 24 Feb 2009 19:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH280vfooSBj for ; Tue, 24 Feb 2009 19:56:31 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4C0423A69BA for ; Tue, 24 Feb 2009 19:56:31 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_24_22_16_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Feb 2009 22:16:23 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 21:56:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 21:56:48 -0600 Message-ID: In-Reply-To: <49A4B9D6.9040805@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-george-ecrit-lamp-post-00] Thread-Index: AcmW+I5jS2UNGmJ0SzCe6mCWqB0oCQABEtgw References: <49A4B9D6.9040805@huawei.com> From: "Winterbottom, James" To: , "ECRIT IETF" X-OriginalArrivalTime: 25 Feb 2009 03:56:50.0128 (UTC) FILETIME=[1644F500:01C996FD] Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:56:32 -0000 A couple of things.=0D=0A=0D=0AFirst this should be posted to geopriv and e= crit.=0D=0A=0D=0ASecondly, could these not be covered by the LOC and landma= rk fields=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A-----Original Message-= ----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On B= ehalf=0D=0AOf Robins George=0D=0ASent: Wednesday, 25 February 2009 2:24 PM=0D= =0ATo: ECRIT IETF=0D=0ASubject: [Ecrit] draft-george-ecrit-lamp-post-00]=0D= =0A=0D=0AHi All,=0D=0A=0D=0AI have submitted a draft which describes an ext= ension to civic location=20=0D=0Aformat and=0D=0Aadds new element PN (pole = number). PN carries utility and lamp post=0D=0Anumber=0D=0Ainformation whic= h can identify a civic location.=0D=0A=0D=0Ahttp://tools.ietf.org/html/draf= t-george-ecrit-lamp-post-00=0D=0A=0D=0AComments are appreciated.=0D=0A=0D=0A= Regards,=0D=0ARobins.=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A = =20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A--=20=0D=0A=0D=0A___= ____________________________________________=0D=0AEcrit mailing list=0D=0AE= crit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0AThis message is for the designated recipient only= and may=0D=0Acontain privileged, proprietary, or otherwise private 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 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE973A67DD for ; Tue, 24 Feb 2009 20:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7ttuJXHjOg2 for ; Tue, 24 Feb 2009 20:00:10 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1A6C93A67CF for ; Tue, 24 Feb 2009 20:00:09 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_24_22_20_02 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Feb 2009 22:20:02 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 22:00:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 22:00:28 -0600 Message-ID: In-Reply-To: <49A4B9D6.9040805@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-george-ecrit-lamp-post-00] Thread-Index: AcmW+I5jS2UNGmJ0SzCe6mCWqB0oCQABLA5g References: <49A4B9D6.9040805@huawei.com> From: "Winterbottom, James" To: , "ECRIT IETF" X-OriginalArrivalTime: 25 Feb 2009 04:00:29.0336 (UTC) FILETIME=[98ED7180:01C996FD] Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 04:00:11 -0000 Further to that.=0D=0AIf you do require to have additional fields, then it = would be much=0D=0Acleaner create a new namespace for the extra elements th= at you require,=0D=0Aand then add this to your civic structure.=0D=0A=0D=0A= I will send an example when I get a spare few minutes.=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounc= es@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Robins George=0D= =0ASent: Wednesday, 25 February 2009 2:24 PM=0D=0ATo: ECRIT IETF=0D=0ASubje= ct: [Ecrit] draft-george-ecrit-lamp-post-00]=0D=0A=0D=0AHi All,=0D=0A=0D=0A= I have submitted a draft which describes an extension to civic location=20=0D= =0Aformat and=0D=0Aadds new element PN (pole number). PN carries utility an= d lamp post=0D=0Anumber=0D=0Ainformation which can identify a civic locatio= n.=0D=0A=0D=0Ahttp://tools.ietf.org/html/draft-george-ecrit-lamp-post-00=0D= =0A=0D=0AComments are appreciated.=0D=0A=0D=0ARegards,=0D=0ARobins.=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A =20=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A--=20=0D=0A=0D=0A_____________________________________= __________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.iet= f.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------------------= -------------------------------------------------------------=0D=0AThis mes= sage is for the designated recipient only and may=0D=0Acontain privileged, = proprietary, or otherwise private information. =20=0D=0AIf you have receive= d it in error, please notify the sender=0D=0Aimmediately and delete the ori= ginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------= ---------------------------------------------------------------------------= --------------=0D=0A[mf2]=0D=0A Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66BDF28C19C for ; Wed, 25 Feb 2009 09:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzTZOcwgzpE0 for ; Wed, 25 Feb 2009 09:15:59 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 7720D28C247 for ; Wed, 25 Feb 2009 09:15:59 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1PHGIe8018520 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Feb 2009 18:16:18 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 25 Feb 2009 18:16:18 +0100 From: "DRAGE, Keith (Keith)" To: ECRIT Date: Wed, 25 Feb 2009 18:16:17 +0100 Thread-Topic: ECRIT interim meeting Thread-Index: AcmXazTenS7wUGfMRK6q60QME7uaMg== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A8C82D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [Ecrit] ECRIT interim meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:16:00 -0000 Can you put out an email that has all the details of this interim meeting i= n the same message, i.e. - date and time - agenda - bridge details - any registration details So far what I have seen seems to be split across multiple mails, and I don'= t believe I have even seen direct confirmation it is actually happening. Keith= Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBCC3A68CB for ; Wed, 25 Feb 2009 09:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kreoWWIFkIJ for ; Wed, 25 Feb 2009 09:25:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5B08F3A687A for ; Wed, 25 Feb 2009 09:25:23 -0800 (PST) Received: (qmail invoked by alias); 25 Feb 2009 17:25:37 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp047) with SMTP; 25 Feb 2009 18:25:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+kvUcF5HqkzXuaAp4nkOdTx9ITuMMwL52IAcuLcg MVCXOT6JMTuZZN From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'ECRIT'" References: <28B7C3AA2A7ABA4A841F11217ABE78D674A8C82D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Wed, 25 Feb 2009 19:26:36 +0200 Message-ID: <006401c9976e$373e0d20$2ab5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmXazTenS7wUGfMRK6q60QME7uaMgAAi/cg In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A8C82D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Subject: [Ecrit] REMINDER: ECRIT interim meeting - 26th February, 2:00 PM EST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:25:29 -0000 As distributed a while ago you can find information about the conference call at the ECRIT WG Wiki: http://tools.ietf.org/wg/ecrit/trac/wiki (conference bridge info, agenda, Webex) Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of DRAGE, Keith (Keith) >Sent: 25 February, 2009 19:16 >To: ECRIT >Subject: [Ecrit] ECRIT interim meeting > >Can you put out an email that has all the details of this >interim meeting in the same message, i.e. > >- date and time >- agenda >- bridge details >- any registration details > >So far what I have seen seems to be split across multiple >mails, and I don't believe I have even seen direct >confirmation it is actually happening. > >Keith >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7141A3A6923 for ; Wed, 25 Feb 2009 10:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze7ccrcTzKfq for ; Wed, 25 Feb 2009 10:46:31 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CDA883A6848 for ; Wed, 25 Feb 2009 10:46:30 -0800 (PST) Received: (qmail invoked by alias); 25 Feb 2009 18:46:46 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 25 Feb 2009 19:46:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18aSWIQbZkapd7BjLDc5qZ8XadS2AdM+/4WjlC4j+ yaRWpFJE9AEHYU From: "Hannes Tschofenig" To: "'ECRIT'" Date: Wed, 25 Feb 2009 20:47:46 +0200 Message-ID: <00ab01c99779$8d516ad0$2ab5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmXeYzAy+YFJEnNSsKu3ZSIVh0zGw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Subject: [Ecrit] Slides, Please X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 18:46:32 -0000 Please send me your slides for our phone conference so that I can upload them to the ECRIT wiki page before the meeting starts. Thanks. Ciao Hannes Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C6728C334 for ; Wed, 25 Feb 2009 12:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O6KTrCTiH1C for ; Wed, 25 Feb 2009 12:26:05 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 8D86928C2E2 for ; Wed, 25 Feb 2009 12:26:04 -0800 (PST) Received: by ewy25 with SMTP id 25so297043ewy.37 for ; Wed, 25 Feb 2009 12:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BkpTisnrn/sheNpGNT6sbNEXGDlWGcm/Yv9WMvppAPY=; b=v246bx1uXVr8a6tl/X+JCJsYusftkF4saVYm4KmSmm606PNNqF1fEKYHdTg2oLwD62 feuQE1UqP1B94jxK6hAxC4+BxKej2fja8CNBiBrc4rHACGgnc+FvuZvMrr5WeNeia2do p36vTsd+FIQKjONRXaPjJBH4FaAjQyTSFi+A0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WEU+5rfIjcQuWAmV/JpwZzVqcoiLW+zZ+MhfUFVabJSoMrPYs8NZv7cvzwQesI2UdP 6azS84ftFRoabjPkwe6w9mdm3pUXJYT+VICWnCRoEo9I5GyqtyHLNNli7wHc80lUK2IB TdXKW/naIE9V9kHPrNcVfYRUse82oQMQTDzQE= MIME-Version: 1.0 Received: by 10.220.95.202 with SMTP id e10mr470795vcn.12.1235593583477; Wed, 25 Feb 2009 12:26:23 -0800 (PST) In-Reply-To: References: <49A4B9D6.9040805@huawei.com> Date: Wed, 25 Feb 2009 15:26:23 -0500 Message-ID: From: Karl Heinz Wolf To: "Winterbottom, James" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT IETF Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 20:26:05 -0000 Wouldn't the ADDCODE (Additional Code) element be a good place for the lamp number code? karl heinz On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James wrote: > A couple of things. > > First this should be posted to geopriv and ecrit. > > Secondly, could these not be covered by the LOC and landmark fields? > > Cheers > James > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Robins George > Sent: Wednesday, 25 February 2009 2:24 PM > To: ECRIT IETF > Subject: [Ecrit] draft-george-ecrit-lamp-post-00] > > Hi All, > > I have submitted a draft which describes an extension to civic location > format and > adds new element PN (pole number). PN carries utility and lamp post > number > information which can identify a civic location. > > http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00 > > Comments are appreciated. > > Regards, > Robins. > > > > > > > > > > > > > > -- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------= ----------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. =A0Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------= ----------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D763A6B85; Wed, 25 Feb 2009 16:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiWCEFGSw15r; Wed, 25 Feb 2009 16:40:18 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 472603A6B1B; Wed, 25 Feb 2009 16:40:18 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFN007YTDVGK2@szxga02-in.huawei.com>; Thu, 26 Feb 2009 08:40:28 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFN005J5DVGQC@szxga02-in.huawei.com>; Thu, 26 Feb 2009 08:40:28 +0800 (CST) Received: from [10.85.203.87] by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFN00EDVDVG8P@szxml05-in.huawei.com>; Thu, 26 Feb 2009 08:40:28 +0800 (CST) Date: Thu, 26 Feb 2009 08:40:30 +0800 From: Robins George In-reply-to: To: Karl Heinz Wolf Message-id: <49A5E4FE.3000603@huawei.com> Organization: Huawei Technologies Co. Ltd MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) References: <49A4B9D6.9040805@huawei.com> Cc: GEOPRIV , ECRIT IETF Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 00:40:19 -0000 I 'd prefer using the PIDF-LO IANA procedure for adding a new element for lamp posts. I think that re-using the address code is probably not a particularly good idea. -robins Karl Heinz Wolf wrote: > Wouldn't the ADDCODE (Additional Code) element be a good place for the > lamp number code? > > karl heinz > > On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James > wrote: > >> A couple of things. >> >> First this should be posted to geopriv and ecrit. >> >> Secondly, could these not be covered by the LOC and landmark fields? >> >> Cheers >> James >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Robins George >> Sent: Wednesday, 25 February 2009 2:24 PM >> To: ECRIT IETF >> Subject: [Ecrit] draft-george-ecrit-lamp-post-00] >> >> Hi All, >> >> I have submitted a draft which describes an extension to civic location >> format and >> adds new element PN (pole number). PN carries utility and lamp post >> number >> information which can identify a civic location. >> >> http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00 >> >> Comments are appreciated. >> >> Regards, >> Robins. >> >> >> >> >> Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E8728C178; Wed, 25 Feb 2009 17:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC8PIOwp9MjD; Wed, 25 Feb 2009 17:01:40 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DFA6328C112; Wed, 25 Feb 2009 17:01:39 -0800 (PST) Received: from [128.89.254.78] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LcUdT-0000yn-Dz; Wed, 25 Feb 2009 20:01:59 -0500 Message-ID: <49A5EA06.2080307@bbn.com> Date: Wed, 25 Feb 2009 20:01:58 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: robinsg@huawei.com References: <49A4B9D6.9040805@huawei.com> <49A5E4FE.3000603@huawei.com> In-Reply-To: <49A5E4FE.3000603@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: GEOPRIV , ECRIT IETF Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 01:01:41 -0000 Robins, Given that your use case may be of a more local than global nature, I wonder if it would be appropriate to instead set a local standard that maps to the global (RFC 5139) standard. We've been working on a document that has recommendations for how to do that: --Richard Robins George wrote: > > I 'd prefer using the PIDF-LO IANA procedure for adding a new element > for lamp posts. > I think that re-using the address code is probably not a particularly > good idea. > > -robins > > Karl Heinz Wolf wrote: >> Wouldn't the ADDCODE (Additional Code) element be a good place for the >> lamp number code? >> >> karl heinz >> >> On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James >> wrote: >> >>> A couple of things. >>> >>> First this should be posted to geopriv and ecrit. >>> >>> Secondly, could these not be covered by the LOC and landmark fields? >>> >>> Cheers >>> James >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Robins George >>> Sent: Wednesday, 25 February 2009 2:24 PM >>> To: ECRIT IETF >>> Subject: [Ecrit] draft-george-ecrit-lamp-post-00] >>> >>> Hi All, >>> >>> I have submitted a draft which describes an extension to civic location >>> format and >>> adds new element PN (pole number). PN carries utility and lamp post >>> number >>> information which can identify a civic location. >>> >>> http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00 >>> >>> Comments are appreciated. >>> >>> Regards, >>> Robins. >>> >>> >>> >>> >>> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C537F28C280 for ; Wed, 25 Feb 2009 18:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQKx3TAzsjay for ; Wed, 25 Feb 2009 18:12:38 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 836E43A6BC2 for ; Wed, 25 Feb 2009 18:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1235614380; x=1267150380; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20B rian=20Rosen=20,=20"'ECRIT'"=20|Date:=20Wed,=2025=20Feb=202009=2018:10:51=20-08 00|Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework =20Draft|Thread-Topic:=20[Ecrit]=20Comments=20on=20Framew ork=20Draft|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoX wKeEe+gADZBfMA=3D|Message-ID:=20<1288E74A73964940B132A0B9 EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com>|References: =20<1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04. na.qualcomm.com>=0D=0A=20<0a8d01c991ff$fd063420$f7129c60$ @net>|In-Reply-To:=20<0a8d01c991ff$fd063420$f7129c60$@net >|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5536"=3B=20a=3D"15807688"; bh=S3FVPKrjxosR5XTea53KMrbRscsfOlVLarhLF1IJ9JA=; b=yE6MJ0tZQyMRiJs9nZkCv/7BkZlWyiLcPpVAUh3UjkzRW4x7WLxwpY1q o5bZQuKjPmYZZ8bw9bi3QGQlziI85JBWHVtqWr6lbgCydP6v97tEGMiiF 6fQQmm1ZdSjEsei2AhhqeI17F4CJMDXP4IDNgCPP2BZdLntlWjj47An6y k=; X-IronPort-AV: E=McAfee;i="5300,2777,5536"; a="15807688" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2009 18:12:58 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1Q2CvOk016090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Feb 2009 18:12:58 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1Q2CmLd025684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Feb 2009 18:12:57 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Wed, 25 Feb 2009 18:12:48 -0800 From: "Edge, Stephen" To: Brian Rosen , "'ECRIT'" Date: Wed, 25 Feb 2009 18:10:51 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMA= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <0a8d01c991ff$fd063420$f7129c60$@net> In-Reply-To: <0a8d01c991ff$fd063420$f7129c60$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 02:12:40 -0000 Brian First of all apologies for the likely lateness of this reply - I actually w= rote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems unlik= ely that my VPN, Outlook server and WiFi access capability will cooperate t= ogether to get it sent until I return to the office mid-next week. Anyhow thanks for your comments. There have actually been a number of confe= rence calls between IETF and 3GPP participants over the last couple of year= s at which common features like support of IP emergency calls were discusse= d and these could have been good forum for participants on either side to h= ave raised the kinds of issues you elaborate on below. Given that seems not= so far to have happened, it could still be possible in future such calls. But the issues we are raising are not directly to do with further aligning = the 2 solutions or with the lack of this in the past. We are simply pointin= g out that the solutions are currently different and that from a cellular w= ireless perspective, the Ecrit solution is not seen as suitable in all resp= ects (for support of IP emergency calls originating from such access types)= . That is not just our point of view. 3GPP2 sent a liaison to Ecrit some mo= nths ago pointing out the same issues. So we are proposing that the Ecrit framework and phoneBCP spec.s include a = statement acknowledging this - e.g. by referencing the alternative 3GPP/3GP= P2 solution and indicating the IP access types for which the Ecrit solution= will work without limitation (or equivalently the access types where limit= ations are not ruled out). We are not proposing further modification and extension of the Ecrit soluti= on - just pointing out that this would be needed (as with the 3GPP/3GPP2 so= lution) to fully cover all types of access. Kind Regards=20 Stephen -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, February 18, 2009 8:07 PM To: Edge, Stephen; 'ECRIT' Subject: RE: [Ecrit] Comments on Framework Draft I have bit my tongue on this one for a long time. Stephen, with respect, please go talk to 3GPP management and ask them why there has been no participation in the ecrit effort despite multiple YEARS of begging them to get involved. To put it frankly, 3GPP is quite willing to bully IETF into doing its work on its schedule, but cannot be bothered t= o get work done it knows it will eventually have to do when the IETF asks it to do so. 3GPP understands the mess that is being created by not participating. They know full well that when they finally get around to dealing with PS terminated emergency calls, that there will be a lot of resistance to changing fully specified and implemented standards to more closely align with 3GPP standards. I expect you will have several interworking functions to define and build. So, politely, please go away, we're finishing work we dearly wanted you all to be involved with for years, but you refused to do anything. It's too late for this rev. Now, having said that, there are quite a few people who have participated i= n the IETF work who are IMS aware and I believe that despite your fears, everything you need is in the specs. The mechanisms we have defined provid= e the ability for the network to insert location, recognize and mark emergenc= y calls, and route on behalf of endpoints. An E-CSCF could quite straightforwardly provide a SIP call towards an ecrit compatible PSAP. The only not-quite-nice interwork would be from SUPL to HELD (or SIP), but it's pretty easy to do that. I'll also note that we have tried to get OMA and IETF to cooperate on location protocols, but we have been spectacularly unsuccessful at that effort also. Brian =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Edge, Stephen > Sent: Thursday, February 05, 2009 2:50 AM > To: 'ECRIT' > Subject: [Ecrit] Comments on Framework Draft >=20 > All >=20 > draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative > description of how terminals and networks should support emergency > calls made over IP capable facilities to IP capable PSAPs. It appears > intended to cover all types of access network - including fixed line, > WiFi and cellular (e.g. examples involving each can be found throughout > the draft). >=20 > When we evaluated this with respect to support of wireless cellular > access and WiFi access associated with a cellular operator (e.g. WLAN > or Femto cells integrated into a cellular network), we found that > certain portions of the draft exhibited one or more of the following > characteristics: >=20 > =A0=A0=A0 (A) Inconsistent with already standardized wireless solutions >=20 > =A0=A0=A0 (B) Inconsistent with essential wireless requirements and > conventions >=20 > =A0=A0=A0 (C) Already part of wireless standards or potentially part of > future standards >=20 > (A) refers to all portions of the draft framework that differ from the > requirements and procedures currently standardized for wireless > emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of > solution and could be resolved through support of both solutions by > terminals (with each solution being used according to the type of > access network and VSP) or could be resolved by supporting only one > solution and accessing only the types of network supporting that > solution. To acknowledge this category, the framework document could > reference the applicable wireless standards and point out that these > are valid alternatives for wireless cellular based access. >=20 > (B) refers to portions of the draft that would be unsuitable for > wireless networks even if no alternative solution existed together with > other portions missing from the draft that would be needed to fully > support wireless networks. Examples of the former include: (a) emphasis > on endpoint derivation of location, performance of Lost query and > receipt of local dial strings; (b) restriction of LCPs to protocols > that require terminal initiation (not allowing for network initiation > as far as we can tell) and that include two LCPs (DHCP and LLDP) that > are not applicable to (not defined for) cellular access; and (c) the > requirement that a terminal or at least a LIS will update the PSAP > whenever location changes. (a) is impractical due to network and > terminal loading consequences and failure to support non-IP capable > PSAPs; (b) makes location verification and updated location provision > to PSAPs difficult or impossible; while (c) is also incompatible with > support of existing non-IP capable PSAPs besides increasing terminal > load and possibly interfering with optimum maintenance of the RF > connection (e.g. if a terminal has to tune away from the serving base > station or WLAN periodically to make location measurements). Examples > of the latter include (d) absence of support for access to non-IP > capable PSAPs as already mentioned (e.g. to support E911 phase 2 in the > US); (e) no support for handover from the IP to the circuit domain when > a terminal loses (e.g. moves out of) RF coverage in the IP domain; and > (f) no allowance for limited access modes wherein a terminal may access > a network only to place an emergency call with ensuing restrictions on > (for example) location acquisition, PSAP callback and caller > verification and identification to the PSAP. To resolve this category > either significant changes to the framework document could be made or a > disclaimer/applicability statement could be added stating that support > of cellular wireless networks and their associated WLAN and Femto > access points is not covered. >=20 > Category (C) comprises concepts and capabilities in the draft that are > either already part of the standardized solution for wireless networks > or that might be added at a later time. Examples of the former include > LoST, SIP location conveyance, general use of SIP, location for routing > versus for dispatch, cellular positioning methods. Examples of the > latter include use of location references and dereferencing and > possible interworking between the current wireless network solutions > (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The > presence of this category could be acknowledged by following the > disclaimer for (B) with a statement that certain portions of the > solution are expected to be incorporated into wireless networks now > and/or in the future. >=20 > We hope that these comments will be seen to be a useful addition to > this review in the sense of enabling a more precise scoping for the > framework document and we are willing to assist in providing wording > for any disclaimer/applicability statement that the Ecrit working group > may now deem fit to include. >=20 > Kind Regards >=20 > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm > 3GPP2 TSG-X and TSG-C participant) >=20 > PS this being sent on 2/4/09 at 11:50pm PST >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0128928C2A7 for ; Wed, 25 Feb 2009 18:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NQWil9EETWg for ; Wed, 25 Feb 2009 18:29:47 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 717FB3A6783 for ; Wed, 25 Feb 2009 18:29:47 -0800 (PST) Received: from [128.89.254.78] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LcW0k-0001W0-Fd; Wed, 25 Feb 2009 21:30:07 -0500 Message-ID: <49A5FEAE.6000605@bbn.com> Date: Wed, 25 Feb 2009 21:30:06 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Edge, Stephen" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com> <0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 02:29:49 -0000 Hi Stephen, I'm a little confused by the scope of what you're asking. The framework and phonebcp documents exist in order to describe the ECRIT solution: They say, in effect, "SIP emergency calling works if all parties behave as specified in these documents." As I understand what you're saying (and I'm by no means an expert in 3GPP), 3GPP specifies that one or more elements of this system behave differently. This simply means that 3GPP networks aren't complying with these specs. Just like there's no disclaimer in RFC 791 (IPv4) that says "this doesn't work on X.25 networks", it's not clear to me that an analogous disclaimer is called for here. I presume there are similar documents describing how emergency calling works in 3GPP networks. Do they include notes saying that the 3GPP solution doesn't work in the broader Internet? --Richard Edge, Stephen wrote: > Brian > > First of all apologies for the likely lateness of this reply - I actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems unlikely that my VPN, Outlook server and WiFi access capability will cooperate together to get it sent until I return to the office mid-next week. > > Anyhow thanks for your comments. There have actually been a number of conference calls between IETF and 3GPP participants over the last couple of years at which common features like support of IP emergency calls were discussed and these could have been good forum for participants on either side to have raised the kinds of issues you elaborate on below. Given that seems not so far to have happened, it could still be possible in future such calls. > > But the issues we are raising are not directly to do with further aligning the 2 solutions or with the lack of this in the past. We are simply pointing out that the solutions are currently different and that from a cellular wireless perspective, the Ecrit solution is not seen as suitable in all respects (for support of IP emergency calls originating from such access types). That is not just our point of view. 3GPP2 sent a liaison to Ecrit some months ago pointing out the same issues. > > So we are proposing that the Ecrit framework and phoneBCP spec.s include a statement acknowledging this - e.g. by referencing the alternative 3GPP/3GPP2 solution and indicating the IP access types for which the Ecrit solution will work without limitation (or equivalently the access types where limitations are not ruled out). > > We are not proposing further modification and extension of the Ecrit solution - just pointing out that this would be needed (as with the 3GPP/3GPP2 solution) to fully cover all types of access. > > Kind Regards > > Stephen > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, February 18, 2009 8:07 PM > To: Edge, Stephen; 'ECRIT' > Subject: RE: [Ecrit] Comments on Framework Draft > > I have bit my tongue on this one for a long time. > > Stephen, with respect, please go talk to 3GPP management and ask them why > there has been no participation in the ecrit effort despite multiple YEARS > of begging them to get involved. To put it frankly, 3GPP is quite willing > to bully IETF into doing its work on its schedule, but cannot be bothered to > get work done it knows it will eventually have to do when the IETF asks it > to do so. > > 3GPP understands the mess that is being created by not participating. They > know full well that when they finally get around to dealing with PS > terminated emergency calls, that there will be a lot of resistance to > changing fully specified and implemented standards to more closely align > with 3GPP standards. I expect you will have several interworking functions > to define and build. > > So, politely, please go away, we're finishing work we dearly wanted you all > to be involved with for years, but you refused to do anything. It's too > late for this rev. > > Now, having said that, there are quite a few people who have participated in > the IETF work who are IMS aware and I believe that despite your fears, > everything you need is in the specs. The mechanisms we have defined provide > the ability for the network to insert location, recognize and mark emergency > calls, and route on behalf of endpoints. An E-CSCF could quite > straightforwardly provide a SIP call towards an ecrit compatible PSAP. The > only not-quite-nice interwork would be from SUPL to HELD (or SIP), but it's > pretty easy to do that. I'll also note that we have tried to get OMA and > IETF to cooperate on location protocols, but we have been spectacularly > unsuccessful at that effort also. > > Brian > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Thursday, February 05, 2009 2:50 AM >> To: 'ECRIT' >> Subject: [Ecrit] Comments on Framework Draft >> >> All >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> description of how terminals and networks should support emergency >> calls made over IP capable facilities to IP capable PSAPs. It appears >> intended to cover all types of access network - including fixed line, >> WiFi and cellular (e.g. examples involving each can be found throughout >> the draft). >> >> When we evaluated this with respect to support of wireless cellular >> access and WiFi access associated with a cellular operator (e.g. WLAN >> or Femto cells integrated into a cellular network), we found that >> certain portions of the draft exhibited one or more of the following >> characteristics: >> >> (A) Inconsistent with already standardized wireless solutions >> >> (B) Inconsistent with essential wireless requirements and >> conventions >> >> (C) Already part of wireless standards or potentially part of >> future standards >> >> (A) refers to all portions of the draft framework that differ from the >> requirements and procedures currently standardized for wireless >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of >> solution and could be resolved through support of both solutions by >> terminals (with each solution being used according to the type of >> access network and VSP) or could be resolved by supporting only one >> solution and accessing only the types of network supporting that >> solution. To acknowledge this category, the framework document could >> reference the applicable wireless standards and point out that these >> are valid alternatives for wireless cellular based access. >> >> (B) refers to portions of the draft that would be unsuitable for >> wireless networks even if no alternative solution existed together with >> other portions missing from the draft that would be needed to fully >> support wireless networks. Examples of the former include: (a) emphasis >> on endpoint derivation of location, performance of Lost query and >> receipt of local dial strings; (b) restriction of LCPs to protocols >> that require terminal initiation (not allowing for network initiation >> as far as we can tell) and that include two LCPs (DHCP and LLDP) that >> are not applicable to (not defined for) cellular access; and (c) the >> requirement that a terminal or at least a LIS will update the PSAP >> whenever location changes. (a) is impractical due to network and >> terminal loading consequences and failure to support non-IP capable >> PSAPs; (b) makes location verification and updated location provision >> to PSAPs difficult or impossible; while (c) is also incompatible with >> support of existing non-IP capable PSAPs besides increasing terminal >> load and possibly interfering with optimum maintenance of the RF >> connection (e.g. if a terminal has to tune away from the serving base >> station or WLAN periodically to make location measurements). Examples >> of the latter include (d) absence of support for access to non-IP >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in the >> US); (e) no support for handover from the IP to the circuit domain when >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; and >> (f) no allowance for limited access modes wherein a terminal may access >> a network only to place an emergency call with ensuing restrictions on >> (for example) location acquisition, PSAP callback and caller >> verification and identification to the PSAP. To resolve this category >> either significant changes to the framework document could be made or a >> disclaimer/applicability statement could be added stating that support >> of cellular wireless networks and their associated WLAN and Femto >> access points is not covered. >> >> Category (C) comprises concepts and capabilities in the draft that are >> either already part of the standardized solution for wireless networks >> or that might be added at a later time. Examples of the former include >> LoST, SIP location conveyance, general use of SIP, location for routing >> versus for dispatch, cellular positioning methods. Examples of the >> latter include use of location references and dereferencing and >> possible interworking between the current wireless network solutions >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The >> presence of this category could be acknowledged by following the >> disclaimer for (B) with a statement that certain portions of the >> solution are expected to be incorporated into wireless networks now >> and/or in the future. >> >> We hope that these comments will be seen to be a useful addition to >> this review in the sense of enabling a more precise scoping for the >> framework document and we are willing to assist in providing wording >> for any disclaimer/applicability statement that the Ecrit working group >> may now deem fit to include. >> >> Kind Regards >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm >> 3GPP2 TSG-X and TSG-C participant) >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258413A699E for ; Wed, 25 Feb 2009 20:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V-dX6GJFcOv for ; Wed, 25 Feb 2009 20:47:59 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 834CC3A696D for ; Wed, 25 Feb 2009 20:47:41 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_02_25_23_07_36 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Feb 2009 23:07:35 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 22:48:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Feb 2009 22:47:59 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoA== References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , "Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 26 Feb 2009 04:48:02.0023 (UTC) FILETIME=[67ACAF70:01C997CD] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:48:01 -0000 Hi Stephen,=0D=0A=0D=0AIt is a pity that you were not in the NENA location = WG meeting in Orlando last week, as we had a very pertinent example put for= ward.=0D=0A=0D=0AThe example was a guy with a CDMA EVDO capable device, he = is able to establish a VPN connection back into his corporate network and t= hen make VoIP calls. The gentleman in question claims that he does this reg= ularly. If he were to make an emergency call would it be following the ECRI= T or 3GPP2 call flows=3F=0D=0A=0D=0AThe answer is that the call flow follow= s the ECRIT flow but the access is CDMA EVDO, clearly 3GPP2, and clearly ce= llular! Ipso facto ECRIT on cellular works!=0D=0A=0D=0AI don't believe that= anybody that understands the ECRIT architecture and has a notion of what p= roducts are being sold and used today can seriously suggest that the ECRIT = architecture doesn't work for a cellular network. The fact that home router= s with 3G Internet connections are being sold is an indicator that the 3G s= ervice is just another access to the Internet and that VoIP over 3G is bein= g used and that ECRIT over 3G is quite possible.=0D=0A=0D=0APerhaps it woul= d be pertinent at this time to ask precisely which bits of the ECRIT archit= ecture you feel are unworkable in a 3GPP/2 network=3F=0D=0A=0D=0ACheers=0D=0A= James=0D=0A=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen=0D= =0ASent: Thursday, 26 February 2009 1:11 PM=0D=0ATo: Brian Rosen; 'ECRIT'=0D= =0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0ABrian=0D=0A=0D= =0AFirst of all apologies for the likely lateness of this reply - I actuall= y wrote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems un= likely that my VPN, Outlook server and WiFi access capability will cooperat= e together to get it sent until I return to the office mid-next week.=0D=0A=0D= =0AAnyhow thanks for your comments. There have actually been a number of co= nference calls between IETF and 3GPP participants over the last couple of y= ears at which common features like support of IP emergency calls were discu= ssed and these could have been good forum for participants on either side t= o have raised the kinds of issues you elaborate on below. Given that seems = not so far to have happened, it could still be possible in future such call= s.=0D=0A=0D=0ABut the issues we are raising are not directly to do with fur= ther aligning the 2 solutions or with the lack of this in the past. We are = simply pointing out that the solutions are currently different and that fro= m a cellular wireless perspective, the Ecrit solution is not seen as suitab= le in all respects (for support of IP emergency calls originating from such= access types). That is not just our point of view. 3GPP2 sent a liaison to= Ecrit some months ago pointing out the same issues.=0D=0A=0D=0ASo we are p= roposing that the Ecrit framework and phoneBCP spec.s include a statement a= cknowledging this - e.g. by referencing the alternative 3GPP/3GPP2 solution= and indicating the IP access types for which the Ecrit solution will work = without limitation (or equivalently the access types where limitations are = not ruled out).=0D=0A=0D=0AWe are not proposing further modification and ex= tension of the Ecrit solution - just pointing out that this would be needed= (as with the 3GPP/3GPP2 solution) to fully cover all types of access.=0D=0A=0D= =0AKind Regards=20=0D=0A=0D=0AStephen=0D=0A-----Original Message-----=0D=0A= From: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, Febru= ary 18, 2009 8:07 PM=0D=0ATo: Edge, Stephen; 'ECRIT'=0D=0ASubject: RE: [Ecr= it] Comments on Framework Draft=0D=0A=0D=0AI have bit my tongue on this one= for a long time.=0D=0A=0D=0AStephen, with respect, please go talk to 3GPP = management and ask them why=0D=0Athere has been no participation in the ec= rit effort despite multiple YEARS=0D=0Aof begging them to get involved. To= put it frankly, 3GPP is quite willing=0D=0Ato bully IETF into doing its wo= rk on its schedule, but cannot be bothered to=0D=0Aget work done it knows i= t will eventually have to do when the IETF asks it=0D=0Ato do so.=0D=0A=0D=0A= 3GPP understands the mess that is being created by not participating. They=0D= =0Aknow full well that when they finally get around to dealing with PS=0D=0A= terminated emergency calls, that there will be a lot of resistance to=0D=0A= changing fully specified and implemented standards to more closely align=0D= =0Awith 3GPP standards. I expect you will have several interworking functi= ons=0D=0Ato define and build.=0D=0A=0D=0ASo, politely, please go away, we'r= e finishing work we dearly wanted you all=0D=0Ato be involved with for year= s, but you refused to do anything. It's too=0D=0Alate for this rev.=0D=0A=0D= =0ANow, having said that, there are quite a few people who have participate= d in=0D=0Athe IETF work who are IMS aware and I believe that despite your f= ears,=0D=0Aeverything you need is in the specs. The mechanisms we have def= ined provide=0D=0Athe ability for the network to insert location, recognize= and mark emergency=0D=0Acalls, and route on behalf of endpoints. An E-CSC= F could quite=0D=0Astraightforwardly provide a SIP call towards an ecrit co= mpatible PSAP. The=0D=0Aonly not-quite-nice interwork would be from SUPL t= o HELD (or SIP), but it's=0D=0Apretty easy to do that. I'll also note that= we have tried to get OMA and=0D=0AIETF to cooperate on location protocols,= but we have been spectacularly=0D=0Aunsuccessful at that effort also.=0D=0A=0D= =0ABrian=0D=0A=0D=0A =20=0D=0A=0D=0A> -----Original Message-----=0D=0A> Fro= m: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0A> = Of Edge, Stephen=0D=0A> Sent: Thursday, February 05, 2009 2:50 AM=0D=0A> To= : 'ECRIT'=0D=0A> Subject: [Ecrit] Comments on Framework Draft=0D=0A>=20=0D=0A= > All=0D=0A>=20=0D=0A> draft-ietf-ecrit-framework-07 is (as we see it) a mo= stly informative=0D=0A> description of how terminals and networks should su= pport emergency=0D=0A> calls made over IP capable facilities to IP capable = PSAPs. It appears=0D=0A> intended to cover all types of access network - in= cluding fixed line,=0D=0A> WiFi and cellular (e.g. examples involving each = can be found throughout=0D=0A> the draft).=0D=0A>=20=0D=0A> When we evaluat= ed this with respect to support of wireless cellular=0D=0A> access and WiFi= access associated with a cellular operator (e.g. WLAN=0D=0A> or Femto cell= s integrated into a cellular network), we found that=0D=0A> certain portion= s of the draft exhibited one or more of the following=0D=0A> characteristic= s:=0D=0A>=20=0D=0A> =A0=A0=A0 (A) Inconsistent with already standardized wi= reless solutions=0D=0A>=20=0D=0A> =A0=A0=A0 (B) Inconsistent with essential= wireless requirements and=0D=0A> conventions=0D=0A>=20=0D=0A> =A0=A0=A0 (C= ) Already part of wireless standards or potentially part of=0D=0A> future s= tandards=0D=0A>=20=0D=0A> (A) refers to all portions of the draft framework= that differ from the=0D=0A> requirements and procedures currently standard= ized for wireless=0D=0A> emergency access by 3GPP, 3GPP2 and OMA. This is a= plain difference of=0D=0A> solution and could be resolved through support = of both solutions by=0D=0A> terminals (with each solution being used accord= ing to the type of=0D=0A> access network and VSP) or could be resolved by s= upporting only one=0D=0A> solution and accessing only the types of network = supporting that=0D=0A> solution. To acknowledge this category, the framewor= k document could=0D=0A> reference the applicable wireless standards and poi= nt out that these=0D=0A> are valid alternatives for wireless cellular based= access.=0D=0A>=20=0D=0A> (B) refers to portions of the draft that would be= unsuitable for=0D=0A> wireless networks even if no alternative solution ex= isted together with=0D=0A> other portions missing from the draft that would= be needed to fully=0D=0A> support wireless networks. Examples of the forme= r include: (a) emphasis=0D=0A> on endpoint derivation of location, performa= nce of Lost query and=0D=0A> receipt of local dial strings; (b) restriction= of LCPs to protocols=0D=0A> that require terminal initiation (not allowing= for network initiation=0D=0A> as far as we can tell) and that include two = LCPs (DHCP and LLDP) that=0D=0A> are not applicable to (not defined for) ce= llular access; and (c) the=0D=0A> requirement that a terminal or at least a= LIS will update the PSAP=0D=0A> whenever location changes. (a) is impracti= cal due to network and=0D=0A> terminal loading consequences and failure to = support non-IP capable=0D=0A> PSAPs; (b) makes location verification and up= dated location provision=0D=0A> to PSAPs difficult or impossible; while (c)= is also incompatible with=0D=0A> support of existing non-IP capable PSAPs = besides increasing terminal=0D=0A> load and possibly interfering with optim= um maintenance of the RF=0D=0A> connection (e.g. if a terminal has to tune = away from the serving base=0D=0A> station or WLAN periodically to make loca= tion measurements). Examples=0D=0A> of the latter include (d) absence of su= pport for access to non-IP=0D=0A> capable PSAPs as already mentioned (e.g. = to support E911 phase 2 in the=0D=0A> US); (e) no support for handover from= the IP to the circuit domain when=0D=0A> a terminal loses (e.g. moves out = of) RF coverage in the IP domain; and=0D=0A> (f) no allowance for limited a= ccess modes wherein a terminal may access=0D=0A> a network only to place an= emergency call with ensuing restrictions on=0D=0A> (for example) location = acquisition, PSAP callback and caller=0D=0A> verification and identificatio= n to the PSAP. To resolve this category=0D=0A> either significant changes t= o the framework document could be made or a=0D=0A> disclaimer/applicability= statement could be added stating that support=0D=0A> of cellular wireless = networks and their associated WLAN and Femto=0D=0A> access points is not co= vered.=0D=0A>=20=0D=0A> Category (C) comprises concepts and capabilities in= the draft that are=0D=0A> either already part of the standardized solution= for wireless networks=0D=0A> or that might be added at a later time. Examp= les of the former include=0D=0A> LoST, SIP location conveyance, general use= of SIP, location for routing=0D=0A> versus for dispatch, cellular position= ing methods. Examples of the=0D=0A> latter include use of location referenc= es and dereferencing and=0D=0A> possible interworking between the current w= ireless network solutions=0D=0A> (in 3GPP, 3GPP2 and OMA) and the solution = described in this draft. The=0D=0A> presence of this category could be ackn= owledged by following the=0D=0A> disclaimer for (B) with a statement that c= ertain portions of the=0D=0A> solution are expected to be incorporated into= wireless networks now=0D=0A> and/or in the future.=0D=0A>=20=0D=0A> We hop= e that these comments will be seen to be a useful addition to=0D=0A> this r= eview in the sense of enabling a more precise scoping for the=0D=0A> framew= ork document and we are willing to assist in providing wording=0D=0A> for a= ny disclaimer/applicability statement that the Ecrit working group=0D=0A> m= ay now deem fit to include.=0D=0A>=20=0D=0A> Kind Regards=0D=0A>=20=0D=0A> = Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm=0D=0A= > 3GPP2 TSG-X and TSG-C participant)=0D=0A>=20=0D=0A> PS this being sent o= n 2/4/09 at 11:50pm PST=0D=0A>=20=0D=0A> __________________________________= _____________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https:= //www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A__________________________= _____________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttp= s://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------------------------= ------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0423A6BAA; Thu, 26 Feb 2009 04:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGF21dPwamdJ; Thu, 26 Feb 2009 04:35:22 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6C9C83A6A8C; Thu, 26 Feb 2009 04:35:19 -0800 (PST) Received: from 12-198-63-152att-inc.com (12-198-63-152att-inc.com [12.198.63.152] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n1QCZXLF021449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Feb 2009 07:35:35 -0500 (EST) Message-Id: <21744BCF-FF4D-47BB-BA3F-6050998BF4C3@cs.columbia.edu> From: Henning Schulzrinne To: Richard Barnes In-Reply-To: <49A5EA06.2080307@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 07:35:33 -0500 References: <49A4B9D6.9040805@huawei.com> <49A5E4FE.3000603@huawei.com> <49A5EA06.2080307@bbn.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: GEOPRIV , ECRIT IETF Subject: Re: [Ecrit] draft-george-ecrit-lamp-post-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 12:35:23 -0000 Richard, pole numbers are actually fairly common and don't seem to be restricted to a particular country. For example, in New Jersey (where I live), towns are so close together that it is often difficult to tell which one you are in at the moment. The "insider" recommendation is to look at the nearest utility pole; the first two letters correspond to the town name (followed by a unique numeric identifier). Henning On Feb 25, 2009, at 8:01 PM, Richard Barnes wrote: > Robins, > > Given that your use case may be of a more local than global nature, > I wonder if it would be appropriate to instead set a local standard > that maps to the global (RFC 5139) standard. We've been working on > a document that has recommendations for how to do that: > > > > --Richard > > > Robins George wrote: >> I 'd prefer using the PIDF-LO IANA procedure for adding a new >> element for lamp posts. >> I think that re-using the address code is probably not a >> particularly good idea. >> -robins >> Karl Heinz Wolf wrote: >>> Wouldn't the ADDCODE (Additional Code) element be a good place for >>> the >>> lamp number code? >>> >>> karl heinz >>> >>> On Tue, Feb 24, 2009 at 10:56 PM, Winterbottom, James >>> wrote: >>> >>>> A couple of things. >>>> >>>> First this should be posted to geopriv and ecrit. >>>> >>>> Secondly, could these not be covered by the LOC and landmark >>>> fields? >>>> >>>> Cheers >>>> James >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf >>>> Of Robins George >>>> Sent: Wednesday, 25 February 2009 2:24 PM >>>> To: ECRIT IETF >>>> Subject: [Ecrit] draft-george-ecrit-lamp-post-00] >>>> >>>> Hi All, >>>> >>>> I have submitted a draft which describes an extension to civic >>>> location >>>> format and >>>> adds new element PN (pole number). PN carries utility and lamp post >>>> number >>>> information which can identify a civic location. >>>> >>>> http://tools.ietf.org/html/draft-george-ecrit-lamp-post-00 >>>> >>>> Comments are appreciated. >>>> >>>> Regards, >>>> Robins. >>>> >>>> >>>> >>>> >>>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524753A6784; Thu, 26 Feb 2009 11:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WJ0fnBvJbIZ; Thu, 26 Feb 2009 11:38:59 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3D8583A677C; Thu, 26 Feb 2009 11:38:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,272,1233532800"; d="scan'208";a="137879810" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 26 Feb 2009 19:39:21 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1QJdL39028061; Thu, 26 Feb 2009 11:39:21 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n1QJdGhL002045; Thu, 26 Feb 2009 19:39:21 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); Thu, 26 Feb 2009 11:39:17 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.23.24]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 11:39:17 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Feb 2009 13:39:12 -0600 To: Janet P Gunn From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Feb 2009 19:39:17.0319 (UTC) FILETIME=[E96F4D70:01C99849] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16743; t=1235677161; x=1236541161; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-01=0A=20=20submitted |Sender:=20; bh=hiKRKh+o64SI5iTdqQAq/Uc1oFXvEx1GdFtWH5b6kuM=; b=OsLHvsAF5rroWkFutgdujPAyn9j81Co1ndQfzTIkTd+xBJe4jT7Fq8f+mz RghmJ03IWfMIT5BUVpTVkQpRwFc5mUUOOpt7YvZKQsm7aKWdHiYJb8SZ2MBY NKnWQjGBbF; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:39:01 -0000 At 03:10 PM 2/24/2009, Janet P Gunn wrote: >James >Some of this is editorial, some is substantive and technical, and >some repeats my comments on 00 that do not seem to have been addressed. > >2nd paragraph of section 1, this sentence doesn't make sense. >" Within controlled environments, such as an IMS infrastructure or > Emergency Services network (ESInet), where misuse can be reduced to > a minimum where possible, this namespace is to be to provide an > explicit priority indication facilitates treatment of emergency SIP > messages according to local policy." I think this makes perfect sense as written >Perhaps you mean >" Within controlled environments, such as an IMS infrastructure or > Emergency Services network (ESInet), where misuse can be reduced to > a minimum, this namespace is expected to be used to provide an > explicit priority indication, facilitating treatment of emergency SIP > messages according to local policy." But I am not sure if that > is what you meant. that's another way of saying the same thing >Same para >"This indication is used to > differentiate SIP requests, or dialogs, from other requests or > dialogs that do not have the need for priority treatment." >sounds as if you are differentiating SIP requests form non-SIP >requests. Perhaps what you mean is >"This indication is used to > differentiate Emergency Services related SIP requests, or > dialogs, from other (non Emergency >Services related) SIP requests or dialogs. again -- this appears to be two ways of saying the same thing. >Note that "do not have the need for priority treatment" is not correct. it applies to other traffic that does not need priority treatment. In other words, the traffic that doesn't need priority treatment -- because there will be some traffic that does not need priority treatment within the ESInet (as well as an esnet namespace capable VSP) >The esnet RPH would >distinguish ES related messages from GETS related messages (ets and >wps namespaces), but they >would each get their own particular flavor of "priority treatment". > > >5th para of section 1 > >"From this fact about RFC 4412, and the possibility that within > emergency services networks, a Multilevel Precedence and Preemption > (MLPP)-like behavior can be achieved - ensuring more important calls > are established or retained, the "esnet" namespace is given 5 > priority-levels." >What is "this fact"? Perhaps "Because we can't add new values later..." the fact is right above this sentence >I don't understand the "can be achieved". Do you mean "MLPP-like >behavior may be desired"? it can be, which is all that I'm offering -- but I'm not recommending or stipulating or demanding or anything else... I'm just saying that with more than 2 levels, a natural hierarchy _can_ be configured. >I fully agree with assigning 5 levels, and the underlying logic. It >is only the description that is problematic. > >Perhaps >"Because we can't add new values later, and because Multilevel >Precedence and Preemption > (MLPP)-like behavior may be desired the "esnet" namespace is > given 5 priority-levels." that is within 4412 >2nd to last paragraph of section 1 >"Within the ESINet, there will be emergency calls requiring different > treatments, according to the type of call. " >We don't know if they will require different treatment or not. > >I would prefer >"Within the ESINet, there may be emergency calls requiring different > treatments, according to the type of call. " > >or if the use of "may" will be confused with normative language, >"Within the ESINet, there could be emergency calls requiring different > treatments, according to the type of call. " I'm ok with this >This sentence at the end of sec 1 doesn't quite work. >"This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not just > of those from citizens to PSAPs." (no clear antecedent for "those") fair >Perhaps >"This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not > just for calls or sessions > from citizens to PSAPs." >(same comment applied to 00) I'll back off this even more - to "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just for calls or sessions towards PSAPs." >Section 2 first para says > "This document updates the behaviors of the SIP Resource Priority > header, defined in [RFC4412], during the treatment options > surrounding this new "esnet" namespace only. The usage of the > "esnet" namespace does not have a normal, or routine call level. > Every use of this namespace will be in times of an emergency, where > at least one end of the signaling is with a local emergency > organization." > >I don't see this as an "update of the behavior of 4412". Neither >the ets namespace not the wps namespace have a "normal" or "routine" >call level. but either (ets or wps) can simply not be used. here there is no routine esnet calls, every one is an emergency call, and likely every call will be an emergency. >Every use of the wps and ets namespaces will have priority over >calls without RPH. > >Suggest changing text to say >" Like the ets and wps namespaces defined in [RFC4412], the > "esnet" namespace does not have a normal, or routine call level. > Every use of this namespace will be in times of an emergency, where > at least one end of the signaling is with a local emergency > organization." see comment above >Section 2, para immediately below Figure 1 >" Because the more important usage of the > "esnet" namespace occurs within the ESInet, the edge proxy, called > an Emergency Services Routing Proxy (ESRP) can modify or delete this > namespace. This is a normative change to the allowed behavior within > [RFC4412], but MUST only be considered valid in this usage at the > ESInet boundary for this one RP namespace (and associated > priority-value). " > >I have major (content, not editorial) concerns with this, more for >what it says about 4412 than about esnet > > >First of all, it is not clear to me why this is "a normative change >to the allowed behavior within [RFC4412]". because 4412 says "do not modify or delete, just ignore if you don't like it" this doc changes that for esnet only. >For one thing I see nothing in 4412 that would prohibit a "SIP actor >that understands the name space" >from modifying or deleting the namespace. 4.6.2. No Known Namespace or Priority Value If an RP actor does not understand any of the resource values in the request, the treatment depends on the presence of the Require 'resource-priority' option tag: 1. Without the option tag, the RP actor treats the request as if it contained no 'Resource-Priority' header field and processes it with default priority. Resource values that are not understood MUST NOT be modified or deleted. so, evidence to the contrary (from your statement above) >It is certainly anticipated that at least some of the namespaces >described in 4412 will be >modified or deleted, (e.g., when there is reason to believe it is >unauthorized). no, just ignored >4412 says "Existing implementations of RFC 3261 that do not >participate in the > resource priority mechanism follow the normal rules of RFC 3261, > Section 8.2.2: "If a UAS does not understand a header field in a > request (that is, the header field is not defined in this > specification or in any supported extension), the server MUST ignore > that header field and continue processing the message". " What about SIP entities that not only understand RPH, but understand the "esnet" namespace - yet have an incorrect priority-value for that call? That's a problem that needs to be fixed in the ESInet (with use of the esnet). >But I do not see anywhere that is says that a UAS that DOES >understand the namespace is >forbidden from deleting it. see 4.6.2 (quoted above) >For instance, sec 4.7.1 of 4412 says that "the UAC > MAY attempt a subsequent request with the same or different resource > value." This certainly implies the ability to overwrite or > delete an RPH namespace. (See >also, for instance the PTSC SAC document on the use of the ets and >wps namespaces.) > >I would suggest rewording this to say >" Because the more important usage of the > "esnet" namespace occurs within the ESInet, the edge proxy, called > an Emergency Services Routing Proxy (ESRP) can modify or delete this > namespace. This is consistent with [RFC4412]. " > > > > >Section 3.2,para after the relative priority order. > >" The "esnet" namespace will be assigned into the priority queuing > algorithm (Section 4.5.2 of [RFC4412]) from the public user to the > PSAP. This does not limit its usage to only the priority queue > algorithm; meaning the preemption algorithm can be used where the > local jurisdiction preferred to preempt normal calls in lieu of > completing emergency calls. This document is not RECOMMENDING this > usage, merely pointing out those behaviors are a matter of local > policy." > >My concern here is the reference to "preempt normal calls". Since >you have already said that >there is no "normal" level in the esnet priority value set, I have >to assume that you mean >"preempt calls with no RPH" (or perhaps "preempt calls with a >different RPH namespace"). no, I'm leaving open the possibility that perhaps one local jurisdiction wants to use preemption -- kinda like the country of Japan does today (therefore... it needs to be possible, *and* mentioned). > > >This WOULD BE a normative change to 4412, which says in 4.7.2.1 >"A UAS compliant with this specification MUST terminate a session > established with a valid namespace and lower-priority value in favor > of a new session set up with a valid namespace and higher relative > priority value, unless local policy has some form of call-waiting > capability enabled." > >Note that the only sessions that can be preempted are ones "with a >valid namespace and a lower >priority value". A "normal" call has neither a "valid namespace", >nor a "priority value" >(higher or lower), and thus cannot be preempted under 4412. we are not private ESInet network police -- and we shouldn't be so firm in deciding normal calls aren't preempted in one or more local configurations within jurisdictions. >Furthermore, RFC4411 (which focuses on "preemption") repeatedly >refers to the pre-empted >call/session having an RPH with a lower priority value. 4411 is how to indicate to a preempted caller their session has been preempted. I see no reason at this point to include any 4411 reference. For example, if NENA wanted to allow preemption (which I am NOT suggesting), their docs should include this reference and usage of 4411. >The circuit switched versions of preemption ( both MLPP for >landlines, and 3GPP e-MLPP for GSM) >are even more restrictive. In those schemes, a call can only >preempt a lower priority call IN >THE SAME PREEMPTION DOMAIN (there is a rough correspondence between >"preemption domain" and "RPH namespace"). > >So I take serious objection to any suggestion of preempting "normal" calls. respectfully, that's a personal opinion that I question the universal applicability of. Especially given that Japan currently preempts normal calls in lieu of 911 calls. Other jurisdictions *may* have similar or future plans >If you want to have high priority esnet calls preempt low priority >esnet calls, I don't object as >strenuously. (But no preempting "normal" calls.) > > >Section 5, 3rd para >" A simple means of preventing this usage is to not allow marked > traffic preferential treatment unless the destination is towards the > local/regional ESInet. " neither of the quotes below talk about granting preferential treatment across the ESInet ESRP boundary. This comment does. But I can expand on this sentence to clarify this meaning. >This seems to contradict the text in section 1 >"This new namespace can > be used for inbound calls to PSAPs, between PSAPs, and between a > PSAP and first responders and their organizations." >and section 3 >" This namespace will also be used > for communications between emergency authorities, and MAY be used > for emergency authorities calling public citizens. An example of > the later is a PSAP operator calling back someone who previously > called 9111/112/999 and the communication was terminated before it > should have been (in the operator's judgment)." > >Finally, at IETF 73 you assured me that you would insert strong >language pointing to section 8 of >RFC4412 addressing the relative priority of the different >namespaces. This is to eliminate any >possible suggestion (that some people - not me- read into the 00 >version) that an esnet >namespace would have higher priority than an ets namespace. well... I agree I haven't emphasized section 8 of 4412, and can mention this in a generic form when other namespaces are present. Secondly, this document should never insist that esnet is above or below ets or wps. that's a matter of local policy, for example - to within NENA/APCO for whether they believe (and are going to implement to) this. That's for an operational doc that this ID isn't. > I find no such reference to section >8 of 4412. > >Thanks, and please note that I strongly support the creation of the >esnet namespace. None of my comment should be interpreted as being >"against" esnet. > >Janet > > > > > > > > > >This is a PRIVATE message. If you are not the intended recipient, >please delete without copying and kindly advise us by e-mail of the >mistake in delivery. >NOTE: Regardless of content, this e-mail shall not operate to bind >CSC to any order or other contract unless pursuant to explicit >written agreement or government initiative expressly permitting the >use of e-mail for such purpose. > > >"James M. Polk" >Sent by: ecrit-bounces@ietf.org > >02/19/2009 09:32 PM >To >"'ECRIT'" >cc >Subject >[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted > > > > >ECRIT > >I've just submitted a rev of the "esnet" Resource-Prioriy header draft. > >I've removed all mention of UAs from the draft, but leave in the >possibility for adjacent VSPs to have a trust relationship with the >local ESInet and mark these SIP requests accordingly through the >VSP's domain. I offer that the ESRP at the ESInet edge will be >tasked with mapping the esnet.priority-values from outside the ESInet >to the indications used inside the ESInet. The ID gives no guidance >on what the priority-values should be in either case - as that is a >matter for other documents (and I'd argue - for other SDOs or >consortia such as NENA and EENA, though I don't mention either >organization in the ID). > >Comments are welcome > >James > > >From: IETF I-D Submission Tool > >To: jmpolk@cisco.com > >Subject: New Version Notification for > > draft-ietf-ecrit-local-emergency-rph-namespace-01 > >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST) > > > > > >A new version of I-D, > >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been > >successfuly submitted by James Polk and posted to the IETF repository. > > > >Filename: draft-ietf-ecrit-local-emergency-rph-namespace > >Revision: 01 > >Title: IANA Registering a SIP Resource Priority Header > >Namespace for Local Emergency Communications > >Creation_date: 2009-02-19 > >WG ID: ecrit > >Number_of_pages: 7 > > > >Abstract: > >This document creates and IANA registers the new Session Initiation > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > >local emergency usage to a public safety answering point (PSAP), > >between PSAPs, and between a PSAP and first responders and their > >organizations. > > > > > > > > > >The IETF Secretariat. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586BB28C2F3 for ; Thu, 26 Feb 2009 12:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk8XMD049REJ for ; Thu, 26 Feb 2009 12:59:53 -0800 (PST) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id E26843A67A7 for ; Thu, 26 Feb 2009 12:59:52 -0800 (PST) Received: from BLU137-W24 ([65.55.116.72]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 13:00:14 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: Date: Thu, 26 Feb 2009 13:00:14 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Feb 2009 21:00:14.0535 (UTC) FILETIME=[388FA570:01C99855] Subject: [Ecrit] Comments on "Extensions for dealing with Unauthenticated and Unauthorized Devices" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:59:54 -0000 --_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access Section 2 summarizes the status of this document: At the time of writing there is no regulation in place that demands the functionality described in this memo. SDOs have started their work on this subject in a proactive fashion in the anticipation that national regulation will demand it for a subset of network environments. Not only is there no regulation that demands this functionality=2C but ther= e is potential legislation relating to authentication and record keeping that could affect the viability of such a service: http://news.cnet.com/8301-13578_3-10168114-38.html In practice=2C some of these record keeping requirements are already in=20 effect=2C due to the implications of legislation such as Sarbanes Oxley and HIPAA.=20 Given this=2C I'd suggest that the document needs to think more carefully about the requirements for offering such a service. This includes not only the potential (conflicting) regulatory requirements=2C but also some of the security issues. For example=2C in its response to the IEEE 802.11u liaison=2C EMU WG provided a number of questions that needed to be answered= : http://www.ietf.org/mail-archive/web/emu/current/msg00685.html =20 In particular=2C the ISP MUST allow emergency callers to acquire an IP address and to reach a LoST server=2C either provided by the ISP or some third party. It SHOULD also provide location information via one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without requiring authorization unless it can safely assume that all nodes in the access network can determine their own location=2C e.g.=2C via GPS. Given the current state of knowledge=2C and the capabilities of the ISP and enterprise equipment in place=2C we also need to think carefully about=20 normative requirements. For example=2C some of the older WLAN networks may have limited abilities to actively advertise multiple networks (e.g. they may not be able to beacon an Emergency Services network with access restricted as recommended in the document).=20 Also=2C if this work is going to go forward=2C it should probably be coordinated with other IETF WGs such as EMU=2C as well as=20 SDO efforts such as IEEE 802.11u and more recently=2C IEEE 802.21. For example=2C the IEEE 802.21 Emergency Services charter can be found below: https://mentor.ieee.org/802.21/file/08/21-08-0313-03-00es-emergency-service= s-five-criteria.doc =20 --_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access
Section 2 summarizes the status of this document:

 =3B&nbs= p=3B At the time of writing there is no regulation in place that demands =3B =3B the functionality described in this memo. =3B SDOs ha= ve started their
 =3B =3B work on this subject in a proactive fa= shion in the anticipation that
 =3B =3B national regulation will= demand it for a subset of network
 =3B =3B environments.
Not only is there no regulation that demands this functionality=2C but the= re
is potential legislation relating to authentication and record keepin= g that
could affect the viability of such a service:
http://news.cnet= .com/8301-13578_3-10168114-38.html

In practice=2C some of these reco= rd keeping requirements are already in
effect=2C due to the implication= s of legislation such as Sarbanes Oxley
and HIPAA.

Given this=2C= I'd suggest that the document needs to think more carefully
about the r= equirements for offering such a service. =3B This includes not
only = the potential (conflicting) regulatory requirements=2C but also some
of = the security issues. =3B For example=2C in its response to the IEEE 802= .11u
liaison=2C EMU WG provided a number of questions that needed to be = answered:
http://www.ietf.org/mail-archive/web/emu/current/msg00685.html=  =3B 

   In particular=2C the ISP MUST al=
low emergency callers to acquire an IP
   address and to reach a LoST se=
rver=2C either provided by the ISP or
   some third party.  It SHOULD al=
so provide location information via
   one of the mechanisms specified i=
n [I-D.ietf-ecrit-phonebcp] without
   requiring authorization unl=
ess it can safely assume that all nodes in
   the access network can det=
ermine their own location=2C e.g.=2C via GPS.

Given the curren= t state of knowledge=2C and the capabilities of the ISP and
enterprise e= quipment in place=2C we also need to think carefully about
normative re= quirements. =3B For example=2C some of the older WLAN networks
may h= ave limited abilities to actively advertise multiple networks
(e.g. they= may not be able to beacon an Emergency Services network
with access res= tricted as recommended in the document).

Also=2C if this work is go= ing to go forward=2C it should probably be
coordinated with other IETF W= Gs such as EMU=2C as well as
SDO efforts such as IEEE 802.11u and more<= br>recently=2C IEEE 802.21. =3B For example=2C the IEEE 802.21 Emergenc= y
Services charter can be found below:
https://mentor.ieee.org/802.21= /file/08/21-08-0313-03-00es-emergency-services-five-criteria.doc
 = =3B

= --_4b5be22a-e6cb-49e0-8b6a-7db62790b04e_-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFC33A6C15; Thu, 26 Feb 2009 13:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+gOPwezTeYT; Thu, 26 Feb 2009 13:52:05 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with ESMTP id 824B03A6C10; Thu, 26 Feb 2009 13:52:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-85.messagelabs.com!1235685144!46234341!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 26323 invoked from network); 26 Feb 2009 21:52:24 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 26 Feb 2009 21:52:24 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id n1QLqOda017986; Thu, 26 Feb 2009 16:52:24 -0500 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 26 Feb 2009 16:52:20 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 02/26/2009 04:54:43 PM, Serialize complete at 02/26/2009 04:54:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0078257E85257569_=" Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:52:08 -0000 This is a multipart message in MIME format. --=_alternative 0078257E85257569_= Content-Type: text/plain; charset="US-ASCII" James, Please go back and R E A D S L O W L Y. You have missed the point on many of my comments. For instance - 1) Do you REALLY think "...this namespace is to be to provide an explicit priority indication facilitates treatment..." makes sense? What is the subject of the verb "facilitates"? 2) I agree that 4412 says "do not modify or delete, just ignore if you don't like it" FOR SIP ACTORS THAT DO NOT UNDERSTAND THE NAMESPACE. There is NO SUCH PROHIBITION in 4412 for SIP Actors that DO UNDERSTAND the namespace, which is what is being discussed here. 3) Yes, it is just my opinion that "preempting normal calls" is a bad idea. But it is WRITTEN IN 4412 (not just my opinion) that only calls "with a valid namespace and a lower priority value" can be preempted. And furthermore it is a fact that for both the MLPP and eMLPP , the protocol standards are very clear that you can't preempt calls that don't have a priority value, in the same preemption domain. I have no idea how they do it in Japan, but if they are using MLPP, then the "normal" calls must be in the same preemption domain as the "911" calls, with a lower priority. Hence not "normal calls" in the usual sense of the word 4) Your replies contradict each other. When I say that "ets and wps don't have a 'routine' or 'normal' value", you say that esnet is different because "here there is no routine esnet calls, every one is an emergency call, and likely every call will be an emergency." A- That is equally true of ets and wps. There are no routine NS/EP calls. Every call with the ets or wps namespace is an NS/EP (hence special) call. B - If you mean that the esnet namespace will ONLY be used in networks where EVERY relevant SIP message uses the esnet RPH, then -Yes, it is different from ets and wps -BUT if this is the case, there are no "normal" calls to preempt -If this is the case, you need to state clearly that esnet will only be used in networks where everything is marked esnet. But I don't think that is what you mean (at least based on the diagram you presented today). C - I think you mean that esnet will be used in some networks where there are both esnet and non esnet messages (as well as some where all are marked esnet) - If this is the case, then it is EXACTLY the same as ets and wps, and no change from 4412 And so on. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. "James M. Polk" 02/26/2009 02:39 PM To Janet P Gunn/FED/CSC@CSC cc "'ECRIT'" , ecrit-bounces@ietf.org Subject Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted At 03:10 PM 2/24/2009, Janet P Gunn wrote: >James >Some of this is editorial, some is substantive and technical, and >some repeats my comments on 00 that do not seem to have been addressed. > >2nd paragraph of section 1, this sentence doesn't make sense. >" Within controlled environments, such as an IMS infrastructure or > Emergency Services network (ESInet), where misuse can be reduced to > a minimum where possible, this namespace is to be to provide an > explicit priority indication facilitates treatment of emergency SIP > messages according to local policy." I think this makes perfect sense as written >Perhaps you mean >" Within controlled environments, such as an IMS infrastructure or > Emergency Services network (ESInet), where misuse can be reduced to > a minimum, this namespace is expected to be used to provide an > explicit priority indication, facilitating treatment of emergency SIP > messages according to local policy." But I am not sure if that > is what you meant. that's another way of saying the same thing >Same para >"This indication is used to > differentiate SIP requests, or dialogs, from other requests or > dialogs that do not have the need for priority treatment." >sounds as if you are differentiating SIP requests form non-SIP >requests. Perhaps what you mean is >"This indication is used to > differentiate Emergency Services related SIP requests, or > dialogs, from other (non Emergency >Services related) SIP requests or dialogs. again -- this appears to be two ways of saying the same thing. >Note that "do not have the need for priority treatment" is not correct. it applies to other traffic that does not need priority treatment. In other words, the traffic that doesn't need priority treatment -- because there will be some traffic that does not need priority treatment within the ESInet (as well as an esnet namespace capable VSP) >The esnet RPH would >distinguish ES related messages from GETS related messages (ets and >wps namespaces), but they >would each get their own particular flavor of "priority treatment". > > >5th para of section 1 > >"From this fact about RFC 4412, and the possibility that within > emergency services networks, a Multilevel Precedence and Preemption > (MLPP)-like behavior can be achieved - ensuring more important calls > are established or retained, the "esnet" namespace is given 5 > priority-levels." >What is "this fact"? Perhaps "Because we can't add new values later..." the fact is right above this sentence >I don't understand the "can be achieved". Do you mean "MLPP-like >behavior may be desired"? it can be, which is all that I'm offering -- but I'm not recommending or stipulating or demanding or anything else... I'm just saying that with more than 2 levels, a natural hierarchy _can_ be configured. >I fully agree with assigning 5 levels, and the underlying logic. It >is only the description that is problematic. > >Perhaps >"Because we can't add new values later, and because Multilevel >Precedence and Preemption > (MLPP)-like behavior may be desired the "esnet" namespace is > given 5 priority-levels." that is within 4412 >2nd to last paragraph of section 1 >"Within the ESINet, there will be emergency calls requiring different > treatments, according to the type of call. " >We don't know if they will require different treatment or not. > >I would prefer >"Within the ESINet, there may be emergency calls requiring different > treatments, according to the type of call. " > >or if the use of "may" will be confused with normative language, >"Within the ESINet, there could be emergency calls requiring different > treatments, according to the type of call. " I'm ok with this >This sentence at the end of sec 1 doesn't quite work. >"This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not just > of those from citizens to PSAPs." (no clear antecedent for "those") fair >Perhaps >"This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not > just for calls or sessions > from citizens to PSAPs." >(same comment applied to 00) I'll back off this even more - to "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just for calls or sessions towards PSAPs." >Section 2 first para says > "This document updates the behaviors of the SIP Resource Priority > header, defined in [RFC4412], during the treatment options > surrounding this new "esnet" namespace only. The usage of the > "esnet" namespace does not have a normal, or routine call level. > Every use of this namespace will be in times of an emergency, where > at least one end of the signaling is with a local emergency > organization." > >I don't see this as an "update of the behavior of 4412". Neither >the ets namespace not the wps namespace have a "normal" or "routine" >call level. but either (ets or wps) can simply not be used. here there is no routine esnet calls, every one is an emergency call, and likely every call will be an emergency. >Every use of the wps and ets namespaces will have priority over >calls without RPH. > >Suggest changing text to say >" Like the ets and wps namespaces defined in [RFC4412], the > "esnet" namespace does not have a normal, or routine call level. > Every use of this namespace will be in times of an emergency, where > at least one end of the signaling is with a local emergency > organization." see comment above >Section 2, para immediately below Figure 1 >" Because the more important usage of the > "esnet" namespace occurs within the ESInet, the edge proxy, called > an Emergency Services Routing Proxy (ESRP) can modify or delete this > namespace. This is a normative change to the allowed behavior within > [RFC4412], but MUST only be considered valid in this usage at the > ESInet boundary for this one RP namespace (and associated > priority-value). " > >I have major (content, not editorial) concerns with this, more for >what it says about 4412 than about esnet > > >First of all, it is not clear to me why this is "a normative change >to the allowed behavior within [RFC4412]". because 4412 says "do not modify or delete, just ignore if you don't like it" this doc changes that for esnet only. >For one thing I see nothing in 4412 that would prohibit a "SIP actor >that understands the name space" >from modifying or deleting the namespace. 4.6.2. No Known Namespace or Priority Value If an RP actor does not understand any of the resource values in the request, the treatment depends on the presence of the Require 'resource-priority' option tag: 1. Without the option tag, the RP actor treats the request as if it contained no 'Resource-Priority' header field and processes it with default priority. Resource values that are not understood MUST NOT be modified or deleted. so, evidence to the contrary (from your statement above) >It is certainly anticipated that at least some of the namespaces >described in 4412 will be >modified or deleted, (e.g., when there is reason to believe it is >unauthorized). no, just ignored >4412 says "Existing implementations of RFC 3261 that do not >participate in the > resource priority mechanism follow the normal rules of RFC 3261, > Section 8.2.2: "If a UAS does not understand a header field in a > request (that is, the header field is not defined in this > specification or in any supported extension), the server MUST ignore > that header field and continue processing the message". " What about SIP entities that not only understand RPH, but understand the "esnet" namespace - yet have an incorrect priority-value for that call? That's a problem that needs to be fixed in the ESInet (with use of the esnet). >But I do not see anywhere that is says that a UAS that DOES >understand the namespace is >forbidden from deleting it. see 4.6.2 (quoted above) >For instance, sec 4.7.1 of 4412 says that "the UAC > MAY attempt a subsequent request with the same or different resource > value." This certainly implies the ability to overwrite or > delete an RPH namespace. (See >also, for instance the PTSC SAC document on the use of the ets and >wps namespaces.) > >I would suggest rewording this to say >" Because the more important usage of the > "esnet" namespace occurs within the ESInet, the edge proxy, called > an Emergency Services Routing Proxy (ESRP) can modify or delete this > namespace. This is consistent with [RFC4412]. " > > > > >Section 3.2,para after the relative priority order. > >" The "esnet" namespace will be assigned into the priority queuing > algorithm (Section 4.5.2 of [RFC4412]) from the public user to the > PSAP. This does not limit its usage to only the priority queue > algorithm; meaning the preemption algorithm can be used where the > local jurisdiction preferred to preempt normal calls in lieu of > completing emergency calls. This document is not RECOMMENDING this > usage, merely pointing out those behaviors are a matter of local > policy." > >My concern here is the reference to "preempt normal calls". Since >you have already said that >there is no "normal" level in the esnet priority value set, I have >to assume that you mean >"preempt calls with no RPH" (or perhaps "preempt calls with a >different RPH namespace"). no, I'm leaving open the possibility that perhaps one local jurisdiction wants to use preemption -- kinda like the country of Japan does today (therefore... it needs to be possible, *and* mentioned). > > >This WOULD BE a normative change to 4412, which says in 4.7.2.1 >"A UAS compliant with this specification MUST terminate a session > established with a valid namespace and lower-priority value in favor > of a new session set up with a valid namespace and higher relative > priority value, unless local policy has some form of call-waiting > capability enabled." > >Note that the only sessions that can be preempted are ones "with a >valid namespace and a lower >priority value". A "normal" call has neither a "valid namespace", >nor a "priority value" >(higher or lower), and thus cannot be preempted under 4412. we are not private ESInet network police -- and we shouldn't be so firm in deciding normal calls aren't preempted in one or more local configurations within jurisdictions. >Furthermore, RFC4411 (which focuses on "preemption") repeatedly >refers to the pre-empted >call/session having an RPH with a lower priority value. 4411 is how to indicate to a preempted caller their session has been preempted. I see no reason at this point to include any 4411 reference. For example, if NENA wanted to allow preemption (which I am NOT suggesting), their docs should include this reference and usage of 4411. >The circuit switched versions of preemption ( both MLPP for >landlines, and 3GPP e-MLPP for GSM) >are even more restrictive. In those schemes, a call can only >preempt a lower priority call IN >THE SAME PREEMPTION DOMAIN (there is a rough correspondence between >"preemption domain" and "RPH namespace"). > >So I take serious objection to any suggestion of preempting "normal" calls. respectfully, that's a personal opinion that I question the universal applicability of. Especially given that Japan currently preempts normal calls in lieu of 911 calls. Other jurisdictions *may* have similar or future plans >If you want to have high priority esnet calls preempt low priority >esnet calls, I don't object as >strenuously. (But no preempting "normal" calls.) > > >Section 5, 3rd para >" A simple means of preventing this usage is to not allow marked > traffic preferential treatment unless the destination is towards the > local/regional ESInet. " neither of the quotes below talk about granting preferential treatment across the ESInet ESRP boundary. This comment does. But I can expand on this sentence to clarify this meaning. >This seems to contradict the text in section 1 >"This new namespace can > be used for inbound calls to PSAPs, between PSAPs, and between a > PSAP and first responders and their organizations." >and section 3 >" This namespace will also be used > for communications between emergency authorities, and MAY be used > for emergency authorities calling public citizens. An example of > the later is a PSAP operator calling back someone who previously > called 9111/112/999 and the communication was terminated before it > should have been (in the operator's judgment)." > >Finally, at IETF 73 you assured me that you would insert strong >language pointing to section 8 of >RFC4412 addressing the relative priority of the different >namespaces. This is to eliminate any >possible suggestion (that some people - not me- read into the 00 >version) that an esnet >namespace would have higher priority than an ets namespace. well... I agree I haven't emphasized section 8 of 4412, and can mention this in a generic form when other namespaces are present. Secondly, this document should never insist that esnet is above or below ets or wps. that's a matter of local policy, for example - to within NENA/APCO for whether they believe (and are going to implement to) this. That's for an operational doc that this ID isn't. > I find no such reference to section >8 of 4412. > >Thanks, and please note that I strongly support the creation of the >esnet namespace. None of my comment should be interpreted as being >"against" esnet. > >Janet > > > > > > > > > >This is a PRIVATE message. If you are not the intended recipient, >please delete without copying and kindly advise us by e-mail of the >mistake in delivery. >NOTE: Regardless of content, this e-mail shall not operate to bind >CSC to any order or other contract unless pursuant to explicit >written agreement or government initiative expressly permitting the >use of e-mail for such purpose. > > >"James M. Polk" >Sent by: ecrit-bounces@ietf.org > >02/19/2009 09:32 PM >To >"'ECRIT'" >cc >Subject >[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted > > > > >ECRIT > >I've just submitted a rev of the "esnet" Resource-Prioriy header draft. > >I've removed all mention of UAs from the draft, but leave in the >possibility for adjacent VSPs to have a trust relationship with the >local ESInet and mark these SIP requests accordingly through the >VSP's domain. I offer that the ESRP at the ESInet edge will be >tasked with mapping the esnet.priority-values from outside the ESInet >to the indications used inside the ESInet. The ID gives no guidance >on what the priority-values should be in either case - as that is a >matter for other documents (and I'd argue - for other SDOs or >consortia such as NENA and EENA, though I don't mention either >organization in the ID). > >Comments are welcome > >James > > >From: IETF I-D Submission Tool > >To: jmpolk@cisco.com > >Subject: New Version Notification for > > draft-ietf-ecrit-local-emergency-rph-namespace-01 > >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST) > > > > > >A new version of I-D, > >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been > >successfuly submitted by James Polk and posted to the IETF repository. > > > >Filename: draft-ietf-ecrit-local-emergency-rph-namespace > >Revision: 01 > >Title: IANA Registering a SIP Resource Priority Header > >Namespace for Local Emergency Communications > >Creation_date: 2009-02-19 > >WG ID: ecrit > >Number_of_pages: 7 > > > >Abstract: > >This document creates and IANA registers the new Session Initiation > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > >local emergency usage to a public safety answering point (PSAP), > >between PSAPs, and between a PSAP and first responders and their > >organizations. > > > > > > > > > >The IETF Secretariat. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 0078257E85257569_= Content-Type: text/html; charset="US-ASCII"
James,

Please go back and R E A D  S L O W L Y.   You have missed the point on many of my comments.

For instance -

1) Do you REALLY think
"...this namespace is to be to provide an  explicit priority indication facilitates treatment..."
makes sense?  What is the subject of the verb "facilitates"?

2) I agree that  
4412 says "do not modify or delete, just ignore if you don't like it"
FOR SIP ACTORS THAT DO NOT UNDERSTAND THE NAMESPACE.

There is NO SUCH PROHIBITION in 4412 for SIP Actors that DO UNDERSTAND the namespace, which is what is being discussed here.
3) Yes, it is just my opinion that "preempting normal calls" is a bad idea.

But it is WRITTEN IN 4412 (not just my opinion) that only calls "with a valid namespace and a lower priority value" can be preempted.

And furthermore it is a fact that for both the MLPP and eMLPP , the protocol standards are very clear that you can't preempt calls that don't have a priority value, in the same preemption domain.  I have no idea how they do it in Japan, but if they are using MLPP, then the "normal" calls must be in the same preemption domain as the "911" calls, with a lower priority.    Hence not "normal calls" in the usual sense of the word

4) Your replies contradict each other.  When I say that "ets and wps don't have a 'routine' or 'normal' value", you say that esnet is different because "here there is no routine esnet calls, every one is an emergency call, and likely every
call will be an emergency."

A- That is equally true of ets and wps.   There are no routine NS/EP calls. Every call with the ets or wps namespace is an NS/EP (hence special) call.

B - If you mean that the esnet namespace will ONLY be used in networks where EVERY relevant SIP message uses the esnet RPH, then
        -Yes, it is different from ets and wps
        -BUT if this is the case, there are no "normal" calls to preempt
        -If this is the case, you need to state clearly that esnet will only be used in networks where everything is marked esnet.

But I don't think that is what you mean (at least based on the diagram you presented today).

C -  I think you mean that esnet will be used in some networks where there are both esnet and non esnet messages (as well as some where all are marked esnet)
        - If this is the case, then it is EXACTLY the same as ets and wps, and no change from 4412

And so on.

Janet


This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


"James M. Polk" <jmpolk@cisco.com>

02/26/2009 02:39 PM

To
Janet P Gunn/FED/CSC@CSC
cc
"'ECRIT'" <ecrit@ietf.org>, ecrit-bounces@ietf.org
Subject
Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01  submitted





At 03:10 PM 2/24/2009, Janet P Gunn wrote:

>James
>Some of this is editorial, some is substantive and technical, and
>some repeats my comments on 00 that do not seem to have been addressed.
>
>2nd paragraph of section 1, this sentence doesn't make sense.
>"   Within controlled environments, such as an IMS infrastructure or
>    Emergency Services network (ESInet), where misuse can be reduced to
>    a minimum where possible, this namespace is to be to provide an
>    explicit priority indication facilitates treatment of emergency SIP
>    messages according to local policy."

I think this makes perfect sense as written


>Perhaps you mean
>"   Within controlled environments, such as an IMS infrastructure or
>    Emergency Services network (ESInet), where misuse can be reduced to
>    a minimum, this namespace is expected to be used to provide an
>    explicit priority indication, facilitating treatment of emergency SIP
>    messages according to local policy."  But I am not sure if that
> is what you meant.

that's another way of saying the same thing


>Same para
>"This indication is used to
>    differentiate SIP requests, or dialogs, from other requests or
>    dialogs that do not have the need for priority treatment."
>sounds as if you are differentiating SIP requests form non-SIP
>requests.  Perhaps what you mean is
>"This indication is used to
>    differentiate Emergency Services related  SIP requests, or
> dialogs, from other (non Emergency
>Services related) SIP requests or  dialogs.

again -- this appears to be two ways of saying the same thing.


>Note that "do not have the need for priority treatment" is not correct.

it applies to other traffic that does not need priority treatment. In
other words, the traffic that doesn't need priority treatment --
because there will be some traffic that does not need priority
treatment within the ESInet (as well as an esnet namespace capable VSP)

>The esnet RPH would
>distinguish ES related messages from GETS related messages (ets and
>wps namespaces), but they
>would each get their own particular flavor of "priority treatment".
>
>
>5th para of section 1
>
>"From this fact about RFC 4412, and the possibility that within
>    emergency services networks, a Multilevel Precedence and Preemption
>    (MLPP)-like behavior can be achieved - ensuring more important calls
>    are established or retained, the "esnet" namespace is given 5
>    priority-levels."
>What is "this fact"?  Perhaps "Because we can't add new values later..."

the fact is right above this sentence


>I don't understand the "can be achieved".  Do you mean "MLPP-like
>behavior may be desired"?

it can be, which is all that I'm offering -- but I'm not recommending
or stipulating or demanding or anything else... I'm just saying that
with more than 2 levels, a natural hierarchy _can_ be configured.


>I fully agree with assigning 5 levels, and the underlying logic. It
>is only the description that is problematic.
>
>Perhaps
>"Because we can't add new values later, and because  Multilevel
>Precedence and Preemption
>    (MLPP)-like behavior may be desired the "esnet" namespace is
> given 5 priority-levels."

that is within 4412


>2nd to last paragraph of section 1
>"Within the ESINet, there will be emergency calls requiring different
>    treatments, according to the type of call. "
>We don't know if they will require different treatment or not.
>
>I would prefer
>"Within the ESINet, there may be emergency calls requiring different
>    treatments, according to the type of call. "
>
>or if the use of "may" will be confused with normative language,
>"Within the ESINet, there could be emergency calls requiring different
>    treatments, according to the type of call. "

I'm ok with this

>This sentence at the end of sec 1 doesn't quite work.
>"This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not just
>    of those from citizens to PSAPs." (no clear antecedent for "those")

fair


>Perhaps
>"This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not
> just for calls or sessions
>     from citizens to PSAPs."
>(same comment applied to 00)

I'll back off this even more - to

"This document IANA registers the "esnet"
  RPH namespace for use within emergency services networks, not just
for calls or sessions
  towards PSAPs."




>Section 2  first para says
>  "This document updates the behaviors of the SIP Resource Priority
>    header, defined in [RFC4412], during the treatment options
>    surrounding this new "esnet" namespace only. The usage of the
>    "esnet" namespace does not have a normal, or routine call level.
>    Every use of this namespace will be in times of an emergency, where
>    at least one end of the signaling is with a local emergency
>    organization."
>
>I don't see this as an "update of the behavior of 4412".  Neither
>the ets namespace not the wps namespace have a "normal" or "routine"
>call level.

but either (ets or wps) can simply not be used. here there is no
routine esnet calls, every one is an emergency call, and likely every
call will be an emergency.

>Every use of the wps and ets namespaces will have priority over
>calls without RPH.
>
>Suggest changing text to say
>"   Like the ets and wps namespaces defined in [RFC4412], the
>    "esnet" namespace does not have a normal, or routine call level.
>     Every use of this namespace will be in times of an emergency, where
>    at least one end of the signaling is with a local emergency
>    organization."

see comment above



>Section 2, para immediately below Figure 1
>"   Because the more important usage of the
>    "esnet" namespace occurs within the ESInet, the edge proxy, called
>    an Emergency Services Routing Proxy (ESRP) can modify or delete this
>    namespace. This is a normative change to the allowed behavior within
>    [RFC4412], but MUST only be considered valid in this usage at the
>    ESInet boundary for this one RP namespace (and associated
>    priority-value). "
>
>I have major (content, not editorial) concerns with this, more for
>what it says about 4412 than about esnet
>
>
>First of all, it is not clear to me why this is "a normative change
>to the allowed behavior within [RFC4412]".

because 4412 says "do not modify or delete, just ignore if you don't like it"

this doc changes that for esnet only.


>For one thing I see nothing in 4412 that would prohibit a "SIP actor
>that understands the name space"
>from modifying or deleting the namespace.



4.6.2.  No Known Namespace or Priority Value

   If an RP actor does not understand any of the resource values in
the request, the treatment depends on the presence of the Require
'resource-priority' option tag:

   1.  Without the option tag, the RP actor treats the request as if
it contained no 'Resource-Priority' header field and processes it
with default priority.  Resource values that are not understood MUST
NOT be modified or deleted.


so, evidence to the contrary (from your statement above)

>It is certainly anticipated that at least some of the namespaces
>described in 4412 will be
>modified or deleted, (e.g., when there is reason to  believe it is
>unauthorized).

no, just ignored


>4412 says "Existing implementations of RFC 3261 that do not
>participate in the
>    resource priority mechanism follow the normal rules of RFC 3261,
>    Section 8.2.2: "If a UAS does not understand a header field in a
>    request (that is, the header field is not defined in this
>    specification or in any supported extension), the server MUST ignore
>    that header field and continue processing the message". "

What about SIP entities that not only understand RPH, but understand
the "esnet" namespace - yet have an incorrect priority-value for that call?

That's a problem that needs to be fixed in the ESInet (with use of the esnet).


>But I do not see anywhere that is says that a UAS that DOES
>understand the namespace is
>forbidden from deleting it.

see 4.6.2 (quoted above)

>For instance, sec 4.7.1 of 4412 says that "the UAC
>    MAY attempt a subsequent request with the same or different resource
>    value."  This certainly implies the ability to overwrite or
> delete an RPH namespace.  (See
>also, for instance the PTSC SAC document on the use of the ets and
>wps namespaces.)
>
>I would suggest rewording this to say
>"   Because the more important usage of the
>    "esnet" namespace occurs within the ESInet, the edge proxy, called
>    an Emergency Services Routing Proxy (ESRP) can modify or delete this
>    namespace. This is consistent with [RFC4412]. "
>
>
>
>
>Section 3.2,para after the relative priority order.
>
>"  The "esnet" namespace will be assigned into the priority queuing
>    algorithm (Section 4.5.2 of [RFC4412]) from the public user to the
>    PSAP.  This does not limit its usage to only the priority queue
>    algorithm; meaning the preemption algorithm can be used where the
>    local jurisdiction preferred to preempt normal calls in lieu of
>    completing emergency calls.  This document is not RECOMMENDING this
>    usage, merely pointing out those behaviors are a matter of local
>    policy."
>
>My concern here is the reference to "preempt normal calls".  Since
>you have already said that
>there is no "normal" level in the esnet priority value set, I have
>to assume that you mean
>"preempt calls with no RPH" (or perhaps "preempt calls  with a
>different RPH namespace").

no, I'm leaving open the possibility that perhaps one local
jurisdiction wants to use preemption -- kinda like the country of
Japan does today (therefore... it needs to be possible, *and* mentioned).

>
>
>This WOULD BE a normative change to 4412, which says in 4.7.2.1
>"A UAS compliant with this specification MUST terminate a session
>    established with a valid namespace and lower-priority value in favor
>    of a new session set up with a valid namespace and higher relative
>    priority value, unless local policy has some form of call-waiting
>    capability enabled."
>
>Note that the only sessions that can be preempted are ones "with a
>valid namespace and a lower
>priority value".  A "normal" call has neither a "valid namespace",
>nor a "priority value"
>(higher or lower), and thus cannot be preempted under 4412.

we are not private ESInet network police -- and we shouldn't be so
firm in deciding normal calls aren't preempted in one or more local
configurations within jurisdictions.


>Furthermore, RFC4411 (which focuses on "preemption") repeatedly
>refers to the pre-empted
>call/session having an RPH with a lower priority value.

4411 is how to indicate to a preempted caller their session has been
preempted. I see no reason at this point to include any 4411
reference. For example, if NENA wanted to allow preemption (which I
am NOT suggesting), their docs should include this reference and usage of 4411.


>The circuit switched versions of preemption ( both MLPP for
>landlines, and 3GPP e-MLPP for GSM)
>are even more restrictive.  In those schemes, a call can only
>preempt a lower priority call IN
>THE SAME PREEMPTION DOMAIN (there is a rough correspondence between
>"preemption domain" and "RPH namespace").
>
>So I take serious objection to any suggestion of preempting "normal" calls.

respectfully, that's a personal opinion that I question the universal
applicability of. Especially given that Japan currently preempts
normal calls in lieu of 911 calls.

Other jurisdictions *may* have similar or future plans

>If you want to have high priority esnet calls preempt low priority
>esnet calls, I don't object as
>strenuously. (But no preempting "normal" calls.)
>
>
>Section 5, 3rd para
>"  A simple means of preventing this usage is to not allow marked
>    traffic preferential treatment unless the destination is towards the
>    local/regional ESInet. "

neither of the quotes below talk about granting preferential
treatment across the ESInet ESRP boundary.  This comment does. But I
can expand on this sentence to clarify this meaning.


>This seems to contradict the text in section 1
>"This new namespace can
>    be used for inbound calls to PSAPs, between PSAPs, and between a
>    PSAP and first responders and their organizations."
>and section 3
>" This namespace will also be used
>    for communications between emergency authorities, and MAY be used
>    for emergency authorities calling public citizens.  An example of
>    the later is a PSAP operator calling back someone who previously
>    called 9111/112/999 and the communication was terminated before it
>    should have been (in the operator's judgment)."
>
>Finally, at IETF 73 you assured me that you would insert strong
>language pointing to section 8 of
>RFC4412 addressing the relative priority of the different
>namespaces.  This is to eliminate any
>possible suggestion (that some people - not me- read into the 00
>version) that an esnet
>namespace would have higher priority than an ets namespace.

well... I agree I haven't emphasized section 8 of 4412, and can
mention this in a generic form when other namespaces are present.

Secondly, this document should never insist that esnet is above or
below ets or wps. that's a matter of local policy, for example - to
within NENA/APCO for whether they believe (and are going to implement
to) this.  That's for an operational doc that this ID isn't.

>  I find no such reference to section
>8 of 4412.
>
>Thanks, and please note that I strongly support the creation of the
>esnet namespace.  None of my comment should be interpreted as being
>"against" esnet.
>
>Janet
>
>
>
>
>
>
>
>
>
>This is a PRIVATE message. If you are not the intended recipient,
>please delete without copying and kindly advise us by e-mail of the
>mistake in delivery.
>NOTE: Regardless of content, this e-mail shall not operate to bind
>CSC to any order or other contract unless pursuant to explicit
>written agreement or government initiative expressly permitting the
>use of e-mail for such purpose.
>
>
>"James M. Polk" <jmpolk@cisco.com>
>Sent by: ecrit-bounces@ietf.org
>
>02/19/2009 09:32 PM
>To
>"'ECRIT'" <ecrit@ietf.org>
>cc
>Subject
>[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted
>
>
>
>
>ECRIT
>
>I've just submitted a rev of the "esnet" Resource-Prioriy header draft.
>
>I've removed all mention of UAs from the draft, but leave in the
>possibility for adjacent VSPs to have a trust relationship with the
>local ESInet and mark these SIP requests accordingly through the
>VSP's domain.  I offer that the ESRP at the ESInet edge will be
>tasked with mapping the esnet.priority-values from outside the ESInet
>to the indications used inside the ESInet.  The ID gives no guidance
>on what the priority-values should be in either case - as that is a
>matter for other documents (and I'd argue - for other SDOs or
>consortia such as NENA and EENA, though I don't mention either
>organization in the ID).
>
>Comments are welcome
>
>James
>
> >From: IETF I-D Submission Tool <idsubmission@ietf.org>
> >To: jmpolk@cisco.com
> >Subject: New Version Notification for
> >          draft-ietf-ecrit-local-emergency-rph-namespace-01
> >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
> >
> >
> >A new version of I-D,
> >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been
> >successfuly submitted by James Polk and posted to the IETF repository.
> >
> >Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
> >Revision:       01
> >Title:          IANA Registering a SIP Resource Priority Header
> >Namespace for Local Emergency Communications
> >Creation_date:  2009-02-19
> >WG ID:          ecrit
> >Number_of_pages: 7
> >
> >Abstract:
> >This document creates and IANA registers the new Session Initiation
> >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
> >local emergency usage to a public safety answering point (PSAP),
> >between PSAPs, and between a PSAP and first responders and their
> >organizations.
> >
> >
> >
> >
> >The IETF Secretariat.
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
--=_alternative 0078257E85257569_=-- Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69ADC3A67EE; Thu, 26 Feb 2009 15:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSXcocRiOpal; Thu, 26 Feb 2009 15:00:01 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ED4D33A6835; Thu, 26 Feb 2009 15:00:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,273,1233532800"; d="scan'208";a="135784921" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2009 23:00:22 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1QN0MoE014708; Thu, 26 Feb 2009 15:00:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1QN0Mjx015852; Thu, 26 Feb 2009 23:00: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); Thu, 26 Feb 2009 15:00:22 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.23.24]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 15:00:21 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Feb 2009 17:00:20 -0600 To: Janet P Gunn From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Feb 2009 23:00:21.0976 (UTC) FILETIME=[0087DD80:01C99866] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23157; t=1235689222; x=1236553222; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-01=20=0A=20=20submitted |Sender:=20; bh=oVjRmpppEvd9LLxiocA6EyCeVZOI7+fl7UdAUVzhw3Y=; b=A5FegGdWho3lS6cc4lfsqAUFmM8/LQRQgTvAjmogWqqYPPQmz52umfbf9Z EyBzxDVwWyQHjpI8OR09Xnckx9B7A134d6+zteQ/vv1GtG10gGCKaj6WJZxq azU7MzlKBY; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:00:03 -0000 At 03:52 PM 2/26/2009, Janet P Gunn wrote: >James, > >Please go back and R E A D S L O W L Y. You have missed the point >on many of my comments. > >For instance - > >1) Do you REALLY think >"...this namespace is to be to provide an explicit priority >indication facilitates treatment..." >makes sense? What is the subject of the verb "facilitates"? the indication perhaps I can put a "that" in front of "facilitates" to make it easier to read. >2) I agree that >4412 says "do not modify or delete, just ignore if you don't like it" >FOR SIP ACTORS THAT DO NOT UNDERSTAND THE NAMESPACE. > >There is NO SUCH PROHIBITION in 4412 for SIP Actors that DO >UNDERSTAND the namespace, which is what is being discussed here. what's being discussed here is your point that ESInet behaviors are exactly how 4412 says, which they are not. This ID is officially updating 4412 to allow SIP actors that understand RPH and a particular namespace to modify, delete or just ignore *just the esnet* namespace. This doesn't apply to any other namespaces but esnet. >3) Yes, it is just my opinion that "preempting normal calls" is a bad idea. what do you say to a country that does do this, they're wrong? >But it is WRITTEN IN 4412 (not just my opinion) that only calls >"with a valid namespace and a lower priority value" can be preempted. the text you are referring to is not normative - and is left to local policy, but it can happen (as it does in Japan), and I think that makes it worth mentioning. >And furthermore it is a fact that for both the MLPP and eMLPP , the >protocol standards are very clear that you can't preempt calls that >don't have a priority value, in the same preemption domain. well, those are individual domain policies - they are not uniformly SIP wide, to be taken as from God across the planet. >I have no idea how they do it in Japan, but if they are using MLPP, >then the "normal" calls must be in the same preemption domain as the >"911" calls, with a lower priority. Hence not "normal calls" in >the usual sense of the word this is semantics only >4) Your replies contradict each other. When I say that "ets and wps >don't have a 'routine' or 'normal' value", you say that esnet is >different because "here there is no routine esnet calls, every one >is an emergency call, and likely every >call will be an emergency." > >A- That is equally true of ets and wps. no it is not, because nowhere will ets or wps be wholly within "a single domain" that is only ets or wps. It is more likely the case that esnet will be in a similar network situation to MLPP domains (that are typically government run networks). > There are no routine NS/EP calls. Every call with the ets or wps > namespace is an NS/EP (hence special) call. but the two situations are not comparable (esnet to ets or wps). >B - If you mean that the esnet namespace will ONLY be used in >networks where EVERY relevant SIP message uses the esnet RPH, then > -Yes, it is different from ets and wps see above - we agree finally then > -BUT if this is the case, there are no "normal" calls to preempt but there very well may be ESInet calls with no RPH that are considered to have no priority -- which is different than MLPP type environments where the lowest priority calls are the regular normal/routine calls. The thing is here, that SIP can signal so much nowadays -- that there may be non-calls (involving something other than voice or video, such as IM or Presence, or data transfer or something else) that doesn't need to be marked at all. Where I believe you firmly are in the camp that everything SIP has to be a "call", whether it's voice or video. I'm saying that's not true. Think of a subscription establishment. That can be a dialog (i.e., long lasting), yet doesn't need any priority treatment - therefore can be a SIP request without RPH and be perfectly normal. > -If this is the case, you need to state clearly that esnet > will only be used in networks where everything is marked esnet. see above, I clearly do not believe that to be the case. >But I don't think that is what you mean (at least based on the >diagram you presented today). that diagram covers real-time communications -- but did not discuss all the SIP requests that are not real-time that will still be present within the ESInet. >C - I think you mean that esnet will be used in some networks where >there are both esnet and non esnet messages (as well as some where >all are marked esnet) no, there will be a mix always > - If this is the case, then it is EXACTLY the same as ets > and wps, and no change from 4412 no it isn't, because it is still within the boundaries of a single administrator -- who gets to choose which traffic is marked (and at what level) and what traffic is not marked... this is not the same. >And so on. > >Janet > > >This is a PRIVATE message. If you are not the intended recipient, >please delete without copying and kindly advise us by e-mail of the >mistake in delivery. >NOTE: Regardless of content, this e-mail shall not operate to bind >CSC to any order or other contract unless pursuant to explicit >written agreement or government initiative expressly permitting the >use of e-mail for such purpose. > > >"James M. Polk" > >02/26/2009 02:39 PM >To >Janet P Gunn/FED/CSC@CSC >cc >"'ECRIT'" , ecrit-bounces@ietf.org >Subject >Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted > > > > >At 03:10 PM 2/24/2009, Janet P Gunn wrote: > > >James > >Some of this is editorial, some is substantive and technical, and > >some repeats my comments on 00 that do not seem to have been addressed. > > > >2nd paragraph of section 1, this sentence doesn't make sense. > >" Within controlled environments, such as an IMS infrastructure or > > Emergency Services network (ESInet), where misuse can be reduced to > > a minimum where possible, this namespace is to be to provide an > > explicit priority indication facilitates treatment of emergency SIP > > messages according to local policy." > >I think this makes perfect sense as written > > > >Perhaps you mean > >" Within controlled environments, such as an IMS infrastructure or > > Emergency Services network (ESInet), where misuse can be reduced to > > a minimum, this namespace is expected to be used to provide an > > explicit priority indication, facilitating treatment of emergency SIP > > messages according to local policy." But I am not sure if that > > is what you meant. > >that's another way of saying the same thing > > > >Same para > >"This indication is used to > > differentiate SIP requests, or dialogs, from other requests or > > dialogs that do not have the need for priority treatment." > >sounds as if you are differentiating SIP requests form non-SIP > >requests. Perhaps what you mean is > >"This indication is used to > > differentiate Emergency Services related SIP requests, or > > dialogs, from other (non Emergency > >Services related) SIP requests or dialogs. > >again -- this appears to be two ways of saying the same thing. > > > >Note that "do not have the need for priority treatment" is not correct. > >it applies to other traffic that does not need priority treatment. In >other words, the traffic that doesn't need priority treatment -- >because there will be some traffic that does not need priority >treatment within the ESInet (as well as an esnet namespace capable VSP) > > >The esnet RPH would > >distinguish ES related messages from GETS related messages (ets and > >wps namespaces), but they > >would each get their own particular flavor of "priority treatment". > > > > > >5th para of section 1 > > > >"From this fact about RFC 4412, and the possibility that within > > emergency services networks, a Multilevel Precedence and Preemption > > (MLPP)-like behavior can be achieved - ensuring more important calls > > are established or retained, the "esnet" namespace is given 5 > > priority-levels." > >What is "this fact"? Perhaps "Because we can't add new values later..." > >the fact is right above this sentence > > > >I don't understand the "can be achieved". Do you mean "MLPP-like > >behavior may be desired"? > >it can be, which is all that I'm offering -- but I'm not recommending >or stipulating or demanding or anything else... I'm just saying that >with more than 2 levels, a natural hierarchy _can_ be configured. > > > >I fully agree with assigning 5 levels, and the underlying logic. It > >is only the description that is problematic. > > > >Perhaps > >"Because we can't add new values later, and because Multilevel > >Precedence and Preemption > > (MLPP)-like behavior may be desired the "esnet" namespace is > > given 5 priority-levels." > >that is within 4412 > > > >2nd to last paragraph of section 1 > >"Within the ESINet, there will be emergency calls requiring different > > treatments, according to the type of call. " > >We don't know if they will require different treatment or not. > > > >I would prefer > >"Within the ESINet, there may be emergency calls requiring different > > treatments, according to the type of call. " > > > >or if the use of "may" will be confused with normative language, > >"Within the ESINet, there could be emergency calls requiring different > > treatments, according to the type of call. " > >I'm ok with this > > >This sentence at the end of sec 1 doesn't quite work. > >"This document IANA registers the "esnet" > > RPH namespace for use within emergency services networks, not just > > of those from citizens to PSAPs." (no clear antecedent for "those") > >fair > > > >Perhaps > >"This document IANA registers the "esnet" > > RPH namespace for use within emergency services networks, not > > just for calls or sessions > > from citizens to PSAPs." > >(same comment applied to 00) > >I'll back off this even more - to > >"This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not just >for calls or sessions > towards PSAPs." > > > > > >Section 2 first para says > > "This document updates the behaviors of the SIP Resource Priority > > header, defined in [RFC4412], during the treatment options > > surrounding this new "esnet" namespace only. The usage of the > > "esnet" namespace does not have a normal, or routine call level. > > Every use of this namespace will be in times of an emergency, where > > at least one end of the signaling is with a local emergency > > organization." > > > >I don't see this as an "update of the behavior of 4412". Neither > >the ets namespace not the wps namespace have a "normal" or "routine" > >call level. > >but either (ets or wps) can simply not be used. here there is no >routine esnet calls, every one is an emergency call, and likely every >call will be an emergency. > > >Every use of the wps and ets namespaces will have priority over > >calls without RPH. > > > >Suggest changing text to say > >" Like the ets and wps namespaces defined in [RFC4412], the > > "esnet" namespace does not have a normal, or routine call level. > > Every use of this namespace will be in times of an emergency, where > > at least one end of the signaling is with a local emergency > > organization." > >see comment above > > > > >Section 2, para immediately below Figure 1 > >" Because the more important usage of the > > "esnet" namespace occurs within the ESInet, the edge proxy, called > > an Emergency Services Routing Proxy (ESRP) can modify or delete this > > namespace. This is a normative change to the allowed behavior within > > [RFC4412], but MUST only be considered valid in this usage at the > > ESInet boundary for this one RP namespace (and associated > > priority-value). " > > > >I have major (content, not editorial) concerns with this, more for > >what it says about 4412 than about esnet > > > > > >First of all, it is not clear to me why this is "a normative change > >to the allowed behavior within [RFC4412]". > >because 4412 says "do not modify or delete, just ignore if you don't like it" > >this doc changes that for esnet only. > > > >For one thing I see nothing in 4412 that would prohibit a "SIP actor > >that understands the name space" > >from modifying or deleting the namespace. > > > >4.6.2. No Known Namespace or Priority Value > > If an RP actor does not understand any of the resource values in >the request, the treatment depends on the presence of the Require >'resource-priority' option tag: > > 1. Without the option tag, the RP actor treats the request as if >it contained no 'Resource-Priority' header field and processes it >with default priority. Resource values that are not understood MUST >NOT be modified or deleted. > > >so, evidence to the contrary (from your statement above) > > >It is certainly anticipated that at least some of the namespaces > >described in 4412 will be > >modified or deleted, (e.g., when there is reason to believe it is > >unauthorized). > >no, just ignored > > > >4412 says "Existing implementations of RFC 3261 that do not > >participate in the > > resource priority mechanism follow the normal rules of RFC 3261, > > Section 8.2.2: "If a UAS does not understand a header field in a > > request (that is, the header field is not defined in this > > specification or in any supported extension), the server MUST ignore > > that header field and continue processing the message". " > >What about SIP entities that not only understand RPH, but understand >the "esnet" namespace - yet have an incorrect priority-value for that call? > >That's a problem that needs to be fixed in the ESInet (with use of the esnet). > > > >But I do not see anywhere that is says that a UAS that DOES > >understand the namespace is > >forbidden from deleting it. > >see 4.6.2 (quoted above) > > >For instance, sec 4.7.1 of 4412 says that "the UAC > > MAY attempt a subsequent request with the same or different resource > > value." This certainly implies the ability to overwrite or > > delete an RPH namespace. (See > >also, for instance the PTSC SAC document on the use of the ets and > >wps namespaces.) > > > >I would suggest rewording this to say > >" Because the more important usage of the > > "esnet" namespace occurs within the ESInet, the edge proxy, called > > an Emergency Services Routing Proxy (ESRP) can modify or delete this > > namespace. This is consistent with [RFC4412]. " > > > > > > > > > >Section 3.2,para after the relative priority order. > > > >" The "esnet" namespace will be assigned into the priority queuing > > algorithm (Section 4.5.2 of [RFC4412]) from the public user to the > > PSAP. This does not limit its usage to only the priority queue > > algorithm; meaning the preemption algorithm can be used where the > > local jurisdiction preferred to preempt normal calls in lieu of > > completing emergency calls. This document is not RECOMMENDING this > > usage, merely pointing out those behaviors are a matter of local > > policy." > > > >My concern here is the reference to "preempt normal calls". Since > >you have already said that > >there is no "normal" level in the esnet priority value set, I have > >to assume that you mean > >"preempt calls with no RPH" (or perhaps "preempt calls with a > >different RPH namespace"). > >no, I'm leaving open the possibility that perhaps one local >jurisdiction wants to use preemption -- kinda like the country of >Japan does today (therefore... it needs to be possible, *and* mentioned). > > > > > > >This WOULD BE a normative change to 4412, which says in 4.7.2.1 > >"A UAS compliant with this specification MUST terminate a session > > established with a valid namespace and lower-priority value in favor > > of a new session set up with a valid namespace and higher relative > > priority value, unless local policy has some form of call-waiting > > capability enabled." > > > >Note that the only sessions that can be preempted are ones "with a > >valid namespace and a lower > >priority value". A "normal" call has neither a "valid namespace", > >nor a "priority value" > >(higher or lower), and thus cannot be preempted under 4412. > >we are not private ESInet network police -- and we shouldn't be so >firm in deciding normal calls aren't preempted in one or more local >configurations within jurisdictions. > > > >Furthermore, RFC4411 (which focuses on "preemption") repeatedly > >refers to the pre-empted > >call/session having an RPH with a lower priority value. > >4411 is how to indicate to a preempted caller their session has been >preempted. I see no reason at this point to include any 4411 >reference. For example, if NENA wanted to allow preemption (which I >am NOT suggesting), their docs should include this reference and >usage of 4411. > > > >The circuit switched versions of preemption ( both MLPP for > >landlines, and 3GPP e-MLPP for GSM) > >are even more restrictive. In those schemes, a call can only > >preempt a lower priority call IN > >THE SAME PREEMPTION DOMAIN (there is a rough correspondence between > >"preemption domain" and "RPH namespace"). > > > >So I take serious objection to any suggestion of preempting "normal" calls. > >respectfully, that's a personal opinion that I question the universal >applicability of. Especially given that Japan currently preempts >normal calls in lieu of 911 calls. > >Other jurisdictions *may* have similar or future plans > > >If you want to have high priority esnet calls preempt low priority > >esnet calls, I don't object as > >strenuously. (But no preempting "normal" calls.) > > > > > >Section 5, 3rd para > >" A simple means of preventing this usage is to not allow marked > > traffic preferential treatment unless the destination is towards the > > local/regional ESInet. " > >neither of the quotes below talk about granting preferential >treatment across the ESInet ESRP boundary. This comment does. But I >can expand on this sentence to clarify this meaning. > > > >This seems to contradict the text in section 1 > >"This new namespace can > > be used for inbound calls to PSAPs, between PSAPs, and between a > > PSAP and first responders and their organizations." > >and section 3 > >" This namespace will also be used > > for communications between emergency authorities, and MAY be used > > for emergency authorities calling public citizens. An example of > > the later is a PSAP operator calling back someone who previously > > called 9111/112/999 and the communication was terminated before it > > should have been (in the operator's judgment)." > > > >Finally, at IETF 73 you assured me that you would insert strong > >language pointing to section 8 of > >RFC4412 addressing the relative priority of the different > >namespaces. This is to eliminate any > >possible suggestion (that some people - not me- read into the 00 > >version) that an esnet > >namespace would have higher priority than an ets namespace. > >well... I agree I haven't emphasized section 8 of 4412, and can >mention this in a generic form when other namespaces are present. > >Secondly, this document should never insist that esnet is above or >below ets or wps. that's a matter of local policy, for example - to >within NENA/APCO for whether they believe (and are going to implement >to) this. That's for an operational doc that this ID isn't. > > > I find no such reference to section > >8 of 4412. > > > >Thanks, and please note that I strongly support the creation of the > >esnet namespace. None of my comment should be interpreted as being > >"against" esnet. > > > >Janet > > > > > > > > > > > > > > > > > > > >This is a PRIVATE message. If you are not the intended recipient, > >please delete without copying and kindly advise us by e-mail of the > >mistake in delivery. > >NOTE: Regardless of content, this e-mail shall not operate to bind > >CSC to any order or other contract unless pursuant to explicit > >written agreement or government initiative expressly permitting the > >use of e-mail for such purpose. > > > > > >"James M. Polk" > >Sent by: ecrit-bounces@ietf.org > > > >02/19/2009 09:32 PM > >To > >"'ECRIT'" > >cc > >Subject > >[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted > > > > > > > > > >ECRIT > > > >I've just submitted a rev of the "esnet" Resource-Prioriy header draft. > > > >I've removed all mention of UAs from the draft, but leave in the > >possibility for adjacent VSPs to have a trust relationship with the > >local ESInet and mark these SIP requests accordingly through the > >VSP's domain. I offer that the ESRP at the ESInet edge will be > >tasked with mapping the esnet.priority-values from outside the ESInet > >to the indications used inside the ESInet. The ID gives no guidance > >on what the priority-values should be in either case - as that is a > >matter for other documents (and I'd argue - for other SDOs or > >consortia such as NENA and EENA, though I don't mention either > >organization in the ID). > > > >Comments are welcome > > > >James > > > > >From: IETF I-D Submission Tool > > >To: jmpolk@cisco.com > > >Subject: New Version Notification for > > > draft-ietf-ecrit-local-emergency-rph-namespace-01 > > >Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST) > > > > > > > > >A new version of I-D, > > >draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been > > >successfuly submitted by James Polk and posted to the IETF repository. > > > > > >Filename: draft-ietf-ecrit-local-emergency-rph-namespace > > >Revision: 01 > > >Title: IANA Registering a SIP Resource Priority Header > > >Namespace for Local Emergency Communications > > >Creation_date: 2009-02-19 > > >WG ID: ecrit > > >Number_of_pages: 7 > > > > > >Abstract: > > >This document creates and IANA registers the new Session Initiation > > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > > >local emergency usage to a public safety answering point (PSAP), > > >between PSAPs, and between a PSAP and first responders and their > > >organizations. > > > > > > > > > > > > > > >The IETF Secretariat. > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >