From john@johnlange.ca Mon Jun 1 12:25:28 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 1B0AA3A6D5A for ; Mon, 1 Jun 2009 12:25:28 -0700 (PDT) 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 GhzLdkvbiyV3 for ; Mon, 1 Jun 2009 12:25:24 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id E2A793A6E52 for ; Mon, 1 Jun 2009 12:25:23 -0700 (PDT) Received: (qmail 8033 invoked from network); 1 Jun 2009 14:25:22 -0500 Received: from unknown (HELO ?192.168.4.9?) (192.168.4.9) by lh02.epicnet.ca with SMTP; 1 Jun 2009 14:25:21 -0500 From: John Lange To: ecrit Content-Type: text/plain Date: Mon, 01 Jun 2009 14:25:11 -0500 Message-Id: <1243884311.17673.212.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 01 Jun 2009 19:25:28 -0000 On April 15 2009, the Canadian Radio and Telecommunications Commission (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom Notice of Consultation CRTC 2009-194". http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm Paragraph 17 asks; "Are there alternative solutions that would improve on the current nomadic VoIP 9-1-1 service." The proposed architecture was developed by Bell Canada based very loosely on NENAi2 with extensive modifications. As it was developed by the ILECs in 2006/2007, it does not employ the IETF standards. I am working on a submission to this proceeding which advocates the implementation of the standards developed by the IETF's ECRIT working group and it's members. (As a side note, if there are any participants on this list which are interested in helping with this effort, please do contact me.) After examining draft-ietf-ecrit-framework-09 and it's related RFCs and RFC-drafts, I have some specific questions/concerns which I hope this list can answer. The Emergency Call Framework (ECF) as proposed : - Location is cached at end-point during boot/location discovery but there does not appear to be any mechanism whereby the end-point announces the success of this process to the SIP Registrar. If the device is able to determine it's location it should relay the location information to the SIP registration server and the SIP registrar should cache this information. This allows the SIP Registrar and SIP proxy the ability to act "on-behalf-of" end points that are not able to determine their location either because they are not location capable, or because they are not able to determine location from their access provider. Furthermore, it removes the burden of "real-time" "on-behalf-of" functionality from the rest of the network. The ability of the registrar to query and cache location data for endpoints as opposed to the requirement to perform location determination in real-time, has a dramatic impact on the technical requirements of the overall solution. If location data must be queried in real-time during an actual emergency event, the network components must be engineered to a much higher standard. In some jurisdictions the mandated hardware and network requirements will be impacted significantly. No less than redundant five-nine hardware running on dedicated private networks will be required resulting in higher costs. I submit that a query-and-cache methodology is more in line with the spirit of other IETF protocols, the DNS system being a prime example. - Concerns with draft-ietf-geopriv-lis-discovery: The focus of LIS discovery seems to be on local access network methods such as DHCP and LLDP. DHCP & LLDP are not good choices for LIS discovery because they are not supported in the residential market. Residential firewall devices are not likely to have DHCP/LLDP functionality and the likelihood that these devices will be replaced or upgraded is small. It would therefore seem that the emphasis should be on a LIS discovery mechanism that does not rely on the local network such as STUN + DNS. 1) Device determines its IP address by querying the STUN server. 2) Device determines its domain name using reverse DNS. 3) Device does LIS discovery via DNS (SRV/NAPTR). - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on behalf of devices if: The proxy has a relationship with all access networks the device could connect to". This wording seems overly restrictive; in effect "all access networks the device could connect to" amounts to every network on earth which seems like an unreasonably high standard. How about: "Proxies MAY provide location on behalf of devices if: the device does not provide it's own location and the proxy is able to determine location on-behalf-of the device. Any comments and/or questions would be welcome. Regards, -- John Lange http://www.johnlange.ca From br@brianrosen.net Mon Jun 1 14:09: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 4C1A93A6B24 for ; Mon, 1 Jun 2009 14:09:20 -0700 (PDT) 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 GtFcp38uhXUh for ; Mon, 1 Jun 2009 14:09:18 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D908A3A68AF for ; Mon, 1 Jun 2009 14:09:18 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MBEkl-00087f-O9; Mon, 01 Jun 2009 16:09:08 -0500 From: "Brian Rosen" To: "'John Lange'" , "'ecrit'" References: <1243884311.17673.212.camel@vandium.darkcore.net> In-Reply-To: <1243884311.17673.212.camel@vandium.darkcore.net> Date: Mon, 1 Jun 2009 17:09:10 -0400 Message-ID: <19ea01c9e2fd$37007570$a5016050$@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: Acni7rVi0EPgQ6VUQ16TKqA18qJDjQABbU5g 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] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 01 Jun 2009 21:09:20 -0000 At the time of the call, the device either does have its location, or it doesn't. If it does, then the SIP proxy can use it, if it needs to, because it's on the signaling. There isn't any point in caching it at the proxy, and it's a privacy issue if it does. The reason you want to get fresh location is that it's pretty darn hard to know if a device is mobile and thus location at boot time is not necessarily correct at run time. If the device is fixed location, and the location at boot is the same as location at call time, then if the location infrastructure fails, the cached location is all you have, but it's correct. That implies that the infrastructure doesn't absolutely need to be 5 nines. "On behalf of" is needed when the device DOESN'T get it's location from its access network. I think you have a point on the language of the on behalf of language in -phonebcp, but your suggestion is not good enough. The problem to be solved is one way or another we have to get location. The current wording is aimed at proxies who think they ought to do it always, and the language says, fine, as long as you CAN do it always. Your language says "do it if you can" but that let's the proxy off the hook; it has to work always. I suppose we could craft something that is more like, if the proxy knows that the device will be used on some networks that supply location to the device, and in every other network it can supply location OBO, then it's okay. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of John Lange > Sent: Monday, June 01, 2009 3:25 PM > To: ecrit > Subject: [Ecrit] Emergency Call Framework for Canada; Questions on > draft-ietf-ecrit-framework-09 > > On April 15 2009, the Canadian Radio and Telecommunications Commission > (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom > Notice of Consultation CRTC 2009-194". > > http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm > > Paragraph 17 asks; "Are there alternative solutions that would improve > on the current nomadic VoIP 9-1-1 service." > > The proposed architecture was developed by Bell Canada based very > loosely on NENAi2 with extensive modifications. As it was developed by > the ILECs in 2006/2007, it does not employ the IETF standards. > > I am working on a submission to this proceeding which advocates the > implementation of the standards developed by the IETF's ECRIT working > group and it's members. (As a side note, if there are any participants > on this list which are interested in helping with this effort, please > do > contact me.) > > After examining draft-ietf-ecrit-framework-09 and it's related RFCs and > RFC-drafts, I have some specific questions/concerns which I hope this > list can answer. > > The Emergency Call Framework (ECF) as proposed : > > - Location is cached at end-point during boot/location discovery but > there does not appear to be any mechanism whereby the end-point > announces the success of this process to the SIP Registrar. > > If the device is able to determine it's location it should relay the > location information to the SIP registration server and the SIP > registrar should cache this information. > > This allows the SIP Registrar and SIP proxy the ability to act > "on-behalf-of" end points that are not able to determine their location > either because they are not location capable, or because they are not > able to determine location from their access provider. > > Furthermore, it removes the burden of "real-time" "on-behalf-of" > functionality from the rest of the network. > > The ability of the registrar to query and cache location data for > endpoints as opposed to the requirement to perform location > determination in real-time, has a dramatic impact on the technical > requirements of the overall solution. > > If location data must be queried in real-time during an actual > emergency > event, the network components must be engineered to a much higher > standard. In some jurisdictions the mandated hardware and network > requirements will be impacted significantly. No less than redundant > five-nine hardware running on dedicated private networks will be > required resulting in higher costs. > > I submit that a query-and-cache methodology is more in line with the > spirit of other IETF protocols, the DNS system being a prime example. > > - Concerns with draft-ietf-geopriv-lis-discovery: > > The focus of LIS discovery seems to be on local access network methods > such as DHCP and LLDP. > > DHCP & LLDP are not good choices for LIS discovery because they are not > supported in the residential market. Residential firewall devices are > not likely to have DHCP/LLDP functionality and the likelihood that > these > devices will be replaced or upgraded is small. > > It would therefore seem that the emphasis should be on a LIS discovery > mechanism that does not rely on the local network such as STUN + DNS. > > 1) Device determines its IP address by querying the STUN server. > 2) Device determines its domain name using reverse DNS. > 3) Device does LIS discovery via DNS (SRV/NAPTR). > > - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on > behalf > of devices if: The proxy has a relationship with all access networks > the > device could connect to". > > This wording seems overly restrictive; in effect "all access networks > the device could connect to" amounts to every network on earth which > seems like an unreasonably high standard. > > How about: > > "Proxies MAY provide location on behalf of devices if: the device does > not provide it's own location and the proxy is able to determine > location on-behalf-of the device. > > Any comments and/or questions would be welcome. > > Regards, > -- > John Lange > http://www.johnlange.ca > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Mon Jun 1 15:02:00 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 7DA153A6B14 for ; Mon, 1 Jun 2009 15:02:00 -0700 (PDT) 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 M5NaIPBDwkzD for ; Mon, 1 Jun 2009 15:01:55 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E98813A69AB for ; Mon, 1 Jun 2009 15:01:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,286,1241395200"; d="scan'208";a="78695489" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2009 22:01:56 +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 n51M1u00025717; Mon, 1 Jun 2009 15:01:56 -0700 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 n51M1uco009339; Mon, 1 Jun 2009 22:01:56 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.3959); Mon, 1 Jun 2009 15:01:56 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.122]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Jun 2009 15:01:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Jun 2009 17:01:54 -0500 To: John Lange , ecrit From: "James M. Polk" In-Reply-To: <1243884311.17673.212.camel@vandium.darkcore.net> References: <1243884311.17673.212.camel@vandium.darkcore.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jun 2009 22:01:55.0720 (UTC) FILETIME=[93E1E880:01C9E304] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7239; t=1243893716; x=1244757716; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=vgSzPlluF/wQIog0kxir0e0aO1KYI3L+GwLioFGsY94=; b=p328hfUkPO5arnf4Q6Osvml8sbNMq0tRtC9FqDKB8VM/H6JNVOzu9V0lKE rjV2dsRU9vlyrv6GY9KPdCFVP2x+90HCGREx2Q6vJAqpZTDHkvl4E44CfufR IGBTN/TkIT06x/cVtUJ+NtDSKdVXiebltG2t5mJeWT9kl67AXcuOE=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 01 Jun 2009 22:02:00 -0000 John some comments in-line below At 02:25 PM 6/1/2009, John Lange wrote: >On April 15 2009, the Canadian Radio and Telecommunications Commission >(CRTC), which is the Canadian equivalent of the FCC, issued "Telecom >Notice of Consultation CRTC 2009-194". > >http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm > >Paragraph 17 asks; "Are there alternative solutions that would improve >on the current nomadic VoIP 9-1-1 service." > >The proposed architecture was developed by Bell Canada based very >loosely on NENAi2 with extensive modifications. As it was developed by >the ILECs in 2006/2007, it does not employ the IETF standards. > >I am working on a submission to this proceeding which advocates the >implementation of the standards developed by the IETF's ECRIT working >group and it's members. (As a side note, if there are any participants >on this list which are interested in helping with this effort, please do >contact me.) > >After examining draft-ietf-ecrit-framework-09 and it's related RFCs and >RFC-drafts, I have some specific questions/concerns which I hope this >list can answer. > >The Emergency Call Framework (ECF) as proposed : > >- Location is cached at end-point during boot/location discovery but >there does not appear to be any mechanism whereby the end-point >announces the success of this process to the SIP Registrar. This can be done with this specification: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-13.txt >If the device is able to determine it's location it should relay the >location information to the SIP registration server and the SIP >registrar should cache this information. The registrar caching geolocation is not a protocol issue, it's a configuration issue (once it receives the location from the endpoint). Notice this does not have to be with the first REGISTER request (meaning with a subsequent one), and/or it could be with each REGISTER request. >This allows the SIP Registrar and SIP proxy the ability to act >"on-behalf-of" end points that are not able to determine their location >either because they are not location capable, or because they are not >able to determine location from their access provider. I'm missing what you mean by the starting "this" in the paragraph above? If the UA has its location, nothing needs to act "on-behalf-of" (OBO) it when sending location in any SIP request. >Furthermore, it removes the burden of "real-time" "on-behalf-of" >functionality from the rest of the network. If endpoints have their location (your original premise), OBO is unnecessary -- which further reduces network complexity, no? >The ability of the registrar to query and cache location data for >endpoints as opposed to the requirement to perform location >determination in real-time, has a dramatic impact on the technical >requirements of the overall solution. How is this better or easier or an optimization from the endpoint including its location in the SIP request in the first place? >If location data must be queried in real-time during an actual emergency >event, the network components must be engineered to a much higher >standard. In some jurisdictions the mandated hardware and network >requirements will be impacted significantly. No less than redundant >five-nine hardware running on dedicated private networks will be >required resulting in higher costs. again, all this goes away if the endpoint has its location prior to placing the emergency call, then including this location information if more current location information cannot be discovered easily. Remember, unless you believe that everything needs to be built for mobile endpoints (i.e., those that actually move from room to room and from city to city with many times within the same day), being IP based doesn't mean endpoints move much. Further, given the fact that there are lower layer solutions already in place (802.11k and y and 3GPP) -- the IETF doesn't need to solve everything moving as if it was never where it is before. For example, my IP phones at home haven't moved all day (or all week, or all year, etc) -- therefore the location value they understand 1 minute ago, as well as a day ago, and a month ago haven't changed. This makes these locations valid for call routing and dispatch. Mobile nodes that are 3GPP based have their own way of tracking location changes. Mobile nodes that are 802.11 based will likely have a valid location for call routing at any time during the day, but dispatch could take a bit longer to determine. The good thing here is that most systems can determine location within 15 seconds for dispatch -- and I'd like to meet the dispatchers that can make it to their destination in time for that to be an issue ;-) >I submit that a query-and-cache methodology is more in line with the >spirit of other IETF protocols, the DNS system being a prime example. > >- Concerns with draft-ietf-geopriv-lis-discovery: > >The focus of LIS discovery seems to be on local access network methods >such as DHCP and LLDP. > >DHCP & LLDP are not good choices for LIS discovery because they are not >supported in the residential market. Residential firewall devices are >not likely to have DHCP/LLDP functionality and the likelihood that these >devices will be replaced or upgraded is small. For LLDP, I fully agree with what you have above. I've had 4 ISPs over the last 10 years, and EACH of them have used DHCP, so I'm not sure where you get your data wrt DHCP not being supported in the residential market. >It would therefore seem that the emphasis should be on a LIS discovery >mechanism that does not rely on the local network such as STUN + DNS. How many vendors in the residential market do you know of that implement STUN? It appears you keep getting back to a solution that requires an upgrade in the access networks or endpoints. >1) Device determines its IP address by querying the STUN server. >2) Device determines its domain name using reverse DNS. >3) Device does LIS discovery via DNS (SRV/NAPTR). > >- draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on behalf >of devices if: The proxy has a relationship with all access networks the >device could connect to". > >This wording seems overly restrictive; in effect "all access networks >the device could connect to" amounts to every network on earth which >seems like an unreasonably high standard. > >How about: > >"Proxies MAY provide location on behalf of devices if: the device does >not provide it's own location and the proxy is able to determine >location on-behalf-of the device. How does anyone know if this location OBO by the proxy is good enough for dispatch? I think (and this is just my opinion) that proxies in this situation will be just guessing where the endpoints are... >Any comments and/or questions would be welcome. > >Regards, >-- >John Lange >http://www.johnlange.ca > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From john@johnlange.ca Tue Jun 2 11:13:19 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 9066628C161 for ; Tue, 2 Jun 2009 11:13:19 -0700 (PDT) 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 X5wK1qNF5sw3 for ; Tue, 2 Jun 2009 11:13:18 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 11B7428C12D for ; Tue, 2 Jun 2009 11:13:17 -0700 (PDT) Received: (qmail 16553 invoked from network); 2 Jun 2009 13:13:17 -0500 Received: from unknown (HELO ?192.168.4.54?) (192.168.4.54) by lh02.epicnet.ca with SMTP; 2 Jun 2009 13:13:17 -0500 From: John Lange To: ecrit In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> Content-Type: text/plain Date: Tue, 02 Jun 2009 13:13:06 -0500 Message-Id: <1243966386.4449.676.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 18:13:19 -0000 I covered a lot of ground in my last post and I can tell from the responses that some of the points weren't clear. I apologize so please let me clarify; - I'm not disputing that having the endpoint do network discovery of location is the best first choice. What I'm saying is; 1) Endpoint location discovery via DHCP is not going to work for residential so some other mechanism will need to be employed (and I think it should be STUN + DNS). 2) The SIP Registrar needs to know if the end point has it's location so that the SIP Registrar can do OBO and discover the Emergency Services Routing Proxy (ESRP) URI _before_ an emergency call is placed. 3) allowing the OBO to happen before the call will dramatically reduce the network infrastructure requirements and therefore the cost of implementing the solution because real-time IP location determination done to a standard good enough for emergency call routing (less than 3 seconds) requires a significantly more robust solution than a query-cache methodology. --- The bottom line here is that if the device doesn't know it's location and the SIP registrar isn't aware that it needs to do OBO, then in all likelihood the device can not place an emergency call to the correct ESRP since querying location on-the-fly will be too slow to route the call correctly. That's it in a nutshell but I'm going to pull all the threads together and reply with some more detail to some specific questions inline below: On Mon, 2009-06-01 at 17:01 -0500, James M. Polk wrote: > For LLDP, I fully agree with what you have above. I've had 4 ISPs > over the last 10 years, and EACH of them have used DHCP, so I'm not > sure where you get your data wrt DHCP not being supported in the > residential market. I'm talking about residential firewall/routers. Someone else on this list pointed me to this: "Location Information Server (LIS) Discovery From Behind Residential Gateways" http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-00 > >It would therefore seem that the emphasis should be on a LIS discovery > >mechanism that does not rely on the local network such as STUN + DNS. > > How many vendors in the residential market do you know of that implement STUN? STUN would be implemented by the VOIP provider and their devices would be provisioned to query their own STUN servers. Many VOIP providers are using STUN today and every recent VOIP device I've looked at recently has an implementation of STUN so I submit that it is widely supported. > It appears you keep getting back to a solution that requires an > upgrade in the access networks Not at all. That is precisely what I'm trying to avoid. > or endpoints. An upgrade to endpoints so they can do location is inevitable but the OBO functionality is there to cover-off those devices which can not be upgraded. On Mon, 2009-06-01 at 17:09 -0400, Brian Rosen wrote: > There isn't any point in caching it at the proxy, and it's a privacy > issue if it does. You are correct that caching isn't required if the device knows it's location _provided that_ the proxy is aware that the device already has it's location. However, as I stated above, if the devices doesn't know it's location the registrar needs to know about it so it can do OBO. And if the registrar is doing OBO then it needs to cache the result. So my point would be, if you are going to allow the registrar to do OBO and cache results then it might as well cache location for the other devices as well so it can use that information as a backup just in case the device looses its location or becomes unreachable for some reason (for example, lets say the internet to the endpoint drops during a 911 call. If the proxy has the info cached it could answer OBO the device). Furthermore, (*** this is a critical point ***) if the device does not provide location and the OBO server is not able to determine location, this could trigger some other action. This allows VOIP providers to easily identify "dead spots" in the LIS/LOST (such as non-compliant ISPs) and take corrective action (notify the regulator). On the topic of privacy; real-time IP location determination is a _MASSIVE_ privacy issue that will need to be addressed with public policy, not an RFC. Keep in mind that the VOIP provider already has sensitive personal information for the user so suffice to say that as long as the information is only accessible to authorized people, then exactly who those authorized people are is something for the politicians to decide. > "On behalf of" is needed when the device DOESN'T get it's location from its > access network. I think you have a point on the language of the on behalf > of language in -phonebcp, but your suggestion is not good enough. The > problem to be solved is one way or another we have to get location. The > current wording is aimed at proxies who think they ought to do it always, > and the language says, fine, as long as you CAN do it always. Actually, I think BCP would be: "Proxies MUST provide location on behalf of devices ONLY if the device does not provide it's own location." "If the device does not provide location and the proxy can't find location OBO the device, then the call MUST be routed to a 3rd party call centre for verbal location and routing." Regards, -- John Lange http://www.johnlange.ca From br@brianrosen.net Tue Jun 2 11:35:06 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 8B5C13A69B4 for ; Tue, 2 Jun 2009 11:35:06 -0700 (PDT) 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 sW7JoGDFIi4a for ; Tue, 2 Jun 2009 11:35:05 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1E89B3A6D18 for ; Tue, 2 Jun 2009 11:35:05 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MBYp6-0007it-AV; Tue, 02 Jun 2009 13:34:56 -0500 From: "Brian Rosen" To: "'John Lange'" , "'ecrit'" References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> In-Reply-To: <1243966386.4449.676.camel@vandium.darkcore.net> Date: Tue, 2 Jun 2009 14:35:02 -0400 Message-ID: <01d101c9e3b0$d90bfac0$8b23f040$@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: AcnjrdigyBjoUz8rTFC5oHjeldqJtgAAkavA 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] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 18:35:06 -0000 Why would the proxy really care to know if the device can get its own location? I would assume it would OBO as much as it could. In general, OBO isn't reliable unless there is a regulatory requirement to make relationships between providers exist in every case. You can't have environments where it doesn't always work (unless you know for sure that the access network provides location). You're focused on fixed devices, which is okay, but what you are describing won't (necessarily) work for mobile or nomadic devices. We're also familiar with the no DHCP in DSL environments. Although we recognize that this is the case today, we understand that is not the case tomorrow, and this whole document is aimed at new devices. If the access network is upgraded to handle location, it's likely to offer DHCP (and, BTW, it doesn't have to use DHCP to give out IP addresses). Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of John Lange > Sent: Tuesday, June 02, 2009 2:13 PM > To: ecrit > Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on > draft-ietf-ecrit-framework-09 > > I covered a lot of ground in my last post and I can tell from the > responses that some of the points weren't clear. > > I apologize so please let me clarify; > > - I'm not disputing that having the endpoint do network discovery of > location is the best first choice. > > What I'm saying is; > > 1) Endpoint location discovery via DHCP is not going to work for > residential so some other mechanism will need to be employed (and I > think it should be STUN + DNS). > > 2) The SIP Registrar needs to know if the end point has it's location > so > that the SIP Registrar can do OBO and discover the Emergency Services > Routing Proxy (ESRP) URI _before_ an emergency call is placed. > > 3) allowing the OBO to happen before the call will dramatically reduce > the network infrastructure requirements and therefore the cost of > implementing the solution because real-time IP location determination > done to a standard good enough for emergency call routing (less than 3 > seconds) requires a significantly more robust solution than a > query-cache methodology. > > --- > > The bottom line here is that if the device doesn't know it's location > and the SIP registrar isn't aware that it needs to do OBO, then in all > likelihood the device can not place an emergency call to the correct > ESRP since querying location on-the-fly will be too slow to route the > call correctly. > > That's it in a nutshell but I'm going to pull all the threads together > and reply with some more detail to some specific questions inline > below: > > On Mon, 2009-06-01 at 17:01 -0500, James M. Polk wrote: > > For LLDP, I fully agree with what you have above. I've had 4 ISPs > > over the last 10 years, and EACH of them have used DHCP, so I'm not > > sure where you get your data wrt DHCP not being supported in the > > residential market. > > I'm talking about residential firewall/routers. Someone else on this > list pointed me to this: > > "Location Information Server (LIS) Discovery From Behind Residential > Gateways" > > http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery- > 00 > > > >It would therefore seem that the emphasis should be on a LIS > discovery > > >mechanism that does not rely on the local network such as STUN + > DNS. > > > > How many vendors in the residential market do you know of that > implement STUN? > > STUN would be implemented by the VOIP provider and their devices would > be provisioned to query their own STUN servers. Many VOIP providers are > using STUN today and every recent VOIP device I've looked at recently > has an implementation of STUN so I submit that it is widely supported. > > > It appears you keep getting back to a solution that requires an > > upgrade in the access networks > > Not at all. That is precisely what I'm trying to avoid. > > > or endpoints. > > An upgrade to endpoints so they can do location is inevitable but the > OBO functionality is there to cover-off those devices which can not be > upgraded. > > On Mon, 2009-06-01 at 17:09 -0400, Brian Rosen wrote: > > There isn't any point in caching it at the proxy, and it's a privacy > > issue if it does. > > You are correct that caching isn't required if the device knows it's > location _provided that_ the proxy is aware that the device already has > it's location. > > However, as I stated above, if the devices doesn't know it's location > the registrar needs to know about it so it can do OBO. And if the > registrar is doing OBO then it needs to cache the result. > > So my point would be, if you are going to allow the registrar to do OBO > and cache results then it might as well cache location for the other > devices as well so it can use that information as a backup just in case > the device looses its location or becomes unreachable for some reason > (for example, lets say the internet to the endpoint drops during a 911 > call. If the proxy has the info cached it could answer OBO the device). > > Furthermore, (*** this is a critical point ***) if the device does not > provide location and the OBO server is not able to determine location, > this could trigger some other action. This allows VOIP providers to > easily identify "dead spots" in the LIS/LOST (such as non-compliant > ISPs) and take corrective action (notify the regulator). > > On the topic of privacy; real-time IP location determination is a > _MASSIVE_ privacy issue that will need to be addressed with public > policy, not an RFC. > > Keep in mind that the VOIP provider already has sensitive personal > information for the user so suffice to say that as long as the > information is only accessible to authorized people, then exactly who > those authorized people are is something for the politicians to decide. > > > "On behalf of" is needed when the device DOESN'T get it's location > from its > > access network. I think you have a point on the language of the on > behalf > > of language in -phonebcp, but your suggestion is not good enough. > The > > problem to be solved is one way or another we have to get location. > The > > current wording is aimed at proxies who think they ought to do it > always, > > and the language says, fine, as long as you CAN do it always. > > Actually, I think BCP would be: "Proxies MUST provide location on > behalf > of devices ONLY if the device does not provide it's own location." > > "If the device does not provide location and the proxy can't find > location OBO the device, then the call MUST be routed to a 3rd party > call centre for verbal location and routing." > > Regards, > -- > John Lange > http://www.johnlange.ca > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Jun 2 11:42:21 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 1AEAA3A6C33 for ; Tue, 2 Jun 2009 11:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[AWL=1.189, 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 MfC5WYKf0ybq for ; Tue, 2 Jun 2009 11:42:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C5EB53A6AC9 for ; Tue, 2 Jun 2009 11:42:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,292,1241395200"; d="scan'208";a="193695475" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 02 Jun 2009 18:42:20 +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 n52IgLVX019923; Tue, 2 Jun 2009 11:42:21 -0700 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 n52IgLTZ003694; Tue, 2 Jun 2009 18:42:21 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); Tue, 2 Jun 2009 11:42:20 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.6.102]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 11:42:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 13:42:19 -0500 To: John Lange , ecrit From: "James M. Polk" In-Reply-To: <1243966386.4449.676.camel@vandium.darkcore.net> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2009 18:42:20.0482 (UTC) FILETIME=[DC7F5A20:01C9E3B1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6377; t=1243968141; x=1244832141; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=C/LkqqiDC9QI6FWETv7wfjjJb/NE9nHC+2AGHJBNEuk=; b=Fj28545u9jsBLs+GkieC0KljdMHKUqVqTHDxScuef8UBFccTcbIKW1fjb9 D+JAK74/GY3vhi7L2m3BASH5DOJhPnlL2HBjMtKrOrItJyMtZpWqlnuewx9m rJM2FECWpR; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 18:42:21 -0000 At 01:13 PM 6/2/2009, John Lange wrote: >I covered a lot of ground in my last post and I can tell from the >responses that some of the points weren't clear. > >I apologize so please let me clarify; > >- I'm not disputing that having the endpoint do network discovery of >location is the best first choice. this was not clear in your original post. >What I'm saying is; > >1) Endpoint location discovery via DHCP is not going to work for >residential so some other mechanism will need to be employed (and I >think it should be STUN + DNS). > >2) The SIP Registrar needs to know if the end point has it's location so >that the SIP Registrar can do OBO and discover the Emergency Services >Routing Proxy (ESRP) URI _before_ an emergency call is placed. clearly a SIP server that doesn't receive location in a 911 call knows to include Ua location if it knows it. The issue is recognizing the call is 911 from the URI to know location needs to be looked for before transmitting the INVITE on. The trick is recognizing the URI as that of a PSAP (without the sos urn, that is). >3) allowing the OBO to happen before the call will dramatically reduce >the network infrastructure requirements and therefore the cost of >implementing the solution because real-time IP location determination >done to a standard good enough for emergency call routing (less than 3 >seconds) requires a significantly more robust solution than a >query-cache methodology. OBO before the fact means the location information could be stale/old/wrong... this was the argument for using a URI instead of actual location. It seems we can't get away from this little detail. >--- > >The bottom line here is that if the device doesn't know it's location >and the SIP registrar isn't aware that it needs to do OBO, then in all >likelihood the device can not place an emergency call to the correct >ESRP since querying location on-the-fly will be too slow to route the >call correctly. > >That's it in a nutshell but I'm going to pull all the threads together >and reply with some more detail to some specific questions inline below: > >On Mon, 2009-06-01 at 17:01 -0500, James M. Polk wrote: > > For LLDP, I fully agree with what you have above. I've had 4 ISPs > > over the last 10 years, and EACH of them have used DHCP, so I'm not > > sure where you get your data wrt DHCP not being supported in the > > residential market. > >I'm talking about residential firewall/routers. Someone else on this >list pointed me to this: > >"Location Information Server (LIS) Discovery From Behind Residential >Gateways" > >http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-00 > > > >It would therefore seem that the emphasis should be on a LIS discovery > > >mechanism that does not rely on the local network such as STUN + DNS. > > > > How many vendors in the residential market do you know of that > implement STUN? > >STUN would be implemented by the VOIP provider and their devices would >be provisioned to query their own STUN servers. Many VOIP providers are >using STUN today and every recent VOIP device I've looked at recently >has an implementation of STUN so I submit that it is widely supported. > > > It appears you keep getting back to a solution that requires an > > upgrade in the access networks > >Not at all. That is precisely what I'm trying to avoid. > > > or endpoints. > >An upgrade to endpoints so they can do location is inevitable but the >OBO functionality is there to cover-off those devices which can not be >upgraded. > >On Mon, 2009-06-01 at 17:09 -0400, Brian Rosen wrote: > > There isn't any point in caching it at the proxy, and it's a privacy > > issue if it does. > >You are correct that caching isn't required if the device knows it's >location _provided that_ the proxy is aware that the device already has >it's location. > >However, as I stated above, if the devices doesn't know it's location >the registrar needs to know about it so it can do OBO. And if the >registrar is doing OBO then it needs to cache the result. > >So my point would be, if you are going to allow the registrar to do OBO >and cache results then it might as well cache location for the other >devices as well so it can use that information as a backup just in case >the device looses its location or becomes unreachable for some reason >(for example, lets say the internet to the endpoint drops during a 911 >call. If the proxy has the info cached it could answer OBO the device). > >Furthermore, (*** this is a critical point ***) if the device does not >provide location and the OBO server is not able to determine location, >this could trigger some other action. This allows VOIP providers to >easily identify "dead spots" in the LIS/LOST (such as non-compliant >ISPs) and take corrective action (notify the regulator). > >On the topic of privacy; real-time IP location determination is a >_MASSIVE_ privacy issue that will need to be addressed with public >policy, not an RFC. > >Keep in mind that the VOIP provider already has sensitive personal >information for the user so suffice to say that as long as the >information is only accessible to authorized people, then exactly who >those authorized people are is something for the politicians to decide. > > > "On behalf of" is needed when the device DOESN'T get it's location from its > > access network. I think you have a point on the language of the on behalf > > of language in -phonebcp, but your suggestion is not good enough. The > > problem to be solved is one way or another we have to get location. The > > current wording is aimed at proxies who think they ought to do it always, > > and the language says, fine, as long as you CAN do it always. > >Actually, I think BCP would be: "Proxies MUST provide location on behalf >of devices ONLY if the device does not provide it's own location." > >"If the device does not provide location and the proxy can't find >location OBO the device, then the call MUST be routed to a 3rd party >call centre for verbal location and routing." > >Regards, >-- >John Lange >http://www.johnlange.ca > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From fmenard@xittelecom.com Tue Jun 2 13:15:58 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 87BF83A6E03 for ; Tue, 2 Jun 2009 13:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 p4xpwsMOV3iZ for ; Tue, 2 Jun 2009 13:15:56 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 648D53A68AB for ; Tue, 2 Jun 2009 13:15:56 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1MBUqe-000868-Pz; Tue, 02 Jun 2009 10:20:17 -0400 Received: from [205.151.16.4] (helo=[192.168.2.63]) by relay2.infoteck.qc.ca with esmtp (Exim 4.43) id 1MBV7c-0005ue-7b; Tue, 02 Jun 2009 10:37:50 -0400 Message-Id: From: =?ISO-8859-1?Q?=22Fran=E7ois_D._M=E9nard=22?= 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 v929.2) Date: Tue, 2 Jun 2009 10:36:01 -0400 References: <1243884311.17673.212.camel@vandium.darkcore.net> X-Mailer: Apple Mail (2.929.2) Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 20:15:58 -0000 See www.brisenet.net for my proposed architecture. We're currently costing the modification of ISC DHCPD to support Option 99 pass-through of PIDF-LO's and my ATA vendor is costing the inclusion of DHCP Option 99 & SIP LOCATION CONVEYANCE in their end- points, for submission to the CRTC in August. f. On 1-Jun-09, at 6:01 PM, James M. Polk wrote: > John > > some comments in-line below > > At 02:25 PM 6/1/2009, John Lange wrote: >> On April 15 2009, the Canadian Radio and Telecommunications >> Commission >> (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom >> Notice of Consultation CRTC 2009-194". >> >> http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm >> >> Paragraph 17 asks; "Are there alternative solutions that would >> improve >> on the current nomadic VoIP 9-1-1 service." >> >> The proposed architecture was developed by Bell Canada based very >> loosely on NENAi2 with extensive modifications. As it was developed >> by >> the ILECs in 2006/2007, it does not employ the IETF standards. >> >> I am working on a submission to this proceeding which advocates the >> implementation of the standards developed by the IETF's ECRIT working >> group and it's members. (As a side note, if there are any >> participants >> on this list which are interested in helping with this effort, >> please do >> contact me.) >> >> After examining draft-ietf-ecrit-framework-09 and it's related RFCs >> and >> RFC-drafts, I have some specific questions/concerns which I hope this >> list can answer. >> >> The Emergency Call Framework (ECF) as proposed : >> >> - Location is cached at end-point during boot/location discovery but >> there does not appear to be any mechanism whereby the end-point >> announces the success of this process to the SIP Registrar. > > This can be done with this specification: > http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-13.txt > > >> If the device is able to determine it's location it should relay the >> location information to the SIP registration server and the SIP >> registrar should cache this information. > > The registrar caching geolocation is not a protocol issue, it's a > configuration issue (once it receives the location from the > endpoint). Notice this does not have to be with the first REGISTER > request (meaning with a subsequent one), and/or it could be with > each REGISTER request. > > >> This allows the SIP Registrar and SIP proxy the ability to act >> "on-behalf-of" end points that are not able to determine their >> location >> either because they are not location capable, or because they are not >> able to determine location from their access provider. > > I'm missing what you mean by the starting "this" in the paragraph > above? > > If the UA has its location, nothing needs to act "on-behalf- > of" (OBO) it when sending location in any SIP request. > > >> Furthermore, it removes the burden of "real-time" "on-behalf-of" >> functionality from the rest of the network. > > If endpoints have their location (your original premise), OBO is > unnecessary -- which further reduces network complexity, no? > > >> The ability of the registrar to query and cache location data for >> endpoints as opposed to the requirement to perform location >> determination in real-time, has a dramatic impact on the technical >> requirements of the overall solution. > > How is this better or easier or an optimization from the endpoint > including its location in the SIP request in the first place? > > >> If location data must be queried in real-time during an actual >> emergency >> event, the network components must be engineered to a much higher >> standard. In some jurisdictions the mandated hardware and network >> requirements will be impacted significantly. No less than redundant >> five-nine hardware running on dedicated private networks will be >> required resulting in higher costs. > > again, all this goes away if the endpoint has its location prior to > placing the emergency call, then including this location information > if more current location information cannot be discovered easily. > Remember, unless you believe that everything needs to be built for > mobile endpoints (i.e., those that actually move from room to room > and from city to city with many times within the same day), being IP > based doesn't mean endpoints move much. Further, given the fact > that there are lower layer solutions already in place (802.11k and y > and 3GPP) -- the IETF doesn't need to solve everything moving as if > it was never where it is before. For example, my IP phones at home > haven't moved all day (or all week, or all year, etc) -- therefore > the location value they understand 1 minute ago, as well as a day > ago, and a month ago haven't changed. This makes these locations > valid for call routing and dispatch. > > Mobile nodes that are 3GPP based have their own way of tracking > location changes. > > Mobile nodes that are 802.11 based will likely have a valid location > for call routing at any time during the day, but dispatch could take > a bit longer to determine. The good thing here is that most systems > can determine location within 15 seconds for dispatch -- and I'd > like to meet the dispatchers that can make it to their destination > in time for that to be an issue ;-) > > >> I submit that a query-and-cache methodology is more in line with the >> spirit of other IETF protocols, the DNS system being a prime example. >> >> - Concerns with draft-ietf-geopriv-lis-discovery: >> >> The focus of LIS discovery seems to be on local access network >> methods >> such as DHCP and LLDP. >> >> DHCP & LLDP are not good choices for LIS discovery because they are >> not >> supported in the residential market. Residential firewall devices are >> not likely to have DHCP/LLDP functionality and the likelihood that >> these >> devices will be replaced or upgraded is small. > > For LLDP, I fully agree with what you have above. I've had 4 ISPs > over the last 10 years, and EACH of them have used DHCP, so I'm not > sure where you get your data wrt DHCP not being supported in the > residential market. > > >> It would therefore seem that the emphasis should be on a LIS >> discovery >> mechanism that does not rely on the local network such as STUN + DNS. > > How many vendors in the residential market do you know of that > implement STUN? > > It appears you keep getting back to a solution that requires an > upgrade in the access networks or endpoints. > > >> 1) Device determines its IP address by querying the STUN server. >> 2) Device determines its domain name using reverse DNS. >> 3) Device does LIS discovery via DNS (SRV/NAPTR). >> >> - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on >> behalf >> of devices if: The proxy has a relationship with all access >> networks the >> device could connect to". >> >> This wording seems overly restrictive; in effect "all access networks >> the device could connect to" amounts to every network on earth which >> seems like an unreasonably high standard. >> >> How about: >> >> "Proxies MAY provide location on behalf of devices if: the device >> does >> not provide it's own location and the proxy is able to determine >> location on-behalf-of the device. > > How does anyone know if this location OBO by the proxy is good > enough for dispatch? > > I think (and this is just my opinion) that proxies in this situation > will be just guessing where the endpoints are... > > >> Any comments and/or questions would be welcome. >> >> Regards, >> -- >> John Lange >> http://www.johnlange.ca >> >> _______________________________________________ >> 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 john@johnlange.ca Tue Jun 2 14:20:10 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 0B7F93A69B6 for ; Tue, 2 Jun 2009 14:20:10 -0700 (PDT) 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 CcBHroBw6xBt for ; Tue, 2 Jun 2009 14:20:08 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 183393A6931 for ; Tue, 2 Jun 2009 14:20:05 -0700 (PDT) Received: (qmail 3741 invoked from network); 2 Jun 2009 16:20:06 -0500 Received: from unknown (HELO ?192.168.4.54?) (192.168.4.54) by lh02.epicnet.ca with SMTP; 2 Jun 2009 16:20:05 -0500 From: John Lange To: Brian Rosen In-Reply-To: <01d101c9e3b0$d90bfac0$8b23f040$@net> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> Content-Type: text/plain Date: Tue, 02 Jun 2009 16:19:54 -0500 Message-Id: <1243977594.4449.813.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 21:20:10 -0000 On Tue, 2009-06-02 at 14:35 -0400, Brian Rosen wrote: > Why would the proxy really care to know if the device can get its own > location? I would assume it would OBO as much as it could. In general, OBO > isn't reliable unless there is a regulatory requirement to make > relationships between providers exist in every case. Yes, the IP location determination infrastructure requires a relationship between the VOIP Provider, the ESRP (PSAP), and the ASP/ISP. I took this as being understood because it's mentioned in the paragraph 2 of draft-ietf-ecrit-framework: "Supporting emergency calling requires cooperation by a number of elements, their vendors and service providers." The requirement to have a relationship between the providers isn't a significant obstacle. The regulator will say "you MUST implement this" and it will happen. The goal is to have a standard that can be followed so that when the mandate is imposed, the solution is known and hopefully there are already vendors who support it. > You can't have environments where it doesn't always work You can't? Well that makes some sense in the context of draft-ietf-ecrit-framework. Since the Internet is an environment that "doesn't always work", perhaps draft-ietf-ecrit-framework was not intended for use there? It makes no specific mention of this but by design it could only be deployed where the endpoint has a direct relationship with a local network that knows about location. That pretty much eliminates all residential and small/medium business. > You're focused on fixed devices, which is okay, but what you are describing > won't (necessarily) work for mobile or nomadic devices. What I envision will work for fixed and nomadic devices that access the internet through fixed access points that cover relatively small geographical areas. In other words, residential and small/medium businesses. Large enterprises would implement their own solutions and that is where the DHCP style solution described in the ecrit-framework makes the most sense. Mobile devices would also work depending on how they are accessing the internet but I don't want to side-track on the discussion of cell phones vs. mobile VOIP phones etc. > We're also familiar with the no DHCP in DSL environments. Although we > recognize that this is the case today, we understand that is not the case > tomorrow, and this whole document is aimed at new devices. As I said, maybe I've misunderstood the purpose of this group. If draft-ietf-ecrit-framework is just intended as "blue-sky" or use in the enterprise then I apologize for hijacking this list with my concerns over real-world implementation. > If the access network is upgraded to handle location, it's likely to > offer DHCP ... and a DHCP solution won't work behind residential firewalls and won't allow OBO functionality so it can't be implemented for the number one place where governments are likely to mandate a solution; nomadic/residential VOIP. IMHO, if you don't have a solution for residential then it's all just theory. That is why I'm advocating a closer look at something like STUN + DNS for LIS discovery. It will work, allows OBO and requires no new hardware. If the IETF publishes a standard then each jurisdiction can decide to implement it or not. Chances are good they will implement it because the advantage of implementing an IETF standard over some other "home-brew" solution is that your citizens can roam to other jurisdictions and vice-versa. Plus the likelihood of endpoints supporting the IETF standard at a reasonable cost is much higher than if vendors have to implement a unique solution for every jurisdiction. That is what standards are all about after all... On the other hand, I doubt any solution will ever be universally implemented but that's fine. As a VOIP provider I only have to meet the regulatory requirements in my jurisdiction, not every place on earth. Regards, -- John Lange http://www.johnlange.ca From James.Winterbottom@andrew.com Tue Jun 2 14:28: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 3DF183A683F for ; Tue, 2 Jun 2009 14:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] 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 18oYBRaQ9ZCI for ; Tue, 2 Jun 2009 14:28:18 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 80A493A681F for ; Tue, 2 Jun 2009 14:28:18 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_02_16_49_46 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, 02 Jun 2009 16:49:46 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 16:28:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jun 2009 16:27:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 Thread-Index: AcnjvvTdFfzsLSn2QSWSeC2qxvkMDgACeirU References: <1243884311.17673.212.camel@vandium.darkcore.net> From: "Winterbottom, James" To: =?iso-8859-1?Q?=22Fran=E7ois_D=2E_M=E9nard=22?= , "James M. Polk" X-OriginalArrivalTime: 02 Jun 2009 21:28:19.0008 (UTC) FILETIME=[0C3DD400:01C9E3C9] Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 21:28:20 -0000 =0D=0AHow will address the millions of already deployed terminals and route= rs=3F=0D=0A=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bo= unces@ietf.org on behalf of "Fran=E7ois D. M=E9nard"=0D=0ASent: Tue 6/2/200= 9 9:36 AM=0D=0ATo: James M. Polk=0D=0ACc: ecrit=0D=0ASubject: Re: [Ecrit] E= mergency Call Framework for Canada;Questions on draft-ietf-ecrit-framework= -09=0D=0A=20=0D=0A=0D=0ASee www.brisenet.net for my proposed architecture.=0D= =0A=0D=0AWe're currently costing the modification of ISC DHCPD to support =0D= =0AOption 99 pass-through of PIDF-LO's and my ATA vendor is costing the =0D= =0Ainclusion of DHCP Option 99 & SIP LOCATION CONVEYANCE in their end-=20=0D= =0Apoints, for submission to the CRTC in August.=0D=0A=0D=0Af.=0D=0A=0D=0A=0D= =0AOn 1-Jun-09, at 6:01 PM, James M. Polk wrote:=0D=0A=0D=0A> John=0D=0A>=0D= =0A> some comments in-line below=0D=0A>=0D=0A> At 02:25 PM 6/1/2009, John L= ange wrote:=0D=0A>> On April 15 2009, the Canadian Radio and Telecommunicat= ions =20=0D=0A>> Commission=0D=0A>> (CRTC), which is the Canadian equivalen= t of the FCC, issued "Telecom=0D=0A>> Notice of Consultation CRTC 2009-194"= =2E=0D=0A>>=0D=0A>> http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm=0D=0A= >>=0D=0A>> Paragraph 17 asks; "Are there alternative solutions that would =0D= =0A>> improve=0D=0A>> on the current nomadic VoIP 9-1-1 service."=0D=0A>>=0D= =0A>> The proposed architecture was developed by Bell Canada based very=0D=0A= >> loosely on NENAi2 with extensive modifications. As it was developed =20=0D= =0A>> by=0D=0A>> the ILECs in 2006/2007, it does not employ the IETF standa= rds.=0D=0A>>=0D=0A>> I am working on a submission to this proceeding which = advocates the=0D=0A>> implementation of the standards developed by the IETF= 's ECRIT working=0D=0A>> group and it's members. (As a side note, if there = are any =20=0D=0A>> participants=0D=0A>> on this list which are interested = in helping with this effort, =20=0D=0A>> please do=0D=0A>> contact me.)=0D=0A= >>=0D=0A>> After examining draft-ietf-ecrit-framework-09 and it's related R= FCs =20=0D=0A>> and=0D=0A>> RFC-drafts, I have some specific questions/conc= erns which I hope this=0D=0A>> list can answer.=0D=0A>>=0D=0A>> The Emergen= cy Call Framework (ECF) as proposed :=0D=0A>>=0D=0A>> - Location is cached = at end-point during boot/location discovery but=0D=0A>> there does not appe= ar to be any mechanism whereby the end-point=0D=0A>> announces the success = of this process to the SIP Registrar.=0D=0A>=0D=0A> This can be done with t= his specification:=0D=0A> http://www.ietf.org/internet-drafts/draft-ietf-si= p-location-conveyance-13.txt=0D=0A>=0D=0A>=0D=0A>> If the device is able to= determine it's location it should relay the=0D=0A>> location information t= o the SIP registration server and the SIP=0D=0A>> registrar should cache th= is information.=0D=0A>=0D=0A> The registrar caching geolocation is not a pr= otocol issue, it's a =20=0D=0A> configuration issue (once it receives the l= ocation from the =20=0D=0A> endpoint). Notice this does not have to be with= the first REGISTER =20=0D=0A> request (meaning with a subsequent one), and= /or it could be with =20=0D=0A> each REGISTER request.=0D=0A>=0D=0A>=0D=0A>= > This allows the SIP Registrar and SIP proxy the ability to act=0D=0A>> "o= n-behalf-of" end points that are not able to determine their =20=0D=0A>> lo= cation=0D=0A>> either because they are not location capable, or because the= y are not=0D=0A>> able to determine location from their access provider.=0D= =0A>=0D=0A> I'm missing what you mean by the starting "this" in the paragra= ph =20=0D=0A> above=3F=0D=0A>=0D=0A> If the UA has its location, nothing ne= eds to act "on-behalf-=20=0D=0A> of" (OBO) it when sending location in any = SIP request.=0D=0A>=0D=0A>=0D=0A>> Furthermore, it removes the burden of "r= eal-time" "on-behalf-of"=0D=0A>> functionality from the rest of the network= =2E=0D=0A>=0D=0A> If endpoints have their location (your original premise),= OBO is =20=0D=0A> unnecessary -- which further reduces network complexity,= no=3F=0D=0A>=0D=0A>=0D=0A>> The ability of the registrar to query and cach= e location data for=0D=0A>> endpoints as opposed to the requirement to perf= orm location=0D=0A>> determination in real-time, has a dramatic impact on t= he technical=0D=0A>> requirements of the overall solution.=0D=0A>=0D=0A> Ho= w is this better or easier or an optimization from the endpoint =20=0D=0A> = including its location in the SIP request in the first place=3F=0D=0A>=0D=0A= >=0D=0A>> If location data must be queried in real-time during an actual =0D= =0A>> emergency=0D=0A>> event, the network components must be engineered to= a much higher=0D=0A>> standard. In some jurisdictions the mandated hardwar= e and network=0D=0A>> requirements will be impacted significantly. No less = than redundant=0D=0A>> five-nine hardware running on dedicated private netw= orks will be=0D=0A>> required resulting in higher costs.=0D=0A>=0D=0A> agai= n, all this goes away if the endpoint has its location prior to =20=0D=0A> = placing the emergency call, then including this location information =20=0D= =0A> if more current location information cannot be discovered easily. =20=0D= =0A> Remember, unless you believe that everything needs to be built for =0D= =0A> mobile endpoints (i.e., those that actually move from room to room =0D= =0A> and from city to city with many times within the same day), being IP =0D= =0A> based doesn't mean endpoints move much. Further, given the fact =20=0D= =0A> that there are lower layer solutions already in place (802.11k and y =0D= =0A> and 3GPP) -- the IETF doesn't need to solve everything moving as if =0D= =0A> it was never where it is before. For example, my IP phones at home =0D= =0A> haven't moved all day (or all week, or all year, etc) -- therefore =0D= =0A> the location value they understand 1 minute ago, as well as a day =20=0D= =0A> ago, and a month ago haven't changed. This makes these locations =20=0D= =0A> valid for call routing and dispatch.=0D=0A>=0D=0A> Mobile nodes that a= re 3GPP based have their own way of tracking =20=0D=0A> location changes.=0D= =0A>=0D=0A> Mobile nodes that are 802.11 based will likely have a valid loc= ation =20=0D=0A> for call routing at any time during the day, but dispatch = could take =20=0D=0A> a bit longer to determine. The good thing here is tha= t most systems =20=0D=0A> can determine location within 15 seconds for disp= atch -- and I'd =20=0D=0A> like to meet the dispatchers that can make it to= their destination =20=0D=0A> in time for that to be an issue ;-)=0D=0A>=0D= =0A>=0D=0A>> I submit that a query-and-cache methodology is more in line wi= th the=0D=0A>> spirit of other IETF protocols, the DNS system being a prime= example.=0D=0A>>=0D=0A>> - Concerns with draft-ietf-geopriv-lis-discovery:=0D= =0A>>=0D=0A>> The focus of LIS discovery seems to be on local access networ= k =20=0D=0A>> methods=0D=0A>> such as DHCP and LLDP.=0D=0A>>=0D=0A>> DHCP &= LLDP are not good choices for LIS discovery because they are =20=0D=0A>> n= ot=0D=0A>> supported in the residential market. Residential firewall device= s are=0D=0A>> not likely to have DHCP/LLDP functionality and the likelihood= that =20=0D=0A>> these=0D=0A>> devices will be replaced or upgraded is sma= ll.=0D=0A>=0D=0A> For LLDP, I fully agree with what you have above. I've ha= d 4 ISPs =20=0D=0A> over the last 10 years, and EACH of them have used DHCP= , so I'm not =20=0D=0A> sure where you get your data wrt DHCP not being sup= ported in the =20=0D=0A> residential market.=0D=0A>=0D=0A>=0D=0A>> It would= therefore seem that the emphasis should be on a LIS =20=0D=0A>> discovery=0D= =0A>> mechanism that does not rely on the local network such as STUN + DNS.=0D= =0A>=0D=0A> How many vendors in the residential market do you know of that = =20=0D=0A> implement STUN=3F=0D=0A>=0D=0A> It appears you keep getting back= to a solution that requires an =20=0D=0A> upgrade in the access networks o= r endpoints.=0D=0A>=0D=0A>=0D=0A>> 1) Device determines its IP address by q= uerying the STUN server.=0D=0A>> 2) Device determines its domain name using= reverse DNS.=0D=0A>> 3) Device does LIS discovery via DNS (SRV/NAPTR).=0D=0A= >>=0D=0A>> - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location o= n =20=0D=0A>> behalf=0D=0A>> of devices if: The proxy has a relationship wi= th all access =20=0D=0A>> networks the=0D=0A>> device could connect to".=0D= =0A>>=0D=0A>> This wording seems overly restrictive; in effect "all access = networks=0D=0A>> the device could connect to" amounts to every network on e= arth which=0D=0A>> seems like an unreasonably high standard.=0D=0A>>=0D=0A>= > How about:=0D=0A>>=0D=0A>> "Proxies MAY provide location on behalf of dev= ices if: the device =20=0D=0A>> does=0D=0A>> not provide it's own location = and the proxy is able to determine=0D=0A>> location on-behalf-of the device= =2E=0D=0A>=0D=0A> How does anyone know if this location OBO by the proxy is= good =20=0D=0A> enough for dispatch=3F=0D=0A>=0D=0A> I think (and this is = just my opinion) that proxies in this situation =20=0D=0A> will be just gue= ssing where the endpoints are...=0D=0A>=0D=0A>=0D=0A>> Any comments and/or = questions would be welcome.=0D=0A>>=0D=0A>> Regards,=0D=0A>> --=0D=0A>> Joh= n Lange=0D=0A>> http://www.johnlange.ca=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> 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=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A From john@johnlange.ca Tue Jun 2 14:40:05 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 8AA2D3A6C64 for ; Tue, 2 Jun 2009 14:40:05 -0700 (PDT) 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 th1LQ7Dc0PDG for ; Tue, 2 Jun 2009 14:40:04 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 596EE3A6985 for ; Tue, 2 Jun 2009 14:39:50 -0700 (PDT) Received: (qmail 8554 invoked from network); 2 Jun 2009 16:39:50 -0500 Received: from unknown (HELO ?192.168.4.54?) (192.168.4.54) by lh02.epicnet.ca with SMTP; 2 Jun 2009 16:39:50 -0500 From: John Lange To: "James M. Polk" In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> Content-Type: text/plain Date: Tue, 02 Jun 2009 16:39:39 -0500 Message-Id: <1243978779.4449.826.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 21:40:05 -0000 On Tue, 2009-06-02 at 13:42 -0500, James M. Polk wrote: > clearly a SIP server that doesn't receive location in a 911 call > knows to include Ua location if it knows it. Under the proposed draft-ietf-ecrit-framework, the sip registrar will never know the location of the end-point and certainly not in time to route the call to the correct PSAP. > OBO before the fact means the location information could be > stale/old/wrong... this was the argument for using a URI instead of > actual location. It seems we can't get away from this little detail. Yes, it "could be" but that is very unlikely. How often will a device roam so far from the location it was at when it registered with the VOIP provider that the cached location can't be used for routing to the correct ESRP/PSAP? And don't forget that an updated location can still be queried during the call to erase any doubt. There will always be examples of where it won't work, wifi on trains and plains is a good example so they'll have to implement their own location or we'll have to live with it. If we wait for a solution that solves every possible scenario then we'll just have to invent new scenarios ;) -- John Lange http://www.johnlange.ca From br@brianrosen.net Tue Jun 2 14:44:17 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 034BD3A6901 for ; Tue, 2 Jun 2009 14:44:17 -0700 (PDT) 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 39tYJzZUBgou for ; Tue, 2 Jun 2009 14:44:15 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id ABB453A68E0 for ; Tue, 2 Jun 2009 14:44:15 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MBbm9-0002eJ-Bj; Tue, 02 Jun 2009 16:44:05 -0500 From: "Brian Rosen" To: "'John Lange'" References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> In-Reply-To: <1243977594.4449.813.camel@vandium.darkcore.net> Date: Tue, 2 Jun 2009 17:44:12 -0400 Message-ID: <023801c9e3cb$46467a60$d2d36f20$@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: Acnjx+LPT+frwCBYRiKpntzRr/mG2AAATVEg 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: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 21:44:17 -0000 We're trying to define real world solutions. We may fail, but we're trying. OBO doesn't always work, because by the time a call gets to a VoIP provider, it's IP address can be obscured by VPNs. It doesn't work because the regulator can't force connections between a service provider it doesn't have jurisdiction over to an access network (which it probably always has jurisdiction over, because it's always local). The easy example is my famous "Sierra Leone VoIP Services Pty" provider serving a customer at a Starbucks in, say, Calgary. You can scream all you want, but CRTC can't tell SLVS to connect to Rogers Cable. On the other hand, the device can get location from the hotspot in Starbucks, who can pass it through SLVS on it's way to the Calgary PSAP. OBO is usually aimed at transition: before we get the devices all upgraded, what do we do. In that environment, we may not be able to get location every time, although I think the VPN problem is so prevalent that it's going to fail too often. I'm still in favor of trying to get OBO to work, for transition only, and with the caveat that it may not always work. DHCP works very well in residential VoIP. The phone may have a NATed address, but as long as the home router passes the location option, the query to the provider will have the right thing to get the DHCP system to return the location of the residence. If you don't like DHCP, use HELD, but you still have some remnants of the VPN problem. Don't confuse DHCP for LIS discovery with DHCP for location configuration. Both work, but DHCP discovery of a HELD server works. I've stayed out of most of the LIS discovery discussions because I don't seem to have much to offer. I'll let others reply to STUN + Reverse lookup + SRV. It's been discussed many times. Brian > -----Original Message----- > From: John Lange [mailto:john@johnlange.ca] > Sent: Tuesday, June 02, 2009 5:20 PM > To: Brian Rosen > Cc: 'ecrit' > Subject: RE: [Ecrit] Emergency Call Framework for Canada; Questions on > draft-ietf-ecrit-framework-09 > > On Tue, 2009-06-02 at 14:35 -0400, Brian Rosen wrote: > > Why would the proxy really care to know if the device can get its own > > location? I would assume it would OBO as much as it could. In > general, OBO > > isn't reliable unless there is a regulatory requirement to make > > relationships between providers exist in every case. > > Yes, the IP location determination infrastructure requires a > relationship between the VOIP Provider, the ESRP (PSAP), and the > ASP/ISP. I took this as being understood because it's mentioned in the > paragraph 2 of draft-ietf-ecrit-framework: "Supporting emergency > calling > requires cooperation by a number of elements, their vendors and service > providers." > > The requirement to have a relationship between the providers isn't a > significant obstacle. The regulator will say "you MUST implement this" > and it will happen. The goal is to have a standard that can be followed > so that when the mandate is imposed, the solution is known and > hopefully > there are already vendors who support it. > > > You can't have environments where it doesn't always work > > You can't? Well that makes some sense in the context of > draft-ietf-ecrit-framework. Since the Internet is an environment that > "doesn't always work", perhaps draft-ietf-ecrit-framework was not > intended for use there? It makes no specific mention of this but by > design it could only be deployed where the endpoint has a direct > relationship with a local network that knows about location. That > pretty > much eliminates all residential and small/medium business. > > > You're focused on fixed devices, which is okay, but what you are > describing > > won't (necessarily) work for mobile or nomadic devices. > > What I envision will work for fixed and nomadic devices that access the > internet through fixed access points that cover relatively small > geographical areas. In other words, residential and small/medium > businesses. > > Large enterprises would implement their own solutions and that is where > the DHCP style solution described in the ecrit-framework makes the most > sense. > > Mobile devices would also work depending on how they are accessing the > internet but I don't want to side-track on the discussion of cell > phones > vs. mobile VOIP phones etc. > > > We're also familiar with the no DHCP in DSL environments. Although we > > recognize that this is the case today, we understand that is not the > case > > tomorrow, and this whole document is aimed at new devices. > > As I said, maybe I've misunderstood the purpose of this group. If > draft-ietf-ecrit-framework is just intended as "blue-sky" or use in the > enterprise then I apologize for hijacking this list with my concerns > over real-world implementation. > > > If the access network is upgraded to handle location, it's likely to > > offer DHCP > > ... and a DHCP solution won't work behind residential firewalls and > won't allow OBO functionality so it can't be implemented for the number > one place where governments are likely to mandate a solution; > nomadic/residential VOIP. > > IMHO, if you don't have a solution for residential then it's all just > theory. > > That is why I'm advocating a closer look at something like STUN + DNS > for LIS discovery. It will work, allows OBO and requires no new > hardware. > > If the IETF publishes a standard then each jurisdiction can decide to > implement it or not. > > Chances are good they will implement it because the advantage of > implementing an IETF standard over some other "home-brew" solution is > that your citizens can roam to other jurisdictions and vice-versa. Plus > the likelihood of endpoints supporting the IETF standard at a > reasonable > cost is much higher than if vendors have to implement a unique solution > for every jurisdiction. > > That is what standards are all about after all... > > On the other hand, I doubt any solution will ever be universally > implemented but that's fine. As a VOIP provider I only have to meet the > regulatory requirements in my jurisdiction, not every place on earth. > > Regards, > -- > John Lange > http://www.johnlange.ca From James.Winterbottom@andrew.com Tue Jun 2 14:44:59 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 6ED6F3A690A for ; Tue, 2 Jun 2009 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] 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 EfsQrRDbzqE5 for ; Tue, 2 Jun 2009 14:44:58 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B547E3A68E0 for ; Tue, 2 Jun 2009 14:44:57 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_02_17_06_24 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); Tue, 02 Jun 2009 17:06:24 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 16:44:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jun 2009 16:41:56 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 Thread-Index: AcnjynLUg1tc1m0lTzOVbf4grQ+5mgAAICk4 References: <1243884311.17673.212.camel@vandium.darkcore.net> From: "Winterbottom, James" To: =?iso-8859-1?Q?=22Fran=E7ois_D=2E_M=E9nard=22?= X-OriginalArrivalTime: 02 Jun 2009 21:44:57.0442 (UTC) FILETIME=[5F5AC420:01C9E3CB] Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 21:44:59 -0000 That is not entirely true.=0D=0AIt works for any device that is behind a re= sidential gateway.=0D=0ASo, unless I am mistaken, your proposal will also r= equire every single residential gateway to be updated AND, for all DSL that= uses PPP as opposed to DHCP to be upgraded either to use DHCP or to suppor= t modifications so that a new options is available over PPP, and supported = by the RG.=0D=0A=0D=0AI think that this number is substantially more than t= he 400,000 devices you are talking about and a massive massive cost in infr= astructure upgrade, substantially more that the $500m you are talking about= =2E=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original Message----= -=0D=0AFrom: "Fran=E7ois D. M=E9nard" [mailto:fmenard@xittelecom.com]=0D=0A= Sent: Tue 6/2/2009 4:38 PM=0D=0ATo: Winterbottom, James=0D=0ACc: James M. P= olk; ecrit=0D=0ASubject: Re: [Ecrit] Emergency Call Framework for Canada;Qu= estions on draft-ietf-ecrit-framework-09=0D=0A=20=0D=0AJames,=0D=0A=0D=0AT= he architecture that ILECs are proposing in Canada does not work for =20=0D= =0Adevices which are not on the public Internet.=0D=0A=0D=0AIt'll be cheape= r to upgrade 400,000 ATAs in Canada than to spend 500M$ =20=0D=0Aon impleme= ntation of a non-ECRIT solution.=0D=0A=0D=0AF.=0D=0A=0D=0A=0D=0A=0D=0AOn 2-= Jun-09, at 5:27 PM, Winterbottom, James wrote:=0D=0A=0D=0A>=0D=0A> How will= address the millions of already deployed terminals and =20=0D=0A> routers=3F=0D= =0A>=0D=0A>=0D=0A>=0D=0A> -----Original Message-----=0D=0A> From: ecrit-bou= nces@ietf.org on behalf of "Fran=E7ois D. M=E9nard"=0D=0A> Sent: Tue 6/2/20= 09 9:36 AM=0D=0A> To: James M. Polk=0D=0A> Cc: ecrit=0D=0A> Subject: Re: [E= crit] Emergency Call Framework for Canada;Questions =20=0D=0A> on draft-ie= tf-ecrit-framework-09=0D=0A>=0D=0A>=0D=0A> See www.brisenet.net for my prop= osed architecture.=0D=0A>=0D=0A> We're currently costing the modification o= f ISC DHCPD to support=0D=0A> Option 99 pass-through of PIDF-LO's and my A= TA vendor is costing the=0D=0A> inclusion of DHCP Option 99 & SIP LOCATION = CONVEYANCE in their end-=0D=0A> points, for submission to the CRTC in Augus= t.=0D=0A>=0D=0A> f.=0D=0A>=0D=0A>=0D=0A> On 1-Jun-09, at 6:01 PM, James M. = Polk wrote:=0D=0A>=0D=0A>> John=0D=0A>>=0D=0A>> some comments in-line below=0D= =0A>>=0D=0A>> At 02:25 PM 6/1/2009, John Lange wrote:=0D=0A>>> On April 15 = 2009, the Canadian Radio and Telecommunications=0D=0A>>> Commission=0D=0A>>= > (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom=0D=0A= >>> Notice of Consultation CRTC 2009-194".=0D=0A>>>=0D=0A>>> http://www.crt= c.gc.ca/eng/archive/2009/2009-194.htm=0D=0A>>>=0D=0A>>> Paragraph 17 asks; = "Are there alternative solutions that would=0D=0A>>> improve=0D=0A>>> on th= e current nomadic VoIP 9-1-1 service."=0D=0A>>>=0D=0A>>> The proposed archi= tecture was developed by Bell Canada based very=0D=0A>>> loosely on NENAi2 = with extensive modifications. As it was developed=0D=0A>>> by=0D=0A>>> the = ILECs in 2006/2007, it does not employ the IETF standards.=0D=0A>>>=0D=0A>>= > I am working on a submission to this proceeding which advocates the=0D=0A= >>> implementation of the standards developed by the IETF's ECRIT =20=0D=0A= >>> working=0D=0A>>> group and it's members. (As a side note, if there are = any=0D=0A>>> participants=0D=0A>>> on this list which are interested in hel= ping with this effort,=0D=0A>>> please do=0D=0A>>> contact me.)=0D=0A>>>=0D= =0A>>> After examining draft-ietf-ecrit-framework-09 and it's related RFCs=0D= =0A>>> and=0D=0A>>> RFC-drafts, I have some specific questions/concerns whi= ch I hope =20=0D=0A>>> this=0D=0A>>> list can answer.=0D=0A>>>=0D=0A>>> The= Emergency Call Framework (ECF) as proposed :=0D=0A>>>=0D=0A>>> - Location = is cached at end-point during boot/location discovery but=0D=0A>>> there do= es not appear to be any mechanism whereby the end-point=0D=0A>>> announces = the success of this process to the SIP Registrar.=0D=0A>>=0D=0A>> This can = be done with this specification:=0D=0A>> http://www.ietf.org/internet-draft= s/draft-ietf-sip-location-conveyance-13.txt=0D=0A>>=0D=0A>>=0D=0A>>> If the= device is able to determine it's location it should relay the=0D=0A>>> loc= ation information to the SIP registration server and the SIP=0D=0A>>> regis= trar should cache this information.=0D=0A>>=0D=0A>> The registrar caching g= eolocation is not a protocol issue, it's a=0D=0A>> configuration issue (onc= e it receives the location from the=0D=0A>> endpoint). Notice this does not= have to be with the first REGISTER=0D=0A>> request (meaning with a subsequ= ent one), and/or it could be with=0D=0A>> each REGISTER request.=0D=0A>>=0D= =0A>>=0D=0A>>> This allows the SIP Registrar and SIP proxy the ability to a= ct=0D=0A>>> "on-behalf-of" end points that are not able to determine their=0D= =0A>>> location=0D=0A>>> either because they are not location capable, or b= ecause they are =20=0D=0A>>> not=0D=0A>>> able to determine location from t= heir access provider.=0D=0A>>=0D=0A>> I'm missing what you mean by the star= ting "this" in the paragraph=0D=0A>> above=3F=0D=0A>>=0D=0A>> If the UA has= its location, nothing needs to act "on-behalf-=0D=0A>> of" (OBO) it when s= ending location in any SIP request.=0D=0A>>=0D=0A>>=0D=0A>>> Furthermore, i= t removes the burden of "real-time" "on-behalf-of"=0D=0A>>> functionality f= rom the rest of the network.=0D=0A>>=0D=0A>> If endpoints have their locati= on (your original premise), OBO is=0D=0A>> unnecessary -- which further red= uces network complexity, no=3F=0D=0A>>=0D=0A>>=0D=0A>>> The ability of the = registrar to query and cache location data for=0D=0A>>> endpoints as oppose= d to the requirement to perform location=0D=0A>>> determination in real-tim= e, has a dramatic impact on the technical=0D=0A>>> requirements of the over= all solution.=0D=0A>>=0D=0A>> How is this better or easier or an optimizati= on from the endpoint=0D=0A>> including its location in the SIP request in t= he first place=3F=0D=0A>>=0D=0A>>=0D=0A>>> If location data must be queried= in real-time during an actual=0D=0A>>> emergency=0D=0A>>> event, the netwo= rk components must be engineered to a much higher=0D=0A>>> standard. In som= e jurisdictions the mandated hardware and network=0D=0A>>> requirements wil= l be impacted significantly. No less than redundant=0D=0A>>> five-nine hard= ware running on dedicated private networks will be=0D=0A>>> required result= ing in higher costs.=0D=0A>>=0D=0A>> again, all this goes away if the endpo= int has its location prior to=0D=0A>> placing the emergency call, then incl= uding this location information=0D=0A>> if more current location informatio= n cannot be discovered easily.=0D=0A>> Remember, unless you believe that ev= erything needs to be built for=0D=0A>> mobile endpoints (i.e., those that a= ctually move from room to room=0D=0A>> and from city to city with many time= s within the same day), being IP=0D=0A>> based doesn't mean endpoints move = much. Further, given the fact=0D=0A>> that there are lower layer solutions= already in place (802.11k and y=0D=0A>> and 3GPP) -- the IETF doesn't need= to solve everything moving as if=0D=0A>> it was never where it is before. = For example, my IP phones at home=0D=0A>> haven't moved all day (or all we= ek, or all year, etc) -- therefore=0D=0A>> the location value they understa= nd 1 minute ago, as well as a day=0D=0A>> ago, and a month ago haven't chan= ged. This makes these locations=0D=0A>> valid for call routing and dispatch= =2E=0D=0A>>=0D=0A>> Mobile nodes that are 3GPP based have their own way of = tracking=0D=0A>> location changes.=0D=0A>>=0D=0A>> Mobile nodes that are 80= 2.11 based will likely have a valid location=0D=0A>> for call routing at an= y time during the day, but dispatch could take=0D=0A>> a bit longer to dete= rmine. The good thing here is that most systems=0D=0A>> can determine locat= ion within 15 seconds for dispatch -- and I'd=0D=0A>> like to meet the disp= atchers that can make it to their destination=0D=0A>> in time for that to b= e an issue ;-)=0D=0A>>=0D=0A>>=0D=0A>>> I submit that a query-and-cache me= thodology is more in line with the=0D=0A>>> spirit of other IETF protocols,= the DNS system being a prime =20=0D=0A>>> example.=0D=0A>>>=0D=0A>>> - Con= cerns with draft-ietf-geopriv-lis-discovery:=0D=0A>>>=0D=0A>>> The focus of= LIS discovery seems to be on local access network=0D=0A>>> methods=0D=0A>>= > such as DHCP and LLDP.=0D=0A>>>=0D=0A>>> DHCP & LLDP are not good choices= for LIS discovery because they are=0D=0A>>> not=0D=0A>>> supported in the = residential market. Residential firewall devices =20=0D=0A>>> are=0D=0A>>> = not likely to have DHCP/LLDP functionality and the likelihood that=0D=0A>>>= these=0D=0A>>> devices will be replaced or upgraded is small.=0D=0A>>=0D=0A= >> For LLDP, I fully agree with what you have above. I've had 4 ISPs=0D=0A>= > over the last 10 years, and EACH of them have used DHCP, so I'm not=0D=0A= >> sure where you get your data wrt DHCP not being supported in the=0D=0A>>= residential market.=0D=0A>>=0D=0A>>=0D=0A>>> It would therefore seem that = the emphasis should be on a LIS=0D=0A>>> discovery=0D=0A>>> mechanism that = does not rely on the local network such as STUN + =20=0D=0A>>> DNS.=0D=0A>>=0D= =0A>> How many vendors in the residential market do you know of that=0D=0A>= > implement STUN=3F=0D=0A>>=0D=0A>> It appears you keep getting back to a s= olution that requires an=0D=0A>> upgrade in the access networks or endpoint= s.=0D=0A>>=0D=0A>>=0D=0A>>> 1) Device determines its IP address by querying= the STUN server.=0D=0A>>> 2) Device determines its domain name using rever= se DNS.=0D=0A>>> 3) Device does LIS discovery via DNS (SRV/NAPTR).=0D=0A>>>=0D= =0A>>> - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on=0D= =0A>>> behalf=0D=0A>>> of devices if: The proxy has a relationship with all= access=0D=0A>>> networks the=0D=0A>>> device could connect to".=0D=0A>>>=0D= =0A>>> This wording seems overly restrictive; in effect "all access =20=0D=0A= >>> networks=0D=0A>>> the device could connect to" amounts to every network= on earth which=0D=0A>>> seems like an unreasonably high standard.=0D=0A>>>=0D= =0A>>> How about:=0D=0A>>>=0D=0A>>> "Proxies MAY provide location on behalf= of devices if: the device=0D=0A>>> does=0D=0A>>> not provide it's own loca= tion and the proxy is able to determine=0D=0A>>> location on-behalf-of the = device.=0D=0A>>=0D=0A>> How does anyone know if this location OBO by the pr= oxy is good=0D=0A>> enough for dispatch=3F=0D=0A>>=0D=0A>> I think (and thi= s is just my opinion) that proxies in this situation=0D=0A>> will be just g= uessing where the endpoints are...=0D=0A>>=0D=0A>>=0D=0A>>> Any comments an= d/or questions would be welcome.=0D=0A>>>=0D=0A>>> Regards,=0D=0A>>> --=0D=0A= >>> John Lange=0D=0A>>> http://www.johnlange.ca=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>> Ecrit mai= ling list=0D=0A>> Ecrit@ietf.org=0D=0A>> https://www.ietf.org/mailman/listi= nfo/ecrit=0D=0A>=0D=0A> _______________________________________________=0D=0A= > Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mail= man/listinfo/ecrit=0D=0A>=0D=0A>=0D=0A> -----------------------------------= -------------------------------------------------------------=0D=0A> This m= essage is for the designated recipient only and may=0D=0A> contain privileg= ed, proprietary, or otherwise private information.=0D=0A> If you have recei= ved it in error, please notify the sender=0D=0A> immediately and delete the= original. Any unauthorized use of=0D=0A> this email is prohibited.=0D=0A>= --------------------------------------------------------------------------= ----------------------=0D=0A> [mf2]=0D=0A>=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=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A From jmpolk@cisco.com Tue Jun 2 14:50:21 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 65FD53A6926 for ; Tue, 2 Jun 2009 14:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.806 X-Spam-Level: X-Spam-Status: No, score=-5.806 tagged_above=-999 required=5 tests=[AWL=0.792, 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 sDMaWx39Baic for ; Tue, 2 Jun 2009 14:50:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 955823A6BD6 for ; Tue, 2 Jun 2009 14:49:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,293,1241395200"; d="scan'208";a="193794737" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Jun 2009 21:49:27 +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 n52LnQd9025806; Tue, 2 Jun 2009 14:49:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n52LnQFp005765; Tue, 2 Jun 2009 21:49:26 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.3959); Tue, 2 Jun 2009 14:49:26 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.6.102]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 14:49:25 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 16:49:24 -0500 To: John Lange , Brian Rosen From: "James M. Polk" In-Reply-To: <1243977594.4449.813.camel@vandium.darkcore.net> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2009 21:49:26.0107 (UTC) FILETIME=[FF7DCAB0:01C9E3CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=335; t=1243979366; x=1244843366; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=C2VGAK0zUMY7tz4+KdgVixRardSd6QOImngpnbFWBV8=; b=o0oyMMkwz/zFmGYvxc09HbZDt97nuqMxYmWTFPg8aJlaOk3IrNeMyzRipx EG4xV0S5RY2pxKfVP8kiPse/t8NQeW5Hs+AtsL9B2jI6oywCls7JEw+pb3I7 1qv8iAzuC/Yjx4Mj3e+4SXadqhEPPxg/BOmbK1nwik50oMIPNNPCQ=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 21:50:21 -0000 At 04:19 PM 6/2/2009, John Lange wrote: >That is why I'm advocating a closer look at something like STUN + DNS >for LIS discovery. It will work, allows OBO and requires no new >hardware. James -- upgrading residential gateways to support (DHCP) Option 99 or 123 requires no new hardware either.... (last I checked) James From jmpolk@cisco.com Tue Jun 2 14:52:56 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 260933A6930 for ; Tue, 2 Jun 2009 14:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.594, 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 UXZuU4-7ljhS for ; Tue, 2 Jun 2009 14:52:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 447EE3A68E0 for ; Tue, 2 Jun 2009 14:52:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,293,1241395200"; d="scan'208";a="166649118" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2009 21:50:56 +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 n52LoqU4016143; Tue, 2 Jun 2009 14:50:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n52LoqPi027703; Tue, 2 Jun 2009 21:50:52 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.3959); Tue, 2 Jun 2009 14:50:52 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.6.102]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 14:50:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 16:50:51 -0500 To: John Lange , Brian Rosen From: "James M. Polk" In-Reply-To: <7.1.0.9.2.20090602164753.04fa3e28@cisco.com> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <7.1.0.9.2.20090602164753.04fa3e28@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2009 21:50:52.0404 (UTC) FILETIME=[32EDAB40:01C9E3CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=492; t=1243979455; x=1244843455; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=51PH1ppXrMu/+XIxLyMhqdinyjpS93Q5uK/9hHJdmfs=; b=YSWpcC/6cm7T11fgxVTccB0dm6joZ7ISEUvpgpWlfmNm3QDcUjmiYwAExX ZnipL4yN+VUwOvuNaf9w34y1DpDI1iLdPAjEOdAEGWBQ6HBPwdP9bBcXUXTL Q8As5q1/bo; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 21:52:56 -0000 James W - I apologize (!!), this is a response to John, not your post (which is the next message) At 04:49 PM 6/2/2009, James M. Polk wrote: >At 04:19 PM 6/2/2009, John Lange wrote: >>That is why I'm advocating a closer look at something like STUN + DNS >>for LIS discovery. It will work, allows OBO and requires no new >>hardware. > > >James -- upgrading residential gateways to support (DHCP) Option 99 >or 123 requires no new hardware either.... (last I checked) > >James From fmenard@xittelecom.com Tue Jun 2 15:01:27 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 7BED33A6930 for ; Tue, 2 Jun 2009 15:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 WFLebwlXnrXO for ; Tue, 2 Jun 2009 15:01:26 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 98FCA3A681F for ; Tue, 2 Jun 2009 15:01:26 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1MBc2r-0008AX-1f; Tue, 02 Jun 2009 18:01:21 -0400 Received: from [205.151.16.4] (helo=[192.168.2.63]) by relay2.infoteck.qc.ca with esmtp (Exim 4.43) id 1MBc2r-0000dq-KK; Tue, 02 Jun 2009 18:01:21 -0400 Message-Id: <62E51439-398D-4004-9FDF-B4C41302F505@xittelecom.com> From: =?ISO-8859-1?Q?=22Fran=E7ois_D._M=E9nard=22?= To: Brian Rosen In-Reply-To: <023801c9e3cb$46467a60$d2d36f20$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Jun 2009 18:01:21 -0400 References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <023801c9e3cb$46467a60$d2d36f20$@net> X-Mailer: Apple Mail (2.929.2) Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 22:01:27 -0000 > DHCP works very well in residential VoIP. The phone may have a NATed > address, but as long as the home router passes the location option, > the > query to the provider will have the right thing to get the DHCP > system to > return the location of the residence. If you don't like DHCP, use > HELD, but > you still have some remnants of the VPN problem. Don't confuse DHCP > for LIS > discovery with DHCP for location configuration. Both work, but DHCP > discovery of a HELD server works. > I concur. If you have a router which does not pass on DHCP Option 99, you can always initiate a PPPoE tunnel from your ATA and do a DHCP Option 99 fetching through it. There is nothing wrong with having multiple PPPoE sessions from your home to your ISP, and one dedicated to VoIP. Furthermore, this will be an excellent mean to use PPPoE to prioritize the username/password for a VoIP PPPoE session over the username/ password for Internet access, for two sessions coming from the same home. The ATAs we use here can be patched to support DHCP Option 99 fetching through a PPPoE session. All you need is to put a little Ethernet switch between your DSL modem / Cable Modem and your ATA and to allow for the possibility that both your ATA as well as your Router will launch a PPPoE tunnel to your ISP. I'll send you a sticker you can can put on your router here... plug here and die - this box does not pass on location. This architecture has the added bonus of accelerating the transition to IPv6. For those concerned with that, our wholesale cable modem incumbent cable operator, permits up to 3 public IPs behind a single cable modem, and I use a switch behind my CM to assign a separate public IP for my VoIP PBX SIPtrunk client, from the public IP address of my router, which currently is too dumb to relay DHCP Option 99. So all I need is to have the DHCP server programmed to send a PIDF-LO. And for my SIP client to support SIP LOCATION CONVEYANCE. And for it not to never send a BYE if I dial 9-1-1, even if I hang-up. F. From James.Winterbottom@andrew.com Tue Jun 2 15:21:43 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 329DD3A68E0 for ; Tue, 2 Jun 2009 15:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=0.308, 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 lSzwbYJ-rYgo for ; Tue, 2 Jun 2009 15:21:42 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 49A9C3A68D3 for ; Tue, 2 Jun 2009 15:21:41 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_02_17_43_10 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); Tue, 02 Jun 2009 17:43:09 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 17:21:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jun 2009 17:17:44 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 Thread-Index: AcnjzCR6cUY/Iv1CQvqPOqDhCgoRagAA8+bC References: <1243884311.17673.212.camel@vandium.darkcore.net><1243966386.4449.676.camel@vandium.darkcore.net><01d101c9e3b0$d90bfac0$8b23f040$@net><1243977594.4449.813.camel@vandium.darkcore.net> From: "Winterbottom, James" To: "James M. Polk" , "John Lange" , "Brian Rosen" X-OriginalArrivalTime: 02 Jun 2009 22:21:42.0749 (UTC) FILETIME=[81D1E8D0:01C9E3D0] Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 22:21:43 -0000 =0D=0AThere was one very strong point made in i2 all along, and that is NO = UPGRADES to residential equipment is required in order for it work. It may = work better if upgrades are made, but they MUST NOT be required.=0D=0A=0D=0A= So, if I can use a device inside my home network and it can go out through = my RG to the Internet and VSP to make an emergency call it has to work out = of the box, as is, no matter when I bought it. I know some people don't lik= e these requirements, but they are still requirements.=0D=0A=0D=0AI will al= so point out that these are the requirements that are addressed in the LIS = discovery through an RG draft that Martin T is authoring.=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@iet= f.org on behalf of James M. Polk=0D=0ASent: Tue 6/2/2009 4:49 PM=0D=0ATo: J= ohn Lange; Brian Rosen=0D=0ACc: 'ecrit'=0D=0ASubject: Re: [Ecrit] Emergency= Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09=0D=0A= =20=0D=0AAt 04:19 PM 6/2/2009, John Lange wrote:=0D=0A>That is why I'm advo= cating a closer look at something like STUN + DNS=0D=0A>for LIS discovery. = It will work, allows OBO and requires no new=0D=0A>hardware.=0D=0A=0D=0A=0D= =0AJames -- upgrading residential gateways to support (DHCP) Option 99=20=0D= =0Aor 123 requires no new hardware either.... (last I checked)=0D=0A=0D=0AJ= ames=0D=0A=0D=0A=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 From fmenard@xittelecom.com Tue Jun 2 15:30:09 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 D44333A6CD7 for ; Tue, 2 Jun 2009 15:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] 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 ymsnXNLQWMCj for ; Tue, 2 Jun 2009 15:30:03 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id C73293A6CC6 for ; Tue, 2 Jun 2009 15:28:49 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1MBbgU-0005pe-1J; Tue, 02 Jun 2009 17:38:17 -0400 Received: from [205.151.16.4] (helo=[192.168.2.63]) by relay2.infoteck.qc.ca with esmtp (Exim 4.43) id 1MBbgQ-00075W-TI; Tue, 02 Jun 2009 17:38:14 -0400 Message-Id: From: =?ISO-8859-1?Q?=22Fran=E7ois_D._M=E9nard=22?= To: "Winterbottom, James" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Jun 2009 17:38:10 -0400 References: <1243884311.17673.212.camel@vandium.darkcore.net> X-Mailer: Apple Mail (2.929.2) Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 22:30:09 -0000 James, The architecture that ILECs are proposing in Canada does not work for =20= devices which are not on the public Internet. It'll be cheaper to upgrade 400,000 ATAs in Canada than to spend 500M$ =20= on implementation of a non-ECRIT solution. F. On 2-Jun-09, at 5:27 PM, Winterbottom, James wrote: > > How will address the millions of already deployed terminals and =20 > routers? > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of "Fran=E7ois D. M=E9nard" > Sent: Tue 6/2/2009 9:36 AM > To: James M. Polk > Cc: ecrit > Subject: Re: [Ecrit] Emergency Call Framework for Canada;Questions =20 > on draft-ietf-ecrit-framework-09 > > > See www.brisenet.net for my proposed architecture. > > We're currently costing the modification of ISC DHCPD to support > Option 99 pass-through of PIDF-LO's and my ATA vendor is costing the > inclusion of DHCP Option 99 & SIP LOCATION CONVEYANCE in their end- > points, for submission to the CRTC in August. > > f. > > > On 1-Jun-09, at 6:01 PM, James M. Polk wrote: > >> John >> >> some comments in-line below >> >> At 02:25 PM 6/1/2009, John Lange wrote: >>> On April 15 2009, the Canadian Radio and Telecommunications >>> Commission >>> (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom >>> Notice of Consultation CRTC 2009-194". >>> >>> http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm >>> >>> Paragraph 17 asks; "Are there alternative solutions that would >>> improve >>> on the current nomadic VoIP 9-1-1 service." >>> >>> The proposed architecture was developed by Bell Canada based very >>> loosely on NENAi2 with extensive modifications. As it was developed >>> by >>> the ILECs in 2006/2007, it does not employ the IETF standards. >>> >>> I am working on a submission to this proceeding which advocates the >>> implementation of the standards developed by the IETF's ECRIT =20 >>> working >>> group and it's members. (As a side note, if there are any >>> participants >>> on this list which are interested in helping with this effort, >>> please do >>> contact me.) >>> >>> After examining draft-ietf-ecrit-framework-09 and it's related RFCs >>> and >>> RFC-drafts, I have some specific questions/concerns which I hope =20 >>> this >>> list can answer. >>> >>> The Emergency Call Framework (ECF) as proposed : >>> >>> - Location is cached at end-point during boot/location discovery but >>> there does not appear to be any mechanism whereby the end-point >>> announces the success of this process to the SIP Registrar. >> >> This can be done with this specification: >> = http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-13.= txt >> >> >>> If the device is able to determine it's location it should relay the >>> location information to the SIP registration server and the SIP >>> registrar should cache this information. >> >> The registrar caching geolocation is not a protocol issue, it's a >> configuration issue (once it receives the location from the >> endpoint). Notice this does not have to be with the first REGISTER >> request (meaning with a subsequent one), and/or it could be with >> each REGISTER request. >> >> >>> This allows the SIP Registrar and SIP proxy the ability to act >>> "on-behalf-of" end points that are not able to determine their >>> location >>> either because they are not location capable, or because they are =20= >>> not >>> able to determine location from their access provider. >> >> I'm missing what you mean by the starting "this" in the paragraph >> above? >> >> If the UA has its location, nothing needs to act "on-behalf- >> of" (OBO) it when sending location in any SIP request. >> >> >>> Furthermore, it removes the burden of "real-time" "on-behalf-of" >>> functionality from the rest of the network. >> >> If endpoints have their location (your original premise), OBO is >> unnecessary -- which further reduces network complexity, no? >> >> >>> The ability of the registrar to query and cache location data for >>> endpoints as opposed to the requirement to perform location >>> determination in real-time, has a dramatic impact on the technical >>> requirements of the overall solution. >> >> How is this better or easier or an optimization from the endpoint >> including its location in the SIP request in the first place? >> >> >>> If location data must be queried in real-time during an actual >>> emergency >>> event, the network components must be engineered to a much higher >>> standard. In some jurisdictions the mandated hardware and network >>> requirements will be impacted significantly. No less than redundant >>> five-nine hardware running on dedicated private networks will be >>> required resulting in higher costs. >> >> again, all this goes away if the endpoint has its location prior to >> placing the emergency call, then including this location information >> if more current location information cannot be discovered easily. >> Remember, unless you believe that everything needs to be built for >> mobile endpoints (i.e., those that actually move from room to room >> and from city to city with many times within the same day), being IP >> based doesn't mean endpoints move much. Further, given the fact >> that there are lower layer solutions already in place (802.11k and y >> and 3GPP) -- the IETF doesn't need to solve everything moving as if >> it was never where it is before. For example, my IP phones at home >> haven't moved all day (or all week, or all year, etc) -- therefore >> the location value they understand 1 minute ago, as well as a day >> ago, and a month ago haven't changed. This makes these locations >> valid for call routing and dispatch. >> >> Mobile nodes that are 3GPP based have their own way of tracking >> location changes. >> >> Mobile nodes that are 802.11 based will likely have a valid location >> for call routing at any time during the day, but dispatch could take >> a bit longer to determine. The good thing here is that most systems >> can determine location within 15 seconds for dispatch -- and I'd >> like to meet the dispatchers that can make it to their destination >> in time for that to be an issue ;-) >> >> >>> I submit that a query-and-cache methodology is more in line with the >>> spirit of other IETF protocols, the DNS system being a prime =20 >>> example. >>> >>> - Concerns with draft-ietf-geopriv-lis-discovery: >>> >>> The focus of LIS discovery seems to be on local access network >>> methods >>> such as DHCP and LLDP. >>> >>> DHCP & LLDP are not good choices for LIS discovery because they are >>> not >>> supported in the residential market. Residential firewall devices =20= >>> are >>> not likely to have DHCP/LLDP functionality and the likelihood that >>> these >>> devices will be replaced or upgraded is small. >> >> For LLDP, I fully agree with what you have above. I've had 4 ISPs >> over the last 10 years, and EACH of them have used DHCP, so I'm not >> sure where you get your data wrt DHCP not being supported in the >> residential market. >> >> >>> It would therefore seem that the emphasis should be on a LIS >>> discovery >>> mechanism that does not rely on the local network such as STUN + =20 >>> DNS. >> >> How many vendors in the residential market do you know of that >> implement STUN? >> >> It appears you keep getting back to a solution that requires an >> upgrade in the access networks or endpoints. >> >> >>> 1) Device determines its IP address by querying the STUN server. >>> 2) Device determines its domain name using reverse DNS. >>> 3) Device does LIS discovery via DNS (SRV/NAPTR). >>> >>> - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on >>> behalf >>> of devices if: The proxy has a relationship with all access >>> networks the >>> device could connect to". >>> >>> This wording seems overly restrictive; in effect "all access =20 >>> networks >>> the device could connect to" amounts to every network on earth which >>> seems like an unreasonably high standard. >>> >>> How about: >>> >>> "Proxies MAY provide location on behalf of devices if: the device >>> does >>> not provide it's own location and the proxy is able to determine >>> location on-behalf-of the device. >> >> How does anyone know if this location OBO by the proxy is good >> enough for dispatch? >> >> I think (and this is just my opinion) that proxies in this situation >> will be just guessing where the endpoints are... >> >> >>> Any comments and/or questions would be welcome. >>> >>> Regards, >>> -- >>> John Lange >>> http://www.johnlange.ca >>> >>> _______________________________________________ >>> 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 fmenard@xittelecom.com Tue Jun 2 15:56:34 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 CAD633A6DE6 for ; Tue, 2 Jun 2009 15:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] 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 XaX-jw4UZ7iM for ; Tue, 2 Jun 2009 15:56:33 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 007D63A6D98 for ; Tue, 2 Jun 2009 15:56:32 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1MBbsY-0007Ks-FX; Tue, 02 Jun 2009 17:50:47 -0400 Received: from [205.151.16.4] (helo=[192.168.2.63]) by relay2.infoteck.qc.ca with esmtp (Exim 4.43) id 1MBbsT-000829-Tv; Tue, 02 Jun 2009 17:50:43 -0400 Message-Id: <4DE76109-454D-4568-B7A0-84E5F6945FE7@xittelecom.com> From: =?ISO-8859-1?Q?=22Fran=E7ois_D._M=E9nard=22?= To: "Winterbottom, James" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Jun 2009 17:50:37 -0400 References: <1243884311.17673.212.camel@vandium.darkcore.net> X-Mailer: Apple Mail (2.929.2) Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 02 Jun 2009 22:56:34 -0000 > It works for any device that is behind a residential gateway. Not if the key for emergency dispatch is only a public IP, which is =20 what the ILECs are proposing. Private IP =3D you use the legacy system and order T1s to all 9-1-1 =20 tandems. > So, unless I am mistaken, your proposal will also require every =20 > single residential gateway to be updated AND, for all DSL that uses =20= > PPP as opposed to DHCP to be upgraded either to use DHCP or to =20 > support modifications so that a new options is available over PPP, =20 > and supported by the RG. You can do a DHCP query across a PPPoE session to get an option 99 =20 PIDF-LO, atop an IP address that was already assigned via IPCP. > > > I think that this number is substantially more than the 400,000 =20 > devices you are talking about Nope. Canada =3D 400,000 nomadic VoIP subs. > and a massive massive cost in infrastructure upgrade, substantially =20= > more that the $500m you are talking about. > Infrastructure upgrades worth $500M are behind the ILEC proposals in =20 Canada, and that will be a patch that will not even support location =20 aware devices from the get go. f. > Cheers > James > > > -----Original Message----- > From: "Fran=E7ois D. M=E9nard" [mailto:fmenard@xittelecom.com] > Sent: Tue 6/2/2009 4:38 PM > To: Winterbottom, James > Cc: James M. Polk; ecrit > Subject: Re: [Ecrit] Emergency Call Framework for Canada;Questions =20 > on draft-ietf-ecrit-framework-09 > > James, > > The architecture that ILECs are proposing in Canada does not work for > devices which are not on the public Internet. > > It'll be cheaper to upgrade 400,000 ATAs in Canada than to spend 500M$ > on implementation of a non-ECRIT solution. > > F. > > > > On 2-Jun-09, at 5:27 PM, Winterbottom, James wrote: > >> >> How will address the millions of already deployed terminals and >> routers? >> >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org on behalf of "Fran=E7ois D. M=E9nard" >> Sent: Tue 6/2/2009 9:36 AM >> To: James M. Polk >> Cc: ecrit >> Subject: Re: [Ecrit] Emergency Call Framework for Canada;Questions >> on draft-ietf-ecrit-framework-09 >> >> >> See www.brisenet.net for my proposed architecture. >> >> We're currently costing the modification of ISC DHCPD to support >> Option 99 pass-through of PIDF-LO's and my ATA vendor is costing the >> inclusion of DHCP Option 99 & SIP LOCATION CONVEYANCE in their end- >> points, for submission to the CRTC in August. >> >> f. >> >> >> On 1-Jun-09, at 6:01 PM, James M. Polk wrote: >> >>> John >>> >>> some comments in-line below >>> >>> At 02:25 PM 6/1/2009, John Lange wrote: >>>> On April 15 2009, the Canadian Radio and Telecommunications >>>> Commission >>>> (CRTC), which is the Canadian equivalent of the FCC, issued =20 >>>> "Telecom >>>> Notice of Consultation CRTC 2009-194". >>>> >>>> http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm >>>> >>>> Paragraph 17 asks; "Are there alternative solutions that would >>>> improve >>>> on the current nomadic VoIP 9-1-1 service." >>>> >>>> The proposed architecture was developed by Bell Canada based very >>>> loosely on NENAi2 with extensive modifications. As it was developed >>>> by >>>> the ILECs in 2006/2007, it does not employ the IETF standards. >>>> >>>> I am working on a submission to this proceeding which advocates the >>>> implementation of the standards developed by the IETF's ECRIT >>>> working >>>> group and it's members. (As a side note, if there are any >>>> participants >>>> on this list which are interested in helping with this effort, >>>> please do >>>> contact me.) >>>> >>>> After examining draft-ietf-ecrit-framework-09 and it's related RFCs >>>> and >>>> RFC-drafts, I have some specific questions/concerns which I hope >>>> this >>>> list can answer. >>>> >>>> The Emergency Call Framework (ECF) as proposed : >>>> >>>> - Location is cached at end-point during boot/location discovery =20= >>>> but >>>> there does not appear to be any mechanism whereby the end-point >>>> announces the success of this process to the SIP Registrar. >>> >>> This can be done with this specification: >>> = http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-13.= txt >>> >>> >>>> If the device is able to determine it's location it should relay =20= >>>> the >>>> location information to the SIP registration server and the SIP >>>> registrar should cache this information. >>> >>> The registrar caching geolocation is not a protocol issue, it's a >>> configuration issue (once it receives the location from the >>> endpoint). Notice this does not have to be with the first REGISTER >>> request (meaning with a subsequent one), and/or it could be with >>> each REGISTER request. >>> >>> >>>> This allows the SIP Registrar and SIP proxy the ability to act >>>> "on-behalf-of" end points that are not able to determine their >>>> location >>>> either because they are not location capable, or because they are >>>> not >>>> able to determine location from their access provider. >>> >>> I'm missing what you mean by the starting "this" in the paragraph >>> above? >>> >>> If the UA has its location, nothing needs to act "on-behalf- >>> of" (OBO) it when sending location in any SIP request. >>> >>> >>>> Furthermore, it removes the burden of "real-time" "on-behalf-of" >>>> functionality from the rest of the network. >>> >>> If endpoints have their location (your original premise), OBO is >>> unnecessary -- which further reduces network complexity, no? >>> >>> >>>> The ability of the registrar to query and cache location data for >>>> endpoints as opposed to the requirement to perform location >>>> determination in real-time, has a dramatic impact on the technical >>>> requirements of the overall solution. >>> >>> How is this better or easier or an optimization from the endpoint >>> including its location in the SIP request in the first place? >>> >>> >>>> If location data must be queried in real-time during an actual >>>> emergency >>>> event, the network components must be engineered to a much higher >>>> standard. In some jurisdictions the mandated hardware and network >>>> requirements will be impacted significantly. No less than redundant >>>> five-nine hardware running on dedicated private networks will be >>>> required resulting in higher costs. >>> >>> again, all this goes away if the endpoint has its location prior to >>> placing the emergency call, then including this location information >>> if more current location information cannot be discovered easily. >>> Remember, unless you believe that everything needs to be built for >>> mobile endpoints (i.e., those that actually move from room to room >>> and from city to city with many times within the same day), being IP >>> based doesn't mean endpoints move much. Further, given the fact >>> that there are lower layer solutions already in place (802.11k and y >>> and 3GPP) -- the IETF doesn't need to solve everything moving as if >>> it was never where it is before. For example, my IP phones at home >>> haven't moved all day (or all week, or all year, etc) -- therefore >>> the location value they understand 1 minute ago, as well as a day >>> ago, and a month ago haven't changed. This makes these locations >>> valid for call routing and dispatch. >>> >>> Mobile nodes that are 3GPP based have their own way of tracking >>> location changes. >>> >>> Mobile nodes that are 802.11 based will likely have a valid location >>> for call routing at any time during the day, but dispatch could take >>> a bit longer to determine. The good thing here is that most systems >>> can determine location within 15 seconds for dispatch -- and I'd >>> like to meet the dispatchers that can make it to their destination >>> in time for that to be an issue ;-) >>> >>> >>>> I submit that a query-and-cache methodology is more in line with =20= >>>> the >>>> spirit of other IETF protocols, the DNS system being a prime >>>> example. >>>> >>>> - Concerns with draft-ietf-geopriv-lis-discovery: >>>> >>>> The focus of LIS discovery seems to be on local access network >>>> methods >>>> such as DHCP and LLDP. >>>> >>>> DHCP & LLDP are not good choices for LIS discovery because they are >>>> not >>>> supported in the residential market. Residential firewall devices >>>> are >>>> not likely to have DHCP/LLDP functionality and the likelihood that >>>> these >>>> devices will be replaced or upgraded is small. >>> >>> For LLDP, I fully agree with what you have above. I've had 4 ISPs >>> over the last 10 years, and EACH of them have used DHCP, so I'm not >>> sure where you get your data wrt DHCP not being supported in the >>> residential market. >>> >>> >>>> It would therefore seem that the emphasis should be on a LIS >>>> discovery >>>> mechanism that does not rely on the local network such as STUN + >>>> DNS. >>> >>> How many vendors in the residential market do you know of that >>> implement STUN? >>> >>> It appears you keep getting back to a solution that requires an >>> upgrade in the access networks or endpoints. >>> >>> >>>> 1) Device determines its IP address by querying the STUN server. >>>> 2) Device determines its domain name using reverse DNS. >>>> 3) Device does LIS discovery via DNS (SRV/NAPTR). >>>> >>>> - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on >>>> behalf >>>> of devices if: The proxy has a relationship with all access >>>> networks the >>>> device could connect to". >>>> >>>> This wording seems overly restrictive; in effect "all access >>>> networks >>>> the device could connect to" amounts to every network on earth =20 >>>> which >>>> seems like an unreasonably high standard. >>>> >>>> How about: >>>> >>>> "Proxies MAY provide location on behalf of devices if: the device >>>> does >>>> not provide it's own location and the proxy is able to determine >>>> location on-behalf-of the device. >>> >>> How does anyone know if this location OBO by the proxy is good >>> enough for dispatch? >>> >>> I think (and this is just my opinion) that proxies in this situation >>> will be just guessing where the endpoints are... >>> >>> >>>> Any comments and/or questions would be welcome. >>>> >>>> Regards, >>>> -- >>>> John Lange >>>> http://www.johnlange.ca >>>> >>>> _______________________________________________ >>>> 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] >> > > > > = --------------------------------------------------------------------------= ---------------------- > 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 fmenard@xittelecom.com Tue Jun 2 19:00:10 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 50E253A6AF0 for ; Tue, 2 Jun 2009 19:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 qBrygnR5yA7H for ; Tue, 2 Jun 2009 19:00:09 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 427A93A6A80 for ; Tue, 2 Jun 2009 19:00:09 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1MBcbE-0002cc-7X; Tue, 02 Jun 2009 18:36:56 -0400 Received: from [205.151.16.4] (helo=[192.168.2.63]) by relay.infoteck.qc.ca with esmtp (Exim 4.43) id 1MBcb9-0002cQ-Ra; Tue, 02 Jun 2009 18:36:52 -0400 Message-Id: <849DDE05-9800-445A-8D81-F64CB370BD24@xittelecom.com> From: =?ISO-8859-1?Q?=22Fran=E7ois_D._M=E9nard=22?= To: John Lange In-Reply-To: <1243966386.4449.676.camel@vandium.darkcore.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Jun 2009 18:36:48 -0400 References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> X-Mailer: Apple Mail (2.929.2) Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 02:00:10 -0000 > > On the topic of privacy; real-time IP location determination is a > _MASSIVE_ privacy issue that will need to be addressed with public > policy, not an RFC. That's a good reason to keep the location in the end-point, where the end-point would only reveal it upon requesting S.O.S. I find that OBO is a _MASSIVE_ violation of privacy. > Keep in mind that the VOIP provider already has sensitive personal > information for the user so suffice to say that as long as the > information is only accessible to authorized people, then exactly who > those authorized people are is something for the politicians to > decide. > However, the VOIP provider if access independant (i.e. Vonage atop an ISP), has no idea of the location associated with the underlying circuit. The question here is if VONAGE is to steer the call to the right PSAP, based upon which information will it be able do that ? >> "On behalf of" is needed when the device DOESN'T get it's location >> from its >> access network. I think you have a point on the language of the on >> behalf >> of language in -phonebcp, but your suggestion is not good enough. >> The >> problem to be solved is one way or another we have to get >> location. The >> current wording is aimed at proxies who think they ought to do it >> always, >> and the language says, fine, as long as you CAN do it always. > > Actually, I think BCP would be: "Proxies MUST provide location on > behalf > of devices ONLY if the device does not provide it's own location." That's a good statement, but it is not sufficiently precise. The question is 'how can proxies (which are by definition stateless), inspect an S.O.S. call and try to look for the presence of a PIDF-LO by way of SIP LOCATION CONVEYANCE', and upon that not being there, decide to inject it. This seems like a violation of the mother-rule-of-SIP, which is that proxies do not modify SIP message contents, which is where Lby? lies. Some people are claiming that adding Location-by-reference does not violate the rule, however location-by-value would violate the rule. What's the latest take on that? > "If the device does not provide location and the proxy can't find > location OBO the device, then the call MUST be routed to a 3rd party > call centre for verbal location and routing." What mechanism will a PROXY use to make this determination? f. > > > Regards, > -- > John Lange > http://www.johnlange.ca > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Jun 2 20:07:31 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 9C5AC3A6BB3 for ; Tue, 2 Jun 2009 20:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.973 X-Spam-Level: X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 yi3ZySnU1b5e for ; Tue, 2 Jun 2009 20:07:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8D4663A6A10 for ; Tue, 2 Jun 2009 20:07:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,295,1241395200"; d="scan'208";a="315636757" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Jun 2009 03:07:32 +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 n5337W3X018155; Tue, 2 Jun 2009 20:07:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5337VAF022548; Wed, 3 Jun 2009 03:07:31 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); Tue, 2 Jun 2009 20:07:31 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.6.102]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 20:07:31 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 22:07:30 -0500 To: "\"\" =?iso-8859-1?Q?Fran=E7ois?= D. =?iso-8859-1?Q?M=E9nard?= \"\"" , John Lange From: "James M. Polk" In-Reply-To: <849DDE05-9800-445A-8D81-F64CB370BD24@xittelecom.com> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <849DDE05-9800-445A-8D81-F64CB370BD24@xittelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 03 Jun 2009 03:07:31.0406 (UTC) FILETIME=[6F374EE0:01C9E3F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3472; t=1243998452; x=1244862452; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=yCPmH8iN9JYphjVlnHWtcPHLO2sblOLdouxNK9M5LfM=; b=IgXFkdar35cIa+4qQTfEBD1gzq8N4BuTI3cS6KvMnVzN2Q78ss0cssKxRq w6H1mKTa5Sare5ASwsAI+OP5+tqHj45u9NluVxS6ZCeWk1mOXqFn86izBVaV ZT/NCrUAbH; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 03:07:31 -0000 At 05:36 PM 6/2/2009, "Fran=E7ois D. M=E9nard" wrote: >>Actually, I think BCP would be: "Proxies MUST provide location on >>behalf of devices ONLY if the device does not provide it's own location." > >That's a good statement, but it is not sufficiently precise. has anyone ever heard of a default route? the call only has to be to _A_ PSAP --=20 preferrably in the same country (or=20 state/province or county or city)... The call can=20 be transferred from that PSAP to the appropriate=20 one once the location of the caller is determined=20 (when they tell the dispatcher). This transfer=20 ought be nearly on speed-dial, considering how few PSAPs there are. >The question is 'how can proxies (which are by definition stateless), well, this statement is false. Proxies can merely=20 choose to become transaction stateful (because=20 the request and response go through the same=20 proxies), and can inject a Record-Route into a=20 SIP request to becomes dialog stateful. This=20 means all subsequent requests go through this=20 proxy also (all BYEs, REFERs, INFOs...) > >inspect an S.O.S. call and try to look for the presence of a PIDF-LO >by way of SIP LOCATION CONVEYANCE', well, perhaps all you need to look for is the=20 presence of the Geolocation header, because that=20 has to be present in order for there to be a=20 Location URI or a PIDF-LO message body (i.e.,=20 this header's presence in the SIP request is a=20 dead giveaway that location is not=20 there). Something can be done upon realizing that header is not present. >and upon that not being there, >decide to inject it. > >This seems like a violation of the mother-rule-of-SIP, which is that >proxies do not modify SIP message contents, which is where Lby? lies. possible correction -- proxies aren't to modify=20 or delete message bodies, but they can certainly=20 add or change the contents of any SIP header,=20 though some aren't recommended to be changed=20 (like Via, From or To, for example). >Some people are claiming that adding Location-by-reference does not >violate the rule, however location-by-value would violate the rule. so long as the SIP server is operating strictly=20 as proxy, but many SIP servers don't limit=20 themselves to only operating as a proxy -- many=20 are B2BUAs and SBCs -- which by definition, *can* modify SIP message bodies. >What's the latest take on that? see above >>"If the device does not provide location and the proxy can't find >>location OBO the device, then the call MUST be routed to a 3rd party >>call centre for verbal location and routing." personally, I think OBO shouldn't be done, given=20 how often I believe this will be incorrect=20 location information, but I've been out-argued on=20 this point. That said, routing to the 3rd party=20 call center (as written above) would be my recommended 2nd step. >What mechanism will a PROXY use to make this determination? local configuration, clearly... even though that won't taste too good to some.=20 it's the way SIP generally operates. >f. > >>Regards, >>-- >>John Lange >>http://www.johnlange.ca >> >>_______________________________________________ >>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 john@johnlange.ca Tue Jun 2 20:22:16 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 031403A67A3 for ; Tue, 2 Jun 2009 20:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 ZyNkAbkJMHTu for ; Tue, 2 Jun 2009 20:22:15 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 0B8733A659B for ; Tue, 2 Jun 2009 20:22:13 -0700 (PDT) Received: (qmail 12309 invoked from network); 2 Jun 2009 22:22:14 -0500 Received: from s01060014bf82696b.wp.shawcable.net (HELO ?192.168.1.135?) (24.76.182.108) by lh02.epicnet.ca with SMTP; 2 Jun 2009 22:22:14 -0500 From: John Lange To: "James M. Polk" In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> Content-Type: text/plain Date: Tue, 02 Jun 2009 22:22:01 -0500 Message-Id: <1243999321.4449.868.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 03:22:16 -0000 On Tue, 2009-06-02 at 16:49 -0500, James M. Polk wrote: > At 04:19 PM 6/2/2009, John Lange wrote: > >That is why I'm advocating a closer look at something like STUN + DNS > >for LIS discovery. It will work, allows OBO and requires no new > >hardware. > > > James -- upgrading residential gateways to support (DHCP) Option 99 > or 123 requires no new hardware either.... (last I checked) James, you should check again. You need not look any further than your own company. Ask around and see if Cisco will be providing new firmware for _all_ of the devices it has ever made including devices from companies it has purchased such as Linksys and Sipura. Even if they did, what percentage of users would actually apply the updates? Any solution that requires the upgrading of residential gateways is not feasible. -- John Lange http://www.johnlange.ca From john@johnlange.ca Tue Jun 2 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 19B953A6CCD for ; Tue, 2 Jun 2009 20:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 t9cFY7tEd8gx for ; Tue, 2 Jun 2009 20:30:21 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 4F27E3A6C7C for ; Tue, 2 Jun 2009 20:30:21 -0700 (PDT) Received: (qmail 14342 invoked from network); 2 Jun 2009 22:30:22 -0500 Received: from s01060014bf82696b.wp.shawcable.net (HELO ?192.168.1.135?) (24.76.182.108) by lh02.epicnet.ca with SMTP; 2 Jun 2009 22:30:22 -0500 From: John Lange To: "Winterbottom, James" In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> Content-Type: text/plain Date: Tue, 02 Jun 2009 22:30:10 -0500 Message-Id: <1243999810.4449.877.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 03:30:23 -0000 On Tue, 2009-06-02 at 17:17 -0500, Winterbottom, James wrote: > There was one very strong point made in i2 all along, and that is NO > UPGRADES to residential equipment is required in order for it work. It > may work better if upgrades are made, but they MUST NOT be required. I agree completely (even though i2 is not my favourite document). Upgrades to RGs MUST NOT be required. Upgrades to VOIP endpoints is much more feasible since most VOIP endpoints are already provisioned remotely and receive periodic updates from their VOIP providers but this MUST NOT be a requirement. And that is why OBO MUST be a requirement. > I will also point out that these are the requirements that are > addressed in the LIS discovery through an RG draft that Martin T is > authoring. An excellent document that still needs some work and should... ahem, I mean MUST ;) be referenced the ecrit-framework and BCP. -- John Lange http://www.johnlange.ca From jmpolk@cisco.com Tue Jun 2 20:31:32 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 1FEAF3A6E2D for ; Tue, 2 Jun 2009 20:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.421, 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 wC5yS0-nvqrE for ; Tue, 2 Jun 2009 20:31:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5B2203A6E02 for ; Tue, 2 Jun 2009 20:31:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,295,1241395200"; d="scan'208";a="315649794" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Jun 2009 03:31:32 +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 n533VWW4022653; Tue, 2 Jun 2009 20:31:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n533VWe5029158; Wed, 3 Jun 2009 03:31:32 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); Tue, 2 Jun 2009 20:31:32 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.6.102]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 20:31:31 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 22:31:30 -0500 To: John Lange From: "James M. Polk" In-Reply-To: <1243999321.4449.868.camel@vandium.darkcore.net> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <1243999321.4449.868.camel@vandium.darkcore.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2009 03:31:31.0990 (UTC) FILETIME=[C9DEFB60:01C9E3FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1270; t=1243999892; x=1244863892; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=/kTFBBeyv5efyuIXjhYcFenO1J4rmAB1EP0ZaMGnph8=; b=GN9HpYb+YCIdWeMs99BbkRXQKwTfv00FreK7uKY0i0gTckGzWukotzMhhQ kpiGCRN8djYXznNGHd8zRiAgpbhnRmBX8/93CFoY5bi486hdAiOrDWEqiiC8 kOkN/dmeAO; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 03:31:32 -0000 At 10:22 PM 6/2/2009, John Lange wrote: >On Tue, 2009-06-02 at 16:49 -0500, James M. Polk wrote: > > At 04:19 PM 6/2/2009, John Lange wrote: > > >That is why I'm advocating a closer look at something like STUN + DNS > > >for LIS discovery. It will work, allows OBO and requires no new > > >hardware. > > > > > > James -- upgrading residential gateways to support (DHCP) Option 99 > > or 123 requires no new hardware either.... (last I checked) > >James, you should check again. You need not look any further than your >own company. Ask around and see if Cisco will be providing new firmware >for _all_ of the devices it has ever made including devices from >companies it has purchased such as Linksys and Sipura. > >Even if they did, what percentage of users would actually apply the >updates? > >Any solution that requires the upgrading of residential gateways is not >feasible. I'm not questioning the idea of the upgrade (in fact, I'm convinced it will be required in most instances), just that HW would be required. That's all this comment was about... The question about the likelihood of the upgrade is a very different question, which is in and of itself an *interesting* question. >-- >John Lange >http://www.johnlange.ca From rbarnes@bbn.com Tue Jun 2 22:07:46 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 E6F3E3A6E2D for ; Tue, 2 Jun 2009 22:07:46 -0700 (PDT) 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 xEMYxrtvuH4w for ; Tue, 2 Jun 2009 22:07:45 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D6EB13A6877 for ; Tue, 2 Jun 2009 22:07:45 -0700 (PDT) Received: from [128.89.254.245] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MBihW-0005xV-Fy for ecrit@ietf.org; Wed, 03 Jun 2009 01:07:47 -0400 Message-ID: <4A260522.1030503@bbn.com> Date: Wed, 03 Jun 2009 01:07:46 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) 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-03] 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, 03 Jun 2009 05:07:47 -0000 Just submitted a new version of rough-loc. Changes are pretty minor, mainly related to how to handle civic addresses: -------- Original Message -------- Subject: New Version Notification for draft-barnes-ecrit-rough-loc-03 Date: Tue, 2 Jun 2009 20:25:24 -0700 (PDT) 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-03.txt has been successfuly submitted by Richard Barnes and posted to the IETF repository. Filename: draft-barnes-ecrit-rough-loc Revision: 03 Title: Using Imprecise Location for Emergency Context Resolution Creation_date: 2009-06-02 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. From patrik@frobbit.se Tue Jun 2 22:09:37 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 BC8883A6ED5 for ; Tue, 2 Jun 2009 22:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.118 X-Spam-Level: X-Spam-Status: No, score=0.118 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] 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 jRW-ngTb9Rva for ; Tue, 2 Jun 2009 22:09:36 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id AB4713A6E9E for ; Tue, 2 Jun 2009 22:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3C565566EE53; Wed, 3 Jun 2009 07:09:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Jz-fTOC3mBh; Wed, 3 Jun 2009 07:09:36 +0200 (CEST) Received: from 79.138.146.123.bredband.tre.se (79.138.146.123.bredband.tre.se [79.138.146.123]) by srv01.frobbit.se (Postfix) with ESMTP id F1014566EE4C; Wed, 3 Jun 2009 07:09:34 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: John Lange In-Reply-To: <1243966386.4449.676.camel@vandium.darkcore.net> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-20--589398378" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Jun 2009 07:09:33 +0200 References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 05:09:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-20--589398378 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2 jun 2009, at 20.13, John Lange wrote: > 1) Endpoint location discovery via DHCP is not going to work for > residential so some other mechanism will need to be employed (and I > think it should be STUN + DNS). I think people should be careful with statements of the form "will not work for X". Much better to say "will not work in all situations" or "will not work if Y". Even "will not work for MANY deployments" is dangerous as I claim noone actually know what "many" implies in statements like that. I know network deployments where location by DHCP will work extremely well. I know location by DHCP will not work in some cases, and work in some. Patrik --Apple-Mail-20--589398378 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFKJgWNrMabGguI180RAlCmAKCXWQHs0HrCf+ENbnJpRLXXjNscUgCgj+4j 9BRN/HitngaeTtSLAB8m/kg= =tnqc -----END PGP SIGNATURE----- --Apple-Mail-20--589398378-- From hannes.tschofenig@nsn.com Wed Jun 3 00:55:04 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 3CBC43A6AC3; Wed, 3 Jun 2009 00:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.863 X-Spam-Level: X-Spam-Status: No, score=-4.863 tagged_above=-999 required=5 tests=[AWL=1.736, 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 g1GTWafXemVS; Wed, 3 Jun 2009 00:55:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B873D3A67E5; Wed, 3 Jun 2009 00:55:01 -0700 (PDT) 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 n537sxvv007280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2009 09:54:59 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n537swGp016314; Wed, 3 Jun 2009 09:54:58 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:54:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 10:56:41 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016847FA@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO writeup for draft-patel-ecrit-sos-parameter Thread-Index: AcnkINRxn6IjaL22S12MnCOH0Y+bMQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Cullen Jennings" , X-OriginalArrivalTime: 03 Jun 2009 07:54:49.0987 (UTC) FILETIME=[92360530:01C9E420] Cc: ECRIT Subject: [Ecrit] PROTO writeup for draft-patel-ecrit-sos-parameter 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, 03 Jun 2009 07:55:04 -0000 PROTO Writeup for draft-patel-ecrit-sos-parameter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-06 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Hannes Tschofenig is the document shepherd.=20 The document is ready for publication. Cullen Jennings, who is the=20 responsible AD, indicated that an additional review from SIP experts may be performed.=20 (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document originally came from the 3GPP and was presented to the IETF because a Standards Track extension to SIP was needed. The document was=20 reviewed by ECRIT working group members and an expert reviewer, namely Gonzallo Camarillo, was appointed. His review can be found here:=20 http://www.ietf.org/mail-archive/web/ecrit/current/msg06037.html His comments got addressed in subsequent draft versions.=20 (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns with the document. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? This document is not a product of the ECRIT working group but required=20 by the 3GPP for their Release 7 emergency services architecture.=20 There are architectural differences between the IETF and the 3GPP=20 emergency services architecture whereby the solution developed in this document is currenly only needed by the 3GPP.=20 There is, however, consensus within the ECRIT WG to publish the document.=20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. There were only questions regarding the overall interworking between IETF and 3GPP when it comes to work that is of interest for the 3GPP only but has to be carried out in the IETF. This relates to the ongoing=20 discussion about the SIP Change Process.=20 (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The ABNF parses with no errors. Nits have been checked. The errors regarding RFC 2119 boilerplate seem to be incorrect.=20 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references in the document have been split into normative and informative.=20 Normative references are all stable documents published as RFCs. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? IANA considerations exist within the document and are consistent with=20 the body of the document. The new URI parameter has been specified as=20 defined by RFC 3261.=20 The document requests IANA to register the URI parameter. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP registration requests related to emergency services. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it. Working Group Summary This document is not the product of a working group. The document was considered to become an ECRIT working group item. However, based on=20 the current work schedule and the urgency of the document the decision was made to progress it as an AD sponsored document (initially with=20 Jon Peterson as the AD sponsoring it).=20 Document Quality The document has been reviewed by IETF ECRIT WG members and by=20 the 3GPP community. An expert review has been carried out by=20 Gonzalo Camarillo. The implementation status of this document is unknown.=20 Personnel Hannes Tschofenig is the document shepherd for this document. Cullen Jennings is the responsible AD.=20 From hannes.tschofenig@nsn.com Wed Jun 3 01:30:17 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 076CB3A6B71; Wed, 3 Jun 2009 01:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=-0.698, 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 OidP04SP3mnR; Wed, 3 Jun 2009 01:30:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EA2DD3A69DB; Wed, 3 Jun 2009 01:30:15 -0700 (PDT) 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 n538UCWw020157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2009 10:30:12 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n538U96S014144; Wed, 3 Jun 2009 10:30:12 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 10:30:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 11:32:02 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450168486B@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Milestone Update Thread-Index: AcnkJcSac30+NczqRemIJn0TORqUug== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 08:30:10.0735 (UTC) FILETIME=[82467BF0:01C9E425] Cc: ECRIT , Robert Sparks Subject: [Ecrit] ECRIT Milestone 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: , X-List-Received-Date: Wed, 03 Jun 2009 08:30:17 -0000 Please update the milestones for the ECRIT working group: ---------------------------------- Goals and Milestones: Done Submit 'Requirements for Emergency Context Resolution with Internet Technologies' to the IESG for consideration as an Informational RFC. Done Submit 'Security Threats and Requirements for Emergency Call Marking and Mapping' to the IESG for consideration as an Informational RFC. Done Submit 'A Uniform Resource Name (URN) for Emergency and Other Well-Known Services' to the IESG for consideration as a Proposed Standard. Done Submit 'LoST: A Location-to-Service Translation Protocol' to the IESG for consideration as a Proposed Standard. Done Submit 'Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)' to the IESG for consideration as an Informational RFC. Done Submit 'Location-to-URL Mapping Architecture and Framework' to the IESG for consideration as an Informational RFC. Done Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC.=20 Done Submit 'Specifying Holes in LoST Service Boundaries' to the IESG for consideration as an Informational RFC.=20 Jul 2009 Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC.=20 Jul 2009 Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Jul 2009 Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document From bernard_aboba@hotmail.com Wed Jun 3 02:26:28 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 182973A63C9 for ; Wed, 3 Jun 2009 02:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.363 X-Spam-Level: * X-Spam-Status: No, score=1.363 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=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 nwyyN+wVqwKN for ; Wed, 3 Jun 2009 02:26:27 -0700 (PDT) Received: from blu0-omc1-s37.blu0.hotmail.com (blu0-omc1-s37.blu0.hotmail.com [65.55.116.48]) by core3.amsl.com (Postfix) with ESMTP id 2A4C03A6A8E for ; Wed, 3 Jun 2009 02:26:27 -0700 (PDT) Received: from BLU137-W13 ([65.55.116.7]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 02:26:25 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ae79ce80-f8e8-4735-97f8-3a819fb0be4a_" X-Originating-IP: [97.120.166.87] From: Bernard Aboba To: Date: Wed, 3 Jun 2009 02:26:26 -0700 Importance: Normal In-Reply-To: <1243999810.4449.877.camel@vandium.darkcore.net> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <1243999810.4449.877.camel@vandium.darkcore.net> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2009 09:26:25.0896 (UTC) FILETIME=[5E072E80:01C9E42D] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 09:26:28 -0000 --_ae79ce80-f8e8-4735-97f8-3a819fb0be4a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John Lange said: "1) Device determines its IP address by querying the STUN server=20 2) Device determines its domain name using reverse DNS. 3) Device does LIS discovery via DNS (SRV/NAPTR)." There are some situations in which steps 1 and 2 will not work reliably.=20 With IPv4 exhaustion looming=2C it is likely that service providers will im= plement some form of IPv4 address sharing. =20 In an access network that has deployed a Carrier Grade NAT (CGN)=2C step 1 = will produce an IP address on the CGN=2C not the outer address of the residential CPE. This could then result in di= scovery of a LIS on the wrong side of the CGN=2C which would find itself unable to provide location since the = source IP address will have been shared=20 by too many users.=20 An alternative approach to obtaining a suitable domain for step 3 would be = to use the Domain Name Option (RFC 2132)=20 which is commonly supported today. The Searchlist Option (RFC 3397) is ano= ther possibility but it is not as=20 widely supported. This could produce a suitable domain without requiring t= he implementation of STUN or population of PTR RRs.=20 EMAILING FOR THE LESSER EVIL Join me --_ae79ce80-f8e8-4735-97f8-3a819fb0be4a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
John Lange said:

"1) Device determines its IP address by queryi=
ng the STUN server 
2) Device determines its domain name using reverse D=
NS.
3) Device does LIS discovery via DNS (SRV/NAPTR)."

There are =
some situations in which steps 1 and 2 will not work reliably. 

With=
 IPv4 exhaustion looming=2C it is likely that service providers will implem=
ent some form of IPv4 address sharing.  

In an access network that h=
as deployed a Carrier Grade NAT (CGN)=2C step 1 will produce an IP address =
on the CGN=2C
not the outer address of the residential CPE.  This could =
then result in discovery of a LIS on the wrong side
of the CGN=2C which =
would find itself unable to provide location since the source IP address wi=
ll have been shared 
by too many users. 

An alternative approach =
to obtaining a suitable domain for step 3 would be to use the Domain Name O=
ption (RFC 2132) 
which is commonly supported today.  The Searchlist Opt=
ion (RFC 3397) is another possibility but it is not as 
widely supported=
.  This could produce a suitable domain without requiring the implementatio=
n of STUN or population
of PTR RRs.

3D= EMAILING FOR THE LESSER EVIL
Join me


= --_ae79ce80-f8e8-4735-97f8-3a819fb0be4a_-- From Ray.Bellis@nominet.org.uk Wed Jun 3 02:59: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 C3FA93A6C11; Wed, 3 Jun 2009 02:59:03 -0700 (PDT) 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 RPU+s0ZYXNW2; Wed, 3 Jun 2009 02:59:02 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 6663F3A6F22; Wed, 3 Jun 2009 02:58:54 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=AVUgcjm2B8PDleWSrnSwFmZJx/mB23CadeZp8cfajUdmzDPVs5FQcN9N pVHN882u2r9strJa9oVqskD8wodIxonxXCH5vzV7AUFApx/jcORkphW4O R6S6WX9hf4YSrXS; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1244023138; x=1275559138; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Emergency=20Call=20Framework=20for=20Canada=3B=20Que stions=20on=0D=0A=20=20draft-ietf-ecrit-framework-09 |Date:=20Wed,=203=20Jun=202009=2010:58:54=20+0100 |Message-ID:=20|To:=20Bernard=20Aboba=20 |Cc:=20ecrit@ietf.org,=0D=0A =09ecrit-bounces@ietf.org,=0D=0A=09john@johnlange.ca |MIME-Version:=201.0|In-Reply-To:=20|References:=20<1243884311.17673. 212.camel@vandium.darkcore.net>=09=0D=0A=09<1243966386.444 9.676.camel@vandium.darkcore.net>=09<01d101c9e3b0$d90bfac 0$8b23f040$@net>=0D=0A=09<1243977594.4449.813.camel@vandi um.darkcore.net>=09=0D=0A=09=20=09<1243999810.4449.877. camel@vandium.darkcore.net>=20; bh=JMmR4bb09Qb9m981n2CBAnCNuSOhRfgnE3skBHeRFtA=; b=OzC4TaLcdiYlBKN6fw6coeJQlTYymKAowLYMAD2zWCTTfDktukwDPSPb P7Qt9023orFX1MGCr+RzLKMmqiaJP0JUrT9fhdYMRIPmwayvbdwIbk3rr mh5sFX5DxE10ayZ; X-IronPort-AV: E=Sophos;i="4.41,297,1241391600"; d="scan'208";a="14424889" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Jun 2009 10:58:55 +0100 In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <1243999810.4449.877.camel@vandium.darkcore.net> To: Bernard Aboba MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 3 Jun 2009 10:58:54 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/06/2009 10:58:55 AM, Serialize complete at 03/06/2009 10:58:55 AM Content-Type: text/plain; charset="US-ASCII" Cc: ecrit@ietf.org, ecrit-bounces@ietf.org Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 09:59:03 -0000 Bernard Aboba wrote: > John Lange said: > > "1) Device determines its IP address by querying the STUN server > 2) Device determines its domain name using reverse DNS. > 3) Device does LIS discovery via DNS (SRV/NAPTR)." > > There are some situations in which steps 1 and 2 will not work reliably. > > With IPv4 exhaustion looming, it is likely that service providers > will implement some form of IPv4 address sharing. > > In an access network that has deployed a Carrier Grade NAT (CGN), > step 1 will produce an IP address on the CGN, not the outer address > of the residential CPE. This could then result in discovery of a LIS > on the wrong side of the CGN, which would find itself unable to provide > location since the source IP address will have been shared by too many > users. This shouldn't be a problem. If the ISP is running a CGN such that the end user cannot find a non-RFC1918 public IP address, then all the ISP has to do (per draft-thomson-geopriv-res-gw-lis-discovery-01) is provision the appropriate NAPTR records in "in-addr.arpa" for whatever private IP space they are using. Also, draft-winterbottom-geopriv-held-identity-extensions has recently been updated to allow queries to be based on the particular IP port currently in use. In other words, if the end user's STUN query returns the CGN's IP address, then the LIS that knows about that CGN IP address should be able to interrogate the NAT mappings and determine which customer's location is being requested. > An alternative approach to obtaining a suitable domain for step 3 > would be to use the Domain Name Option (RFC 2132) which is commonly > supported today. The Searchlist Option (RFC 3397) is another > possibility but it is not as widely supported. This could produce > a suitable domain without requiring the implementation of STUN or population > of PTR RRs. I've argued very strongly on the GeoPriv list against either of those options being used. Using either implies a linkage between the access network and domain names which is simply not guaranteed to exist. IME, neither are well supported by residential CPE anyway. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From bernard_aboba@hotmail.com Wed Jun 3 03:25:14 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 07C453A6862; Wed, 3 Jun 2009 03:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.581, 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 DWSOntRRSK0Y; Wed, 3 Jun 2009 03:25:12 -0700 (PDT) Received: from blu0-omc1-s26.blu0.hotmail.com (blu0-omc1-s26.blu0.hotmail.com [65.55.116.37]) by core3.amsl.com (Postfix) with ESMTP id BC3553A67F1; Wed, 3 Jun 2009 03:25:11 -0700 (PDT) Received: from BLU137-W14 ([65.55.116.8]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 03:25:13 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0d0f70a3-390f-4802-978c-041244adfe11_" X-Originating-IP: [97.120.166.87] From: Bernard Aboba To: Date: Wed, 3 Jun 2009 03:25:13 -0700 Importance: Normal In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <1243999810.4449.877.camel@vandium.darkcore.net> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2009 10:25:13.0458 (UTC) FILETIME=[949E6D20:01C9E435] Cc: ecrit@ietf.org, ecrit-bounces@ietf.org Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 10:25:14 -0000 --_0d0f70a3-390f-4802-978c-041244adfe11_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > If the ISP is running a CGN such that the end user cannot find a=20 > non-RFC1918 public IP address=2C then all the ISP has to do (per=20 > draft-thomson-geopriv-res-gw-lis-discovery-01) is provision the=20 > appropriate NAPTR records in "in-addr.arpa" for whatever private IP space= =20 > they are using.=20 Not sure why NATPR RRs would be put in in-addr.arpa. If the ISP is populating RRs in "in-addr.arpa"=2C couldn't they populate PTR RRs pointing to a domain within which the SRV/NATPR RRs could be found?=20 > Also=2C draft-winterbottom-geopriv-held-identity-extensions has recently= =20 > been updated to allow queries to be based on the particular IP port=20 > currently in use. Good idea.=20 > In other words=2C if the end user's STUN query returns the CGN's IP addre= ss=2C=20 > then the LIS that knows about that CGN IP address should be able to=20 > interrogate the NAT mappings and determine which customer's location is=20 > being requested. Is it really a good idea for a LIS to query NAT mappings from a CGN?? I recall a router implementation where there was a facility for=20 retrieving portions of the forwarding table on a backbone router.=20 This didn't work well since the queries chewed up cycles that were needed f= or processing of control plane traffic.=20 --_0d0f70a3-390f-4802-978c-041244adfe11_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B If the ISP is running a CGN such that the end user cannot find a >=3B non-RFC1918 public IP address=2C then all the ISP has to do (per >=3B draft-thomson-geopriv-res-gw-lis-discovery-01) is provision the >=3B appropriate NAPTR records in "in-addr.arpa" for whatever private I= P space
>=3B they are using.

Not sure why NATPR RRs would be = put in in-addr.arpa. =3B If the ISP is
populating RRs in "in-addr.ar= pa"=2C =3B couldn't they populate PTR RRs
pointing to a domain withi= n which the SRV/NATPR RRs could be found?

>=3B Also=2C draft-wint= erbottom-geopriv-held-identity-extensions has recently
>=3B been upda= ted to allow queries to be based on the particular IP port
>=3B curre= ntly in use.

Good idea.

>=3B In other words=2C if the end = user's STUN query returns the CGN's IP address=2C
>=3B then the LIS t= hat knows about that CGN IP address should be able to
>=3B interrogat= e the NAT mappings and determine which customer's location is
>=3B be= ing requested.

Is it really a good idea for a LIS to query NAT mappi= ngs from a CGN??
I recall a router implementation where there was a faci= lity for
retrieving portions of the forwarding table on a backbone rout= er.
This didn't work well since the queries chewed up cycles that were = needed for
processing of control plane traffic.
= --_0d0f70a3-390f-4802-978c-041244adfe11_-- From mlinsner@cisco.com Wed Jun 3 05:58:22 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 76B223A6BAE for ; Wed, 3 Jun 2009 05:58:22 -0700 (PDT) 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 phwJuudNM6mS for ; Wed, 3 Jun 2009 05:58:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A1D433A6ACA for ; Wed, 3 Jun 2009 05:58:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,298,1241395200"; d="scan'208";a="194263669" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 03 Jun 2009 12:58:13 +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 n53CwDIk006409; Wed, 3 Jun 2009 05:58:13 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n53CwBWI020930; Wed, 3 Jun 2009 12:58:13 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 08:58:12 -0400 Received: from [10.116.195.120] ([10.116.195.120]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 08:58:11 -0400 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 08:58:10 -0400 From: Marc Linsner To: Message-ID: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 Thread-Index: AcnkSvJDDB6hoVAczUWAs8zOSUYFUw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Jun 2009 12:58:12.0084 (UTC) FILETIME=[F3819B40:01C9E44A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1643; t=1244033893; x=1244897893; c=relaxed/simple; s=sjdkim3002; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=20=0A=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=UFlaeAx30+V9NpUXnzaJp0hRldJesoO9yICWt9E1LAM=; b=ZsywHPlZ/G5tb3W4TfIl+kdfi0xQCUhs1HVuEgjOGEIy0BPcqRo3a4PDMI /HBJFlr87ZqKgM0liYObsp6G/Rg7TMsfYCuf9HbsxI2ghrH574fbGK/MMF0o KFJ8LwuUm8; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 12:58:22 -0000 Ray, On 6/3/09 5:58 AM, "Ray.Bellis@nominet.org.uk" wrote: > Bernard Aboba wrote: >> John Lange said: >> >> "1) Device determines its IP address by querying the STUN server >> 2) Device determines its domain name using reverse DNS. >> 3) Device does LIS discovery via DNS (SRV/NAPTR)." >> >> There are some situations in which steps 1 and 2 will not work reliably. > >> >> With IPv4 exhaustion looming, it is likely that service providers >> will implement some form of IPv4 address sharing. >> >> In an access network that has deployed a Carrier Grade NAT (CGN), >> step 1 will produce an IP address on the CGN, not the outer address >> of the residential CPE. This could then result in discovery of a LIS >> on the wrong side of the CGN, which would find itself unable to provide >> location since the source IP address will have been shared by too many >> users. > > This shouldn't be a problem. > > If the ISP is running a CGN such that the end user cannot find a > non-RFC1918 public IP address, then all the ISP has to do (per > draft-thomson-geopriv-res-gw-lis-discovery-01) is provision the > appropriate NAPTR records in "in-addr.arpa" for whatever private IP space > they are using. Isn't this making assumptions about which DNS resolver the end host is using? I don't believe we can assume the end host is using the Access Provider's resolver. A common occurrence of bringing up a VPN split-tunnel can change the resolver a host utilizes, or for some, static resolver assignments are made. What am I missing? -Marc- From bs7652@att.com Wed Jun 3 06:30:26 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 D29363A6BAE for ; Wed, 3 Jun 2009 06:30:26 -0700 (PDT) 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 TYfRETouOVLl for ; Wed, 3 Jun 2009 06:30:24 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 391F93A6ACB for ; Wed, 3 Jun 2009 06:30:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-8.tower-167.messagelabs.com!1244035822!9776013!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 23995 invoked from network); 3 Jun 2009 13:30:22 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-8.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Jun 2009 13:30:22 -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 n53DUK5Y016263; Wed, 3 Jun 2009 09:30:22 -0400 Received: from 01GAF5142010622.AD.BLS.COM (01GAF5142010622.ad.bls.com [139.76.131.83]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n53DRVtQ010348; Wed, 3 Jun 2009 09:30:15 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:28:19 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:28:19 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 09:28:13 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0E843CA5@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 thread-index: AcnjzCn9vJNKLR+TSrOsdIWDaFYr1gAga3OQ References: <1243884311.17673.212.camel@vandium.darkcore.net><1243966386.4449.676.camel@vandium.darkcore.net><01d101c9e3b0$d90bfac0$8b23f040$@net><1243977594.4449.813.camel@vandium.darkcore.net> From: "Stark, Barbara" To: "James M. Polk" , "John Lange" , "Brian Rosen" X-OriginalArrivalTime: 03 Jun 2009 13:28:19.0158 (UTC) FILETIME=[289B3760:01C9E44F] Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 13:30:26 -0000 Many retail home routers have been end-of-lifed by their manufacturers. It is highly unrealistic to expect upgrades to be made available for these. It is, likewise, unrealistic to expect the average consumer to know that an upgrade exists (when it does exist) or to know to apply such an upgrade. Discovery of the WAN IP address through a mechanism such as STUN, and then doing a reverse DNS look-up for a LIS server does indeed remain the best option during the many-year-long transition time frame, for the case where an end device isn't able to get location info or LIS info via DHCP. But I'm fine for the IETF not to document or provide a BCP for that. I can go elsewhere for refining best practices. Which is why I don't really care to argue this question anymore. I mainly need the IETF to provide the basic standards, and the basic framework. Which I think they're doing a good job at getting around to. If those documents could just make that final leap to RFC status ... Barbara > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of James M. Polk > Sent: Tuesday, June 02, 2009 5:49 PM > To: John Lange; Brian Rosen > Cc: 'ecrit' > Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on > draft-ietf-ecrit-framework-09 >=20 > At 04:19 PM 6/2/2009, John Lange wrote: > >That is why I'm advocating a closer look at something like STUN + DNS > >for LIS discovery. It will work, allows OBO and requires no new > >hardware. >=20 >=20 > James -- upgrading residential gateways to support (DHCP) Option 99 > or 123 requires no new hardware either.... (last I checked) >=20 > James >=20 >=20 > _______________________________________________ > 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. GA622 From Ray.Bellis@nominet.org.uk Wed Jun 3 06:43: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 D7FC33A6CAD; Wed, 3 Jun 2009 06:43:20 -0700 (PDT) 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 UEpgXw1esSbW; Wed, 3 Jun 2009 06:43:19 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 683D43A6F13; Wed, 3 Jun 2009 06:43:18 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=vpUtYv2l8ufwdzpK6eanPf1Iwi7gILL2B76Jo84SNLLa6fw3luazUi00 1UuYZuQgobPyouUcrEMG7xW8z3YzHE0qLSAjqnW/BGTRkBY99E1pmOOyj xGmT+l3K69DihHm; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1244036601; x=1275572601; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RE:=20[Ecri t]=20Emergency=20Call=20Framework=20for=20Canada=3B=20Que stions=20on=0D=0A=20=20draft-ietf-ecrit-framework-09 |Date:=20Wed,=203=20Jun=202009=2014:43:17=20+0100 |Message-ID:=20|To:=20Bernard=20Aboba=20 |Cc:=20ecrit@ietf.org,=0D=0A =09ecrit-bounces@ietf.org,=0D=0A=09john@johnlange.ca |MIME-Version:=201.0|In-Reply-To:=20|References:=20<1243884311.17673. 212.camel@vandium.darkcore.net>=09=0D=0A=09<1243966386.444 9.676.camel@vandium.darkcore.net>=09<01d101c9e3b0$d90bfac 0$8b23f040$@net>=20=0D=0A=09<1243977594.4449.813.camel@va ndium.darkcore.net>=09=20=0D=0A=09=20=09<1243999810.444 9.877.camel@vandium.darkcore.net>=20=20=20=20; bh=lh8o6uB2KIeW3ysZ4MYheLC/hzEJzyik3RpKTj8akxk=; b=ZFhJGy+JXcrMs7/raypiexF0HMoykb+UlWlNz/0wPIgse3BY2ncbOhoV nOlQmD1dhoK17CF+GfTaRMYWl8BtmASmKELDkhoELnl9d5NnFrrKYDIaU mRI0HNYHx0/V6hO; X-IronPort-AV: E=Sophos;i="4.41,298,1241391600"; d="scan'208";a="14430176" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Jun 2009 14:43:19 +0100 In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <1243999810.4449.877.camel@vandium.darkcore.net> To: Bernard Aboba MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 3 Jun 2009 14:43:17 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/06/2009 02:43:19 PM, Serialize complete at 03/06/2009 02:43:19 PM Content-Type: text/plain; charset="US-ASCII" Cc: ecrit@ietf.org, ecrit-bounces@ietf.org Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 13:43:20 -0000 > Not sure why NATPR RRs would be put in in-addr.arpa. If the ISP is > populating RRs in "in-addr.arpa", couldn't they populate PTR RRs > pointing to a domain within which the SRV/NATPR RRs could be found? They could, but in many cases the choice of the PTR RRs is made by the customer. Using a NAPTR RR allows for separation of the domain name (as used by the customer) from the infrastructure (as provided by the ISP). > > Also, draft-winterbottom-geopriv-held-identity-extensions has recently > > been updated to allow queries to be based on the particular IP port > > currently in use. > > Good idea. Thanks :) > Is it really a good idea for a LIS to query NAT mappings from a CGN?? > I recall a router implementation where there was a facility for > retrieving portions of the forwarding table on a backbone router. > This didn't work well since the queries chewed up cycles that were needed for > processing of control plane traffic. It's probably no worse an idea than CGN itself ;-) kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From bs7652@att.com Wed Jun 3 06:43:35 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 765463A6F5B for ; Wed, 3 Jun 2009 06:43:35 -0700 (PDT) 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, MIME_8BIT_HEADER=0.3, 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 Tc8WYYHAI5bB for ; Wed, 3 Jun 2009 06:43:34 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 6853F3A6E68 for ; Wed, 3 Jun 2009 06:43:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1244036615!14250621!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 5870 invoked from network); 3 Jun 2009 13:43:36 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-2.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Jun 2009 13:43:36 -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 n53DhWw1012301; Wed, 3 Jun 2009 09:43:33 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n53DhRlj012229; Wed, 3 Jun 2009 09:43:27 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:43:27 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:43:26 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 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, 3 Jun 2009 09:43:18 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0E843CB5@crexc41p> In-Reply-To: <62E51439-398D-4004-9FDF-B4C41302F505@xittelecom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 thread-index: AcnjzbQcLjEudW8tQTeEiJzbZ2TdngAgDvjA References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net><1243977594.4449.813.camel@vandium.darkcore.net><023801c9e3cb$46467a60$d2d36f20$@net> <62E51439-398D-4004-9FDF-B4C41302F505@xittelecom.com> From: "Stark, Barbara" To: =?iso-8859-1?Q?=22Fran=E7ois_D=2E_M=E9nard=22?= , "Brian Rosen" X-OriginalArrivalTime: 03 Jun 2009 13:43:26.0812 (UTC) FILETIME=[459C39C0:01C9E451] Cc: ecrit Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 13:43:35 -0000 Most service providers do offer plans with multiple addresses, but the = vast majority of people do not subscribe to these plans. Your service = provider sounds unique in the world of service providers, to give away 3 = addresses to all subscribers. Most service providers who utilize PPPoE = limit (through RADIUS) the number of concurrent PPPoE sessions that are = allowed to 1. The termination points for PPPoE sessions in the network = tend to be capacity limited by number of concurrent sessions, so it = would be a major cost to increase the number of supported PPPoE sessions = per customer, in a world where those customers were actually expected to = use those multiple sessions. Also, each PPPoE session requires an IP = address. Today that's IPv4. As we all know, we're rapidly running out of = those addresses, and doubling the number of IPv4 addresses used by all = customer would be a Very Bad Thing.=20 Oh, and help desk costs of helping people to enter PPPoE login password = in an additional device are significant. Forgotten login/password info = have historically been one of the largest help desk costs that service = providers experience. Again, your proposal is a costly proposal. People who can do the things that you have done in your home network are = few and far between. You are not average. We must have solutions that = work for the average person, and not just the special elite people who = actually understand this stuff. Barbara > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of "Fran=E7ois D. M=E9nard" > Sent: Tuesday, June 02, 2009 6:01 PM > To: Brian Rosen > Cc: ecrit > Subject: Re: [Ecrit] Emergency Call Framework for Canada;Questions on > draft-ietf-ecrit-framework-09 >=20 >=20 > > DHCP works very well in residential VoIP. The phone may have a = NATed > > address, but as long as the home router passes the location option, > > the > > query to the provider will have the right thing to get the DHCP > > system to > > return the location of the residence. If you don't like DHCP, use > > HELD, but > > you still have some remnants of the VPN problem. Don't confuse DHCP > > for LIS > > discovery with DHCP for location configuration. Both work, but DHCP > > discovery of a HELD server works. > > >=20 > I concur. >=20 > If you have a router which does not pass on DHCP Option 99, you can > always initiate a PPPoE tunnel from your ATA and do a DHCP Option 99 > fetching through it. >=20 > There is nothing wrong with having multiple PPPoE sessions from your > home to your ISP, and one dedicated to VoIP. >=20 > Furthermore, this will be an excellent mean to use PPPoE to prioritize > the username/password for a VoIP PPPoE session over the username/ > password for Internet access, for two sessions coming from the same > home. >=20 > The ATAs we use here can be patched to support DHCP Option 99 fetching > through a PPPoE session. All you need is to put a little Ethernet > switch between your DSL modem / Cable Modem and your ATA and to allow > for the possibility that both your ATA as well as your Router will > launch a PPPoE tunnel to your ISP. >=20 > I'll send you a sticker you can can put on your router here... plug > here and die - this box does not pass on location. >=20 > This architecture has the added bonus of accelerating the transition > to IPv6. >=20 > For those concerned with that, our wholesale cable modem incumbent > cable operator, permits up to 3 public IPs behind a single cable > modem, and I use a switch behind my CM to assign a separate public IP > for my VoIP PBX SIPtrunk client, from the public IP address of my > router, which currently is too dumb to relay DHCP Option 99. >=20 > So all I need is to have the DHCP server programmed to send a PIDF-LO. >=20 > And for my SIP client to support SIP LOCATION CONVEYANCE. >=20 > And for it not to never send a BYE if I dial 9-1-1, even if I hang-up. >=20 > F. >=20 > _______________________________________________ > 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. GA625 From Ray.Bellis@nominet.org.uk Wed Jun 3 06:46:45 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 8C1383A6D13 for ; Wed, 3 Jun 2009 06:46:45 -0700 (PDT) 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 gCtJkOWL3hOA for ; Wed, 3 Jun 2009 06:46:41 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id DC2EA3A6F53 for ; Wed, 3 Jun 2009 06:46:36 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=T+9lh56X9Ht661UrqKgHNfLRlAYvLcurWASgbQN+9QaCG7QTQVsvt8MB iFjDJSGzlD8Lzuhl01MhqNAoSVXryhN4MdxBx/OJguQbQsa2qLUIIuw6E ydkCygqfAmA8vD3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1244036799; x=1275572799; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Emergency=20Call=20Framework=20for=20Canada=3B=20Que stions=20on=0D=0A=20=20draft-ietf-ecrit-framework-09 |Date:=20Wed,=203=20Jun=202009=2014:46:22=20+0100 |Message-ID:=20|To:=20Marc=20Linsner=20< mlinsner@cisco.com>|Cc:=20ecrit@ietf.org|MIME-Version:=20 1.0|In-Reply-To:=20 |References:=20=20; bh=/bEQvrwWnKAgrd8lWYKh6gO+UJpAZWxNRDGt1br7WsA=; b=xu3Rv2x1iRJEN5pIyBnV1GhRjLtN6a9aHq4sprMkYJLqzYSOd7lvH3mI EJWFjYWpf04w0Py4F7X+vz+Uc/0AZvhBTgSpfepprSqT5iNo6vdBeckaM QhMo/kauW0fDME3; X-IronPort-AV: E=Sophos;i="4.41,298,1241391600"; d="scan'208";a="14431300" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Jun 2009 14:46:37 +0100 In-Reply-To: References: To: Marc Linsner MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 3 Jun 2009 14:46:22 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/06/2009 02:46:37 PM, Serialize complete at 03/06/2009 02:46:37 PM Content-Type: text/plain; charset="US-ASCII" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 13:46:45 -0000 > > If the ISP is running a CGN such that the end user cannot find a > > non-RFC1918 public IP address, then all the ISP has to do (per > > draft-thomson-geopriv-res-gw-lis-discovery-01) is provision the > > appropriate NAPTR records in "in-addr.arpa" for whatever private IP space > > they are using. > > Isn't this making assumptions about which DNS resolver the end host is > using? I don't believe we can assume the end host is using the Access > Provider's resolver. Good point, that may need some more thought. In the generic case it's fine, because a public IP would be mapped in the public in-addr.arpa zone. > A common occurrence of bringing up a VPN split-tunnel > can change the resolver a host utilizes, or for some, static resolver > assignments are made. As with other LIS discovery processes, this needs doing before any VPNs are established. Ray From drage@alcatel-lucent.com Wed Jun 3 09:21:54 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 2E9033A69E7; Wed, 3 Jun 2009 09:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 1wXlNYqHjGax; Wed, 3 Jun 2009 09:21:53 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7A3A63A695B; Wed, 3 Jun 2009 09:21:52 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n53GLoF2016165 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Jun 2009 18:21:50 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 3 Jun 2009 18:21:50 +0200 From: "DRAGE, Keith (Keith)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , Cullen Jennings , "iesg-secretary@ietf.org" Date: Wed, 3 Jun 2009 18:21:49 +0200 Thread-Topic: PROTO writeup for draft-patel-ecrit-sos-parameter Thread-Index: AcnkINRxn6IjaL22S12MnCOH0Y+bMQAReGlg Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45016847FA@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45016847FA@FIESEXC015.nsn-intra.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.80 Cc: ECRIT Subject: Re: [Ecrit] PROTO writeup for draft-patel-ecrit-sos-parameter 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, 03 Jun 2009 16:21:54 -0000 > The document originally came from the 3GPP and was presented to the IETF= =20 > because a Standards Track extension to SIP was needed.=20 This is not quite accurate. The requirement came from 3GPP. The original requirements did get some deta= iled review in a 3GPP meeting. A number of participants in 3GPP have worked on the document and reviewed t= he contents. The document is used as a normative reference by 3GPP documents, and those = 3GPP documents are in process of implementation by a number of vendors. However there has been no formal review of the contents within a 3GPP meeti= ng or other formal 3GPP process, and the document itself has never been a 3= GPP document. This does match the process that has been followed on a number of other 3GP= P dependencies on IETF. regards Keith =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, June 03, 2009 8:57 AM > To: Cullen Jennings; iesg-secretary@ietf.org > Cc: ECRIT > Subject: [Ecrit] PROTO writeup for draft-patel-ecrit-sos-parameter >=20 > PROTO Writeup for draft-patel-ecrit-sos-parameter=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-06 >=20 >=20 > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of=20 > the document > and, in particular, does he or she believe this version is ready > for forwarding to the IESG for publication? >=20 > Hannes Tschofenig is the document shepherd.=20 > The document is ready for publication. Cullen Jennings, who=20 > is the responsible AD, indicated that an additional review=20 > from SIP experts may be performed.=20 >=20 > (1.b) Has the document had adequate review both from key=20 > members of > the interested community and others? Does the Document Shepherd > have any concerns about the depth or breadth of the reviews that > have been performed? >=20 > The document originally came from the 3GPP and was presented=20 > to the IETF >=20 > because a Standards Track extension to SIP was needed. The=20 > document was reviewed by ECRIT working group members and an=20 > expert reviewer, namely Gonzallo Camarillo, was appointed.=20 > His review can be found here:=20 > http://www.ietf.org/mail-archive/web/ecrit/current/msg06037.html > His comments got addressed in subsequent draft versions.=20 >=20 > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader=20 > perspective, e.g., > security, operational complexity, someone familiar with AAA, > internationalization or XML? >=20 > No. >=20 > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he or > she is uncomfortable with certain parts of the document, or has > concerns whether there really is a need for it. In any=20 > event, if > the interested community has discussed those issues and has > indicated that it still wishes to advance the document, detail > those concerns here. >=20 > There are no concerns with the document. >=20 > (1.e) How solid is the consensus of the interested=20 > community behind > this document? Does it represent the strong=20 > concurrence of a few > individuals, with others being silent, or does the interested > community as a whole understand and agree with it? >=20 > This document is not a product of the ECRIT working group but=20 > required by the 3GPP for their Release 7 emergency services=20 > architecture.=20 > There are architectural differences between the IETF and the=20 > 3GPP emergency services architecture whereby the solution=20 > developed in this document is currenly only needed by the 3GPP.=20 >=20 > There is, however, consensus within the ECRIT WG to publish=20 > the document.=20 >=20 > (1.f) Has anyone threatened an appeal or otherwise=20 > indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) >=20 > No. There were only questions regarding the overall=20 > interworking between >=20 > IETF and 3GPP when it comes to work that is of interest for=20 > the 3GPP only but has to be carried out in the IETF. This=20 > relates to the ongoing discussion about the SIP Change Process.=20 >=20 > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate=20 > checks are not > enough; this check needs to be thorough. Has the=20 > document met all > formal review criteria it needs to, such as the MIB=20 > Doctor, media > type and URI type reviews? >=20 > The ABNF parses with no errors. > Nits have been checked. The errors regarding RFC 2119=20 > boilerplate seem to be incorrect.=20 >=20 > (1.h) Has the document split its references into normative and > informative? Are there normative references to=20 > documents that are > not ready for advancement or are otherwise in an unclear state? > If such normative references exist, what is the=20 > strategy for their > completion? Are there normative references that are downward > references, as described in [RFC3967]? If so, list=20 > these downward > references to support the Area Director in the Last=20 > Call procedure > for them [RFC3967]. >=20 > The references in the document have been split into normative=20 > and informative.=20 > Normative references are all stable documents published as RFCs. >=20 > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body of > the document? If the document specifies protocol=20 > extensions, are > reservations requested in appropriate IANA registries? Are the > IANA registries clearly identified? If the document=20 > creates a new > registry, does it define the proposed initial contents of the > registry and an allocation procedure for future registrations? > Does it suggested a reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If the document > describes an Expert Review process has Shepherd=20 > conferred with the > Responsible Area Director so that the IESG can appoint=20 > the needed > Expert during the IESG Evaluation? >=20 > IANA considerations exist within the document and are=20 > consistent with the body of the document. The new URI=20 > parameter has been specified as defined by RFC 3261.=20 >=20 > The document requests IANA to register the URI parameter. >=20 > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as=20 > XML code, > BNF rules, MIB definitions, etc., validate correctly in an > automated checker? >=20 > Not applicable. >=20 > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: >=20 > Technical Summary >=20 > This document defines a new Session Initiation Protocol=20 > (SIP) Uniform > Resource Identifier (URI) parameter intended for marking SIP > registration requests related to emergency services. The usage of > this new URI parameter complements the usage of the Service Uniform > Resource Name (URN) and is not intended to replace it. >=20 > Working Group Summary >=20 > This document is not the product of a working group. The=20 > document was considered to become an ECRIT working group=20 > item. However, based on the current work schedule and the=20 > urgency of the document the decision was made to progress it=20 > as an AD sponsored document (initially with Jon Peterson as=20 > the AD sponsoring it).=20 >=20 > Document Quality >=20 > The document has been reviewed by IETF ECRIT WG members and=20 > by the 3GPP community. An expert review has been carried out=20 > by Gonzalo Camarillo. >=20 > The implementation status of this document is unknown.=20 >=20 > Personnel >=20 > Hannes Tschofenig is the document shepherd for this document.=20 > Cullen Jennings is the responsible AD.=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From jmpolk@cisco.com Wed Jun 3 09:58:12 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 0700F28C189; Wed, 3 Jun 2009 09:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 11oY4V2hZths; Wed, 3 Jun 2009 09:58:11 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 19FA528C175; Wed, 3 Jun 2009 09:58:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,299,1241395200"; d="scan'208";a="36739919" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 03 Jun 2009 16:57:58 +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 n53GvwpH027931; Wed, 3 Jun 2009 09:57:58 -0700 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 n53GvwAr006923; Wed, 3 Jun 2009 16:57:58 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); Wed, 3 Jun 2009 09:57:58 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.9.214]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:57:57 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Jun 2009 11:57:56 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450168486B@FIESEXC015.nsn-in tra.net> References: <3D3C75174CB95F42AD6BCC56E5555B450168486B@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2009 16:57:57.0869 (UTC) FILETIME=[721A31D0:01C9E46C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2396; t=1244048278; x=1244912278; 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]=20ECRIT=20Milestone=20Update |Sender:=20; bh=xK8LqNb6mfEpyUJl2dJfJxEMWLM4T9wurqDVCiErT78=; b=ZyheI1gSjXWvuZkW4RkvY0UANSdjKTxR64winjxk0/RTXW9bxYliZUj4PF yYELe7kWvDOFYI8N3XkVrJD4qcoUxMeuPU2P2W64N2D/1GzgomXoWBnFpNEx NnORqtG09D; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ECRIT , Robert Sparks Subject: Re: [Ecrit] ECRIT Milestone 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: , X-List-Received-Date: Wed, 03 Jun 2009 16:58:12 -0000 Hannes Why do you continue to ignore the "esnet" Resource-Priority namespace ID in the milestones. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-03.txt This became a WG item more than a year ago, and you stated the last time I pointed this omission out that you were in error. James At 03:32 AM 6/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Please update the milestones for the ECRIT working group: > >---------------------------------- > >Goals and Milestones: > >Done Submit 'Requirements for Emergency Context Resolution >with Internet Technologies' to the IESG for consideration as an >Informational RFC. > >Done Submit 'Security Threats and Requirements for Emergency >Call Marking and Mapping' to the IESG for consideration as an >Informational RFC. > >Done Submit 'A Uniform Resource Name (URN) for Emergency and >Other Well-Known Services' to the IESG for consideration as a Proposed >Standard. > >Done Submit 'LoST: A Location-to-Service Translation >Protocol' to the IESG for consideration as a Proposed Standard. > >Done Submit 'Discovering Location-to-Service Translation >(LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)' to >the IESG for consideration as an Informational RFC. > >Done Submit 'Location-to-URL Mapping Architecture and >Framework' to the IESG for consideration as an Informational RFC. > >Done Submit 'Location Hiding: Problem Statement and Requirements' to >the IESG for consideration as an Informational RFC. > >Done Submit 'Specifying Holes in LoST Service Boundaries' to the >IESG for consideration as an Informational RFC. > >Jul 2009 Submit 'Synchronizing Location-to-Service Translation (LoST) >Protocol based Service Boundaries and Mapping Elements' to the IESG for >consideration as an Experimental RFC. > >Jul 2009 Submit 'Framework for Emergency Calling using >Internet Multimedia' to the IESG for consideration as an Informational >RFC. > >Jul 2009 Submit 'Best Current Practice for Communications >Services in support of Emergency Calling' to the IESG for consideration >as a BCP document >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From bs7652@att.com Wed Jun 3 11:06:05 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 0746828C14C for ; Wed, 3 Jun 2009 11:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 d3sEgQAAuEjL for ; Wed, 3 Jun 2009 11:06:03 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id AAD1C3A6E57 for ; Wed, 3 Jun 2009 11:06:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1244052355!30115154!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 7837 invoked from network); 3 Jun 2009 18:05:56 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-6.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Jun 2009 18:05:56 -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 n53I5spA008369; Wed, 3 Jun 2009 14:05:55 -0400 Received: from 01GAF5142010623.AD.BLS.COM (01GAF5142010623.ad.bls.com [139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n53I5nKH008208; Wed, 3 Jun 2009 14:05:49 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 14:05:49 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 14:05:49 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 14:05:44 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0E843E79@crexc41p> In-Reply-To: <1243884311.17673.212.camel@vandium.darkcore.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 thread-index: Acni7r0YtLHCkIWLQZmB99lWcRh5hQBgNKOg References: <1243884311.17673.212.camel@vandium.darkcore.net> From: "Stark, Barbara" To: "John Lange" , "ecrit" X-OriginalArrivalTime: 03 Jun 2009 18:05:49.0363 (UTC) FILETIME=[ECE6E030:01C9E475] Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 18:06:05 -0000 Going back to respond to John's original email... John, 2. I agree with your LIS discovery issues regarding legacy home routers with NAT. However, solving this does not require new protocols; therefore, I've decided to not object to the current lis-discovery document proceeding as it is. The DHCP options for LIS discovery are needed for the long-term. Getting end VoIP devices to use STUN and do reverse DNS can be handled separately, either with the IETF (e.g., Martin's res-gw-lis-discovery document) or external to the IETF. 3. As for recommended proxy on-behalf-of behavior, the current wording doesn't bother me, although your alternate wording is also fine. It doesn't bother me, because it doesn't change the requirements on the end devices, access nodes, or access networks. Those are the things that have to be very predictable in their behavior, if this architecture is to ultimately succeed. If I were to feel that a proxy under my control should try to get locations, and if such behavior were consistent with the regulatory environment my proxy operated in, then I would have it do just that, no matter how phonebcp is worded. 1. Your suggestion that the device tell its location to its SIP registrar causes me some difficulty. In this case, the device already has its location, so it should also have its PSAP route info. If the device has location and emergency routing info, then the SIP registrar and VSP should just be able to dumbly route. Even if they don't recognize it as an emergency call, they should still be able to route. If the device can't update its location, it will use its locally cached information -- so having the VSP cache this exact same location info would be redundant. Having VSPs that operate inside a country do certain things to ease the transition, like querying location on behalf of location-less devices, is fine, if that's what's desired. Building dependencies on VSP behavior is bad. You don't know where in the world the VSP will be. You don't even know if the "VSP" is nothing more than an Asterix PBX in someone's basement. And there's no need for the emergency call to fail, just because the VSP is foreign. That's part of the beauty of the current architecture -- it's independent of VSP nationality. The device, the access network, and the desired PSAP are usually (not always, in border scenarios) inside the same country. The VSP (registrar) is anywhere. Barbara > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of John Lange > Sent: Monday, June 01, 2009 3:25 PM > To: ecrit > Subject: [Ecrit] Emergency Call Framework for Canada; Questions on > draft-ietf-ecrit-framework-09 >=20 > On April 15 2009, the Canadian Radio and Telecommunications Commission > (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom > Notice of Consultation CRTC 2009-194". >=20 > http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm >=20 > Paragraph 17 asks; "Are there alternative solutions that would improve > on the current nomadic VoIP 9-1-1 service." >=20 > The proposed architecture was developed by Bell Canada based very > loosely on NENAi2 with extensive modifications. As it was developed by > the ILECs in 2006/2007, it does not employ the IETF standards. >=20 > I am working on a submission to this proceeding which advocates the > implementation of the standards developed by the IETF's ECRIT working > group and it's members. (As a side note, if there are any participants > on this list which are interested in helping with this effort, please > do > contact me.) >=20 > After examining draft-ietf-ecrit-framework-09 and it's related RFCs and > RFC-drafts, I have some specific questions/concerns which I hope this > list can answer. >=20 > The Emergency Call Framework (ECF) as proposed : >=20 > - Location is cached at end-point during boot/location discovery but > there does not appear to be any mechanism whereby the end-point > announces the success of this process to the SIP Registrar. >=20 > If the device is able to determine it's location it should relay the > location information to the SIP registration server and the SIP > registrar should cache this information. >=20 > This allows the SIP Registrar and SIP proxy the ability to act > "on-behalf-of" end points that are not able to determine their location > either because they are not location capable, or because they are not > able to determine location from their access provider. >=20 > Furthermore, it removes the burden of "real-time" "on-behalf-of" > functionality from the rest of the network. >=20 > The ability of the registrar to query and cache location data for > endpoints as opposed to the requirement to perform location > determination in real-time, has a dramatic impact on the technical > requirements of the overall solution. >=20 > If location data must be queried in real-time during an actual > emergency > event, the network components must be engineered to a much higher > standard. In some jurisdictions the mandated hardware and network > requirements will be impacted significantly. No less than redundant > five-nine hardware running on dedicated private networks will be > required resulting in higher costs. >=20 > I submit that a query-and-cache methodology is more in line with the > spirit of other IETF protocols, the DNS system being a prime example. >=20 > - Concerns with draft-ietf-geopriv-lis-discovery: >=20 > The focus of LIS discovery seems to be on local access network methods > such as DHCP and LLDP. >=20 > DHCP & LLDP are not good choices for LIS discovery because they are not > supported in the residential market. Residential firewall devices are > not likely to have DHCP/LLDP functionality and the likelihood that > these > devices will be replaced or upgraded is small. >=20 > It would therefore seem that the emphasis should be on a LIS discovery > mechanism that does not rely on the local network such as STUN + DNS. >=20 > 1) Device determines its IP address by querying the STUN server. > 2) Device determines its domain name using reverse DNS. > 3) Device does LIS discovery via DNS (SRV/NAPTR). >=20 > - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on > behalf > of devices if: The proxy has a relationship with all access networks > the > device could connect to". >=20 > This wording seems overly restrictive; in effect "all access networks > the device could connect to" amounts to every network on earth which > seems like an unreasonably high standard. >=20 > How about: >=20 > "Proxies MAY provide location on behalf of devices if: the device does > not provide it's own location and the proxy is able to determine > location on-behalf-of the device. >=20 > Any comments and/or questions would be welcome. >=20 > Regards, > -- > John Lange > http://www.johnlange.ca >=20 > _______________________________________________ > 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. GA623 From john@johnlange.ca Wed Jun 3 11:53:00 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 A45313A6D8A for ; Wed, 3 Jun 2009 11:53:00 -0700 (PDT) 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 f0qxSGbNB80A for ; Wed, 3 Jun 2009 11:52:53 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id A9F7F3A69E5 for ; Wed, 3 Jun 2009 11:52:52 -0700 (PDT) Received: (qmail 5902 invoked from network); 3 Jun 2009 13:52:53 -0500 Received: from unknown (HELO ?192.168.4.43?) (192.168.4.43) by lh02.epicnet.ca with SMTP; 3 Jun 2009 13:52:53 -0500 From: John Lange To: Brian Rosen In-Reply-To: <023801c9e3cb$46467a60$d2d36f20$@net> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <023801c9e3cb$46467a60$d2d36f20$@net> Content-Type: text/plain Date: Wed, 03 Jun 2009 13:52:40 -0500 Message-Id: <1244055160.5470.675.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 18:53:00 -0000 On Tue, 2009-06-02 at 17:44 -0400, Brian Rosen wrote: > We're trying to define real world solutions. We may fail, but we're trying. The work ecrit has done on this issue is exemplary. Much better than previous attempts (i2). However, as James Winterbottom pointed out, "There was one very strong point made in i2 all along, and that is NO UPGRADES to residential equipment is required in order for it work." So i2 might be dead, but the various groups that represent PSAPs in the US and Canada have made this a clear requirement. So, even if you completely disagree with the need for equipment replacement, the parameters have already been set. > OBO doesn't always work, because by the time a call gets to a VoIP provider, > it's IP address can be obscured by VPNs. It doesn't work because the > regulator can't force connections between a service provider it doesn't have > jurisdiction over to an access network (which it probably always has > jurisdiction over, because it's always local). > The easy example is my > famous "Sierra Leone VoIP Services Pty" provider serving a customer at a > Starbucks in, say, Calgary. You can scream all you want, but CRTC can't > tell SLVS to connect to Rogers Cable. Your example clearly identifies the divide between a technical+regulatory solution and a strictly technical one. In the above example, technically it may not work but from a regulatory perspective it does work. It works because the CRTC doesn't care if the SLVS user can reach 911 from his laptop in a Calgary Starbucks. SLVS is not regulated by the CRTC and therefore users of SLVS are not required to have access to 911. To be clear, the CRTC only requires that customers of Canadian VOIP providers have access to 911 while in Canada. Conversely, Canadians using their devices while outside of Canada _MUST NOT_ have access to a Canadian PSAP (i.e. create nuisance calls). It's the opposite of what some might think. If the SLVS regulator wants to dictate that SLVS customers have access to 911 (or whatever) everyplace on earth, then I say good luck with that. > On the other hand, the device can get location from the hotspot in > Starbucks, who can pass it through SLVS on it's way to the Calgary PSAP. On the one hand you've argued that anything based on a public IP won't work because the CRTC doesn't have jurisdiction over SLVS, but on the other hand you've ignored that very same regulatory restriction by assuming that SLVS will have a relationship with a Calgary PSAP. This is not the case. I can positively assure you that the Calgary PSAP will not accept calls from any VOIP provider that it does not have a prior relationship with and for the foreseeable future that means VOIP providers inside Canada. PSAPs are _very_ sensitive to nuisance calls so the concept that the PSAP/ESRP will be open to any IP address in the entire world... no. And as you already pointed out, there can't be a regulatory requirement for this because the CRTC has no jurisdiction to require a relationship with SLVS. (as a side note; the CRTC actually has no jurisdiction over PSAPs what-so-ever but PSAPs will likely go along with the CRTC decision). So, if I understand the position of this group, solutions that require relationships between VOIP providers, ISPs, and PSAPs are not considered viable because they require regulatory authority over all three parties everyplace on earth which is impossible. But the reality is, regulators only care about their own jurisdictions and they DO have authority to order relationships between all three parties. >From the standpoint of the VOIP provider, the PSAP, the ISP and the regulator, the fact that a given solution might not work if one of the three parties is outside the jurisdiction of the regulator is irrelevant. > OBO is usually aimed at transition: before we get the devices all upgraded, > what do we do. In that environment, we may not be able to get location > every time, although I think the VPN problem is so prevalent that it's going > to fail too often. I'm still in favor of trying to get OBO to work, for > transition only, and with the caveat that it may not always work. That is a very reasonable position and one I fully support. OBO must be implemented even though it won't work 100% of the time. > DHCP works very well in residential VoIP. The phone may have a NATed > address, but as long as the home router passes the location option, Ok, full stop here... A couple of messages on this list have made this point without providing any technical explanation. What I don't understand is how this will be done without upgrading or replacing residential firewalls? It's like saying "it's easy to get to the moon provided we shut off the earth's gravity." > If you don't like DHCP, use HELD, I'm advocating using HELD, but first you have to discover the LIS so you can do the HELD query. That's why we need STUN + DNS for LIS discovery on endpoints and DNS LIS discovery for OBO. > but you still have some remnants of the VPN problem. Again, there is a split here between the regulatory and technical. The vast majority of users doing VOIP over VPN are "dialing-in" to corporate VOIP servers. There is no regulatory requirement to provide location for corporate users. It may well become a regulatory requirement in the future but nobody has even raised it yet. Given that we're still struggling with residential, it's safe to say that any such requirement is several years off so holding up everything on that requirement isn't necessary. That being said, the technical solution is for the provider (in this case the corporation) to provide the LIS and by forming a relationship between the VPN tunnel and the enterprise LIS so that the LIS knows to query an external LIS for location based on the public IP, not the WAN/VPN IP. > Don't confuse DHCP for LIS > discovery with DHCP for location configuration. Both work, but DHCP > discovery of a HELD server works. Again, I fundamentally disagree with this statement because it leaves out the phrase "provided we upgrade and/or replace most every residential firewall device currently in service." > I've stayed out of most of the LIS discovery discussions because I don't > seem to have much to offer. I'll let others reply to STUN + Reverse lookup > + SRV. It's been discussed many times. On this list? I went through a fair portion of the list archives and can't find anything. And "google: ecrit stun" turns up nothing from this group. --- The comment by Barbra Stark is quite telling; "But I'm fine for the IETF not to document or provide a BCP for that. I can go elsewhere for refining best practices. Which is why I don't really care to argue this question anymore." With apologies to Barbra for putting words in her mouth; "The BCP developed by this group ignores reality. I'll go elsewhere for for BCP". I get the impression that this has been argued many times in the past so I guess it's just my turn to stir up the pot ;) The framework document I'm developing for submission to my regulator will not follow ecrit-framework or ecript-phonebcp (though it will be based on it) for all of the reasons that I've made apparent on this list. However, the framework would be stronger if it did follow ecrit and likewise, ecrit-framework and ecrit-phonebcp would be stronger if they could demonstrate success in the marketplace. -- John Lange http://www.johnlange.ca From Gabor.Bajko@nokia.com Wed Jun 3 11:59:45 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 EFF3528C150 for ; Wed, 3 Jun 2009 11:59:45 -0700 (PDT) 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 47VjdR0MzPnV for ; Wed, 3 Jun 2009 11:59:45 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DC6343A6DD7 for ; Wed, 3 Jun 2009 11:59:44 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n53IwuTh001158 for ; Wed, 3 Jun 2009 21:59:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 21:59:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 21:59:21 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 3 Jun 2009 20:59:22 +0200 From: To: Date: Wed, 3 Jun 2009 20:59:18 +0200 Thread-Topic: PhoneBCP again Thread-Index: AcnkfWXW6chVFPXXRGajYG7XHjlY8w== Message-ID: 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-OriginalArrivalTime: 03 Jun 2009 18:59:21.0737 (UTC) FILETIME=[67A03F90:01C9E47D] X-Nokia-AV: Clean Subject: [Ecrit] PhoneBCP again 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, 03 Jun 2009 18:59:46 -0000 In today's Interim conf call Brian mentioned that all reasonable suggestion= s were incorporated into PhoneBCP. I sent a while ago a suggestion to the l= ist to revise the abstract instead of including an applicability statement. From: "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." To: "The IETF efforts are targeted at standardizing various aspects of placing emergency calls over the Intern= et. This memo describes requirements for devices, networks and services th= at should be supported in order to make emergency calls over the Internet." The suggestion was ignored (maybe it was not reasonable at that time), but = since today there were discussions around this aspect, I thought it may wor= th resending it.=20 - Gabor= From Hannes.Tschofenig@gmx.net Wed Jun 3 12:04:34 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 E1C8928C19C for ; Wed, 3 Jun 2009 12:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.778, 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 RMNM3IAHNubG for ; Wed, 3 Jun 2009 12:04:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3D30828C198 for ; Wed, 3 Jun 2009 12:04:32 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2009 19:03:57 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp061) with SMTP; 03 Jun 2009 21:03:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Ka4RTYKVKQxt2oplnUwREkMEu0RkHK5oPpfeT/A RZHXu3m6iH5VJW From: "Hannes Tschofenig" To: "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B450168486B@FIESEXC015.nsn-intra.net> Date: Wed, 3 Jun 2009 22:05:49 +0300 Message-ID: <02f001c9e47e$4f7c7ae0$0301a8c0@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: AcnkbHxQx+lHC3OxQrGg1MIcbvJBRQAEb9lg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: 'ECRIT' , 'Robert Sparks' Subject: Re: [Ecrit] ECRIT Milestone 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: , X-List-Received-Date: Wed, 03 Jun 2009 19:04:35 -0000 Hi James, I hope that this issue got clarified during the conference call. This has nothing todo with me. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of James M. Polk >Sent: 03 June, 2009 19:58 >To: Tschofenig, Hannes (NSN - FI/Espoo); iesg-secretary@ietf.org >Cc: ECRIT; Robert Sparks >Subject: Re: [Ecrit] ECRIT Milestone Update > >Hannes > >Why do you continue to ignore the "esnet" Resource-Priority >namespace ID in the milestones. >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >gency-rph-namespace-03.txt > >This became a WG item more than a year ago, and you stated the >last time I pointed this omission out that you were in error. > >James > >At 03:32 AM 6/3/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Please update the milestones for the ECRIT working group: >> >>---------------------------------- >> >>Goals and Milestones: >> >>Done Submit 'Requirements for Emergency Context Resolution >>with Internet Technologies' to the IESG for consideration as an >>Informational RFC. >> >>Done Submit 'Security Threats and Requirements for >Emergency >>Call Marking and Mapping' to the IESG for consideration as an >>Informational RFC. >> >>Done Submit 'A Uniform Resource Name (URN) for >Emergency and >>Other Well-Known Services' to the IESG for consideration as a >Proposed >>Standard. >> >>Done Submit 'LoST: A Location-to-Service Translation >>Protocol' to the IESG for consideration as a Proposed Standard. >> >>Done Submit 'Discovering Location-to-Service Translation >>(LoST) Servers Using the Dynamic Host Configuration Protocol >(DHCP)' to >>the IESG for consideration as an Informational RFC. >> >>Done Submit 'Location-to-URL Mapping Architecture and >>Framework' to the IESG for consideration as an Informational RFC. >> >>Done Submit 'Location Hiding: Problem Statement and >Requirements' to >>the IESG for consideration as an Informational RFC. >> >>Done Submit 'Specifying Holes in LoST Service Boundaries' to the >>IESG for consideration as an Informational RFC. >> >>Jul 2009 Submit 'Synchronizing Location-to-Service Translation (LoST) >>Protocol based Service Boundaries and Mapping Elements' to >the IESG for >>consideration as an Experimental RFC. >> >>Jul 2009 Submit 'Framework for Emergency Calling using >>Internet Multimedia' to the IESG for consideration as an >Informational >>RFC. >> >>Jul 2009 Submit 'Best Current Practice for >Communications >>Services in support of Emergency Calling' to the IESG for >consideration >>as a BCP document _______________________________________________ >>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 br@brianrosen.net Wed Jun 3 12:07:01 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 F3F9A3A6A2A for ; Wed, 3 Jun 2009 12:07:00 -0700 (PDT) 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 KYfCoWtpUrBc for ; Wed, 3 Jun 2009 12:07:00 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 395A03A69A4 for ; Wed, 3 Jun 2009 12:07:00 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MBvnU-0003EW-Ec; Wed, 03 Jun 2009 14:06:49 -0500 From: "Brian Rosen" To: , References: In-Reply-To: Date: Wed, 3 Jun 2009 15:06:54 -0400 Message-ID: <040401c9e47e$781d7b20$68587160$@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: AcnkfWXW6chVFPXXRGajYG7XHjlY8wAANhqA 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] PhoneBCP again 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, 03 Jun 2009 19:07:01 -0000 If this is helpful to resolving the disagreement we are having, I am not opposed to the change. It does have the unfortunate change from "best current practice" to "requirements" which is a problem. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Gabor.Bajko@nokia.com > Sent: Wednesday, June 03, 2009 2:59 PM > To: ecrit@ietf.org > Subject: [Ecrit] PhoneBCP again > > In today's Interim conf call Brian mentioned that all reasonable > suggestions were incorporated into PhoneBCP. I sent a while ago a > suggestion to the list to revise the abstract instead of including an > applicability statement. > > From: > > "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." > > To: > > "The IETF efforts are targeted at > standardizing various aspects of placing emergency calls over the > Internet. This memo describes requirements for devices, networks and > services that should be supported in order to make emergency calls over > the Internet." > > The suggestion was ignored (maybe it was not reasonable at that time), > but since today there were discussions around this aspect, I thought it > may worth resending it. > > - Gabor > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Wed Jun 3 12:30:07 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 371653A6D0E for ; Wed, 3 Jun 2009 12:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 NKu5EfeqKMPV for ; Wed, 3 Jun 2009 12:30:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ADED43A67B6 for ; Wed, 3 Jun 2009 12:29:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,299,1241395200"; d="scan'208";a="78991713" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 03 Jun 2009 19:30:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n53JU0th015738; Wed, 3 Jun 2009 12:30:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n53JU0hu022296; Wed, 3 Jun 2009 19:30:00 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); Wed, 3 Jun 2009 12:30:00 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.9.214]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 12:29:59 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Jun 2009 14:29:58 -0500 To: John Lange , Brian Rosen From: "James M. Polk" In-Reply-To: <1244055160.5470.675.camel@vandium.darkcore.net> References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <023801c9e3cb$46467a60$d2d36f20$@net> <1244055160.5470.675.camel@vandium.darkcore.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2009 19:29:59.0823 (UTC) FILETIME=[AF35E9F0:01C9E481] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9139; t=1244057400; x=1244921400; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20=20draft-ietf-ecrit- framework-09 |Sender:=20; bh=5QJEH3C67C0Sj/qAlOX4K2F1PeU/N7kF4CR/sQCsY0M=; b=XoAZCSZVZKOw2TqVL14dj0IV6+AbbwAEEv3chzGySTJRNCiTE6UR2A132x VV5RKFVPoffRK88NOJFlnCMPbt0wGn0doln0TymVFxTe61Eu20fps7IVCpqk lAz1BtoWsV; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 19:30:07 -0000 At 01:52 PM 6/3/2009, John Lange wrote: >On Tue, 2009-06-02 at 17:44 -0400, Brian Rosen wrote: > > We're trying to define real world solutions. We may fail, but > we're trying. > >The work ecrit has done on this issue is exemplary. Much better than >previous attempts (i2). > >However, as James Winterbottom pointed out, "There was one very strong >point made in i2 all along, and that is NO UPGRADES to residential >equipment is required in order for it work." > >So i2 might be dead, but the various groups that represent PSAPs in the >US and Canada have made this a clear requirement. So, even if you >completely disagree with the need for equipment replacement, the >parameters have already been set. one the one hand you say "i2 might be dead", and on the other hand you mean "we need to remain constrained by the i2 limitations". this is interesting considering i2 didn't change anything in the PSAP, so why are PSAPs involved in making this requirement when they get to "stay in the past" with anything the IETF moves forward with? I'm confused. Further, in the same meeting (in 2003 in Atlanta, that I was in attendance of) - both the i2 and i3 WGs were formed within NENA. Nothing was in stone yet wrt the architecture of either, other than i3 was IP e2e, including into the PSAP (i.e., to the call-taker's phone). Thus, PSAPs have been aware of i2 for as long as they have been aware of i3. Why are they able to dictate i2 rules upon the i3 solution? i3, from the beginning, was to be built on the idea that location would be sent from the calling phone. This means "the residential phone and its network" must be changed to support IP, and all that IP brings to the table. Now you are saying the RG cannot be changed for i3? BTW - I was co-chair of i3 with Brian for the first year... > > OBO doesn't always work, because by the time a call gets to a > VoIP provider, > > it's IP address can be obscured by VPNs. It doesn't work because the > > regulator can't force connections between a service provider it > doesn't have > > jurisdiction over to an access network (which it probably always has > > jurisdiction over, because it's always local). > > > The easy example is my > > famous "Sierra Leone VoIP Services Pty" provider serving a customer at a > > Starbucks in, say, Calgary. You can scream all you want, but CRTC can't > > tell SLVS to connect to Rogers Cable. > >Your example clearly identifies the divide between a >technical+regulatory solution and a strictly technical one. > >In the above example, technically it may not work but from a regulatory >perspective it does work. It works because the CRTC doesn't care if the >SLVS user can reach 911 from his laptop in a Calgary Starbucks. SLVS is >not regulated by the CRTC and therefore users of SLVS are not required >to have access to 911. > >To be clear, the CRTC only requires that customers of Canadian VOIP >providers have access to 911 while in Canada. > >Conversely, Canadians using their devices while outside of Canada _MUST >NOT_ have access to a Canadian PSAP (i.e. create nuisance calls). It's >the opposite of what some might think. > >If the SLVS regulator wants to dictate that SLVS customers have access >to 911 (or whatever) everyplace on earth, then I say good luck with >that. > > > On the other hand, the device can get location from the hotspot in > > Starbucks, who can pass it through SLVS on it's way to the Calgary PSAP. > >On the one hand you've argued that anything based on a public IP won't >work because the CRTC doesn't have jurisdiction over SLVS, but on the >other hand you've ignored that very same regulatory restriction by >assuming that SLVS will have a relationship with a Calgary PSAP. > >This is not the case. I can positively assure you that the Calgary PSAP >will not accept calls from any VOIP provider that it does not have a >prior relationship with and for the foreseeable future that means VOIP >providers inside Canada. > >PSAPs are _very_ sensitive to nuisance calls so the concept that the >PSAP/ESRP will be open to any IP address in the entire world... no. > >And as you already pointed out, there can't be a regulatory requirement >for this because the CRTC has no jurisdiction to require a relationship >with SLVS. (as a side note; the CRTC actually has no jurisdiction over >PSAPs what-so-ever but PSAPs will likely go along with the CRTC >decision). > >So, if I understand the position of this group, solutions that require >relationships between VOIP providers, ISPs, and PSAPs are not considered >viable because they require regulatory authority over all three parties >everyplace on earth which is impossible. > >But the reality is, regulators only care about their own jurisdictions >and they DO have authority to order relationships between all three >parties. > > >From the standpoint of the VOIP provider, the PSAP, the ISP and the >regulator, the fact that a given solution might not work if one of the >three parties is outside the jurisdiction of the regulator is >irrelevant. > > > OBO is usually aimed at transition: before we get the devices all upgraded, > > what do we do. In that environment, we may not be able to get location > > every time, although I think the VPN problem is so prevalent that > it's going > > to fail too often. I'm still in favor of trying to get OBO to work, for > > transition only, and with the caveat that it may not always work. > >That is a very reasonable position and one I fully support. OBO must be >implemented even though it won't work 100% of the time. > > > DHCP works very well in residential VoIP. The phone may have a NATed > > address, but as long as the home router passes the location option, > >Ok, full stop here... A couple of messages on this list have made this >point without providing any technical explanation. > >What I don't understand is how this will be done without upgrading or >replacing residential firewalls? > >It's like saying "it's easy to get to the moon provided we shut off the >earth's gravity." > > > If you don't like DHCP, use HELD, > >I'm advocating using HELD, but first you have to discover the LIS so you >can do the HELD query. That's why we need STUN + DNS for LIS discovery >on endpoints and DNS LIS discovery for OBO. > > > but you still have some remnants of the VPN problem. > >Again, there is a split here between the regulatory and technical. The >vast majority of users doing VOIP over VPN are "dialing-in" to corporate >VOIP servers. There is no regulatory requirement to provide location for >corporate users. It may well become a regulatory requirement in the >future but nobody has even raised it yet. Given that we're still >struggling with residential, it's safe to say that any such requirement >is several years off so holding up everything on that requirement isn't >necessary. > >That being said, the technical solution is for the provider (in this >case the corporation) to provide the LIS and by forming a relationship >between the VPN tunnel and the enterprise LIS so that the LIS knows to >query an external LIS for location based on the public IP, not the >WAN/VPN IP. > > > Don't confuse DHCP for LIS > > discovery with DHCP for location configuration. Both work, but DHCP > > discovery of a HELD server works. > >Again, I fundamentally disagree with this statement because it leaves >out the phrase "provided we upgrade and/or replace most every >residential firewall device currently in service." > > > I've stayed out of most of the LIS discovery discussions because I don't > > seem to have much to offer. I'll let others reply to STUN + Reverse lookup > > + SRV. It's been discussed many times. > >On this list? I went through a fair portion of the list archives and >can't find anything. And "google: ecrit stun" turns up nothing from this >group. > >--- > >The comment by Barbra Stark is quite telling; "But I'm fine for the IETF >not to document or provide a BCP for that. I can go elsewhere for >refining best practices. Which is why I don't really care to argue this >question anymore." > >With apologies to Barbra for putting words in her mouth; "The BCP >developed by this group ignores reality. I'll go elsewhere for for BCP". > >I get the impression that this has been argued many times in the past so >I guess it's just my turn to stir up the pot ;) > >The framework document I'm developing for submission to my regulator >will not follow ecrit-framework or ecript-phonebcp (though it will be >based on it) for all of the reasons that I've made apparent on this >list. > >However, the framework would be stronger if it did follow ecrit and >likewise, ecrit-framework and ecrit-phonebcp would be stronger if they >could demonstrate success in the marketplace. > >-- >John Lange >http://www.johnlange.ca > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Wed Jun 3 13:07:33 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 5F2373A6929 for ; Wed, 3 Jun 2009 13:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=0.102, 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 FvHpBgCmRHNZ for ; Wed, 3 Jun 2009 13:07:32 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 574C83A67E6 for ; Wed, 3 Jun 2009 13:07:31 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_03_15_29_00 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, 03 Jun 2009 15:29:00 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 15:07:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 15:06:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP again Thread-Index: AcnkfWXW6chVFPXXRGajYG7XHjlY8wAANhqAAAIi3vU= References: <040401c9e47e$781d7b20$68587160$@net> From: "Winterbottom, James" To: "Brian Rosen" , , X-OriginalArrivalTime: 03 Jun 2009 20:07:32.0476 (UTC) FILETIME=[EDE57BC0:01C9E486] Subject: Re: [Ecrit] PhoneBCP again 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, 03 Jun 2009 20:07:33 -0000 We had a hum on this on the list.=0D=0ABy my count the number against the i= nclusion of any kind of statement was by far in the majority, so why is the= statement still there=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A---= --Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org on behalf of Bria= n Rosen=0D=0ASent: Wed 6/3/2009 2:06 PM=0D=0ATo: Gabor.Bajko@nokia.com; ecr= it@ietf.org=0D=0ASubject: Re: [Ecrit] PhoneBCP again=0D=0A=20=0D=0AIf this = is helpful to resolving the disagreement we are having, I am not=0D=0Aoppos= ed to the change. It does have the unfortunate change from "best=0D=0Acurr= ent practice" to "requirements" which is a problem.=0D=0A=0D=0ABrian=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: ecrit-bounces@ietf.org [mailto= :ecrit-bounces@ietf.org] On Behalf=0D=0A> Of Gabor.Bajko@nokia.com=0D=0A> S= ent: Wednesday, June 03, 2009 2:59 PM=0D=0A> To: ecrit@ietf.org=0D=0A> Subj= ect: [Ecrit] PhoneBCP again=0D=0A>=20=0D=0A> In today's Interim conf call B= rian mentioned that all reasonable=0D=0A> suggestions were incorporated int= o PhoneBCP. I sent a while ago a=0D=0A> suggestion to the list to revise th= e abstract instead of including an=0D=0A> applicability statement.=0D=0A> =0D= =0A> From:=0D=0A>=20=0D=0A> "The IETF and other standards organization have= efforts targeted at=0D=0A> standardizing various aspects of placing eme= rgency calls on IP=0D=0A> networks. This memo describes best current pr= actice on how devices,=0D=0A> networks and services should use such stan= dards to make emergency=0D=0A> calls."=0D=0A>=20=0D=0A> To:=0D=0A>=20=0D= =0A> "The IETF efforts are targeted at=0D=0A> standardizing various aspe= cts of placing emergency calls over the=0D=0A> Internet. This memo describ= es requirements for devices, networks and=0D=0A> services that should be su= pported in order to make emergency calls over=0D=0A> the Internet."=0D=0A> =0D= =0A> The suggestion was ignored (maybe it was not reasonable at that time),=0D= =0A> but since today there were discussions around this aspect, I thought i= t=0D=0A> may worth resending it.=0D=0A>=20=0D=0A> - Gabor=0D=0A> __________= _____________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecri= t@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A__= _____________________________________________=0D=0AEcrit mailing list=0D=0A= Ecrit@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 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 From mlinsner@cisco.com Wed Jun 3 14:00:28 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 B566028C0E1 for ; Wed, 3 Jun 2009 14:00:28 -0700 (PDT) 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 oKEy0GGMQgVc for ; Wed, 3 Jun 2009 14:00:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 227B83A6B17 for ; Wed, 3 Jun 2009 14:00:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,300,1241395200"; d="scan'208";a="316346770" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 03 Jun 2009 21:00:22 +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 n53L0Lt2002308; Wed, 3 Jun 2009 17:00:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n53L0LTa018990; Wed, 3 Jun 2009 21:00:22 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 17:00:19 -0400 Received: from [10.116.195.120] ([10.116.195.120]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 17:00:18 -0400 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 17:00:17 -0400 From: Marc Linsner To: John Lange Message-ID: Thread-Topic: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 Thread-Index: AcnkjkwZsy6CgRK3gUO2qkGP34m33Q== In-Reply-To: <1244055160.5470.675.camel@vandium.darkcore.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Jun 2009 21:00:19.0089 (UTC) FILETIME=[4D584810:01C9E48E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10452; t=1244062821; x=1244926821; 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]=20Emergency=20Call=20Framework= 20for=20Canada=3B=20Questions=20on=0A=20draft-ietf-ecrit-fra mework-09 |Sender:=20 |To:=20John=20Lange=20; bh=JzY7c4m6i3KkWuV+LPG8FOWh/is5wFT8KHt+nNW17Hg=; b=mNcJni5xE1VnAO1oHZOPqrnjMaFD5v9jEJekdCFZquhotY0xBYN+FLVXN5 hWHamCKLlzZZ7JSRWbRquqEuCxJAOea75VmxyYYgCWZDVo+3iu4MvWQuERGR Eum6Iqobjl; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 21:00:28 -0000 John, I would guess by your comments that you missed some early threads in both ECRIT and GEOPRIV. more in-line.... On 6/3/09 2:52 PM, "John Lange" wrote: > On Tue, 2009-06-02 at 17:44 -0400, Brian Rosen wrote: >> We're trying to define real world solutions. We may fail, but we're trying. > > The work ecrit has done on this issue is exemplary. Much better than > previous attempts (i2). > > However, as James Winterbottom pointed out, "There was one very strong > point made in i2 all along, and that is NO UPGRADES to residential > equipment is required in order for it work." Requirements are wonderful, they guide the solutions. Not every requirement has a technically feasible solution. We can certainly debate how one gains new functionality without upgrades, but that will probably lead us to a very big rat hole, one the IETF has been in many times before. > > So i2 might be dead, but the various groups that represent PSAPs in the > US and Canada have made this a clear requirement. So, even if you > completely disagree with the need for equipment replacement, the > parameters have already been set. i2 is not an IETF developed solution. > >> OBO doesn't always work, because by the time a call gets to a VoIP provider, >> it's IP address can be obscured by VPNs. It doesn't work because the >> regulator can't force connections between a service provider it doesn't have >> jurisdiction over to an access network (which it probably always has >> jurisdiction over, because it's always local). > >> The easy example is my >> famous "Sierra Leone VoIP Services Pty" provider serving a customer at a >> Starbucks in, say, Calgary. You can scream all you want, but CRTC can't >> tell SLVS to connect to Rogers Cable. > > Your example clearly identifies the divide between a > technical+regulatory solution and a strictly technical one. > > In the above example, technically it may not work but from a regulatory > perspective it does work. It works because the CRTC doesn't care if the > SLVS user can reach 911 from his laptop in a Calgary Starbucks. SLVS is > not regulated by the CRTC and therefore users of SLVS are not required > to have access to 911. > > To be clear, the CRTC only requires that customers of Canadian VOIP > providers have access to 911 while in Canada. The CRTC can and will do whatever they want, based on the input from whoever provides them input. If Canada decides to not offer emergency assistance to visitors to Canada, so be it. I would hope the CRTC would consider the consequences of their policies governing the Internet usage. > > Conversely, Canadians using their devices while outside of Canada _MUST > NOT_ have access to a Canadian PSAP (i.e. create nuisance calls). It's > the opposite of what some might think. > > If the SLVS regulator wants to dictate that SLVS customers have access > to 911 (or whatever) everyplace on earth, then I say good luck with > that. > The two points you make are exactly why regulators should proceed with caution when making policy for the Internet. >> On the other hand, the device can get location from the hotspot in >> Starbucks, who can pass it through SLVS on it's way to the Calgary PSAP. > > On the one hand you've argued that anything based on a public IP won't > work because the CRTC doesn't have jurisdiction over SLVS, but on the > other hand you've ignored that very same regulatory restriction by > assuming that SLVS will have a relationship with a Calgary PSAP. > > This is not the case. I can positively assure you that the Calgary PSAP > will not accept calls from any VOIP provider that it does not have a > prior relationship with and for the foreseeable future that means VOIP > providers inside Canada. The Calgary PSAP can certainly dictate who can and who can't call them. They can require that all citizens of Calgary MUST do business with approved providers in order to enjoy the luxury of emergency assistance from governmental agencies. Although, IMO, this is somewhat contrary to the globalization the Internet allows. > > PSAPs are _very_ sensitive to nuisance calls so the concept that the > PSAP/ESRP will be open to any IP address in the entire world... no. This is not the consensus when I talk to PSAPs. They would rather deal with all the bad stuff instead of missing a real call for help. > > And as you already pointed out, there can't be a regulatory requirement > for this because the CRTC has no jurisdiction to require a relationship > with SLVS. (as a side note; the CRTC actually has no jurisdiction over > PSAPs what-so-ever but PSAPs will likely go along with the CRTC > decision). > > So, if I understand the position of this group, solutions that require > relationships between VOIP providers, ISPs, and PSAPs are not considered > viable because they require regulatory authority over all three parties > everyplace on earth which is impossible. IMO, a more correct characterization is: The IETF is all about making the end-user experience better and the Internet work better. The success of the Internet can be directly related to the distillation of access, network, and applications. Hence neither GeoPriv nor ECRIT will propose a solution that requires relationships between various providers at different layers as that would be contrary to the foundation of the Internet. > > But the reality is, regulators only care about their own jurisdictions > and they DO have authority to order relationships between all three > parties. As long as they realize they are restricting their constituent's choice to providers within purview of their jurisdiction. > >> From the standpoint of the VOIP provider, the PSAP, the ISP and the > regulator, the fact that a given solution might not work if one of the > three parties is outside the jurisdiction of the regulator is > irrelevant. > >> OBO is usually aimed at transition: before we get the devices all upgraded, >> what do we do. In that environment, we may not be able to get location >> every time, although I think the VPN problem is so prevalent that it's going >> to fail too often. I'm still in favor of trying to get OBO to work, for >> transition only, and with the caveat that it may not always work. > > That is a very reasonable position and one I fully support. OBO must be > implemented even though it won't work 100% of the time. > >> DHCP works very well in residential VoIP. The phone may have a NATed >> address, but as long as the home router passes the location option, > > Ok, full stop here... A couple of messages on this list have made this > point without providing any technical explanation. > > What I don't understand is how this will be done without upgrading or > replacing residential firewalls? It won't happen without upgrades. > > It's like saying "it's easy to get to the moon provided we shut off the > earth's gravity." > >> If you don't like DHCP, use HELD, > > I'm advocating using HELD, but first you have to discover the LIS so you > can do the HELD query. That's why we need STUN + DNS for LIS discovery > on endpoints and DNS LIS discovery for OBO. The solutions around this have been proposed multiple times without significant progress. Hopefully the technical aspects of this solution will be resolved soon. > >> but you still have some remnants of the VPN problem. > > Again, there is a split here between the regulatory and technical. The > vast majority of users doing VOIP over VPN are "dialing-in" to corporate > VOIP servers. There is no regulatory requirement to provide location for > corporate users. It may well become a regulatory requirement in the > future but nobody has even raised it yet. Given that we're still > struggling with residential, it's safe to say that any such requirement > is several years off so holding up everything on that requirement isn't > necessary. The IETF is proposing solutions that fit the Internet model which includes VPNs. The IETF doesn't sequence it's work based on regulation. > > That being said, the technical solution is for the provider (in this > case the corporation) to provide the LIS and by forming a relationship > between the VPN tunnel and the enterprise LIS so that the LIS knows to > query an external LIS for location based on the public IP, not the > WAN/VPN IP. Again, an IETF solution will not force relationships. > >> Don't confuse DHCP for LIS >> discovery with DHCP for location configuration. Both work, but DHCP >> discovery of a HELD server works. > > Again, I fundamentally disagree with this statement because it leaves > out the phrase "provided we upgrade and/or replace most every > residential firewall device currently in service." > >> I've stayed out of most of the LIS discovery discussions because I don't >> seem to have much to offer. I'll let others reply to STUN + Reverse lookup >> + SRV. It's been discussed many times. > > On this list? I went through a fair portion of the list archives and > can't find anything. And "google: ecrit stun" turns up nothing from this > group. Since most of this discussion is a GeoPriv issue, you would probably have better luck searching there. GeoPriv is defining how a device discovers it's location. -Marc- > > --- > > The comment by Barbra Stark is quite telling; "But I'm fine for the IETF > not to document or provide a BCP for that. I can go elsewhere for > refining best practices. Which is why I don't really care to argue this > question anymore." > > With apologies to Barbra for putting words in her mouth; "The BCP > developed by this group ignores reality. I'll go elsewhere for for BCP". > > I get the impression that this has been argued many times in the past so > I guess it's just my turn to stir up the pot ;) > > The framework document I'm developing for submission to my regulator > will not follow ecrit-framework or ecript-phonebcp (though it will be > based on it) for all of the reasons that I've made apparent on this > list. > > However, the framework would be stronger if it did follow ecrit and > likewise, ecrit-framework and ecrit-phonebcp would be stronger if they > could demonstrate success in the marketplace. From john@johnlange.ca Wed Jun 3 14:07:14 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 A6D2D3A696C for ; Wed, 3 Jun 2009 14:07:14 -0700 (PDT) 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 c-9-IbNBGQqy for ; Wed, 3 Jun 2009 14:07:13 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 6D8683A6AA8 for ; Wed, 3 Jun 2009 14:07:13 -0700 (PDT) Received: (qmail 22030 invoked from network); 3 Jun 2009 16:07:14 -0500 Received: from unknown (HELO ?192.168.4.43?) (192.168.4.43) by lh02.epicnet.ca with SMTP; 3 Jun 2009 16:07:14 -0500 From: John Lange To: "James M. Polk" In-Reply-To: References: <1243884311.17673.212.camel@vandium.darkcore.net> <1243966386.4449.676.camel@vandium.darkcore.net> <01d101c9e3b0$d90bfac0$8b23f040$@net> <1243977594.4449.813.camel@vandium.darkcore.net> <023801c9e3cb$46467a60$d2d36f20$@net> <1244055160.5470.675.camel@vandium.darkcore.net> Content-Type: text/plain Date: Wed, 03 Jun 2009 16:07:01 -0500 Message-Id: <1244063221.5470.918.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 21:07:14 -0000 On Wed, 2009-06-03 at 14:29 -0500, James M. Polk wrote: > one the one hand you say "i2 might be dead", and on the other hand > you mean "we need to remain constrained by the i2 limitations". I think it's pretty clear that the PSAPs have the same requirements today that they always did. And with respect to the issue of replacement or upgrading end-user equipment, I agree with them. > this is interesting considering i2 didn't change anything in the > PSAP, so why are PSAPs involved in making this requirement when they > get to "stay in the past" with anything the IETF moves forward with? I've asked the same question many many times. The answer is; because the PSAP + the ILECs are by far the most powerful influence on the regulators. Of course that is not binding on the IETF but there requirements are never the less something worth keeping in mind. > I'm confused. Ah yes. It's a messed up world we live in. The PSAP argument basically amounts to; "the world is changing but we don't like change so please make your square peg fit in this round hole. Oh, and the cost to us must be zero." Please don't get me started on a PSAP rant. They are dinosaurs all... But they've been trained well by the ILECs and that's the world we live in... ( I should clarify that i mean Canadian PSAPs). > i3, from the beginning, was to be built on the idea that location > would be sent from the calling phone. This means "the residential > phone and its network" must be changed to support IP, and all that IP > brings to the table. But that is technically not a true statement. Yes the phone will have to be changed to support location, and yes, the best way to get accurate location is from the local network. But no, the local network does not have to be changed in order for the phone to get location. Other devices can act OBO the local network and will do just as good a job frequently enough to satisfy regulatory requirements until the day that every RG has been replaced and every DHCP server does option 99 (or whatever the solution turns out to be). > Now you are saying the RG cannot be changed for i3? I'm not saying that at all. What I am saying is, this won't work for residential today and therefore it won't be acceptable to the regulators (today). I understand I could be the one in the wrong here because I don't clearly understand the goals of this group. If ecrit is saying "yes we know ecrit-framework and phonebcp can't be implemented today. We are developing a standard for the future. After we are done we'll do some interim standards to bridge between today and the ecrit-framework of the future", then I think that's a reasonable approach but that is not the impression I've had up until now. My only concern would be that the progress is too slow. We need the interim solutions before future solutions. Without them, the aforementioned PSAPs and ILECs will impose their own "home-brew" solutions with the associated predictable costs. BTW, I listened in on the last 45 minutes of the call today (I screwed up the timezone conversion or I would have been there sooner). Very informative. For one thing, I had no idea that Best Current Practise is not intended to mean what it says. It's not intended to be the best nor is it current so that alleviates some confusion. And the debate about the cell phone group (3GP?) expecting the proxy to do location, not the handset sounded a lot like OBO-redux to me. > BTW - I was co-chair of i3 with Brian for the first year... What is the status of NENA with respect to i3? Is work still going on? Has ecrit replaced it or exactly what is the relationship between the two groups? -- John Lange http://www.johnlange.ca From john@johnlange.ca Wed Jun 3 14:45:19 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 C7A3E3A6D68 for ; Wed, 3 Jun 2009 14:45:19 -0700 (PDT) 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 bSwev8h7A1DX for ; Wed, 3 Jun 2009 14:45:19 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 13AAE28C1CA for ; Wed, 3 Jun 2009 14:44:36 -0700 (PDT) Received: (qmail 1826 invoked from network); 3 Jun 2009 16:44:34 -0500 Received: from unknown (HELO ?192.168.4.43?) (192.168.4.43) by lh02.epicnet.ca with SMTP; 3 Jun 2009 16:44:34 -0500 From: John Lange To: Marc Linsner In-Reply-To: References: Content-Type: text/plain Date: Wed, 03 Jun 2009 16:44:21 -0500 Message-Id: <1244065461.5470.970.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: 'ecrit' Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09 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, 03 Jun 2009 21:45:19 -0000 Marc, no need for me to quote your entire reply. I just want to say that your response was very informative and shed a lot of light onto how the IETF sees regulatory requirements and it's goals as far as developing standards. I just might be able to stop tormenting this list now.... ;) -- John Lange http://www.johnlange.ca From Gabor.Bajko@nokia.com Wed Jun 3 17:04:48 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 B3AE63A7060 for ; Wed, 3 Jun 2009 17:04:48 -0700 (PDT) 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 R89AGChVV60L for ; Wed, 3 Jun 2009 17:04:47 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BEAC628C13F for ; Wed, 3 Jun 2009 17:03:37 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n5403KDW009820; Thu, 4 Jun 2009 03:03:27 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 03:00:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 03:00:29 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 4 Jun 2009 02:00:28 +0200 From: To: , Date: Thu, 4 Jun 2009 02:00:26 +0200 Thread-Topic: [Ecrit] PhoneBCP again Thread-Index: AcnkfWXW6chVFPXXRGajYG7XHjlY8wAANhqAAApACIA= Message-ID: References: <040401c9e47e$781d7b20$68587160$@net> In-Reply-To: <040401c9e47e$781d7b20$68587160$@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-OriginalArrivalTime: 04 Jun 2009 00:00:29.0366 (UTC) FILETIME=[78C5A560:01C9E4A7] X-Nokia-AV: Clean Subject: Re: [Ecrit] PhoneBCP again 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, 04 Jun 2009 00:04:49 -0000 Well, if we can't scope it down this way, then I would prefer having an exp= licit applicability statement. - gabor=20 >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, June 03, 2009 12:07 PM >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >Subject: RE: [Ecrit] PhoneBCP again > >If this is helpful to resolving the disagreement we are=20 >having, I am not opposed to the change. It does have the=20 >unfortunate change from "best current practice" to=20 >"requirements" which is a problem. > >Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org=20 >[mailto:ecrit-bounces@ietf.org] On Behalf=20 >> Of Gabor.Bajko@nokia.com >> Sent: Wednesday, June 03, 2009 2:59 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] PhoneBCP again >>=20 >> In today's Interim conf call Brian mentioned that all reasonable=20 >> suggestions were incorporated into PhoneBCP. I sent a while ago a=20 >> suggestion to the list to revise the abstract instead of=20 >including an=20 >> applicability statement. >>=20 >> From: >>=20 >> "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=20 >how devices, >> networks and services should use such standards to make=20 >emergency >> calls." >>=20 >> To: >>=20 >> "The IETF efforts are targeted at >> standardizing various aspects of placing emergency=20 >calls over the=20 >> Internet. This memo describes requirements for devices,=20 >networks and=20 >> services that should be supported in order to make emergency calls=20 >> over the Internet." >>=20 >> The suggestion was ignored (maybe it was not reasonable at=20 >that time),=20 >> but since today there were discussions around this aspect,=20 >I thought=20 >> it may worth resending it. >>=20 >> - Gabor >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >= From James.Winterbottom@andrew.com Wed Jun 3 22:44:02 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 7C6F23A6B01 for ; Wed, 3 Jun 2009 22:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Gju5PDvvwidW for ; Wed, 3 Jun 2009 22:44:01 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 590DC28C1D2 for ; Wed, 3 Jun 2009 22:43:48 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_04_01_05_19 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); Thu, 04 Jun 2009 01:05:19 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 00:43:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 00:43:48 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outcome of Phone BCP hum Thread-Index: Acnk128Te6eqgiZLSliatPb4pkWy2A== From: "Winterbottom, James" To: X-OriginalArrivalTime: 04 Jun 2009 05:43:50.0680 (UTC) FILETIME=[701CB180:01C9E4D7] Subject: [Ecrit] Outcome of Phone BCP hum 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, 04 Jun 2009 05:44:02 -0000 Hello,=0D=0A=0D=0ASeveral weeks ago now Marc called for a hum on the need a= nd wording of=0D=0Aapplicability in the phone BCP document.=0D=0A=0D=0AI be= lieve that after clarification of what the hum was actually for=0D=0Athere = was a general consensus that there was no need for such a=0D=0Astatement, t= hough no formal outcome was ever announced by the WG chairs.=0D=0A=0D=0AI a= m now extremely alarmed to find that there is list discussion on=0D=0Aalter= ing the current wording when:=0D=0A1) Some people believe the outcome of th= e hum was such that no=0D=0Aapplicability statement should be included.=0D=0A= 2) The chairs have not formally posted what the outcome was.=0D=0A=0D=0AI a= m formally requesting that no further posts on proposing new wording=0D=0Ab= e discussed until the chair come back with a formal outcome of the=0D=0Apre= vious hum.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A------------------------------= ------------------------------------------------------------------=0D=0AThi= s message is for the designated recipient only and may=0D=0Acontain privile= ged, proprietary, or otherwise private information. =20=0D=0AIf you have re= ceived it in error, please notify the sender=0D=0Aimmediately and delete th= e original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0A[mf2]=0D=0A From drage@alcatel-lucent.com Thu Jun 4 03:59: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 11E033A6E2F for ; Thu, 4 Jun 2009 03:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 V2QB4H+dVKJz for ; Thu, 4 Jun 2009 03:59:22 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 135D83A6E06 for ; Thu, 4 Jun 2009 03:59:21 -0700 (PDT) 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 n54AxKfw010515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Jun 2009 12:59:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 4 Jun 2009 12:59:20 +0200 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , ECRIT Date: Thu, 4 Jun 2009 12:59:19 +0200 Thread-Topic: Outcome of Phone BCP hum Thread-Index: Acnk128Te6eqgiZLSliatPb4pkWy2AAK5lpw Message-ID: References: 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 Subject: Re: [Ecrit] Outcome of Phone BCP hum 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, 04 Jun 2009 10:59:23 -0000 You are confusing the absence of consensus for one particular approach with= support for the status quo. They are not the same thing. So yes the chairs need to make clear the position, and I believe that was t= he resultant intent of the call yesterday, but that does not make the exist= ing document the consensus. Nor does it preclude any discussion on the document, unless the document it= self is being abandoned. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Winterbottom, James > Sent: Thursday, June 04, 2009 6:44 AM > To: ecrit@ietf.org > Subject: [Ecrit] Outcome of Phone BCP hum >=20 > Hello, >=20 > Several weeks ago now Marc called for a hum on the need and=20 > wording of applicability in the phone BCP document. >=20 > I believe that after clarification of what the hum was=20 > actually for there was a general consensus that there was no=20 > need for such a statement, though no formal outcome was ever=20 > announced by the WG chairs. >=20 > I am now extremely alarmed to find that there is list=20 > discussion on altering the current wording when: > 1) Some people believe the outcome of the hum was such that=20 > no applicability statement should be included. > 2) The chairs have not formally posted what the outcome was. >=20 > I am formally requesting that no further posts on proposing=20 > new wording be discussed until the chair come back with a=20 > formal outcome of the previous hum. >=20 > Cheers > James > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From James.Winterbottom@andrew.com Thu Jun 4 04:20:55 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 1F36D3A6DF9 for ; Thu, 4 Jun 2009 04:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=0.077, 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 GXnGoMPW44MP for ; Thu, 4 Jun 2009 04:20:54 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3F4EB3A6A0A for ; Thu, 4 Jun 2009 04:20:54 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_04_06_26_32 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, 04 Jun 2009 06:26:32 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 06:05:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 06:03:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outcome of Phone BCP hum Thread-Index: Acnk128Te6eqgiZLSliatPb4pkWy2AAK5lpwAABGh6c= References: From: "Winterbottom, James" To: "DRAGE, Keith (Keith)" , "ECRIT" X-OriginalArrivalTime: 04 Jun 2009 11:05:02.0927 (UTC) FILETIME=[4F4435F0:01C9E504] Subject: Re: [Ecrit] Outcome of Phone BCP hum 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, 04 Jun 2009 11:20:55 -0000 I made no assumptions, I based in on people's clear indication, not on waff= le that was included.=0D=0A=0D=0AA hum response should be clear and not be = clouded with waffle and justification.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: DRAGE, Keith (Keith) [mailto= :drage@alcatel-lucent.com]=0D=0ASent: Thu 6/4/2009 5:59 AM=0D=0ATo: Winterb= ottom, James; ECRIT=0D=0ASubject: RE: Outcome of Phone BCP hum=0D=0A=20=0D=0A= You are confusing the absence of consensus for one particular approach with= support for the status quo. They are not the same thing.=0D=0A=0D=0ASo yes= the chairs need to make clear the position, and I believe that was the res= ultant intent of the call yesterday, but that does not make the existing do= cument the consensus.=0D=0A=0D=0ANor does it preclude any discussion on the= document, unless the document itself is being abandoned.=0D=0A=0D=0Aregard= s=0D=0A=0D=0AKeith=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: ecr= it-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20=0D=0A> On Behalf Of = Winterbottom, James=0D=0A> Sent: Thursday, June 04, 2009 6:44 AM=0D=0A> To:= ecrit@ietf.org=0D=0A> Subject: [Ecrit] Outcome of Phone BCP hum=0D=0A>=20=0D= =0A> Hello,=0D=0A>=20=0D=0A> Several weeks ago now Marc called for a hum on= the need and=20=0D=0A> wording of applicability in the phone BCP document.=0D= =0A>=20=0D=0A> I believe that after clarification of what the hum was=20=0D= =0A> actually for there was a general consensus that there was no=20=0D=0A>= need for such a statement, though no formal outcome was ever=20=0D=0A> ann= ounced by the WG chairs.=0D=0A>=20=0D=0A> I am now extremely alarmed to fin= d that there is list=20=0D=0A> discussion on altering the current wording w= hen:=0D=0A> 1) Some people believe the outcome of the hum was such that=20=0D= =0A> no applicability statement should be included.=0D=0A> 2) The chairs ha= ve not formally posted what the outcome was.=0D=0A>=20=0D=0A> I am formally= requesting that no further posts on proposing=20=0D=0A> new wording be dis= cussed until the chair come back with a=20=0D=0A> formal outcome of the pre= vious hum.=0D=0A>=20=0D=0A> Cheers=0D=0A> James=0D=0A> --------------------= ------------------------------------------=0D=0A> -------------------------= ---------=0D=0A> This message is for the designated recipient only and may =0D= =0A> contain privileged, proprietary, or otherwise private information. =0D= =0A> If you have received it in error, please notify the sender=20=0D=0A> i= mmediately and delete the original. Any unauthorized use of=20=0D=0A> this= email is prohibited.=0D=0A> ----------------------------------------------= ----------------=0D=0A> ----------------------------------=0D=0A> [mf2]=0D=0A= >=20=0D=0A> _______________________________________________=0D=0A> Ecrit ma= iling list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/listin= fo/ecrit=0D=0A>=20=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 From mlinsner@cisco.com Thu Jun 4 05:22:26 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 BA3D23A6B3D for ; Thu, 4 Jun 2009 05:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cxDbbbSdBMpy for ; Thu, 4 Jun 2009 05:22:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 75BC03A6927 for ; Thu, 4 Jun 2009 05:22:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,305,1241395200"; d="scan'208";a="46237229" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Jun 2009 12:22:27 +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 n54CMR4h026351; Thu, 4 Jun 2009 08:22:27 -0400 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 n54CMRAV028136; Thu, 4 Jun 2009 12:22:27 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); Thu, 4 Jun 2009 08:22:27 -0400 Received: from [10.116.195.120] ([10.116.195.120]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 08:22:26 -0400 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 08:22:25 -0400 From: Marc Linsner To: "Winterbottom, James" , Message-ID: Thread-Topic: [Ecrit] Outcome of Phone BCP hum Thread-Index: Acnk128Te6eqgiZLSliatPb4pkWy2AAN68Xj In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 04 Jun 2009 12:22:26.0740 (UTC) FILETIME=[1F31D740:01C9E50F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2738; t=1244118147; x=1244982147; 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]=20Outcome=20of=20Phone=20BCP=20 hum |Sender:=20 |To:=20=22Winterbottom,=20James=22=20,=20; bh=lLzJtFsmkQJo0htuWlve/ZeDG+ofbbCIUhcGwbiASho=; b=rxiYIARGwiWuUmYK5Ea4AxQ8ALFjxyLX6ffUAWvcwYtSluHKPezXpIeTte 1XPrN1rjiPHx9AZhGmBGtY5KIRUJM5bdaK1rFFIwKxnC8S5gwDnzyCwrE8Fw ectyTCcjaG; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] Outcome of Phone BCP hum 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, 04 Jun 2009 12:22:26 -0000 As stated in the call yesterday. Taken from my email on April 24, 2009: "http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt At the San Francisco meeting and ensuing list threads, the last issue aroun= d PhoneBCP was whether or not to include an =8Capplicability statement=B9. The hum during the meeting was inconclusive. The draft editor has included tex= t in this latest version in an attempt to compromise on this issue. Please review this version and respond by Friday May 1 to the list as to your acceptance of this change." A clarification on April 27, 2009: "This is a consolidated hum. If you don't agree that we need an applicability statement, hum against it. If you agree that we need an applicability statement, but don't like the current text, hum against it. If you agree with the statement as written, hum for it. If consensus is against the statement, it will be taken out of the draft." The outcome was as follows: 10 against the change 4 for the change 2 no objection to the change The chairs are reviewing this with the ADs to decide the next steps. -Marc- On 6/4/09 1:43 AM, "Winterbottom, James" wrote: > Hello, >=20 > Several weeks ago now Marc called for a hum on the need and wording of > applicability in the phone BCP document. >=20 > I believe that after clarification of what the hum was actually for > there was a general consensus that there was no need for such a > statement, though no formal outcome was ever announced by the WG chairs. >=20 > I am now extremely alarmed to find that there is list discussion on > altering the current wording when: > 1) Some people believe the outcome of the hum was such that no > applicability statement should be included. > 2) The chairs have not formally posted what the outcome was. >=20 > I am formally requesting that no further posts on proposing new wording > be discussed until the chair come back with a formal outcome of the > previous hum. >=20 > Cheers > James > -------------------------------------------------------------------------= ----- > ------------------ > 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] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Thu Jun 4 06:30:42 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 6F02D3A6E31 for ; Thu, 4 Jun 2009 06:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.273 X-Spam-Level: X-Spam-Status: No, score=-5.273 tagged_above=-999 required=5 tests=[AWL=1.326, 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 5AoVEAD11dtE for ; Thu, 4 Jun 2009 06:30:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 97F363A6B4D for ; Thu, 4 Jun 2009 06:30:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n54DTsBX004372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Jun 2009 15:29:54 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n54DTr6L008019; Thu, 4 Jun 2009 15:29:53 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 15:29:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 16:31:45 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016B00AB@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO writeup for draft-patel-ecrit-sos-parameter Thread-Index: AcnkINRxn6IjaL22S12MnCOH0Y+bMQAReGlgACx9kDA= References: <3D3C75174CB95F42AD6BCC56E5555B45016847FA@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Cullen Jennings" X-OriginalArrivalTime: 04 Jun 2009 13:29:53.0124 (UTC) FILETIME=[8B070A40:01C9E518] Cc: ECRIT Subject: Re: [Ecrit] PROTO writeup for draft-patel-ecrit-sos-parameter 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, 04 Jun 2009 13:30:42 -0000 Hi Keith,=20 =20 Thanks for the update. Good to hear that it is being implemented.=20 Ciao Hannes >> The document originally came from the 3GPP and was presented to the=20 >> IETF because a Standards Track extension to SIP was needed. > >This is not quite accurate. > >The requirement came from 3GPP. The original requirements did=20 >get some detailed review in a 3GPP meeting. > >A number of participants in 3GPP have worked on the document=20 >and reviewed the contents. > >The document is used as a normative reference by 3GPP=20 >documents, and those 3GPP documents are in process of=20 >implementation by a number of vendors. > >However there has been no formal review of the contents within=20 >a 3GPP meeting or other formal 3GPP process, and the document=20 >itself has never been a 3GPP document. > >This does match the process that has been followed on a number=20 >of other 3GPP dependencies on IETF. > >regards > >Keith > >=20 > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Wednesday, June 03, 2009 8:57 AM >> To: Cullen Jennings; iesg-secretary@ietf.org >> Cc: ECRIT >> Subject: [Ecrit] PROTO writeup for draft-patel-ecrit-sos-parameter >>=20 >> PROTO Writeup for draft-patel-ecrit-sos-parameter=20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-06 >>=20 >>=20 >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the=20 >> document >> and, in particular, does he or she believe this=20 >version is ready >> for forwarding to the IESG for publication? >>=20 >> Hannes Tschofenig is the document shepherd.=20 >> The document is ready for publication. Cullen Jennings, who is the=20 >> responsible AD, indicated that an additional review from SIP experts=20 >> may be performed. >>=20 >> (1.b) Has the document had adequate review both from key members=20 >> of >> the interested community and others? Does the=20 >Document Shepherd >> have any concerns about the depth or breadth of the=20 >reviews that >> have been performed? >>=20 >> The document originally came from the 3GPP and was presented to the=20 >> IETF >>=20 >> because a Standards Track extension to SIP was needed. The document=20 >> was reviewed by ECRIT working group members and an expert reviewer,=20 >> namely Gonzallo Camarillo, was appointed. >> His review can be found here:=20 >> http://www.ietf.org/mail-archive/web/ecrit/current/msg06037.html >> His comments got addressed in subsequent draft versions.=20 >>=20 >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective,=20 >> e.g., >> security, operational complexity, someone familiar with AAA, >> internationalization or XML? >>=20 >> No. >>=20 >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director >> and/or the IESG should be aware of? For example, perhaps he or >> she is uncomfortable with certain parts of the document, or has >> concerns whether there really is a need for it. In any event,=20 >> if >> the interested community has discussed those issues and has >> indicated that it still wishes to advance the document, detail >> those concerns here. >>=20 >> There are no concerns with the document. >>=20 >> (1.e) How solid is the consensus of the interested community=20 >> behind >> this document? Does it represent the strong concurrence of a=20 >> few >> individuals, with others being silent, or does the interested >> community as a whole understand and agree with it? >>=20 >> This document is not a product of the ECRIT working group=20 >but required=20 >> by the 3GPP for their Release 7 emergency services architecture. >> There are architectural differences between the IETF and the 3GPP=20 >> emergency services architecture whereby the solution=20 >developed in this=20 >> document is currenly only needed by the 3GPP. >>=20 >> There is, however, consensus within the ECRIT WG to publish the=20 >> document. >>=20 >> (1.f) Has anyone threatened an appeal or otherwise indicated=20 >> extreme >> discontent? If so, please summarise the areas of conflict in >> separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >>=20 >> No. There were only questions regarding the overall interworking=20 >> between >>=20 >> IETF and 3GPP when it comes to work that is of interest for the 3GPP=20 >> only but has to be carried out in the IETF. This relates to the=20 >> ongoing discussion about the SIP Change Process. >>=20 >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See >> http://www.ietf.org/ID-Checklist.html and >> http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 >> not >> enough; this check needs to be thorough. Has the document met=20 >> all >> formal review criteria it needs to, such as the MIB Doctor,=20 >> media >> type and URI type reviews? >>=20 >> The ABNF parses with no errors. >> Nits have been checked. The errors regarding RFC 2119=20 >boilerplate seem=20 >> to be incorrect. >>=20 >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to documents that=20 >> are >> not ready for advancement or are otherwise in an unclear state? >> If such normative references exist, what is the strategy for=20 >> their >> completion? Are there normative references that are downward >> references, as described in [RFC3967]? If so, list these=20 >> downward >> references to support the Area Director in the Last Call=20 >> procedure >> for them [RFC3967]. >>=20 >> The references in the document have been split into normative and=20 >> informative. >> Normative references are all stable documents published as RFCs. >>=20 >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body of >> the document? If the document specifies protocol extensions,=20 >> are >> reservations requested in appropriate IANA registries? Are the >> IANA registries clearly identified? If the document creates a=20 >> new >> registry, does it define the proposed initial contents of the >> registry and an allocation procedure for future registrations? >> Does it suggested a reasonable name for the new registry? See >> [I-D.narten-iana-considerations-rfc2434bis]. If the document >> describes an Expert Review process has Shepherd conferred with=20 >> the >> Responsible Area Director so that the IESG can appoint the=20 >> needed >> Expert during the IESG Evaluation? >>=20 >> IANA considerations exist within the document and are=20 >consistent with=20 >> the body of the document. The new URI parameter has been=20 >specified as=20 >> defined by RFC 3261. >>=20 >> The document requests IANA to register the URI parameter. >>=20 >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML=20 >> code, >> BNF rules, MIB definitions, etc., validate correctly in an >> automated checker? >>=20 >> Not applicable. >>=20 >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Writeup? Recent examples can be found in the >> "Action" announcements for approved documents. The approval >> announcement contains the following sections: >>=20 >> Technical Summary >>=20 >> This document defines a new Session Initiation Protocol >> (SIP) Uniform >> Resource Identifier (URI) parameter intended for marking SIP >> registration requests related to emergency services. The usage of >> this new URI parameter complements the usage of the=20 >Service Uniform >> Resource Name (URN) and is not intended to replace it. >>=20 >> Working Group Summary >>=20 >> This document is not the product of a working group. The=20 >document was=20 >> considered to become an ECRIT working group item. However, based on=20 >> the current work schedule and the urgency of the document=20 >the decision=20 >> was made to progress it as an AD sponsored document (initially with=20 >> Jon Peterson as the AD sponsoring it). >>=20 >> Document Quality >>=20 >> The document has been reviewed by IETF ECRIT WG members and by the=20 >> 3GPP community. An expert review has been carried out by Gonzalo=20 >> Camarillo. >>=20 >> The implementation status of this document is unknown.=20 >>=20 >> Personnel >>=20 >> Hannes Tschofenig is the document shepherd for this document.=20 >> Cullen Jennings is the responsible AD.=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 > From mlinsner@cisco.com Thu Jun 4 08:29:04 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 CDB9E3A6CC1 for ; Thu, 4 Jun 2009 08:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 IX+6LBN+ivAa for ; Thu, 4 Jun 2009 08:29:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B60A33A6ED7 for ; Thu, 4 Jun 2009 08:29:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,306,1241395200"; d="scan'208";a="46259353" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Jun 2009 15:29:03 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n54FT3em028147 for ; Thu, 4 Jun 2009 11:29:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n54FT3Eg010097 for ; Thu, 4 Jun 2009 15:29:03 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); Thu, 4 Jun 2009 11:29:03 -0400 Received: from [10.116.195.120] ([10.116.195.120]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 11:29:02 -0400 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 11:29:01 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: Phone BCP Thread-Index: Acnk128Te6eqgiZLSliatPb4pkWy2AAN68XjAAaEVdk= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 04 Jun 2009 15:29:03.0129 (UTC) FILETIME=[30C33890:01C9E529] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1466; t=1244129343; x=1244993343; 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:=20Phone=20BCP |Sender:=20 |To:=20=22'ecrit'=22=20; bh=orWZzYrq9h0KbzmqALziOs7M7eXPA+u+Q3Ah1eFKLO0=; b=mQiVL8sDZ4fP/URgKR0/xnDyXGPDu/cmAZt0Ec71labXA2ciT50gLyuQlX kpU730Wd84vTYgEGBvIGIeHaLyTvKyETxb/nY/JheyROB8DjeytEnDrBWb8r Y1j2PtyKpM; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Ecrit] 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: , X-List-Received-Date: Thu, 04 Jun 2009 15:29:04 -0000 All, On April 24, 2009 we requested the following: "http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt At the San Francisco meeting and ensuing list threads, the last issue aroun= d PhoneBCP was whether or not to include an =8Capplicability statement=B9. The hum during the meeting was inconclusive. The draft editor has included tex= t in this latest version in an attempt to compromise on this issue. Please review this version and respond by Friday May 1 to the list as to your acceptance of this change." On on April 27, 2009 we answered a clarification question: "This is a consolidated hum. If you don't agree that we need an applicability statement, hum against it. If you agree that we need an applicability statement, but don't like the current text, hum against it. If you agree with the statement as written, hum for it. If consensus is against the statement, it will be taken out of the draft." The outcome was as follows: 10 against the change 4 for the change 2 no objection to the change We now declare that we do not have consensus to support the additional text that was added as the outcome of a discussion labeled 'applicability statement'. We are asking the document editors to produce draft -10 without the text, specifically paragraph 3 of section 2. We will then be asking everyone to further review the draft when that is completed. Thanks, Marc & Hannes From br@brianrosen.net Thu Jun 4 09:59: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 5CB3D3A6A41 for ; Thu, 4 Jun 2009 09:59:03 -0700 (PDT) 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 dzV1FT3VrZu7 for ; Thu, 4 Jun 2009 09:59:02 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id EE4223A6E96 for ; Thu, 4 Jun 2009 09:58:58 -0700 (PDT) Received: from [209.173.57.233] (helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MCGHD-0003gi-R4 for ecrit@ietf.org; Thu, 04 Jun 2009 11:58:52 -0500 From: "Brian Rosen" To: Date: Thu, 4 Jun 2009 12:58:57 -0400 Message-ID: <05b401c9e535$c1f9a2c0$45ece840$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnlNQ2KR2Xl6Zi9TY+ouxdLLLOflQAAJtpQ 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: [Ecrit] FW: New Version Notification for draft-ietf-ecrit-phonebcp-10 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, 04 Jun 2009 16:59:03 -0000 This is a mistake, and I will have to revise it, sorry -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, June 04, 2009 12:54 PM To: br@brianrosen.net Cc: jmpolk@cisco.com Subject: New Version Notification for draft-ietf-ecrit-phonebcp-10=20 A new version of I-D, draft-ietf-ecrit-phonebcp-10.txt has been = successfuly submitted by Brian Rosen and posted to the IETF repository. Filename: draft-ietf-ecrit-phonebcp Revision: 10 Title: Best Current Practice for Communications Services in support of = Emergency Calling Creation_date: 2009-06-04 WG ID: ecrit Number_of_pages: 45 Abstract: 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. = =20 The IETF Secretariat. From root@core3.amsl.com Thu Jun 4 10:00: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 8F82C3A70AC; Thu, 4 Jun 2009 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090604170001.8F82C3A70AC@core3.amsl.com> Date: Thu, 4 Jun 2009 10:00:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-10.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, 04 Jun 2009 17:00: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-10.txt Pages : 45 Date : 2009-06-04 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-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-04095347.I-D@ietf.org> --NextPart-- From br@brianrosen.net Thu Jun 4 10:07:33 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 BBA713A6F15 for ; Thu, 4 Jun 2009 10:07:33 -0700 (PDT) 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 dU1g5kww6t2y for ; Thu, 4 Jun 2009 10:07:33 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 07DB33A6B4F for ; Thu, 4 Jun 2009 10:07:33 -0700 (PDT) Received: from [209.173.57.233] (helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MCGPW-0005An-4J for ecrit@ietf.org; Thu, 04 Jun 2009 12:07:26 -0500 From: "Brian Rosen" To: Date: Thu, 4 Jun 2009 13:07:31 -0400 Message-ID: <05cd01c9e536$f4994590$ddcbd0b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnlNp/fgOyEDUAaQPikhJErmrpD2QAABX+w 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: [Ecrit] FW: New Version Notification for draft-ietf-ecrit-phonebcp-11 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, 04 Jun 2009 17:07:33 -0000 Okay, so -10 has an update to a reference that was a draft and is now an = RFC, and a fix to the "inserted-by" parameter text noticed by John = Elway. -11 is the same as 10 with the "applicability" text removed. Brian -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, June 04, 2009 1:05 PM To: br@brianrosen.net Cc: jmpolk@cisco.com Subject: New Version Notification for draft-ietf-ecrit-phonebcp-11=20 A new version of I-D, draft-ietf-ecrit-phonebcp-11.txt has been = successfuly submitted by Brian Rosen and posted to the IETF repository. Filename: draft-ietf-ecrit-phonebcp Revision: 11 Title: Best Current Practice for Communications Services in support of = Emergency Calling Creation_date: 2009-06-04 WG ID: ecrit Number_of_pages: 45 Abstract: 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. = =20 The IETF Secretariat. From root@core3.amsl.com Thu Jun 4 10:15:02 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 1867D3A6DB3; Thu, 4 Jun 2009 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090604171502.1867D3A6DB3@core3.amsl.com> Date: Thu, 4 Jun 2009 10:15:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-11.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, 04 Jun 2009 17:15: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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-11.txt Pages : 45 Date : 2009-06-04 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-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-04100517.I-D@ietf.org> --NextPart-- From James.Winterbottom@andrew.com Thu Jun 4 13:45:52 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 C40E93A6E11 for ; Thu, 4 Jun 2009 13:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.135 X-Spam-Level: X-Spam-Status: No, score=-1.135 tagged_above=-999 required=5 tests=[AWL=0.068, 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 hOOzd5Yq1nBk for ; Thu, 4 Jun 2009 13:45:52 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6F3BC3A6CBD for ; Thu, 4 Jun 2009 13:45:48 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_04_16_07_20 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, 04 Jun 2009 16:07:20 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 15:45:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 15:45:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Outcome of Phone BCP hum Thread-Index: Acnk128Te6eqgiZLSliatPb4pkWy2AAN68XjABGTws0= References: From: "Winterbottom, James" To: "Marc Linsner" , X-OriginalArrivalTime: 04 Jun 2009 20:45:50.0444 (UTC) FILETIME=[720152C0:01C9E555] Subject: Re: [Ecrit] Outcome of Phone BCP hum 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, 04 Jun 2009 20:45:52 -0000 =0D=0AThanks Marc=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Marc Lin= sner [mailto:mlinsner@cisco.com]=0D=0ASent: Thu 6/4/2009 7:22 AM=0D=0ATo: W= interbottom, James; ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] Outcome of Pho= ne BCP hum=0D=0A=20=0D=0AAs stated in the call yesterday.=0D=0A=0D=0ATaken = from my email on April 24, 2009:=0D=0A=0D=0A"http://www.ietf.org/internet-d= rafts/draft-ietf-ecrit-phonebcp-09.txt=0D=0A=0D=0AAt the San Francisco meet= ing and ensuing list threads, the last issue around=0D=0APhoneBCP was wheth= er or not to include an Oapplicability statement=B9. The=0D=0Ahum during t= he meeting was inconclusive. The draft editor has included text=0D=0Ain th= is latest version in an attempt to compromise on this issue.=0D=0A=0D=0APle= ase review this version and respond by Friday May 1 to the list as to=0D=0A= your acceptance of this change."=0D=0A=0D=0AA clarification on April 27, 20= 09:=0D=0A=0D=0A"This is a consolidated hum.=0D=0A=0D=0AIf you don't agree t= hat we need an applicability statement, hum against it.=0D=0A=0D=0AIf you a= gree that we need an applicability statement, but don't like the=0D=0Acurre= nt text, hum against it.=0D=0A=0D=0AIf you agree with the statement as writ= ten, hum for it.=0D=0A=0D=0AIf consensus is against the statement, it will = be taken out of the draft."=0D=0A=0D=0A=0D=0AThe outcome was as follows:=0D= =0A=0D=0A10 against the change=0D=0A4 for the change=0D=0A2 no objection to= the change=0D=0A=0D=0AThe chairs are reviewing this with the ADs to decide= the next steps.=0D=0A=0D=0A-Marc-=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AOn 6/= 4/09 1:43 AM, "Winterbottom, James" =0D=0Awr= ote:=0D=0A=0D=0A> Hello,=0D=0A>=20=0D=0A> Several weeks ago now Marc called= for a hum on the need and wording of=0D=0A> applicability in the phone BCP= document.=0D=0A>=20=0D=0A> I believe that after clarification of what the = hum was actually for=0D=0A> there was a general consensus that there was no= need for such a=0D=0A> statement, though no formal outcome was ever announ= ced by the WG chairs.=0D=0A>=20=0D=0A> I am now extremely alarmed to find t= hat there is list discussion on=0D=0A> altering the current wording when:=0D= =0A> 1) Some people believe the outcome of the hum was such that no=0D=0A> = applicability statement should be included.=0D=0A> 2) The chairs have not f= ormally posted what the outcome was.=0D=0A>=20=0D=0A> I am formally request= ing that no further posts on proposing new wording=0D=0A> be discussed unti= l the chair come back with a formal outcome of the=0D=0A> previous hum.=0D=0A= >=20=0D=0A> Cheers=0D=0A> James=0D=0A> ------------------------------------= ------------------------------------------=0D=0A> ------------------=0D=0A>= This message is for the designated recipient only and may=0D=0A> contain p= rivileged, proprietary, or otherwise private information.=0D=0A> If you hav= e received it in error, please notify the sender=0D=0A> immediately and del= ete the original. Any unauthorized use of=0D=0A> this email is prohibited.=0D= =0A> ----------------------------------------------------------------------= --------=0D=0A> ------------------=0D=0A> [mf2]=0D=0A>=20=0D=0A> __________= _____________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecri= t@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A------------------------------------------------------------= ------------------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0A[mf2]=0D= =0A From khwolf1@gmail.com Fri Jun 5 02:15:10 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 180663A6BF7 for ; Fri, 5 Jun 2009 02:15:10 -0700 (PDT) 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 lci8UZ5S7Rnu for ; Fri, 5 Jun 2009 02:15:09 -0700 (PDT) Received: from mail-qy0-f184.google.com (mail-qy0-f184.google.com [209.85.221.184]) by core3.amsl.com (Postfix) with ESMTP id 137C43A6BFB for ; Fri, 5 Jun 2009 02:15:08 -0700 (PDT) Received: by qyk14 with SMTP id 14so505829qyk.29 for ; Fri, 05 Jun 2009 02:15:05 -0700 (PDT) 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=slFpfxnFNv6RKjWcdnSGSt7Oc1wKxQzC5d2AshswUNM=; b=Uu+ewRPnuUVtfZcZfHIL57Gum/tTMutvxeP0+3NiN1UmFv3gaJ3LfsGpsHGd0Tbp3a xviLVT/l1+m9YjxosbpreK3p543XH86tG1K+RgxECcoyMo2UQxFytTwGGVJ5ZYoH0kn+ YfSRnauqLJp5YtWxmX5nBMF1ursNxze12/l9E= 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=DewLd0ekL/hXvWhKJTxuB7mYu1f0dpSj94xbiU9MCvfWVlfIx3iNYU8z9aEe+sTfny sTI8EE8KRVdv9LgFejDA5G+TozwYkGmHUqXik0/ewGn1UKE6r/9plOWDx9ROBibtEfGB WBwdCajfwpBG6Z96Z7Ta2EJlp2sti/zueZJlI= MIME-Version: 1.0 Received: by 10.220.74.65 with SMTP id t1mr2221969vcj.89.1244193305510; Fri, 05 Jun 2009 02:15:05 -0700 (PDT) In-Reply-To: <05cd01c9e536$f4994590$ddcbd0b0$@net> References: <05cd01c9e536$f4994590$ddcbd0b0$@net> Date: Fri, 5 Jun 2009 11:15:05 +0200 Message-ID: From: Karl Heinz Wolf To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: New Version Notification for draft-ietf-ecrit-phonebcp-11 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, 05 Jun 2009 09:15:10 -0000 Brian, because of all the discussion on the applicability statement it seems that you forgot to put back ED-6. karl heinz On Thu, Jun 4, 2009 at 7:07 PM, Brian Rosen wrote: > Okay, so -10 has an update to a reference that was a draft and is now an = RFC, and a fix to the "inserted-by" parameter text noticed by John Elway. = =A0-11 is the same as 10 with the "applicability" text removed. > > Brian > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Thursday, June 04, 2009 1:05 PM > To: br@brianrosen.net > Cc: jmpolk@cisco.com > Subject: New Version Notification for draft-ietf-ecrit-phonebcp-11 > > > A new version of I-D, draft-ietf-ecrit-phonebcp-11.txt has been successfu= ly submitted by Brian Rosen and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-ietf-ecrit-phonebcp > Revision: =A0 =A0 =A0 =A011 > Title: =A0 =A0 =A0 =A0 =A0 Best Current Practice for Communications Servi= ces in support of Emergency Calling > Creation_date: =A0 2009-06-04 > WG ID: =A0 =A0 =A0 =A0 =A0 ecrit > Number_of_pages: 45 > > Abstract: > The IETF and other standards organization have efforts targeted at > standardizing various aspects of placing emergency calls on IP > networks. =A0This memo describes best current practice on how devices, > networks and services should use such standards to make emergency > calls. > > > > The IETF Secretariat. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From bernard_aboba@hotmail.com Thu Jun 11 06:43:32 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 D85183A693C for ; Thu, 11 Jun 2009 06:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-0.911, 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 02A5+Qurbqja for ; Thu, 11 Jun 2009 06:43:32 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by core3.amsl.com (Postfix) with ESMTP id 081C73A6919 for ; Thu, 11 Jun 2009 06:43:31 -0700 (PDT) Received: from BLU137-W18 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 06:43:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3d90bbd2-ee8c-4719-86f0-a1a67f7df7fb_" X-Originating-IP: [24.16.113.61] From: Bernard Aboba To: Date: Thu, 11 Jun 2009 06:43:39 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2009 13:43:39.0604 (UTC) FILETIME=[A08A2140:01C9EA9A] Subject: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Services (IEEE 802.21.1) 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, 11 Jun 2009 13:43:33 -0000 --_3d90bbd2-ee8c-4719-86f0-a1a67f7df7fb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The list of PARs under consideration at the July plenary has been posted: http://www.ieee802.org/PARs.shtml This includes a new standard for support of emergency services: http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-services-p= ar-and-5c.doc --_3d90bbd2-ee8c-4719-86f0-a1a67f7df7fb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The list of PARs under consideration at the July plenary has been posted:http://www.ieee802.org/PARs.shtml

This includes a new standard for= support of emergency services:
http://www.ieee802.org/PARs/2009-07/21-0= 9-0027-06-00es-emergency-services-par-and-5c.doc


In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Services (IEEE 802.21.1) Thread-Index: AcnqmqP0EfIwlzJXQ6WRu/ui740MbgABUfPQ References: From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Cc: iab@iab.org, The IESG Subject: Re: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Services (IEEE 802.21.1) 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, 11 Jun 2009 14:23:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EAA0.27F3890B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 Did they decide to go ahead with this? Your May report indicated I think that the PAR was taken off the agenda for the time being - it's back now? or am I confused and confusing?=20 =20 Dan =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, June 11, 2009 4:44 PM To: ecrit@ietf.org Subject: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Services (IEEE 802.21.1) =09 =09 The list of PARs under consideration at the July plenary has been posted: http://www.ieee802.org/PARs.shtml =09 This includes a new standard for support of emergency services: =09 http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-service s-par-and-5c.doc =09 =09 =09 =20 =09 ------_=_NextPart_001_01C9EAA0.27F3890B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
Did they=20 decide to go ahead with this? Your May report indicated I think that the = PAR was=20 taken off the agenda for the time being - it's back now? or am I = confused and=20 confusing?
 
Dan
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Thursday, June 11, 2009 4:44 PM
To:=20 ecrit@ietf.org
Subject: [Ecrit] IEEE 802 considers New = Standard for=20 Support of Emergency Services (IEEE 802.21.1)

The list of PARs under consideration at the July plenary = has been=20 posted:
http://www.ieee802.org/PARs.shtml

This includes a = new=20 standard for support of emergency=20 = services:
http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emerg= ency-services-par-and-5c.doc



<= /HTML> ------_=_NextPart_001_01C9EAA0.27F3890B-- From bernard_aboba@hotmail.com Thu Jun 11 07:30:59 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 256B73A68BD; Thu, 11 Jun 2009 07:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 8ZhR8CGA7ddS; Thu, 11 Jun 2009 07:30:57 -0700 (PDT) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by core3.amsl.com (Postfix) with ESMTP id A4D073A6AF1; Thu, 11 Jun 2009 07:30:57 -0700 (PDT) Received: from BLU137-W17 ([65.55.116.72]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 07:31:05 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_412bf398-40f9-47f8-bd44-f60ea9336f0b_" X-Originating-IP: [24.16.113.61] From: Bernard Aboba To: "dromasca@avaya.com" , Date: Thu, 11 Jun 2009 07:31:05 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2009 14:31:05.0273 (UTC) FILETIME=[40B0C290:01C9EAA1] Cc: iab@iab.org, "iesg@ietf.org" Subject: Re: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Services (IEEE 802.21.1) 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, 11 Jun 2009 14:30:59 -0000 --_412bf398-40f9-47f8-bd44-f60ea9336f0b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The PAR submission has been updated and it is back on the agenda for consid= eration at the San Francisco plenary. Presumably it will go through a simi= lar process to the March meeting in Vancouver (e.g. review=2C discussion by= the IEEE 802 EC=2C etc.).=20 Subject: RE: [Ecrit] IEEE 802 considers New Standard for Support of Emergen= cy Services (IEEE 802.21.1) Date: Thu=2C 11 Jun 2009 16:23:12 +0200 From: dromasca@avaya.com To: bernard_aboba@hotmail.com=3B ecrit@ietf.org CC: iesg@ietf.org=3B iab@iab.org Bernard=2C =20 Did they=20 decide to go ahead with this? Your May report indicated I think that the PA= R was=20 taken off the agenda for the time being - it's back now? or am I confused a= nd=20 confusing?=20 =20 Dan =20 =20 =20 From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Bernard=20 Aboba Sent: Thursday=2C June 11=2C 2009 4:44 PM To:=20 ecrit@ietf.org Subject: [Ecrit] IEEE 802 considers New Standard for=20 Support of Emergency Services (IEEE 802.21.1) The list of PARs under consideration at the July plenary has been=20 posted: http://www.ieee802.org/PARs.shtml This includes a new=20 standard for support of emergency=20 services: http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-services-p= ar-and-5c.doc =20 =20 =20 =20 --_412bf398-40f9-47f8-bd44-f60ea9336f0b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The PAR submission has been updated and it is back on the agenda for consid= eration at the San Francisco plenary. =3B Presumably it will go through= a similar process to the March meeting in Vancouver (e.g. review=2C discus= sion by the IEEE 802 EC=2C etc.).

Subject: = RE: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Servic= es (IEEE 802.21.1)
Date: Thu=2C 11 Jun 2009 16:23:12 +0200
From: drom= asca@avaya.com
To: bernard_aboba@hotmail.com=3B ecrit@ietf.org
CC: ie= sg@ietf.org=3B iab@iab.org

Bernard=2C
 =3B
Did they=20 decide to go ahead with this? Your May report indicated I think that the PA= R was=20 taken off the agenda for the time being - it's back now? or am I confused a= nd=20 confusing?
 =3B
Dan
 =3B

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Thursday=2C June 11=2C 2009 4:44 PM
To:=20 ecrit@ietf.org
Subject: [Ecrit] IEEE 802 considers New Standard= for=20 Support of Emergency Services (IEEE 802.21.1)

The list of PARs under consideration at the July plenary has b= een=20 posted:
http://www.ieee802.org/PARs.shtml

This includes a new=20 standard for support of emergency=20 services:
http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emerg= ency-services-par-and-5c.doc



= --_412bf398-40f9-47f8-bd44-f60ea9336f0b_-- From dromasca@avaya.com Thu Jun 11 10:52:11 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 9CC3428C1D6; Thu, 11 Jun 2009 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, 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 6dAEQYzxmaUd; Thu, 11 Jun 2009 10:52:10 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 10D2228C158; Thu, 11 Jun 2009 10:52:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,203,1243828800"; d="scan'208,217";a="173669547" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Jun 2009 13:52:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 11 Jun 2009 13:52:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EABD.5B459AC0" Date: Thu, 11 Jun 2009 19:52:15 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IEEE 802 considers New Standard for Support ofEmergency Services (IEEE 802.21.1) Thread-Index: AcnqoUWPBcPQ0jlzQHWB4YtPVi7QdwAHAZlQ References: From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Cc: iab@iab.org, iesg@ietf.org Subject: Re: [Ecrit] IEEE 802 considers New Standard for Support ofEmergency Services (IEEE 802.21.1) 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, 11 Jun 2009 17:52:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EABD.5B459AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you - so I believe it's time for review and comments.=20 =20 Dan =20 ________________________________ From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, June 11, 2009 5:31 PM To: Romascanu, Dan (Dan); ecrit@ietf.org Cc: iab@iab.org; iesg@ietf.org Subject: RE: [Ecrit] IEEE 802 considers New Standard for Support ofEmergency Services (IEEE 802.21.1) =09 =09 The PAR submission has been updated and it is back on the agenda for consideration at the San Francisco plenary. Presumably it will go through a similar process to the March meeting in Vancouver (e.g. review, discussion by the IEEE 802 EC, etc.).=20 =09 =09 ________________________________ Subject: RE: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Services (IEEE 802.21.1) Date: Thu, 11 Jun 2009 16:23:12 +0200 From: dromasca@avaya.com To: bernard_aboba@hotmail.com; ecrit@ietf.org CC: iesg@ietf.org; iab@iab.org =09 =09 Bernard, =20 Did they decide to go ahead with this? Your May report indicated I think that the PAR was taken off the agenda for the time being - it's back now? or am I confused and confusing?=20 =20 Dan =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, June 11, 2009 4:44 PM To: ecrit@ietf.org Subject: [Ecrit] IEEE 802 considers New Standard for Support of Emergency Services (IEEE 802.21.1) =09 =09 The list of PARs under consideration at the July plenary has been posted: http://www.ieee802.org/PARs.shtml =09 This includes a new standard for support of emergency services: =09 http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-service s-par-and-5c.doc =09 =09 =09 =20 =09 ------_=_NextPart_001_01C9EABD.5B459AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you -=20 so I believe it's time for review and comments.
 
Dan
 

From: iesg-bounces@ietf.org=20 [mailto:iesg-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Thursday, June 11, 2009 5:31 PM
To: = Romascanu,=20 Dan (Dan); ecrit@ietf.org
Cc: iab@iab.org;=20 iesg@ietf.org
Subject: RE: [Ecrit] IEEE 802 considers New = Standard=20 for Support ofEmergency Services (IEEE 802.21.1)

The PAR submission has been updated and it is back on the = agenda=20 for consideration at the San Francisco plenary.  Presumably it = will go=20 through a similar process to the March meeting in Vancouver (e.g. = review,=20 discussion by the IEEE 802 EC, etc.).

Subject: RE: [Ecrit] IEEE 802 considers New Standard for Support of = Emergency=20 Services (IEEE 802.21.1)
Date: Thu, 11 Jun 2009 16:23:12 = +0200
From:=20 dromasca@avaya.com
To: bernard_aboba@hotmail.com; = ecrit@ietf.org
CC:=20 iesg@ietf.org; iab@iab.org

Bernard,
 
Did they=20 decide to go ahead with this? Your May report indicated I think that = the PAR=20 was taken off the agenda for the time being - it's back now? or am I = confused=20 and confusing?
 
Dan
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Thursday, June 11, 2009 4:44 PM
To:=20 ecrit@ietf.org
Subject: [Ecrit] IEEE 802 considers New = Standard=20 for Support of Emergency Services (IEEE = 802.21.1)

The list of PARs under consideration at the July plenary = has been=20 posted:
http://www.ieee802.org/PARs.shtml

This includes a = new=20 standard for support of emergency=20 = services:
http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emerg= ency-services-par-and-5c.doc



------_=_NextPart_001_01C9EABD.5B459AC0-- From rbarnes@bbn.com Fri Jun 12 08:03:34 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 871C23A68E5 for ; Fri, 12 Jun 2009 08:03:34 -0700 (PDT) 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 NlRD49xg6b6h for ; Fri, 12 Jun 2009 08:03:33 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9EA4C3A6877 for ; Fri, 12 Jun 2009 08:03:33 -0700 (PDT) Received: from ros-dhcp192-1-51-111.bbn.com ([192.1.51.111]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MF7M4-0002Cv-FV for ecrit@ietf.org; Fri, 12 Jun 2009 10:03:40 -0400 Message-ID: <4A326E4C.2030500@bbn.com> Date: Fri, 12 Jun 2009 11:03:40 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Apple Researching Methods for Facilitating Emergency Phone Calls 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, 12 Jun 2009 15:03:34 -0000 Looks like Apple are looking into some of the issues raised on this list, e.g., premature disconnect. From g.caron@bell.ca Fri Jun 12 08:20:01 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 7DD603A6A18 for ; Fri, 12 Jun 2009 08:20:01 -0700 (PDT) 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 cdHEBZvvnnSN for ; Fri, 12 Jun 2009 08:20:00 -0700 (PDT) Received: from mail125.messagelabs.com (mail125.messagelabs.com [85.158.136.35]) by core3.amsl.com (Postfix) with ESMTP id 527713A6A8A for ; Fri, 12 Jun 2009 08:19:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-10.tower-125.messagelabs.com!1244819537!37863655!314 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 28297 invoked from network); 12 Jun 2009 15:19:46 -0000 Received: from dm1c8g.bell.ca (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-10.tower-125.messagelabs.com with RC4-SHA encrypted SMTP; 12 Jun 2009 15:19:46 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.1.358.0; Fri, 12 Jun 2009 11:19:36 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub01-wyn.bell.corp.bce.ca ([142.182.199.48]) with mapi; Fri, 12 Jun 2009 11:19:17 -0400 From: To: , Date: Fri, 12 Jun 2009 11:19:16 -0400 Thread-Topic: [Ecrit] Apple Researching Methods for Facilitating Emergency Phone Calls Thread-Index: Acnrbw3PdEEu+4u5T9itWpMLMjHifgAAIsIw Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2744AE6A7E@MBX02.bell.corp.bce.ca> References: <4A326E4C.2030500@bbn.com> In-Reply-To: <4A326E4C.2030500@bbn.com> Accept-Language: en-US Content-Language: fr-FR 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] Apple Researching Methods for Facilitating Emergency Phone Calls 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, 12 Jun 2009 15:20:01 -0000 Thanks for digging this out Richard. Very informative. Maybe control of premature disconnect is not so silly after all. The iPhone example clearly depicts the power of a GUI solution and seems to= indicate its technical viability in a wireless environment. Hopefully the patent will not impede the ability for this group to continue= exploring this topic further (maybe a non-GUI approach seems more palatabl= e now :-). Guy -----Message d'origine----- De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de R= ichard Barnes Envoy=E9 : 12 juin 2009 11:04 =C0 : ECRIT Objet : [Ecrit] Apple Researching Methods for Facilitating Emergency Phone = Calls Looks like Apple are looking into some of the issues raised on this list, e.g., premature disconnect. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Fri Jun 12 10:13:22 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 C719B3A6A4B for ; Fri, 12 Jun 2009 10:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 knqlX1gMtg9Z for ; Fri, 12 Jun 2009 10:13:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D72343A68FD for ; Fri, 12 Jun 2009 10:13:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,210,1243814400"; d="scan'208";a="169637754" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2009 17:13:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5CHDULG026046; Fri, 12 Jun 2009 10:13:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5CHDUSm017118; Fri, 12 Jun 2009 17:13:30 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.3959); Fri, 12 Jun 2009 10:13:30 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 10:13:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jun 2009 12:13:28 -0500 To: Richard Barnes , ECRIT From: "James M. Polk" In-Reply-To: <4A326E4C.2030500@bbn.com> References: <4A326E4C.2030500@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jun 2009 17:13:29.0888 (UTC) FILETIME=[1B58C200:01C9EB81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=792; t=1244826810; x=1245690810; 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]=20Apple=20Researching=20Methods =20for=20Facilitating=0A=20=20Emergency=20Phone=20Calls |Sender:=20; bh=yKu7+s9v1WqRgGeKEc/S9zoQEAxCYaTm3JJHiaygaGQ=; b=Ddrm/KZScSdsselrJL0ukqLyOo0bUrrD8Oim773ospxO49TAJQNvY4epAk 21ZEZ9Mg75to50GVRM/OoKgVXM6fFbu1An23AT6FIqQCSl2K7G0Dy5Uh8Vlp umhrctX/Js; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] Apple Researching Methods for Facilitating Emergency Phone Calls 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, 12 Jun 2009 17:13:22 -0000 filed only in December of 2007, learning that several pieces mentioned in this description have been discussed way before December 2007 on this open list - it will be interesting whether many parts *can* survive a challenge. that said, there are a few nuggets mentioned that I have not seen or heard before that make this interesting... Thanks for finding this Richard! James At 10:03 AM 6/12/2009, Richard Barnes wrote: >Looks like Apple are looking into some of the issues raised on this >list, e.g., premature disconnect. > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Tue Jun 16 16:00:57 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 B58B828C0DF for ; Tue, 16 Jun 2009 16:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOW=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 SGW4n2Pa4E6F for ; Tue, 16 Jun 2009 16:00:43 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 693513A6C79 for ; Tue, 16 Jun 2009 16:00:43 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 16 Jun 2009 16:00:53 -0700 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_01C9EED6.4C497040" Date: Tue, 16 Jun 2009 16:00:52 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750D1AA901@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Interim Meeting Notes - ECRIT Conf Call June 3, 2009 thread-index: AcneyAenFSDi63X7oUepiu7Q9Yu+6QQCWeCA References: From: "Roger Marshall" To: "ECRIT" Subject: [Ecrit] ECRIT Interim Meeting Notes - ECRIT Conf Call June 3, 2009 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, 16 Jun 2009 23:00:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EED6.4C497040 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9EED6.4C497040" ------_=_NextPart_002_01C9EED6.4C497040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find the raw minutes from our last ECRIT Interim meeting, June 03, 2009, inline. =20 =20 Do send any corrections my way, in case of errors, etc. =20 I've also attached as a MS Word file, in case of formatting difficulties - which may or may not make it through the list server. =20 -roger marshall. ECRIT Secretary rmarshall@telecomsys.com =20 *** =20 ECRIT Interim Meeting Date: Jun 03, 2009 Minutes by: R. Marshall Chairs: Marc Linsner & Hannes Tschofenig Wiki page at: http://trac.tools.ietf.org/wg/ecrit/trac/wiki Local start time: 10:06 AM Pacific Agenda: =20 Attendees: James Polk Keith Drage Hannes Tschofenig Greg Burdett Gabor Bajko John Elwell Karl Heinz Randall Gellens Richard Barnes Robert Sparks Roger Marshall Spencer Dawkins Marc Linsner Brian Rosen Cullen Jennings Milan Patel Dan Romascanu =20 Webex Session: Notes of Meeting Discussion: SLIDE 1-4... SLIDE 5 - review the status of drafts... Sos-parameter Lost-sync WGLC is complete, waiting for a couple of implementers feedback since it is an exp Location Hiding Specifying Holes in LoST service boundaries (correction: Cullen to talk to Martin Thomson) (more details are in the link listed in the slide 5) James: Why isn't there a milestone for RPH here? Hannes: Discussion with AD's - in short, we need to have a wg rechartering. James: yes, for -00, but I'm on -05 Cullen: not unique circumstance, some drafts are not going to go forward until rechartering happens. James: Other drafts (after) have been brought in. Cullen: I'm a little lost myself on RPH - I didn't realize that we needed to recharter for RPH. James: I don't think we need to update the charter. Cullen: IESG will have to approve the recharter. Keith: Which situation are we now in - I believe the wg asked for a milestone addition at Dublin Hannes: RPH is listed as from October, other drafts from June - it was up to Jon and Cullen as to whether these fit within the existing charter, they were considered within the charter. ...Skip to info in mail message sent out with milestone update (see SLIDE 9) James: Other drafts seem to be sneeking in. Cullen: What do you mean. We have the charter, then there is the goals & milestones, then there is the Internet drafts. Keith: One of the AD's (presumably) will give us the determination of whether this draft is within scope, or not. Cullen: Some hesitancy here (on the phone) in light of new AD's coming in... If Jon said it was within scope, then I'll go with it, but I want to go back and look at what was decided. Hannes: Recounting some history, when asked, Jon may have agreed to allow additional drafts to be submitted, possibly because the phonebcp & framework draft completion was right around the corner. Hannes: Secondly, there was a milestones listing mistake, which is why I asked to have the milestones updated. Brian: I think that we're only waiting on one critical issue - the applicability statement - the other issues, I don't think are critical enough to hold up the document. =20 Next Discussion Item - PhoneBCP and the text added based on SF ECRIT discussion: Hannes: SLIDE 6, Marc asked for consensus, but has noted that there is no clear consensus. James: Just one or two people who don't want to take it out. Brian: More than just one or two. Brian: It's a chair call, as to whether there is rough consensus. Hannes: The question in the consensus call that Marc issued was not whether people agreed with the applicability statement, but rather is the present wording acceptable. Randy: I'm saying, ask a different question - we have a draft out there, can that version go forward? Keith: The version with the statement is fine with me, could be clarified, but has a caveat. Hannes: Maybe we should resubmit the document without the statement,=20 Brian: As you have to do is revert. Randy: We should ask whether the current version of the draft can go forward. Hannes: what is the previous version Randy: If we go back, we know from SF that there are problems with the previous version Hannes: You believe there are problems... [skip] Marc: Current version is -09, we could ask the simple question, should we ask do we go forward with -09 or -08? Randy: But, -08 is the same as in SF, and we will get back into the controversy again as in SF. Hannes: We can't avoid the controversy,=20 Randy: Let's not call it an applicability statement, it's just a note of text. Marc: We've got ____ people who didn't like the changes from -08 to -09. Randy: My point was that the question as worded, ... Marc: My proposal of 3 minutes ago...=20 Brian: I think I mis-spoke, since there are other changes as well. You'd have to have a more detailed question to differentiate the two. Hannes: The compromise text was premature, done by a small group. Brian: It was done on the list - not done by a small group of people. Cullen: Consensus is something taken at a point in time, and over time, may change - a good thing - since that's how agreements are reached... it sounds like the chairs are saying, it sounds like we didn't have consensus at that time. Randy: We had a lot of debate on the mailing list, yes during the ietf meeting, but also in the week following. Randy: I think there was consensus that people weren't content with -08 Hannes: Marc: (reading the consensus question from email) Marc: that vote, if by plurality was 10 for, ________ against, etc. Hannes: If there is something in the document that prevent ES from working in certain environments, then we should discuss it, though it comes a little late... Keith: It's not late, these 3GPP documents have been available for a few years. Hannes: 3GPP doesn't put these kinds of statements (e.g., about IETF shortcomings) in their documents Randy: I think we've got some emotional baggage tied in with this. Richard: It doesn't say, "X is a situation, in which things won't work" Hannes: (reading the applicability statement)=20 Randy: All it does it to alert the reader James: This is applies to IP networks Keith: Who says that 3GPP is not an IP network Randy: It's not an applicability statement, doesn't limit a solution in any way. Most documents in the IETF are self-limiting. This document sets itself up as being "the single way" that all emergency calls happen. Hannes: The primary focus of this document is around access providers providing location, and doesn't take into consideration other models, such as the communication service providers to provide, etc. Richard: This document allows for other stuff, but just doesn't map it out... Hannes: There's a big difference, it doesn't talk about emergency registration, etc. Keith: You wouldn't get a 3GPP LoST server, for example... Keith: A Service Provider implementing the 3GPP standard, wouldn't implement a LoST server, because it doesn't mention one. Marc: (voice breaking up) Richard: What do change in the document to eliminate the notion that other models can exist? Keith: To a certain extent, some have suggested that tried that,=20 Richard: If I recall, Stephen (Edge's) comments were fairly general, not specifically pointed changed suggested. Do you think this kind of thing can be done? Keith: I'd have to go back through it. Randy: I'd have to do another detailed read of the document. Spencer: I think the thread indicated that... 3GPP=20 Keith: Sometimes CT1 vs. SA2 need pointed questions asked. Hannes: We've had many conversations with 3GPP, it depends on which questions are asked... which group. Brian: 3GPP... Hannes: I think it's even worse than that, in that some of the communication models are very different. E.g., the split of services vs. being provided by the same provider. Hannes: What is different to the enterprise environment is the interaction between roaming and local... Brian: We should be asking, Is it all right that the service provider queries LoST, if it's not all right... Keith: not the question - the question I am raising, is that if different addressing info is used in a 3GPP network, since 3GPP looks for specific call marking, and the call may not get to the PSAP at all. Brian: The main difference is due to the location being done by the UA or not. Roger: It's a difference between "core" vs. "edge" routing based on location. Marc: If we exclude all other standards development organizations out of this, then it's not overarching. Keith: I'd have to go back and look at the document. Marc: Can you look at it within a week? Keith: Other ietf documents are explicit as to what they apply to... Randy: This statement is helpful, is not harmful to have it here. Hannes: But if it's not a big deal, why do you care so much about this text? Keith: All docs have a scope, what does the document do, and what is the document applicable to. Hannes: Most of the documents are written in such a way as to be generic building blocks... maybe I'm wrong about this assumption, but if what you point out the UA LoST lookup problem is not adequately covered, maybe we should read through again, and makes sure the document says what it needs to say. My opinion is that this is what the document says... Brian: The underlying protocols support either model where a UA gets location & queries LoST or a Proxy gets location & queries LoST, but the phonebcp doesn't really talk about the latter, other than in a fail-case scenario. Roger: Phonebcp is really just a profile for edge-based routing based on location, there is no comparable profile document that describes a proxy-inserted location & routing model architecture. Brian: Yes, but the underlying protocols support it. Roger: yes. Marc: Doesn't the title PhoneBCP suggest the edge context? Brian: As to the applicability statement, I don't think this wording really matters. Keith: I've already referred to wording in the abstract that gives the impression of a universal solution. [skip] Hannes:=20 Randy: Would like the question asked - are people happy with the existing document? Marc: If we could have a -10 w/o the statement, then ask do you (wg) want -09 or -10, would that work? Randy: No, I don't think so. Randy: Ask, given that other documents are being held up, is the present document acceptable? Cullen: you can't leave it binary then, it either needs... James: Ask the question, do you want something, but not what's in -09? John: I think that James' suggestion could break the (apparent) deadlock. Richard: suggest a rev -10 w/o text - two independent consensus calls. Randy: There is a difference between a preference and a strong objection. Brian: ok, suggest asking the question, who is strongly opposed to -09 and who is strongly opposed to -10? James: does that take into consideration whether people want something, but something different? Brian: no, James: right, then it becomes a two-step process. James: I strongly oppose the suggestions. Brian: you need to start with something non-prejudiced. Marc: I will discuss with the AD's. Summary: NO CLEAR CONSENSUS REACHED /end of mtg. at 11:48 AM Pacific =20 CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_002_01C9EED6.4C497040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT Interim Conf Call June 3

Please find the raw minutes from our last ECRIT Interim meet= ing, June 03, 2009, inline. 

 

Do send any corrections my way, in case of errors, etc.=

 

I’ve also attached as a MS Word file, in case of forma= tting difficulties – which may or may not make it through the list server.<= o:p>

 

-roger marshall.

ECRIT Secretary

rmarshall@telecomsys.com

 

***

 

ECRIT Interim Meeting

Date: Jun 03, 2009

Minutes by: R. Marshall

Chairs: Marc Linsner & Hannes Tschofenig

Wiki page at:

http://trac.tools.ietf.org/wg/ecrit/trac/wiki

Local start time: 10:06 AM Pacific

Agenda:

 

Attendees:

James Polk

Keith Drage

Hannes Tschofenig

Greg Burdett

Gabor Bajko

John Elwell

Karl Heinz

Randall Gellens

Richard Barnes

Robert Sparks

Roger Marshall

Spencer Dawkins

Marc Linsner

Brian Rosen

Cullen Jennings

Milan Patel

Dan Romascanu

 

Webex Session:

Notes of Meeting Discussion:

SLIDE 1-4…

SLIDE 5 – review the status of drafts…

Sos-parameter

Lost-sync WGLC is complete, waiting for a couple of implementers feedback since it is an exp

Location Hiding

Specifying Holes in LoST service boundaries (correctio= n: Cullen to talk to Martin Thomson)

(more details are in the link listed in the slide 5)

James: Why isn’t there a milestone for RPH here?=

Hannes: Discussion with AD’s – in short, w= e need to have a wg rechartering.

James: yes, for -00, but I’m on -05

Cullen: not unique circumstance, some drafts are not g= oing to go forward until rechartering happens.

James: Other drafts (after) have been brought in.=

Cullen: I’m a little lost myself on RPH – I didn’t realize that we needed to recharter for RPH.

James: I don’t think we need to update the chart= er.

Cullen: IESG will have to approve the recharter.<= /o:p>

Keith: Which situation are we now in – I believe= the wg asked for a milestone addition at Dublin

Hannes: RPH is listed as from October, other drafts fr= om June – it was up to Jon and Cullen as to whether these fit within the existing charter, they were considered within the charter.

…Skip to info in mail message sent out with mile= stone update (see SLIDE 9)

James: Other drafts seem to be sneeking in.=

Cullen: What do you mean.  We have the charter, t= hen there is the goals & milestones, then there is the Internet drafts.

Keith: One of the AD’s (presumably) will give us= the determination of whether this draft is within scope, or not.

Cullen: Some hesitancy here (on the phone) in light of= new AD’s coming in… If Jon said it was within scope, then I’l= l go with it, but I want to go back and look at what was decided.

Hannes: Recounting some history, when asked, Jon may h= ave agreed to allow additional drafts to be submitted, possibly because the phonebcp & framework draft completion was right around the corner.=

Hannes: Secondly, there was a milestones listing mista= ke, which is why I asked to have the milestones updated.

Brian: I think that we’re only waiting on one cr= itical issue – the applicability statement – the other issues, I don’t think are critical enough to hold up the document.

 

Next Discussion Item – PhoneBCP and the text add= ed based on SF ECRIT discussion:

Hannes: SLIDE 6, Marc asked for consensus, but has not= ed that there is no clear consensus.

James: Just one or two people who don’t want to = take it out.

Brian: More than just one or two.

Brian: It’s a chair call, as  to whether th= ere is rough consensus.

Hannes: The question in the consensus call that Marc i= ssued was not whether people agreed with the applicability statement, but rather = is the present wording acceptable.

Randy: I’m saying, ask a different question R= 11; we have a draft out there, can that version go forward?

Keith: The version with the statement is fine with me,= could be clarified, but has a caveat.

Hannes:  Maybe we should resubmit the document wi= thout the statement,

Brian: As you have to do is revert.

Randy: We should ask whether the current version of the draft can go forward.

Hannes: what is the previous version

Randy: If we go back, we know from SF that there are problems with the previous version

Hannes: You believe there are problems…

[skip]

Marc: Current version is -09, we could ask the simple question, should we ask do we go forward with -09 or -08?

Randy: But, -08 is the same as in SF, and we will get = back into the controversy again as in SF.

Hannes: We can’t avoid the controversy,

Randy: Let’s not call it an applicability statem= ent, it’s just a note of text.

Marc:  We’ve got ____ people who didn’= ;t like the changes from -08 to -09.

Randy: My point was that the question as worded, ̷= 0;

Marc: My proposal of 3 minutes ago… <= /p>

Brian: I think I mis-spoke, since there are other chan= ges as well.  You’d have to have a more detailed question to differenti= ate the two.

Hannes:  The compromise text was premature, done = by a small group.

Brian: It was done on the list – not done by a s= mall group of people.

Cullen: Consensus is something taken at a point in tim= e, and over time, may change – a good thing – since that’s how agreements are reached… it sounds like the chairs are saying, it soun= ds like we didn’t have consensus at that time.

Randy: We had a lot of debate on the mailing list, yes during the ietf meeting, but also in the week following.

Randy: I think there was consensus that people weren&#= 8217;t content with -08

Hannes:

Marc: (reading the consensus question from email)=

Marc: that vote, if by plurality was 10 for, ________ against, etc.

Hannes: If there is something in the document that pre= vent ES from working in certain environments, then we should discuss it, though = it comes a little late…

Keith: It’s not late, these 3GPP documents have = been available for a few years.

Hannes:  3GPP doesn’t put these kinds of statements (e.g., about IETF shortcomings) in their documents

Randy: I think we’ve got some emotional baggage = tied in with this.

Richard: It doesn’t say, “X is a situation= , in which things won’t work”

Hannes: (reading the applicability statement)

Randy: All it does it to alert the reader

James: This is applies to IP networks

Keith: Who says that 3GPP is not an IP network

Randy: It’s not an applicability statement, doesn’t limit a solution in any way.  Most documents in the IETF= are self-limiting.  This document sets itself up as being “the single way” that all emergency calls happen.

Hannes: The primary focus of this document is around a= ccess providers providing location, and doesn’t take into consideration oth= er models, such as the communication service providers to provide, etc.

Richard: This document allows for other stuff, but just doesn’t map it out…

Hannes: There’s a big difference, it doesn’= ;t talk about emergency registration, etc.

Keith: You wouldn’t get a 3GPP LoST server, for example…

Keith: A Service Provider implementing the 3GPP standa= rd, wouldn’t implement a LoST server, because it doesn’t mention on= e.

Marc: (voice breaking up)

Richard: What do change in the document to eliminate t= he notion that other models can exist?

Keith: To a certain extent, some have suggested that t= ried that,

Richard: If I recall, Stephen (Edge’s) comments = were fairly general, not specifically pointed changed suggested.  Do you th= ink this kind of thing can be done?

Keith: I’d have to go back through it.

Randy: I’d have to do another detailed read of t= he document.

Spencer: I think the thread indicated that… 3GPP=

Keith: Sometimes CT1 vs. SA2 need pointed questions as= ked.

Hannes: We’ve had many conversations with 3GPP, = it depends on which questions are asked… which group.

Brian: 3GPP…

Hannes: I think it’s even worse than that, in th= at some of the communication models are very different.  E.g., the split = of services vs. being provided by the same provider.

Hannes: What is different to the enterprise environmen= t is the interaction between roaming and local…

Brian: We should be asking, Is it all right that the s= ervice provider queries LoST, if it’s not all right…

Keith: not the question – the question I am rais= ing, is that if different addressing info is used in a 3GPP network, since 3GPP looks for specific call marking, and the call may not get to the PSAP at al= l.

Brian: The main difference is due to the location bein= g done by the UA or not.

Roger: It’s a difference between “coreR= 21; vs. “edge” routing based on location.

Marc: If we exclude all other standards development organizations out of this, then it’s not overarching.

Keith: I’d have to go back and look at the docum= ent.

Marc: Can you look at it within a week?

Keith: Other ietf documents are explicit as to what th= ey apply to…

Randy: This statement is helpful, is not harmful to ha= ve it here.

Hannes: But if it’s not a big deal, why do you c= are so much about this text?

Keith: All docs have a scope, what does the document d= o, and what is the document applicable to.

Hannes: Most of the documents are written in such a wa= y as to be generic building blocks… maybe I’m wrong about this assumption, but if what you point out the UA LoST lookup problem is not adequately covered, maybe we should read through again, and makes sure the document says what it needs to say.  My opinion is that this is what t= he document says…

Brian: The underlying protocols support either model w= here a UA gets location & queries LoST or a Proxy gets location & queries LoST, but the phonebcp doesn’t really talk about the latter, other th= an in a fail-case scenario.

Roger: Phonebcp is really just a profile for edge-based routing based on location, there is no comparable profile document that describes a proxy-inserted location & routing model architecture.<= /o:p>

Brian: Yes, but the underlying protocols support it.

Roger: yes.

Marc: Doesn’t the title PhoneBCP suggest the edge context?

Brian: As to the applicability statement, I don’t think this wording really matters.

Keith: I’ve already referred to wording in the abstract that gives the impression of a universal solution.

[skip]

Hannes:

Randy: Would like the question asked – are people happy with the existing document?

Marc: If we could have a -10 w/o the statement, then a= sk do you (wg) want -09 or -10, would that work?

Randy: No, I don’t think so.

Randy: Ask, given that other documents are being held = up, is the present document acceptable?

Cullen: you can’t leave it binary then, it either needs…

James: Ask the question, do you want something, but not what’s in -09?

John: I think that James’ suggestion could break= the (apparent) deadlock.

Richard:  suggest a rev -10 w/o text – two independent consensus calls.

Randy: There is a difference between a preference and = a strong objection.

Brian: ok, suggest asking the question, who is strongly opposed to -09 and who is strongly opposed to -10?

James: does that take into consideration whether peopl= e want something, but something different?

Brian: no,

James: right, then it becomes a two-step process.=

James: I strongly oppose the suggestions.

Brian: you need to start with something non-prejudiced= .

Marc: I will discuss with the AD’s.

Summary: NO CLEAR CONSENSUS REACHED

/end of mtg. at 11:48 AM Pacific

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

------_=_NextPart_002_01C9EED6.4C497040-- ------_=_NextPart_001_01C9EED6.4C497040 Content-Type: application/msword; name="ECRIT_Interim_Meeting_20090603.doc" Content-Transfer-Encoding: base64 Content-Description: ECRIT_Interim_Meeting_20090603.doc Content-Disposition: attachment; filename="ECRIT_Interim_Meeting_20090603.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASgAAAAAAAAAA EAAATAAAAAEAAAD+////AAAAAEkAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAAYAJBAAA8BK/AAAAAAAAEAAAAAAACAAAdDEAAA4AYmpianP3c/cAAAAAAAAAAAAAAAAAAAAA AAAJBBYANEIAABGdAAARnQAAdCkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAANYFAAAAAAAA1gUAABkT AAAAAAAAGRMAAAAAAAAZEwAAAAAAABkTAAAAAAAAGRMAABQAAAAAAAAAAAAAAP////8AAAAALRMA AAAAAAAtEwAAAAAAAC0TAAAAAAAALRMAABQAAABBEwAANAAAAC0TAAAAAAAASRgAADABAAB1EwAA FgAAAIsTAAAAAAAAixMAAAAAAACLEwAAAAAAAIsTAAAAAAAAZhQAAAAAAABmFAAAAAAAAGYUAAAA AAAAyBcAAAIAAADKFwAAAAAAAMoXAAAAAAAAyhcAAAAAAADKFwAAAAAAAMoXAAAAAAAAyhcAACQA AAB5GQAAogIAABscAABOAAAA7hcAABUAAAAAAAAAAAAAAAAAAAAAAAAAGRMAAAAAAABmFAAAAAAA AAAAAAAAAAAAAAAAAAAAAABmFAAAAAAAAGYUAAAAAAAAZhQAAAAAAABmFAAAAAAAAO4XAAAAAAAA AAAAAAAAAAAZEwAAAAAAABkTAAAAAAAAixMAAAAAAAAAAAAAAAAAAIsTAADbAAAAAxgAABYAAABU FwAAAAAAAFQXAAAAAAAAVBcAAAAAAABmFAAAWgEAABkTAAAAAAAAixMAAAAAAAAZEwAAAAAAAIsT AAAAAAAAyBcAAAAAAAAAAAAAAAAAAFQXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZhQAAAAAAADIFwAAAAAAAAAAAAAAAAAAVBcAAAAAAAAAAAAA AAAAAFQXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVBcAAAAAAACLEwAAAAAAAP////8AAAAAEGjOTNXu yQEAAAAAAAAAAC0TAAAAAAAAwBUAAAYBAABUFwAAAAAAAAAAAAAAAAAAtBcAABQAAAAZGAAAMAAA AEkYAAAAAAAAVBcAAAAAAABpHAAAAAAAAMYWAACOAAAAaRwAAAAAAABUFwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAGkcAAAAAAAAAAAAAAAAAAAZEwAAAAAAAFQXAABgAAAAZhQAAAAAAABmFAAAAAAAAFQX AAAAAAAAZhQAAAAAAABmFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZhQA AAAAAABmFAAAAAAAAGYUAAAAAAAA7hcAAAAAAADuFwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAVBcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGYUAAAA AAAAZhQAAAAAAABmFAAAAAAAAEkYAAAAAAAAZhQAAAAAAABmFAAAAAAAAGYUAAAAAAAAZhQAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAGkcAAAAAAAAZhQAAAAAAABm FAAAAAAAAGYUAAAAAAAAZhQAAAAAAABmFAAAAAAAAGYUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmFAAAAAAAAGYUAAAAAAAAZhQA AAAAAADWBQAACQwAAN8RAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEVDUklU IEludGVyaW0gTWVldGluZw1EYXRlOiBKdW4gMDMsIDIwMDkNTWludXRlcyBieTogUi4gTWFyc2hh bGwNQ2hhaXJzOiBNYXJjIExpbnNuZXIgJiBIYW5uZXMgVHNjaG9mZW5pZw1XaWtpIHBhZ2UgYXQ6 DRMgSFlQRVJMSU5LICJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9lY3JpdC90cmFjL3dp a2kiIBRodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9lY3JpdC90cmFjL3dpa2kVDUxvY2Fs IHN0YXJ0IHRpbWU6IDEwOjA2IEFNIFBhY2lmaWMNQWdlbmRhOg0NQXR0ZW5kZWVzOg1KYW1lcyBQ b2xrDUtlaXRoIERyYWdlDUhhbm5lcyBUc2Nob2ZlbmlnDUdyZWcgQnVyZGV0dA1HYWJvciBCYWpr bw1Kb2huIEVsd2VsbA1LYXJsIEhlaW56DVJhbmRhbGwgR2VsbGVucw1SaWNoYXJkIEJhcm5lcw1S b2JlcnQgU3BhcmtzDVJvZ2VyIE1hcnNoYWxsDVNwZW5jZXIgRGF3a2lucw1NYXJjIExpbnNuZXIN QnJpYW4gUm9zZW4NQ3VsbGVuIEplbm5pbmdzDU1pbGFuIFBhdGVsDURhbiBSb21hc2NhbnUNDVdl YmV4IFNlc3Npb246DU5vdGVzIG9mIE1lZXRpbmcgRGlzY3Vzc2lvbjoNU0xJREUgMS00hQ1TTElE RSA1IJYgcmV2aWV3IHRoZSBzdGF0dXMgb2YgZHJhZnRzhQ1Tb3MtcGFyYW1ldGVyDUxvc3Qtc3lu YyBXR0xDIGlzIGNvbXBsZXRlLCB3YWl0aW5nIGZvciBhIGNvdXBsZSBvZiBpbXBsZW1lbnRlcnMg ZmVlZGJhY2sgc2luY2UgaXQgaXMgYW4gZXhwDUxvY2F0aW9uIEhpZGluZw1TcGVjaWZ5aW5nIEhv bGVzIGluIExvU1Qgc2VydmljZSBib3VuZGFyaWVzIChjb3JyZWN0aW9uOiBDdWxsZW4gdG8gdGFs ayB0byBNYXJ0aW4gVGhvbXNvbikNKG1vcmUgZGV0YWlscyBhcmUgaW4gdGhlIGxpbmsgbGlzdGVk IGluIHRoZSBzbGlkZSA1KQ1KYW1lczogV2h5IGlzbpJ0IHRoZXJlIGEgbWlsZXN0b25lIGZvciBS UEggaGVyZT8NSGFubmVzOiBEaXNjdXNzaW9uIHdpdGggQUSScyCWIGluIHNob3J0LCB3ZSBuZWVk IHRvIGhhdmUgYSB3ZyByZWNoYXJ0ZXJpbmcuDUphbWVzOiB5ZXMsIGZvciAtMDAsIGJ1dCBJkm0g b24gLTA1DUN1bGxlbjogbm90IHVuaXF1ZSBjaXJjdW1zdGFuY2UsIHNvbWUgZHJhZnRzIGFyZSBu b3QgZ29pbmcgdG8gZ28gZm9yd2FyZCB1bnRpbCByZWNoYXJ0ZXJpbmcgaGFwcGVucy4NSmFtZXM6 IE90aGVyIGRyYWZ0cyAoYWZ0ZXIpIGhhdmUgYmVlbiBicm91Z2h0IGluLg1DdWxsZW46IEmSbSBh IGxpdHRsZSBsb3N0IG15c2VsZiBvbiBSUEggliBJIGRpZG6SdCByZWFsaXplIHRoYXQgd2UgbmVl ZGVkIHRvIHJlY2hhcnRlciBmb3IgUlBILg1KYW1lczogSSBkb26SdCB0aGluayB3ZSBuZWVkIHRv IHVwZGF0ZSB0aGUgY2hhcnRlci4NQ3VsbGVuOiBJRVNHIHdpbGwgaGF2ZSB0byBhcHByb3ZlIHRo ZSByZWNoYXJ0ZXIuDUtlaXRoOiBXaGljaCBzaXR1YXRpb24gYXJlIHdlIG5vdyBpbiCWIEkgYmVs aWV2ZSB0aGUgd2cgYXNrZWQgZm9yIGEgbWlsZXN0b25lIGFkZGl0aW9uIGF0IER1Ymxpbg1IYW5u ZXM6IFJQSCBpcyBsaXN0ZWQgYXMgZnJvbSBPY3RvYmVyLCBvdGhlciBkcmFmdHMgZnJvbSBKdW5l IJYgaXQgd2FzIHVwIHRvIEpvbiBhbmQgQ3VsbGVuIGFzIHRvIHdoZXRoZXIgdGhlc2UgZml0IHdp dGhpbiB0aGUgZXhpc3RpbmcgY2hhcnRlciwgdGhleSB3ZXJlIGNvbnNpZGVyZWQgd2l0aGluIHRo ZSBjaGFydGVyLg2FU2tpcCB0byBpbmZvIGluIG1haWwgbWVzc2FnZSBzZW50IG91dCB3aXRoIG1p bGVzdG9uZSB1cGRhdGUgKHNlZSBTTElERSA5KQ1KYW1lczogT3RoZXIgZHJhZnRzIHNlZW0gdG8g YmUgc25lZWtpbmcgaW4uDUN1bGxlbjogV2hhdCBkbyB5b3UgbWVhbi4gIFdlIGhhdmUgdGhlIGNo YXJ0ZXIsIHRoZW4gdGhlcmUgaXMgdGhlIGdvYWxzICYgbWlsZXN0b25lcywgdGhlbiB0aGVyZSBp cyB0aGUgSW50ZXJuZXQgZHJhZnRzLg1LZWl0aDogT25lIG9mIHRoZSBBRJJzIChwcmVzdW1hYmx5 KSB3aWxsIGdpdmUgdXMgdGhlIGRldGVybWluYXRpb24gb2Ygd2hldGhlciB0aGlzIGRyYWZ0IGlz IHdpdGhpbiBzY29wZSwgb3Igbm90Lg1DdWxsZW46IFNvbWUgaGVzaXRhbmN5IGhlcmUgKG9uIHRo ZSBwaG9uZSkgaW4gbGlnaHQgb2YgbmV3IEFEknMgY29taW5nIGluhSBJZiBKb24gc2FpZCBpdCB3 YXMgd2l0aGluIHNjb3BlLCB0aGVuIEmSbGwgZ28gd2l0aCBpdCwgYnV0IEkgd2FudCB0byBnbyBi YWNrIGFuZCBsb29rIGF0IHdoYXQgd2FzIGRlY2lkZWQuDUhhbm5lczogUmVjb3VudGluZyBzb21l IGhpc3RvcnksIHdoZW4gYXNrZWQsIEpvbiBtYXkgaGF2ZSBhZ3JlZWQgdG8gYWxsb3cgYWRkaXRp b25hbCBkcmFmdHMgdG8gYmUgc3VibWl0dGVkLCBwb3NzaWJseSBiZWNhdXNlIHRoZSBwaG9uZWJj cCAmIGZyYW1ld29yayBkcmFmdCBjb21wbGV0aW9uIHdhcyByaWdodCBhcm91bmQgdGhlIGNvcm5l ci4NSGFubmVzOiBTZWNvbmRseSwgdGhlcmUgd2FzIGEgbWlsZXN0b25lcyBsaXN0aW5nIG1pc3Rh a2UsIHdoaWNoIGlzIHdoeSBJIGFza2VkIHRvIGhhdmUgdGhlIG1pbGVzdG9uZXMgdXBkYXRlZC4N QnJpYW46IEkgdGhpbmsgdGhhdCB3ZZJyZSBvbmx5IHdhaXRpbmcgb24gb25lIGNyaXRpY2FsIGlz c3VlIJYgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IJYgdGhlIG90aGVyIGlzc3VlcywgSSBk b26SdCB0aGluayBhcmUgY3JpdGljYWwgZW5vdWdoIHRvIGhvbGQgdXAgdGhlIGRvY3VtZW50Lg0N TmV4dCBEaXNjdXNzaW9uIEl0ZW0gliBQaG9uZUJDUCBhbmQgdGhlIHRleHQgYWRkZWQgYmFzZWQg b24gU0YgRUNSSVQgZGlzY3Vzc2lvbjoNSGFubmVzOiBTTElERSA2LCBNYXJjIGFza2VkIGZvciBj b25zZW5zdXMsIGJ1dCBoYXMgbm90ZWQgdGhhdCB0aGVyZSBpcyBubyBjbGVhciBjb25zZW5zdXMu DUphbWVzOiBKdXN0IG9uZSBvciB0d28gcGVvcGxlIHdobyBkb26SdCB3YW50IHRvIHRha2UgaXQg b3V0Lg1CcmlhbjogTW9yZSB0aGFuIGp1c3Qgb25lIG9yIHR3by4NQnJpYW46IEl0knMgYSBjaGFp ciBjYWxsLCBhcyAgdG8gd2hldGhlciB0aGVyZSBpcyByb3VnaCBjb25zZW5zdXMuDUhhbm5lczog VGhlIHF1ZXN0aW9uIGluIHRoZSBjb25zZW5zdXMgY2FsbCB0aGF0IE1hcmMgaXNzdWVkIHdhcyBu b3Qgd2hldGhlciBwZW9wbGUgYWdyZWVkIHdpdGggdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50 LCBidXQgcmF0aGVyIGlzIHRoZSBwcmVzZW50IHdvcmRpbmcgYWNjZXB0YWJsZS4NUmFuZHk6IEmS bSBzYXlpbmcsIGFzayBhIGRpZmZlcmVudCBxdWVzdGlvbiCWIHdlIGhhdmUgYSBkcmFmdCBvdXQg dGhlcmUsIGNhbiB0aGF0IHZlcnNpb24gZ28gZm9yd2FyZD8NS2VpdGg6IFRoZSB2ZXJzaW9uIHdp dGggdGhlIHN0YXRlbWVudCBpcyBmaW5lIHdpdGggbWUsIGNvdWxkIGJlIGNsYXJpZmllZCwgYnV0 IGhhcyBhIGNhdmVhdC4NSGFubmVzOiAgTWF5YmUgd2Ugc2hvdWxkIHJlc3VibWl0IHRoZSBkb2N1 bWVudCB3aXRob3V0IHRoZSBzdGF0ZW1lbnQsIA1CcmlhbjogQXMgeW91IGhhdmUgdG8gZG8gaXMg cmV2ZXJ0Lg1SYW5keTogV2Ugc2hvdWxkIGFzayB3aGV0aGVyIHRoZSBjdXJyZW50IHZlcnNpb24g b2YgdGhlIGRyYWZ0IGNhbiBnbyBmb3J3YXJkLg1IYW5uZXM6IHdoYXQgaXMgdGhlIHByZXZpb3Vz IHZlcnNpb24NUmFuZHk6IElmIHdlIGdvIGJhY2ssIHdlIGtub3cgZnJvbSBTRiB0aGF0IHRoZXJl IGFyZSBwcm9ibGVtcyB3aXRoIHRoZSBwcmV2aW91cyB2ZXJzaW9uDUhhbm5lczogWW91IGJlbGll dmUgdGhlcmUgYXJlIHByb2JsZW1zhQ1bc2tpcF0NTWFyYzogQ3VycmVudCB2ZXJzaW9uIGlzIC0w OSwgd2UgY291bGQgYXNrIHRoZSBzaW1wbGUgcXVlc3Rpb24sIHNob3VsZCB3ZSBhc2sgZG8gd2Ug Z28gZm9yd2FyZCB3aXRoIC0wOSBvciAtMDg/DVJhbmR5OiBCdXQsIC0wOCBpcyB0aGUgc2FtZSBh cyBpbiBTRiwgYW5kIHdlIHdpbGwgZ2V0IGJhY2sgaW50byB0aGUgY29udHJvdmVyc3kgYWdhaW4g YXMgaW4gU0YuDUhhbm5lczogV2UgY2FuknQgYXZvaWQgdGhlIGNvbnRyb3ZlcnN5LCANUmFuZHk6 IExldJJzIG5vdCBjYWxsIGl0IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50LCBpdJJzIGp1c3Qg YSBub3RlIG9mIHRleHQuDU1hcmM6ICBXZZJ2ZSBnb3QgX19fXyBwZW9wbGUgd2hvIGRpZG6SdCBs aWtlIHRoZSBjaGFuZ2VzIGZyb20gLTA4IHRvIC0wOS4NUmFuZHk6IE15IHBvaW50IHdhcyB0aGF0 IHRoZSBxdWVzdGlvbiBhcyB3b3JkZWQsIIUNTWFyYzogTXkgcHJvcG9zYWwgb2YgMyBtaW51dGVz IGFnb4UgDUJyaWFuOiBJIHRoaW5rIEkgbWlzLXNwb2tlLCBzaW5jZSB0aGVyZSBhcmUgb3RoZXIg Y2hhbmdlcyBhcyB3ZWxsLiAgWW91kmQgaGF2ZSB0byBoYXZlIGEgbW9yZSBkZXRhaWxlZCBxdWVz dGlvbiB0byBkaWZmZXJlbnRpYXRlIHRoZSB0d28uDUhhbm5lczogIFRoZSBjb21wcm9taXNlIHRl eHQgd2FzIHByZW1hdHVyZSwgZG9uZSBieSBhIHNtYWxsIGdyb3VwLg1CcmlhbjogSXQgd2FzIGRv bmUgb24gdGhlIGxpc3QgliBub3QgZG9uZSBieSBhIHNtYWxsIGdyb3VwIG9mIHBlb3BsZS4NQ3Vs bGVuOiBDb25zZW5zdXMgaXMgc29tZXRoaW5nIHRha2VuIGF0IGEgcG9pbnQgaW4gdGltZSwgYW5k IG92ZXIgdGltZSwgbWF5IGNoYW5nZSCWIGEgZ29vZCB0aGluZyCWIHNpbmNlIHRoYXSScyBob3cg YWdyZWVtZW50cyBhcmUgcmVhY2hlZIUgaXQgc291bmRzIGxpa2UgdGhlIGNoYWlycyBhcmUgc2F5 aW5nLCBpdCBzb3VuZHMgbGlrZSB3ZSBkaWRuknQgaGF2ZSBjb25zZW5zdXMgYXQgdGhhdCB0aW1l Lg1SYW5keTogV2UgaGFkIGEgbG90IG9mIGRlYmF0ZSBvbiB0aGUgbWFpbGluZyBsaXN0LCB5ZXMg ZHVyaW5nIHRoZSBpZXRmIG1lZXRpbmcsIGJ1dCBhbHNvIGluIHRoZSB3ZWVrIGZvbGxvd2luZy4N UmFuZHk6IEkgdGhpbmsgdGhlcmUgd2FzIGNvbnNlbnN1cyB0aGF0IHBlb3BsZSB3ZXJlbpJ0IGNv bnRlbnQgd2l0aCAtMDgNSGFubmVzOg1NYXJjOiAocmVhZGluZyB0aGUgY29uc2Vuc3VzIHF1ZXN0 aW9uIGZyb20gZW1haWwpDU1hcmM6IHRoYXQgdm90ZSwgaWYgYnkgcGx1cmFsaXR5IHdhcyAxMCBm b3IsIF9fX19fX19fIGFnYWluc3QsIGV0Yy4NSGFubmVzOiBJZiB0aGVyZSBpcyBzb21ldGhpbmcg aW4gdGhlIGRvY3VtZW50IHRoYXQgcHJldmVudCBFUyBmcm9tIHdvcmtpbmcgaW4gY2VydGFpbiBl bnZpcm9ubWVudHMsIHRoZW4gd2Ugc2hvdWxkIGRpc2N1c3MgaXQsIHRob3VnaCBpdCBjb21lcyBh IGxpdHRsZSBsYXRlhQ1LZWl0aDogSXSScyBub3QgbGF0ZSwgdGhlc2UgM0dQUCBkb2N1bWVudHMg aGF2ZSBiZWVuIGF2YWlsYWJsZSBmb3IgYSBmZXcgeWVhcnMuDUhhbm5lczogIDNHUFAgZG9lc26S dCBwdXQgdGhlc2Uga2luZHMgb2Ygc3RhdGVtZW50cyAoZS5nLiwgYWJvdXQgSUVURiBzaG9ydGNv bWluZ3MpIGluIHRoZWlyIGRvY3VtZW50cw1SYW5keTogSSB0aGluayB3ZZJ2ZSBnb3Qgc29tZSBl bW90aW9uYWwgYmFnZ2FnZSB0aWVkIGluIHdpdGggdGhpcy4NUmljaGFyZDogSXQgZG9lc26SdCBz YXksIJNYIGlzIGEgc2l0dWF0aW9uLCBpbiB3aGljaCB0aGluZ3Mgd29uknQgd29ya5QNSGFubmVz OiAocmVhZGluZyB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQpIA1SYW5keTogQWxsIGl0IGRv ZXMgaXQgdG8gYWxlcnQgdGhlIHJlYWRlcg1KYW1lczogVGhpcyBpcyBhcHBsaWVzIHRvIElQIG5l dHdvcmtzDUtlaXRoOiBXaG8gc2F5cyB0aGF0IDNHUFAgaXMgbm90IGFuIElQIG5ldHdvcmsNUmFu ZHk6IEl0knMgbm90IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50LCBkb2VzbpJ0IGxpbWl0IGEg c29sdXRpb24gaW4gYW55IHdheS4gIE1vc3QgZG9jdW1lbnRzIGluIHRoZSBJRVRGIGFyZSBzZWxm LWxpbWl0aW5nLiAgVGhpcyBkb2N1bWVudCBzZXRzIGl0c2VsZiB1cCBhcyBiZWluZyCTdGhlIHNp bmdsZSB3YXmUIHRoYXQgYWxsIGVtZXJnZW5jeSBjYWxscyBoYXBwZW4uDUhhbm5lczogVGhlIHBy aW1hcnkgZm9jdXMgb2YgdGhpcyBkb2N1bWVudCBpcyBhcm91bmQgYWNjZXNzIHByb3ZpZGVycyBw cm92aWRpbmcgbG9jYXRpb24sIGFuZCBkb2VzbpJ0IHRha2UgaW50byBjb25zaWRlcmF0aW9uIG90 aGVyIG1vZGVscywgc3VjaCBhcyB0aGUgY29tbXVuaWNhdGlvbiBzZXJ2aWNlIHByb3ZpZGVycyB0 byBwcm92aWRlLCBldGMuDVJpY2hhcmQ6IFRoaXMgZG9jdW1lbnQgYWxsb3dzIGZvciBvdGhlciBz dHVmZiwgYnV0IGp1c3QgZG9lc26SdCBtYXAgaXQgb3V0hQ1IYW5uZXM6IFRoZXJlknMgYSBiaWcg ZGlmZmVyZW5jZSwgaXQgZG9lc26SdCB0YWxrIGFib3V0IGVtZXJnZW5jeSByZWdpc3RyYXRpb24s IGV0Yy4NS2VpdGg6IFlvdSB3b3VsZG6SdCBnZXQgYSAzR1BQIExvU1Qgc2VydmVyLCBmb3IgZXhh bXBsZYUNS2VpdGg6IEEgU2VydmljZSBQcm92aWRlciBpbXBsZW1lbnRpbmcgdGhlIDNHUFAgc3Rh bmRhcmQsIHdvdWxkbpJ0IGltcGxlbWVudCBhIExvU1Qgc2VydmVyLCBiZWNhdXNlIGl0IGRvZXNu knQgbWVudGlvbiBvbmUuDU1hcmM6ICh2b2ljZSBicmVha2luZyB1cCkNUmljaGFyZDogV2hhdCBk byBjaGFuZ2UgaW4gdGhlIGRvY3VtZW50IHRvIGVsaW1pbmF0ZSB0aGUgbm90aW9uIHRoYXQgb3Ro ZXIgbW9kZWxzIGNhbiBleGlzdD8NS2VpdGg6IFRvIGEgY2VydGFpbiBleHRlbnQsIHNvbWUgaGF2 ZSBzdWdnZXN0ZWQgdGhhdCB0cmllZCB0aGF0LCANUmljaGFyZDogSWYgSSByZWNhbGwsIFN0ZXBo ZW4gKEVkZ2WScykgY29tbWVudHMgd2VyZSBmYWlybHkgZ2VuZXJhbCwgbm90IHNwZWNpZmljYWxs eSBwb2ludGVkIGNoYW5nZWQgc3VnZ2VzdGVkLiAgRG8geW91IHRoaW5rIHRoaXMga2luZCBvZiB0 aGluZyBjYW4gYmUgZG9uZT8NS2VpdGg6IEmSZCBoYXZlIHRvIGdvIGJhY2sgdGhyb3VnaCBpdC4N UmFuZHk6IEmSZCBoYXZlIHRvIGRvIGFub3RoZXIgZGV0YWlsZWQgcmVhZCBvZiB0aGUgZG9jdW1l bnQuDVNwZW5jZXI6IEkgdGhpbmsgdGhlIHRocmVhZCBpbmRpY2F0ZWQgdGhhdIUgM0dQUCANS2Vp dGg6IFNvbWV0aW1lcyBDVDEgdnMuIFNBMiBuZWVkIHBvaW50ZWQgcXVlc3Rpb25zIGFza2VkLg1I YW5uZXM6IFdlknZlIGhhZCBtYW55IGNvbnZlcnNhdGlvbnMgd2l0aCAzR1BQLCBpdCBkZXBlbmRz IG9uIHdoaWNoIHF1ZXN0aW9ucyBhcmUgYXNrZWSFIHdoaWNoIGdyb3VwLg1CcmlhbjogM0dQUIUN SGFubmVzOiBJIHRoaW5rIGl0knMgZXZlbiB3b3JzZSB0aGFuIHRoYXQsIGluIHRoYXQgc29tZSBv ZiB0aGUgY29tbXVuaWNhdGlvbiBtb2RlbHMgYXJlIHZlcnkgZGlmZmVyZW50LiAgRS5nLiwgdGhl IHNwbGl0IG9mIHNlcnZpY2VzIHZzLiBiZWluZyBwcm92aWRlZCBieSB0aGUgc2FtZSBwcm92aWRl ci4NSGFubmVzOiBXaGF0IGlzIGRpZmZlcmVudCB0byB0aGUgZW50ZXJwcmlzZSBlbnZpcm9ubWVu dCBpcyB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiByb2FtaW5nIGFuZCBsb2NhbIUNQnJpYW46IFdl IHNob3VsZCBiZSBhc2tpbmcsIElzIGl0IGFsbCByaWdodCB0aGF0IHRoZSBzZXJ2aWNlIHByb3Zp ZGVyIHF1ZXJpZXMgTG9TVCwgaWYgaXSScyBub3QgYWxsIHJpZ2h0hQ1LZWl0aDogbm90IHRoZSBx dWVzdGlvbiCWIHRoZSBxdWVzdGlvbiBJIGFtIHJhaXNpbmcsIGlzIHRoYXQgaWYgZGlmZmVyZW50 IGFkZHJlc3NpbmcgaW5mbyBpcyB1c2VkIGluIGEgM0dQUCBuZXR3b3JrLCBzaW5jZSAzR1BQIGxv b2tzIGZvciBzcGVjaWZpYyBjYWxsIG1hcmtpbmcsIGFuZCB0aGUgY2FsbCBtYXkgbm90IGdldCB0 byB0aGUgUFNBUCBhdCBhbGwuDUJyaWFuOiBUaGUgbWFpbiBkaWZmZXJlbmNlIGlzIGR1ZSB0byB0 aGUgbG9jYXRpb24gYmVpbmcgZG9uZSBieSB0aGUgVUEgb3Igbm90Lg1Sb2dlcjogSXSScyBhIGRp ZmZlcmVuY2UgYmV0d2VlbiCTY29yZZQgdnMuIJNlZGdllCByb3V0aW5nIGJhc2VkIG9uIGxvY2F0 aW9uLg1NYXJjOiBJZiB3ZSBleGNsdWRlIGFsbCBvdGhlciBzdGFuZGFyZHMgZGV2ZWxvcG1lbnQg b3JnYW5pemF0aW9ucyBvdXQgb2YgdGhpcywgdGhlbiBpdJJzIG5vdCBvdmVyYXJjaGluZy4NS2Vp dGg6IEmSZCBoYXZlIHRvIGdvIGJhY2sgYW5kIGxvb2sgYXQgdGhlIGRvY3VtZW50Lg1NYXJjOiBD YW4geW91IGxvb2sgYXQgaXQgd2l0aGluIGEgd2Vlaz8NS2VpdGg6IE90aGVyIGlldGYgZG9jdW1l bnRzIGFyZSBleHBsaWNpdCBhcyB0byB3aGF0IHRoZXkgYXBwbHkgdG+FDVJhbmR5OiBUaGlzIHN0 YXRlbWVudCBpcyBoZWxwZnVsLCBpcyBub3QgaGFybWZ1bCB0byBoYXZlIGl0IGhlcmUuDUhhbm5l czogQnV0IGlmIGl0knMgbm90IGEgYmlnIGRlYWwsIHdoeSBkbyB5b3UgY2FyZSBzbyBtdWNoIGFi b3V0IHRoaXMgdGV4dD8NS2VpdGg6IEFsbCBkb2NzIGhhdmUgYSBzY29wZSwgd2hhdCBkb2VzIHRo ZSBkb2N1bWVudCBkbywgYW5kIHdoYXQgaXMgdGhlIGRvY3VtZW50IGFwcGxpY2FibGUgdG8uDUhh bm5lczogTW9zdCBvZiB0aGUgZG9jdW1lbnRzIGFyZSB3cml0dGVuIGluIHN1Y2ggYSB3YXkgYXMg dG8gYmUgZ2VuZXJpYyBidWlsZGluZyBibG9ja3OFIG1heWJlIEmSbSB3cm9uZyBhYm91dCB0aGlz IGFzc3VtcHRpb24sIGJ1dCBpZiB3aGF0IHlvdSBwb2ludCBvdXQgdGhlIFVBIExvU1QgbG9va3Vw IHByb2JsZW0gaXMgbm90IGFkZXF1YXRlbHkgY292ZXJlZCwgbWF5YmUgd2Ugc2hvdWxkIHJlYWQg dGhyb3VnaCBhZ2FpbiwgYW5kIG1ha2VzIHN1cmUgdGhlIGRvY3VtZW50IHNheXMgd2hhdCBpdCBu ZWVkcyB0byBzYXkuICBNeSBvcGluaW9uIGlzIHRoYXQgdGhpcyBpcyB3aGF0IHRoZSBkb2N1bWVu dCBzYXlzhQ1CcmlhbjogVGhlIHVuZGVybHlpbmcgcHJvdG9jb2xzIHN1cHBvcnQgZWl0aGVyIG1v ZGVsIHdoZXJlIGEgVUEgZ2V0cyBsb2NhdGlvbiAmIHF1ZXJpZXMgTG9TVCBvciBhIFByb3h5IGdl dHMgbG9jYXRpb24gJiBxdWVyaWVzIExvU1QsIGJ1dCB0aGUgcGhvbmViY3AgZG9lc26SdCByZWFs bHkgdGFsayBhYm91dCB0aGUgbGF0dGVyLCBvdGhlciB0aGFuIGluIGEgZmFpbC1jYXNlIHNjZW5h cmlvLg1Sb2dlcjogUGhvbmViY3AgaXMgcmVhbGx5IGp1c3QgYSBwcm9maWxlIGZvciBlZGdlLWJh c2VkIHJvdXRpbmcgYmFzZWQgb24gbG9jYXRpb24sIHRoZXJlIGlzIG5vIGNvbXBhcmFibGUgcHJv ZmlsZSBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBhIHByb3h5LWluc2VydGVkIGxvY2F0aW9uICYg cm91dGluZyBtb2RlbCBhcmNoaXRlY3R1cmUuDUJyaWFuOiBZZXMsIGJ1dCB0aGUgdW5kZXJseWlu ZyBwcm90b2NvbHMgc3VwcG9ydCBpdC4NUm9nZXI6IHllcy4NTWFyYzogRG9lc26SdCB0aGUgdGl0 bGUgUGhvbmVCQ1Agc3VnZ2VzdCB0aGUgZWRnZSBjb250ZXh0Pw1CcmlhbjogQXMgdG8gdGhlIGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50LCBJIGRvbpJ0IHRoaW5rIHRoaXMgd29yZGluZyByZWFsbHkg bWF0dGVycy4NS2VpdGg6IEmSdmUgYWxyZWFkeSByZWZlcnJlZCB0byB3b3JkaW5nIGluIHRoZSBh YnN0cmFjdCB0aGF0IGdpdmVzIHRoZSBpbXByZXNzaW9uIG9mIGEgdW5pdmVyc2FsIHNvbHV0aW9u Lg1bc2tpcF0NSGFubmVzOiANUmFuZHk6IFdvdWxkIGxpa2UgdGhlIHF1ZXN0aW9uIGFza2VkIJYg YXJlIHBlb3BsZSBoYXBweSB3aXRoIHRoZSBleGlzdGluZyBkb2N1bWVudD8NTWFyYzogSWYgd2Ug Y291bGQgaGF2ZSBhIC0xMCB3L28gdGhlIHN0YXRlbWVudCwgdGhlbiBhc2sgZG8geW91ICh3Zykg d2FudCAtMDkgb3IgLTEwLCB3b3VsZCB0aGF0IHdvcms/DVJhbmR5OiBObywgSSBkb26SdCB0aGlu ayBzby4NUmFuZHk6IEFzaywgZ2l2ZW4gdGhhdCBvdGhlciBkb2N1bWVudHMgYXJlIGJlaW5nIGhl bGQgdXAsIGlzIHRoZSBwcmVzZW50IGRvY3VtZW50IGFjY2VwdGFibGU/DUN1bGxlbjogeW91IGNh bpJ0IGxlYXZlIGl0IGJpbmFyeSB0aGVuLCBpdCBlaXRoZXIgbmVlZHOFDUphbWVzOiBBc2sgdGhl IHF1ZXN0aW9uLCBkbyB5b3Ugd2FudCBzb21ldGhpbmcsIGJ1dCBub3Qgd2hhdJJzIGluIC0wOT8N Sm9objogSSB0aGluayB0aGF0IEphbWVzkiBzdWdnZXN0aW9uIGNvdWxkIGJyZWFrIHRoZSAoYXBw YXJlbnQpIGRlYWRsb2NrLg1SaWNoYXJkOiAgc3VnZ2VzdCBhIHJldiAtMTAgdy9vIHRleHQgliB0 d28gaW5kZXBlbmRlbnQgY29uc2Vuc3VzIGNhbGxzLg1SYW5keTogVGhlcmUgaXMgYSBkaWZmZXJl bmNlIGJldHdlZW4gYSBwcmVmZXJlbmNlIGFuZCBhIHN0cm9uZyBvYmplY3Rpb24uDUJyaWFuOiBv aywgc3VnZ2VzdCBhc2tpbmcgdGhlIHF1ZXN0aW9uLCB3aG8gaXMgc3Ryb25nbHkgb3Bwb3NlZCB0 byAtMDkgYW5kIHdobyBpcyBzdHJvbmdseSBvcHBvc2VkIHRvIC0xMD8NSmFtZXM6IGRvZXMgdGhh dCB0YWtlIGludG8gY29uc2lkZXJhdGlvbiB3aGV0aGVyIHBlb3BsZSB3YW50IHNvbWV0aGluZywg YnV0IHNvbWV0aGluZyBkaWZmZXJlbnQ/DUJyaWFuOiBubywNSmFtZXM6IHJpZ2h0LCB0aGVuIGl0 IGJlY29tZXMgYSB0d28tc3RlcCBwcm9jZXNzLg1KYW1lczogSSBzdHJvbmdseSBvcHBvc2UgdGhl IHN1Z2dlc3Rpb25zLg1CcmlhbjogeW91IG5lZWQgdG8gc3RhcnQgd2l0aCBzb21ldGhpbmcgbm9u LXByZWp1ZGljZWQuDU1hcmM6IEkgd2lsbCBkaXNjdXNzIHdpdGggdGhlIEFEknMuDVN1bW1hcnk6 IE5PIENMRUFSIENPTlNFTlNVUyBSRUFDSEVEDS9lbmQgb2YgbXRnLiBhdCAxMTo0OCBBTSBQYWNp ZmljDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAVCAAAFggAAHgIAAB5CAAAtAgAALUI AADiCAAA4wgAAAcJAAAOCQAAGQkAABoJAAA4CQAAQwkAAEQJAABWCQAAXAkAAGkJAAB0CQAAgwkA AIQJAACSCQAAoQkAALAJAAC3CQAAvwkAAMQJAADMCQAA0gkAANgJAAAJCgAAEgoAABgKAAAuCgAA MAoAADsKAABDCgAAYQoAAGIKAABwCgAAcQoAAO0KAAAICwAAOAsAAG0LAAByCwAAngsAAKQLAACb DgAAow4AAJkPAADmDwAA5w8AAHsSAADNEgAAfhUAAIMYAACFGAAA8hoAAKgdAADEHQAAHx8AAAMj AAArIwAALCMAAM0jAADZIwAAiycAAM0nAADOJwAA/yoAAMArAADBKwAADC0AAA0tAADTLQAA/Pj8 8Pzw6vD85vzm/Ob85uLm/Ob85vzm/Ob85vzm/Ob8+Pz43vje/Ob83vze5t7m3uLe2t7a+NrW0tbS 5tLOys7K5srGysbmxub85gAAAAAAAAAAAAAAAAYWaEEWKAAABhZo+19/AAAGFmiGM+kAAAYWaPIo QAAABhZoW221AAAGFmhbV34AAAYWaKQ2SAAABhZosWnAAAAGFmjqTMwAAAoWaCs6fgAwSg8AAA8D agAAAAAWaCs6fgBVCAEGFmh+fd4AAAYWaCs6fgBMAAgAABYIAAApCAAAQQgAAGoIAAB4CAAA5AgA AAcJAAAPCQAAEAkAABsJAAAmCQAAMgkAAEQJAABRCQAAXQkAAGkJAAB0CQAAhAkAAJMJAAChCQAA sAkAAMAJAADNCQAA2QkAAOkJAAD1CQAAAwoAAAQKAAATCgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAB0TCgAAMAoAADsKAABiCgAAcAoAAM0KAADdCgAA OAsAAG0LAACeCwAA6gsAAA4MAABzDAAApQwAAAUNAAA5DQAAag0AAMsNAACFDgAA0A4AAPwOAAB1 DwAA5w8AAJ0QAABiEQAA0REAAHsSAAB8EgAAzRIAACgTAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAHSgTAABlEwAAhxMAAMoTAAB0FAAA2hQAADcVAAB+ FQAAohUAAPAVAAAVFgAAbRYAAJUWAACcFgAADBcAAGwXAACVFwAA5BcAAC4YAABhGAAAhhgAABAZ AABTGQAAmRkAAIIaAADyGgAAOhsAAEIbAAB0GwAAuBsAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAduBsAAFYcAACmHAAADR0AAFAdAACYHQAAxx0AAPEd AAAXHgAARh4AAB8fAADoHwAANCAAAIkgAADCIAAAPiEAAFghAAC1IQAA9yEAAJYiAAC9IgAA+iIA ACwjAABnIwAAzSMAANojAACIJAAA7iQAAFklAAAnJgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAB0nJgAAdiYAAMQmAAAuJwAAYycAAIsnAADOJwAAECgA AF0oAAC+KAAAHioAAP8qAADBKwAA9isAAAIsAAA9LAAAkiwAAP0sAAAELQAADS0AAGEtAADILQAA 5S0AAEMuAAB8LgAAwy4AAA0vAABVLwAAny8AAAowAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAHdMtAADkLQAA5S0AANIwAAAJMQAACjEAAC4xAABSMQAA czEAAHQxAAD8+Pz0/PD08PwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYWaH593gAA BhZoiDn0AAAGFmjqTMwAAAYWaJYQuQAJCjAAAGswAAB2MAAAqDAAANIwAAAKMQAALjEAAFIxAABz MQAAdDEAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAkyADGQaAE6cMcK0AAfsNAvILDgPSGwoAUisKAFI5CgBSSQ oAUlsAAAF7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABqBBAAEgABAAsBDwAHAAMAAwADAAAABAAIAAAAmAAAAJ4AAACeAAAAngAA AJ4AAACeAAAAngAAAJ4AAACeAAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA dgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAAPgIAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA AKgAAAA2BgAANgYAABYAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALgAAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAABoAQAASAEAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAsAMAADYGAAAyBgAAGAAAAMADAADQAwAA4AMAAPAD AAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMA AAAEAAAQBAAAMgYAACgCAADYAQAA6AEAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAA wAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADA AwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMAD AADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMA ANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA 0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAADgBAABY AQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAgAAAAT0oDAFBKAwBRSgMAX0gBBG1ICQRuSAkEc0gJBHRI CQQAAAAASgAAYPH/AgBKAAwQAADHCtAAAAAGAE4AbwByAG0AYQBsAAAADAAAABJkFAEBABSkyAAY AENKFgBfSAEEYUoWAG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAAAAAAAAAAAEQAQWDy/6EARAAMDQAA AAAAABAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABS AGkA8/+zAFIADB0AAAAAAAAwBgwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYG AAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAoAGsg9P/BACgAAA0AAAAAAAAwBgcATgBvACAATABp AHMAdAAAAAIADAAAAAAAQgBVQKIA8QBCAAwJAAArOn4AMAYJAEgAeQBwAGUAcgBsAGkAbgBrAAAA GAA+KgFPSgAAUUoAAF5KAABvKABwaAAA/wBQSwMEFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAABb Q29udGVudF9UeXBlc10ueG1srJHLasMwEEX3hf6D0LbYcroopdjOokl3fSzSDxjksS1qj4Q0Ccnf d+y4ULoILXQjEGLOmXtVro/joA4Yk/NU6VVeaIVkfeOoq/T77im71yoxUAODJ6z0CZNe19dX5e4U MCmZplTpnjk8GJNsjyOk3AckeWl9HIHlGjsTwH5Ah+a2KO6M9cRInPHE0HX5KgtE16B6g8gvMIrH sKDw+/kMJICYC1irxzNhWqLSEMLgLLBEMAdqfugz37bOYuPtfhRpPoMX2M0EM79cYPU/6i/nBlvY D6y2R+niXH/EIf0t21JrLpNz/tS7kC4YLpe3tGHmv60/AQAA//8DAFBLAwQUAAYACAAAACEApdan 58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2gi G9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8 UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/ s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAA IQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2h d5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzF LGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0B AAD//wMAUEsDBBQABgAIAAAAIQCWta3ilgYAAFAbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnht bOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2Fb gRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt 3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyK cCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUC HWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9 A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8b c/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDX ahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BU tb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG //rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI 0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH 8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6 gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeR HOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4 QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHal1CqnQoc 0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5jedd yX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCHQb3OnA5JcWJKI3jM 6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd2WNhUx8YbD2QWO3ywA6v6OH8 XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZfDivGgwW1oQGBEHbAlZehfO5 Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA2KnwkT7knWK1EreWJvsG3M7ipDK7 xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01m k+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6 riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg 7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9t jwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4h Vs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+ 6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX 5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2T tlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN7 4OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAb AQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3 CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyO QFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g 8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMA UEsBAi0AFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5 cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAArAQAAX3Jl bHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAUAgAAdGhl bWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAWAAAA AAAAAAAAAAAAANECAAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2 AAAAGwEAACcAAAAAAAAAAAAAAAAAmwkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54 bWwucmVsc1BLBQYAAAAABQAFAF0BAACWCgAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5n PSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3Nj aGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0 eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJh Y2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2Nl bnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIv PgAAAAB0KQAADQAAQgAAAAD/////AAgAANMtAAB0MQAAGQAAAB8AAAAACAAAEwoAACgTAAC4GwAA JyYAAAowAAB0MQAAGgAAABsAAAAcAAAAHQAAAB4AAAAgAAAAeAAAALQAAADiAAAAdCkAABNYFP8V jA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8A gICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABT AAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAAAAABXAQAA XAEAAGIBAABoAQAA+QEAAAICAAAEAgAACQIAAGICAABlAgAA8QIAAPUCAADZAwAA2wMAANwDAADo AwAAXQQAAGkEAADyBAAA+wQAAF8FAABoBQAAnwUAAKEFAADvBgAA9wYAAB8JAAAnCQAAkwoAAJsK AACXEAAAmhAAAMQSAADIEgAAqBgAAKwYAAARGQAAFRkAADwdAABAHQAAmB8AAJwfAABgIQAAZCEA AHYiAAB6IgAAniIAAKIiAACsIgAAtCIAAAYjAAAOIwAAGiQAACIkAACiJQAApCUAAHYpAAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAAAAAA pAIAALACAAA5AwAAPQMAAMQFAADKBQAAEAcAABUHAAA3BwAAOQcAADgKAAA/CgAAoQsAAKcLAAAN DgAAFA4AAJYOAACaDgAAtg4AALkOAAAcDwAAHg8AAL8PAADJDwAAVxAAAGAQAADrEwAA8hMAAGYU AABrFAAA8hgAAPsYAACRGwAAlhsAAEMcAACHHAAAnyAAALkgAABIIwAAUSMAAP4kAAACJQAAdikA AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAAAAAAOQAAADkAAAABgEAAAYBAAANAQAADQEA AFYBAABcAQAAAwIAAAMCAAAYAgAALgIAADACAAA7AgAAQwIAAGECAACbBgAAowYAAHsKAADNCgAA VCcAAHMpAAB2KQAAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAH ABIAAAAEAAAACAAAAOUAAAAAAAAADwAAAA54EgBBFigA8ihAAKQ2SAArOn4AW1d+APtffwC4Qo0A W221ABJvtwCWELkABkW/ALFpwADqTMwAxwrQAH593gCGM+kAiDn0AAAAAAB0KQAAdikAAAAAAAAB AAAA/0ADAAAAAAAAAHMpAAAAuIIDAQABAHIpAAACAAAAcikAAAAAAAACEAAAAAAAAAB0KQAAaAAA EABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA //8AAAAA//8AAAIA//8AAAAABQAAAEcekAEAAAICBgMFBAUCAwSHKgAgAAAAgAgAAAAAAAAA/wEA AAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUekAECAAUFAQIBBwYCBQcAAAAA AAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMukAEAAAILBgQCAgICAgSHKgAgAAAA gAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA3LpABAAACDwUCAgIEAwIE7wIAoHsgAEAAAAAA AAAAAJ8AAAAAAAAAQwBhAGwAaQBiAHIAaQAAAEEekAEAAAIEBQMFBAYDAgTvAgCg6yAAQgAAAAAA AAAAnwAAAAAAAABDAGEAbQBiAHIAaQBhACAATQBhAHQAaAAAACIABABxCIgYAPDQAgAAaAEAAAAA 9YPWRvWD1kYAAAAAAgABAAAALwYAAEUjAAAHABUAAAAEAAOQSwAAAC8GAABFIwAABwAVAAAASwAA AAAAAABxAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBaAFtAC0AIGBMjAAAAAAAAAA AAAAAAAAAF8pAABfKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAyg1EA8BAACAD8/QEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAISFAAAAAACfD/DwEIJFAAAOQEAAD///9/////f////3////9/////f////3////9/ Kzp+AAAEAAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQQAAAAAAAAAAAAAAAAAAAAAAAAQHAAABAAA AAAAAAAAAHgAAAB4AAAAAAAAAAAAAACgBQAA//8SAAAAAAAAAAAAAAAAAAAACQByAG0AYQByAHMA aABhAGwAbAAJAHIAbQBhAHIAcwBoAGEAbABsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ /wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAB0AQAAEQAAAAEA AACQAAAAAgAAAJgAAAADAAAApAAAAAQAAACwAAAABQAAAMQAAAAGAAAA0AAAAAcAAADcAAAACAAA APAAAAAJAAAABAEAABIAAAAQAQAACgAAADABAAAMAAAAPAEAAA0AAABIAQAADgAAAFQBAAAPAAAA XAEAABAAAABkAQAAEwAAAGwBAAACAAAA5AQAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAM AAAAcm1hcnNoYWxsAAAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAwAAABOb3JtYWwuZG90 bQAeAAAADAAAAHJtYXJzaGFsbAAAAB4AAAAEAAAAMgAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmlj ZSBXb3JkAAAAQAAAAABGwyMAAAAAQAAAAAAuiDLV7skBQAAAAAAuiDLV7skBAwAAAAcAAAADAAAA LwYAAAMAAABFIwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAA AAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rkgB AAAEAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAmAAAAAYAAACgAAAAEQAAAKgAAAAXAAAAsAAA AAsAAAC4AAAAEAAAAMAAAAATAAAAyAAAABYAAADQAAAADQAAANgAAAAMAAAA5QAAAAIAAADkBAAA HgAAACAAAABUZWxlQ29tbXVuaWNhdGlvbiBTeXN0ZW1zLCBJbmMuAAMAAABLAAAAAwAAABUAAAAD AAAAXykAAAMAAAAAAAwACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAEA AAAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAANwAAAADAAAAAAAAACAAAAABAAAAOAAA AAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAAlAAAAAYAAAADAAAA SQBGAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAAuAAAAaAB0AHQAcAA6AC8ALwB0AHIAYQBj AC4AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8AdwBnAC8AZQBjAHIAaQB0AC8AdAByAGEA YwAvAHcAaQBrAGkAAAAfAAAAAQAAAAAA0ggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAF AAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMA AAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAA AP7///8jAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA/v///ysAAAAsAAAALQAAAC4AAAAvAAAA MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA/v///zoAAAA7AAAAPAAAAD0AAAA+ AAAAPwAAAEAAAAD+////QgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAP7////9////SwAAAP7/ ///+/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIA eQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///////// /wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAACPTTNXuyQFNAAAAgAAAAAAAAABEAGEA dABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIA AAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKgAAAGkcAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANEIAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAAAAAEAAAAAAAAAUARABv AGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQAA AAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADA AAAAAAAARicAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgOTctMjAwMyBEb2N1bWVudAAKAAAATVNX b3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_001_01C9EED6.4C497040-- From RMarshall@telecomsys.com Tue Jun 16 16:21:00 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 D36283A6C8C for ; Tue, 16 Jun 2009 16:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=1.150, 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 2-KNyUO2x53f for ; Tue, 16 Jun 2009 16:20:49 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 0D5373A6C83 for ; Tue, 16 Jun 2009 16:20:49 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 16 Jun 2009 16:20:59 -0700 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_01C9EED9.1B33F2F2" Date: Tue, 16 Jun 2009 16:20:58 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750D1AA93C@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT (prior) interim meeting notes - for Webex Virtual Mtg. on Feb 26, 2009 thread-index: AcmYVcYdFXWUpOMGQmmfMrw0h465LhWgfL4A From: "Roger Marshall" To: "ECRIT" Subject: [Ecrit] ECRIT (prior) interim meeting notes - for Webex Virtual Mtg. on Feb 26, 2009 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, 16 Jun 2009 23:21:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EED9.1B33F2F2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9EED9.1B33F2F2" ------_=_NextPart_002_01C9EED9.1B33F2F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that I have neglected to distribute to the list, the raw meeting minutes for the prior ECRIT Interim meeting, (Feb 26, 2009 meeting date). Please find the raw minutes inline. I've also attached as a MS Word file, in case of formatting issues. <>=20 Many apologies. -roger marshall. ECRIT Secretary rmarshall@telecomsys.com *** ECRIT virtual meeting notes - via Webex Date/Time: 2/26/2009:11:00-1:00PM (Pacific, or GMT -8) Attendees: James Polk Milan Roger Richard Tony pike Cullen Gabor Guy Brian Andrea Hannes Benard Jon (missed some) Agenda: (Hannes) at link: http://trac.tools.ietf.org/wg/ecrit/trac/wiki Agenda bashing (Marc) none heard. Phonebcp & Framework drafts 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 in 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 -- Notewell does apply - needs to be added to slide deck -- Discussed Lost-sync Brian: doesn't think this will see wide use. Brian: 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. --=20 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" other civic address, for example, for routing, and follow up with a more precise location. Hannes: hopefully, Richard can apply some of the comments made here, before expiration date. 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:=20 Hannes: Would be good to document what would happen if not there - error cases Milan: yeah, good to do. -- Brian:=20 Marc: we can come back to this one. -- Andrea? -- LoST Service Boundaries - Karlheinz:=20 Comments: Hannes: Thinks its good, but see it maybe as an experimental 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 (?) --=20 Premature Disconnet - Brian=20 Have asked for this to be considered, and have been told... Seems like they (those in the IETF?) only want to solve it through UI only.=20 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?=20 Hannes/Marc: yes, not a wg item. Guy: In order to get there, we need to have rough consensus? -- 12:48 Pacific Forte 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... Andrea: Hannes: 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? What is the plan? ? Discussion around the deadline -- 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. Marc: should probably have meetings for... Brian: would agree, but not agree to having a single 2hr meeting for one document only. -- /end. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_002_01C9EED9.1B33F2F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT (prior) interim meeting notes - for Webex Virtual Mtg. on Feb = 26, 2009

= It seems that I have neglected to distribute to the list,<= SPAN LANG=3D"en-us"> the raw meeti= ng minutes for the prior ECRIT Interim<= FONT COLOR=3D"#1F497D" FACE=3D"Calibri"> meeting, (Feb 26, 2009 meeting= date).  Please find the raw minutes inline.  I= ’ve al= so attached as a MS Word file, in case of formatting issues.

<<ECRIT_Interim_Meeting_20090226.= doc>> =

= Many apologies.

= -roger marshall.

= ECRIT Secretary

= rmarshall@telecomsys.com

= ***

ECRIT virtual meeting notes - = via Webex

Date/Time: = 2/26/2009:11:00-1:00PM (Pacific, or GMT -8)


Attendees:<= /FONT>

James Polk<= /FONT>

Milan

Roger

Richard

Tony pike

Cullen

Gabor

Guy<= /SPAN>

Brian

Andrea

Hannes

Benard

Jon<= /SPAN>

(missed som= e)


Agenda: (Ha= nnes) at link: http://trac.tools.ietf.org/wg/ecrit/trac/wiki

Agenda bash= ing (Marc) none heard.

Phonebcp &a= mp; Framework drafts

Brian: Fram= ework redline update - plan to release today.  No substantive change, = but asks now if we want to discuss Stephen Edge's comments - relating to Wi= reless.

PhoneBCP al= so due out today.  Good comments from John Elwell, probably will submi= t anyway, then if we need to update w/changes, we'll do that.  At leas= t 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 ro= ute header, then default… fine.  If you did see a route header, = how would you know…(?)  Seems like a bad idea to have every Prox= y check the route header to make sure it’s a PSAP URI.<= /P>

(repeat) ph= onebcp requirement that a proxy help out a call that didn't get a LoST answ= er…  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 a= void having to force the proxy from doing the check.

John: isn't= there something already in the geolocation field as a "use for routin= g" ?

Keith: what= about the socks parameter (?)

Brian: 2 go= od comments, that we'll cosider.

Also, anoth= er point of discussion, Henry claims that you can't do a SHOULD in an INFOR= MATIONAL 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: Fram= ework will be INFORMATIONAL now.

Brian: Is t= here a document status that is BCP?  If xml2rfc has that, then I'll ch= ange it to that

--

Notewell do= es apply - needs to be added to slide deck

--

Discussed L= ost-sync

Brian: does= n't think this will see wide use.

Brian: Othe= r database sync mechanisms exist,

Brian: NENA= is looking at OGC's database layer mechanism to replicate

Hannes: may= be you could pass the OGC doc link to the list.

-- <= /SPAN>

RPH - James= Polk

Diagram - 0= 1 shows insertion of "esnet" as RPH marker

Janet: shor= t read - 7 pages w/boilerplate

Marc: any c= omments for James?

Brian: I wa= nt to make this a wg approved document.

James: Alre= ady is a wg document.

Hannes: We = had some re-scope activity… based on our earlier hope to submit frame= work document to the IESG...

Keith: Is t= his a wg doc or not?

Jon: techni= cally, 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 the= re 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: nee= d to read through the document, but basically, the diagram looks better tha= n what was there before.

James: desc= ribes any VSP that is a "trusted" entity with the ESInet.<= /SPAN>

--

Rough locat= ion - Richard Barnes

Discussed g= eo requirements

Geo - point= s out that the greater shape provided encompasses all of the more precise l= ocation possibilities.

Civic locat= ion - harder to do, since filter areas may be harder to delineate.

Roger: I th= ink it's probably impossible to have a general solution that works with civ= ic location.

Brian: civi= c does work - you can provide a "precise" other civic address, fo= r example, for routing, and follow up with a more precise location.<= /SPAN>

Hannes: hop= efully, Richard can apply some of the comments made here, before expiration= date.

Richard: ma= ybe.

--

Sos-paramet= er - Milan Patel

Presentatio= n given

Questions?&= nbsp; No response.

Hannes: Jon= & Keith, SIP expert opinion?

Keith: Have= n't worked through all of part 4 yet

Milan: Woul= dn't recognize the contact address as an emergency use case - contact

Jon:

Hannes:&nbs= p; Would be good to document what would happen if not there - error cases

Milan: yeah= , good to do.

--

Brian:

Marc: we ca= n come back to this one.

--

Andrea?

--

LoST Servic= e Boundaries - Karlheinz:

Comments:

Hannes: Thi= nks its good, but see it maybe as an experimental

Richard: I = think it’s a good, useful draft.

Roger: It's= good - another example of this could be campus security (hole) within a gr= eater metro region.

Brian: I do= n't really care - don't see any danger.

Cullen: Int= roduces hole, but probably already well down that road.

Brian: yeah= .

Hannes: we = should discuss this more on the list (?)

-- <= /SPAN>

Premature D= isconnet - Brian

Have asked = for this to be considered, and have been told…

Seems like = they (those in the IETF?) 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 h= ow to handle.

Guy: (misse= d)

Brian: Can'= t do this through UI

Cullen: Do = you think you could get consensus on that point, that you can't do it throu= gh UI?

Brian: Depe= nds on how you frame the requirement.

Hannes: may= be 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: for= getting the requirements for the moment, could we proceed then?

Keith: The = solution that mimicks the PSTN is not acceptable to me.

Guy: That i= s 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 s= o I understand, this is not yet a working group item?

Hannes/Marc= : yes, not a wg item.

Guy: In ord= er to get there, we need to have rough consensus?

--

12:48 Pacif= ic

Forte Lost = Extensions - Andrea

Define the = service URNs

Hannes: Ver= y much in favor of this - since in many cases, IANA mechanisms require too = much effort to get extensions…  we shouldn't have originally don= e this... expert review is all that's needed.  So I would be very much= in favor.

Andrea: oka= y.

Hannes: Kei= th, you had comments on the list on this?  Some proposed wording you d= idn'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 jus= t be independent.

Hannes: yea= h… will have to think about that…

Andrea:

Hannes: wil= l you be updating the document?

Andrea: yes= , will update the document, wanted here to see what the working group was t= hinking about this.

Hannes: cou= ld you or Henning trigger the discussion on this service urn update? What i= s the plan?

? Discussio= n around the deadline

--

Unauthentic= ated Access - ?

Hannes: Hen= ning couldn't participate, which is probably good since we're running out o= f time.

--

Hannes: Was= this meeting helpful?

(2 or 3 yes= responses)

James: prob= ably a good idea to have this kind of meeting 3 or 4 weeks ahead of a f2f (= for Roger) and the rest of us.

Marc: shoul= d probably have meetings for...

Brian: woul= d agree, but not agree to having a single 2hr meeting for one document only= .

--

/end.




CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

------_=_NextPart_002_01C9EED9.1B33F2F2-- ------_=_NextPart_001_01C9EED9.1B33F2F2 Content-Type: application/msword; name="ECRIT_Interim_Meeting_20090226.doc" Content-Transfer-Encoding: base64 Content-Description: ECRIT_Interim_Meeting_20090226.doc Content-Disposition: attachment; filename="ECRIT_Interim_Meeting_20090226.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAARQAAAAAAAAAA EAAARwAAAAEAAAD+////AAAAAEQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAAYAJBAAA8BK/AAAAAAAAEAAAAAAACAAAPSUAAA4AYmpianP3c/cAAAAAAAAAAAAAAAAAAAAA AAAJBBYANDgAABGdAAARnQAAPR0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAB4GAAAAAAAAHgYAAGET AAAAAAAAYRMAAAAAAABhEwAAAAAAAGETAAAAAAAAYRMAABQAAAAAAAAAAAAAAP////8AAAAAdRMA AAAAAAB1EwAAAAAAAHUTAAAAAAAAdRMAAAwAAACBEwAARAAAAHUTAAAAAAAAYxgAADABAADFEwAA FgAAANsTAAAAAAAA2xMAAAAAAADbEwAAAAAAANsTAAAAAAAAthQAAAAAAAC2FAAAAAAAALYUAAAA AAAA4hcAAAIAAADkFwAAAAAAAOQXAAAAAAAA5BcAAAAAAADkFwAAAAAAAOQXAAAAAAAA5BcAACQA AACTGQAAogIAADUcAABOAAAACBgAABUAAAAAAAAAAAAAAAAAAAAAAAAAYRMAAAAAAAC2FAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC2FAAAAAAAALYUAAAAAAAAthQAAAAAAAC2FAAAAAAAAAgYAAAAAAAA AAAAAAAAAABhEwAAAAAAAGETAAAAAAAA2xMAAAAAAAAAAAAAAAAAANsTAADbAAAAHRgAABYAAABW FwAAAAAAAFYXAAAAAAAAVhcAAAAAAAC2FAAAfgEAAGETAAAAAAAA2xMAAAAAAABhEwAAAAAAANsT AAAAAAAA4hcAAAAAAAAAAAAAAAAAAFYXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAthQAAAAAAADiFwAAAAAAAAAAAAAAAAAAVhcAAAAAAAAAAAAA AAAAAFYXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVhcAAAAAAADbEwAAAAAAAP////8AAAAAAKl6Wdfu yQEAAAAAAAAAAHUTAAAAAAAANBYAABIBAABWFwAAAAAAAAAAAAAAAAAAzhcAABQAAAAzGAAAMAAA AGMYAAAAAAAAVhcAAAAAAACDHAAAAAAAAEYXAAAQAAAAgxwAAAAAAABWFwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABW FwAAFAAAAIMcAAAAAAAAAAAAAAAAAABhEwAAAAAAAGoXAABkAAAAthQAAAAAAAC2FAAAAAAAAFYX AAAAAAAAthQAAAAAAAC2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAthQA AAAAAAC2FAAAAAAAALYUAAAAAAAACBgAAAAAAAAIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAVhcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALYUAAAA AAAAthQAAAAAAAC2FAAAAAAAAGMYAAAAAAAAthQAAAAAAAC2FAAAAAAAALYUAAAAAAAAthQAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAIMcAAAAAAAAthQAAAAAAAC2 FAAAAAAAALYUAAAAAAAAthQAAAAAAAC2FAAAAAAAALYUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2FAAAAAAAALYUAAAAAAAAthQA AAAAAAAeBgAACQwAACcSAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEVDUklU IHZpcnR1YWwgbWVldGluZyBub3RlcyAtIHZpYSBXZWJleA1EYXRlL1RpbWU6IDIvMjYvMjAwOTox MTowMC0xOjAwUE0gKFBhY2lmaWMsIG9yIEdNVCAtOCkNQ2hhaXJzOiBNYXJjIExpbnNuZXIgJiBI YW5uZXMgVHNjaG9mZW5pZw0NQXR0ZW5kZWVzOg1KYW1lcyBQb2xrDU1pbGFuDVJvZ2VyDVJpY2hh cmQNVG9ueSBwaWtlDUN1bGxlbg1HYWJvcg1HdXkNQnJpYW4NQW5kcmVhDUhhbm5lcw1CZW5hcmQN Sm9uDShtaXNzZWQgc29tZSkNDQ1BZ2VuZGE6IChIYW5uZXMpIGF0IGxpbms6IBMgSFlQRVJMSU5L ICJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9lY3JpdC90cmFjL3dpa2kiIBRodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy93Zy9lY3JpdC90cmFjL3dpa2kVDQ1BZ2VuZGEgYmFzaGluZyAo TWFyYykgbm9uZSBoZWFyZC4NDVBob25lYmNwICYgRnJhbWV3b3JrIGRyYWZ0cw0NQnJpYW46IEZy YW1ld29yayByZWRsaW5lIHVwZGF0ZSAtIHBsYW4gdG8gcmVsZWFzZSB0b2RheS4gIE5vIHN1YnN0 YW50aXZlIGNoYW5nZSwgYnV0IGFza3Mgbm93IGlmIHdlIHdhbnQgdG8gZGlzY3VzcyBTdGVwaGVu IEVkZ2UncyBjb21tZW50cyAtIHJlbGF0aW5nIHRvIFdpcmVsZXNzLg0NUGhvbmVCQ1AgYWxzbyBk dWUgb3V0IHRvZGF5LiAgR29vZCBjb21tZW50cyBmcm9tIEpvaG4gRWx3ZWxsLCBwcm9iYWJseSB3 aWxsIHN1Ym1pdCBhbnl3YXksIHRoZW4gaWYgd2UgbmVlZCB0byB1cGRhdGUgdy9jaGFuZ2VzLCB3 ZSdsbCBkbyB0aGF0LiAgQXQgbGVhc3Qgb25lIGktc3BvdCB0aGF0IG5lZWRzIHNvbWV0aGluZyBu ZXcsIG5vdCBzdXJlIHdoYXQgdG8gZG8uICBQcm9ibGVtOiBpZiBkZXZpY2UgZGlkbid0IGtub3cg aG93IHRvIGRvIExvU1QsIG1hcmsgdGhlIGNhbGwgLSBpZiB5b3UgZG9uJ3Qgc2VlIGEgcm91dGUg aGVhZGVyLCB0aGVuIGRlZmF1bHSFIGZpbmUuICBJZiB5b3UgZGlkIHNlZSBhIHJvdXRlIGhlYWRl ciwgaG93IHdvdWxkIHlvdSBrbm93hSg/KSAgU2VlbXMgbGlrZSBhIGJhZCBpZGVhIHRvIGhhdmUg ZXZlcnkgUHJveHkgY2hlY2sgdGhlIHJvdXRlIGhlYWRlciB0byBtYWtlIHN1cmUgaXSScyBhIFBT QVAgVVJJLg0NKHJlcGVhdCkgcGhvbmViY3AgcmVxdWlyZW1lbnQgdGhhdCBhIHByb3h5IGhlbHAg b3V0IGEgY2FsbCB0aGF0IGRpZG4ndCBnZXQgYSBMb1NUIGFuc3dlcoUgIGlmIExvU1QgaGFzbid0 IGJlZW4gZG9uZSwgdGhlbiB0aGUgcHJveHkgc2hvdWxkIGRvIGl0LiAgQSBnb29kIHJlcXVpcmVt ZW50LCBidXQgaG93IGRvZXMgYSBwcm94eSBlbnN1cmUgdGhhdCB0aGlzIGlzIGRvbmUgcmlnaHRs eT8NDUlkZWEgaXMgdHJ5IHRvIGhhdmUgYSBtYXJrZXIgaW4gdGhlIFNJUCBtZXNzYWdlIC0gZG9u J3Qga25vdyBob3cgdG8gZG8gdGhpcy4NDVRyeWluZyB0byBhdm9pZCBoYXZpbmcgdG8gZm9yY2Ug dGhlIHByb3h5IGZyb20gZG9pbmcgdGhlIGNoZWNrLg0NSm9objogaXNuJ3QgdGhlcmUgc29tZXRo aW5nIGFscmVhZHkgaW4gdGhlIGdlb2xvY2F0aW9uIGZpZWxkIGFzIGEgInVzZSBmb3Igcm91dGlu ZyIgPw0NS2VpdGg6IHdoYXQgYWJvdXQgdGhlIHNvY2tzIHBhcmFtZXRlciAoPykNDUJyaWFuOiAy IGdvb2QgY29tbWVudHMsIHRoYXQgd2UnbGwgY29zaWRlci4NDUFsc28sIGFub3RoZXIgcG9pbnQg b2YgZGlzY3Vzc2lvbiwgSGVucnkgY2xhaW1zIHRoYXQgeW91IGNhbid0IGRvIGEgU0hPVUxEIGlu IGFuIElORk9STUFUSU9OQUwgZG9jdW1lbnQgKGRvd25yZWYgZXhjZXB0aW9uKS4NDUpvbjogQWR2 aXNlIHdvdWxkIGJlIHRvIGNoYW5nZSB0aGUgdGV4dCwgdG8gYmUgYXMgaWYgaXQgd291bGQgbm90 IGJlIG5vcm1hdGl2ZS4gIElmIHRoZXJlIGFyZSB0aGluZ3MgdGhhdCBhcmUgbm9ybWF0aXZlIGhl cmUsIHJlcGxpY2F0ZWQgdGhlbSAoaW4gRnJhbWV3b3JrPykNDUtlaXRoOiB3aGF0J3MgdGhlIG5l dyBzdGF0dXM/DQ1CcmlhbjogRnJhbWV3b3JrIHdpbGwgYmUgSU5GT1JNQVRJT05BTCBub3cuDQ1C cmlhbjogSXMgdGhlcmUgYSBkb2N1bWVudCBzdGF0dXMgdGhhdCBpcyBCQ1A/ICBJZiB4bWwycmZj IGhhcyB0aGF0LCB0aGVuIEknbGwgY2hhbmdlIGl0IHRvIHRoYXQNDS0tDQ1Ob3Rld2VsbCBkb2Vz IGFwcGx5IC0gbmVlZHMgdG8gYmUgYWRkZWQgdG8gc2xpZGUgZGVjaw0NLS0NDURpc2N1c3NlZCBM b3N0LXN5bmMNDUJyaWFuOiBkb2Vzbid0IHRoaW5rIHRoaXMgd2lsbCBzZWUgd2lkZSB1c2UuDUJy aWFuOiBPdGhlciBkYXRhYmFzZSBzeW5jIG1lY2hhbmlzbXMgZXhpc3QsDUJyaWFuOiBORU5BIGlz IGxvb2tpbmcgYXQgT0dDJ3MgZGF0YWJhc2UgbGF5ZXIgbWVjaGFuaXNtIHRvIHJlcGxpY2F0ZQ0N SGFubmVzOiBtYXliZSB5b3UgY291bGQgcGFzcyB0aGUgT0dDIGRvYyBsaW5rIHRvIHRoZSBsaXN0 Lg0NLS0gDQ1SUEggLSBKYW1lcyBQb2xrDURpYWdyYW0gLSAwMSBzaG93cyBpbnNlcnRpb24gb2Yg ImVzbmV0IiBhcyBSUEggbWFya2VyDUphbmV0OiBzaG9ydCByZWFkIC0gNyBwYWdlcyB3L2JvaWxl cnBsYXRlDU1hcmM6IGFueSBjb21tZW50cyBmb3IgSmFtZXM/DUJyaWFuOiBJIHdhbnQgdG8gbWFr ZSB0aGlzIGEgd2cgYXBwcm92ZWQgZG9jdW1lbnQuDUphbWVzOiBBbHJlYWR5IGlzIGEgd2cgZG9j dW1lbnQuDUhhbm5lczogV2UgaGFkIHNvbWUgcmUtc2NvcGUgYWN0aXZpdHmFIGJhc2VkIG9uIG91 ciBlYXJsaWVyIGhvcGUgdG8gc3VibWl0IGZyYW1ld29yayBkb2N1bWVudCB0byB0aGUgSUVTRy4u Lg1LZWl0aDogSXMgdGhpcyBhIHdnIGRvYyBvciBub3Q/DUpvbjogdGVjaG5pY2FsbHksIGEgd2cg Y2hhaXIgaXMgZW1wb3dlcmVkIHRvIGFjY2VwdCBhbnl0aGluZyB0aGV5IHRoaW5rIHMvYiBhY2Nl cHRlZCwgYnV0IHRoZXJlIHNob3VsZCBhbHNvIGJlIGFuIHdnIGNoYXJ0ZXIgaXRlbSB0byBjb3Zl ciBpdC4gIFNvLCBiZXR3ZWVuIHR3byB2aWV3cy4NS2VpdGg6DUpvbjogSWYgdGhlcmUgaXMgYSB3 ZyBzZW5zZSB0byB3b3JrIG9uIGl0IC0gSSdtIG5vdCBnb2luZyB0byBzYXkgZG9uJ3QgZG8gaXQu DUpvbjoga2luZGEgbGlrZSB0aGUgc2FtZSB0b25lIG9mICJyZXNpZ25hdGlvbiI/DUhhbm5lczog bmVlZCB0byByZWFkIHRocm91Z2ggdGhlIGRvY3VtZW50LCBidXQgYmFzaWNhbGx5LCB0aGUgZGlh Z3JhbSBsb29rcyBiZXR0ZXIgdGhhbiB3aGF0IHdhcyB0aGVyZSBiZWZvcmUuDUphbWVzOiBkZXNj cmliZXMgYW55IFZTUCB0aGF0IGlzIGEgInRydXN0ZWQiIGVudGl0eSB3aXRoIHRoZSBFU0luZXQu DQ0tLQ0NUm91Z2ggbG9jYXRpb24gLSBSaWNoYXJkIEJhcm5lcw0NRGlzY3Vzc2VkIGdlbyByZXF1 aXJlbWVudHMNR2VvIC0gcG9pbnRzIG91dCB0aGF0IHRoZSBncmVhdGVyIHNoYXBlIHByb3ZpZGVk IGVuY29tcGFzc2VzIGFsbCBvZiB0aGUgbW9yZSBwcmVjaXNlIGxvY2F0aW9uIHBvc3NpYmlsaXRp ZXMuDUNpdmljIGxvY2F0aW9uIC0gaGFyZGVyIHRvIGRvLCBzaW5jZSBmaWx0ZXIgYXJlYXMgbWF5 IGJlIGhhcmRlciB0byBkZWxpbmVhdGUuDQ1Sb2dlcjogSSB0aGluayBpdCdzIHByb2JhYmx5IGlt cG9zc2libGUgdG8gaGF2ZSBhIGdlbmVyYWwgc29sdXRpb24gdGhhdCB3b3JrcyB3aXRoIGNpdmlj IGxvY2F0aW9uLg0NQnJpYW46IGNpdmljIGRvZXMgd29yayAtIHlvdSBjYW4gcHJvdmlkZSBhICJw cmVjaXNlIiBvdGhlciBjaXZpYyBhZGRyZXNzLCBmb3IgZXhhbXBsZSwgZm9yIHJvdXRpbmcsIGFu ZCBmb2xsb3cgdXAgd2l0aCBhIG1vcmUgcHJlY2lzZSBsb2NhdGlvbi4NDUhhbm5lczogaG9wZWZ1 bGx5LCBSaWNoYXJkIGNhbiBhcHBseSBzb21lIG9mIHRoZSBjb21tZW50cyBtYWRlIGhlcmUsIGJl Zm9yZSBleHBpcmF0aW9uIGRhdGUuDVJpY2hhcmQ6IG1heWJlLg0NLS0NDVNvcy1wYXJhbWV0ZXIg LSBNaWxhbiBQYXRlbA0NUHJlc2VudGF0aW9uIGdpdmVuDVF1ZXN0aW9ucz8gIE5vIHJlc3BvbnNl Lg1IYW5uZXM6IEpvbiAmIEtlaXRoLCBTSVAgZXhwZXJ0IG9waW5pb24/DQ1LZWl0aDogSGF2ZW4n dCB3b3JrZWQgdGhyb3VnaCBhbGwgb2YgcGFydCA0IHlldA1NaWxhbjogV291bGRuJ3QgcmVjb2du aXplIHRoZSBjb250YWN0IGFkZHJlc3MgYXMgYW4gZW1lcmdlbmN5IHVzZSBjYXNlIC0gY29udGFj dA1Kb246IA0NSGFubmVzOiAgV291bGQgYmUgZ29vZCB0byBkb2N1bWVudCB3aGF0IHdvdWxkIGhh cHBlbiBpZiBub3QgdGhlcmUgLSBlcnJvciBjYXNlcw1NaWxhbjogeWVhaCwgZ29vZCB0byBkby4N DS0tDQ1CcmlhbjogDU1hcmM6IHdlIGNhbiBjb21lIGJhY2sgdG8gdGhpcyBvbmUuDQ0tLQ0NQW5k cmVhPw0NLS0NDUxvU1QgU2VydmljZSBCb3VuZGFyaWVzIC0gS2FybGhlaW56OiANDUNvbW1lbnRz Og1IYW5uZXM6IFRoaW5rcyBpdHMgZ29vZCwgYnV0IHNlZSBpdCBtYXliZSBhcyBhbiBleHBlcmlt ZW50YWwNDVJpY2hhcmQ6IEkgdGhpbmsgaXSScyBhIGdvb2QsIHVzZWZ1bCBkcmFmdC4NUm9nZXI6 IEl0J3MgZ29vZCAtIGFub3RoZXIgZXhhbXBsZSBvZiB0aGlzIGNvdWxkIGJlIGNhbXB1cyBzZWN1 cml0eSAoaG9sZSkgd2l0aGluIGEgZ3JlYXRlciBtZXRybyByZWdpb24uDQ1CcmlhbjogSSBkb24n dCByZWFsbHkgY2FyZSAtIGRvbid0IHNlZSBhbnkgZGFuZ2VyLg1DdWxsZW46IEludHJvZHVjZXMg aG9sZSwgYnV0IHByb2JhYmx5IGFscmVhZHkgd2VsbCBkb3duIHRoYXQgcm9hZC4NQnJpYW46IHll YWguDUhhbm5lczogd2Ugc2hvdWxkIGRpc2N1c3MgdGhpcyBtb3JlIG9uIHRoZSBsaXN0ICg/KQ0N LS0gDQ1QcmVtYXR1cmUgRGlzY29ubmV0IC0gQnJpYW4gDQ1IYXZlIGFza2VkIGZvciB0aGlzIHRv IGJlIGNvbnNpZGVyZWQsIGFuZCBoYXZlIGJlZW4gdG9sZIUNU2VlbXMgbGlrZSB0aGV5ICh0aG9z ZSBpbiB0aGUgSUVURj8pIG9ubHkgd2FudCB0byBzb2x2ZSBpdCB0aHJvdWdoIFVJIG9ubHkuIA1E b24ndCBrbm93IHdoYXQgdG8gZG8gdG8gbW92ZSB0aGlzIGZvcndhcmQuDQ1IYXMgYmVlbiBhIGRp c2N1c3Npb24gb2Ygc29sdXRpb24gcGF0aHMNDUtlaXRoOiBEaWQgeW91IGdldCBteSBjb21tZW50 cz8NQnJpYW46IFdpbGwgaGF2ZSB0byBnbyBiYWNrIGFuZCBsb29rIC0gSSBrbm93IHNvbWUgd2Vy ZSBhZGRyZXNzYWJsZSwgc29tZSBkb24ndCBrbm93IGhvdyB0byBoYW5kbGUuDQ1HdXk6IChtaXNz ZWQpDQ1CcmlhbjogQ2FuJ3QgZG8gdGhpcyB0aHJvdWdoIFVJDUN1bGxlbjogRG8geW91IHRoaW5r IHlvdSBjb3VsZCBnZXQgY29uc2Vuc3VzIG9uIHRoYXQgcG9pbnQsIHRoYXQgeW91IGNhbid0IGRv IGl0IHRocm91Z2ggVUk/DUJyaWFuOiBEZXBlbmRzIG9uIGhvdyB5b3UgZnJhbWUgdGhlIHJlcXVp cmVtZW50Lg0NSGFubmVzOiBtYXliZSBJIHNob3VsZCB0cnkgdG8gc2V0IHVwIGEgY29uZmVyZW5j ZSBjYWxsLCB0byBpbmNsdWRlIHNldmVyYWwgb2YgeW91IHdobyBoYXZlIGNvbW1lbnRzIG9yIGlu dGVyZXN0Lg1LZWl0aDogSSd2ZSBtYWRlIHNvbWUgZGV0YWlsZWQgY29tbWVudHMgLSBuZWVkIHRv IGhhdmUgdGhlIHJlcXVpcmVtZW50cyBpbiBmcm9udCBvZiBtZS4NDUhhbm5lczogZm9yZ2V0dGlu ZyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgbW9tZW50LCBjb3VsZCB3ZSBwcm9jZWVkIHRoZW4/ DUtlaXRoOiBUaGUgc29sdXRpb24gdGhhdCBtaW1pY2tzIHRoZSBQU1ROIGlzIG5vdCBhY2NlcHRh YmxlIHRvIG1lLg0NR3V5OiBUaGF0IGlzIG5vdCB3aGF0IHdlJ3JlIGFza2luZyBmb3IuDUhhbm5l cyAmIE1hcmMgdG8gcHV0IHRvZ2V0aGVyIGEgbWVldGluZyB0byBkaXNjdXNzLiAgU2hvdWxkIGlu Y2x1ZGU6IEhlbm5pbmcsIFRlZCwgS2VpdGgsIFJhbmR5LCBHdXksIEJyaWFuLg1HdXk6IEp1c3Qg c28gSSB1bmRlcnN0YW5kLCB0aGlzIGlzIG5vdCB5ZXQgYSB3b3JraW5nIGdyb3VwIGl0ZW0/IA1I YW5uZXMvTWFyYzogeWVzLCBub3QgYSB3ZyBpdGVtLg1HdXk6IEluIG9yZGVyIHRvIGdldCB0aGVy ZSwgd2UgbmVlZCB0byBoYXZlIHJvdWdoIGNvbnNlbnN1cz8NDS0tDQ0xMjo0OCBQYWNpZmljDQ1G b3J0ZSBMb3N0IEV4dGVuc2lvbnMgLSBBbmRyZWENDURlZmluZSB0aGUgc2VydmljZSBVUk5zDUhh bm5lczogVmVyeSBtdWNoIGluIGZhdm9yIG9mIHRoaXMgLSBzaW5jZSBpbiBtYW55IGNhc2VzLCBJ QU5BIG1lY2hhbmlzbXMgcmVxdWlyZSB0b28gbXVjaCBlZmZvcnQgdG8gZ2V0IGV4dGVuc2lvbnOF ICB3ZSBzaG91bGRuJ3QgaGF2ZSBvcmlnaW5hbGx5IGRvbmUgdGhpcy4uLiBleHBlcnQgcmV2aWV3 IGlzIGFsbCB0aGF0J3MgbmVlZGVkLiAgU28gSSB3b3VsZCBiZSB2ZXJ5IG11Y2ggaW4gZmF2b3Iu DUFuZHJlYTogb2theS4NSGFubmVzOiBLZWl0aCwgeW91IGhhZCBjb21tZW50cyBvbiB0aGUgbGlz dCBvbiB0aGlzPyAgU29tZSBwcm9wb3NlZCB3b3JkaW5nIHlvdSBkaWRuJ3QgbGlrZT8NS2VpdGg6 IHRoZSBxdWVzdGlvboU/DUhhbm5lczogQXJlIHlvdSBpbiBmYXZvciBvZiBjaGFuZ2luZyBJQU5B IHJlZ2lzdHJhdGlvbiB0byBleHBlcnQgcmV2aWV3IGluc3RlYWQuDUtlaXRoOiBNYXkgaGF2ZSB0 aG91Z2h0cyByZWdhcmRpbmcgdGhlIGhpZXJhY2hpY2FsIHN0cnVjdHVyZYUgbmVlZCB0byBzZWUg YWN0dWFsIHdvcmRzLCBhcmUgdGhleSBpbiB0aGUgZHJhZnQ/DUtlaXRoOiBuZWVkIHRvIHNheSB3 aGF0IHRoZSBydWxlcyBhcmUgd2hlbiB3ZSd2ZSBnb3Qgc29tZSBraW5kIG9mIGhpZXJhcmNoeSwg Y2FuJ3QganVzdCBiZSBpbmRlcGVuZGVudC4NSGFubmVzOiB5ZWFohSB3aWxsIGhhdmUgdG8gdGhp bmsgYWJvdXQgdGhhdIUNQW5kcmVhOg1IYW5uZXM6IHdpbGwgeW91IGJlIHVwZGF0aW5nIHRoZSBk b2N1bWVudD8NQW5kcmVhOiB5ZXMsIHdpbGwgdXBkYXRlIHRoZSBkb2N1bWVudCwgd2FudGVkIGhl cmUgdG8gc2VlIHdoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2FzIHRoaW5raW5nIGFib3V0IHRoaXMu DUhhbm5lczogY291bGQgeW91IG9yIEhlbm5pbmcgdHJpZ2dlciB0aGUgZGlzY3Vzc2lvbiBvbiB0 aGlzIHNlcnZpY2UgdXJuIHVwZGF0ZT8gV2hhdCBpcyB0aGUgcGxhbj8NDT8gRGlzY3Vzc2lvbiBh cm91bmQgdGhlIGRlYWRsaW5lDQ0tLQ0NVW5hdXRoZW50aWNhdGVkIEFjY2VzcyAtID8NSGFubmVz OiBIZW5uaW5nIGNvdWxkbid0IHBhcnRpY2lwYXRlLCB3aGljaCBpcyBwcm9iYWJseSBnb29kIHNp bmNlIHdlJ3JlIHJ1bm5pbmcgb3V0IG9mIHRpbWUuDQ0tLQ0NSGFubmVzOiBXYXMgdGhpcyBtZWV0 aW5nIGhlbHBmdWw/DQ0oMiBvciAzIHllcyByZXNwb25zZXMpDUphbWVzOiBwcm9iYWJseSBhIGdv b2QgaWRlYSB0byBoYXZlIHRoaXMga2luZCBvZiBtZWV0aW5nIDMgb3IgNCB3ZWVrcyBhaGVhZCBv ZiBhIGYyZiAoZm9yIFJvZ2VyKSBhbmQgdGhlIHJlc3Qgb2YgdXMuDQ1NYXJjOiBzaG91bGQgcHJv YmFibHkgaGF2ZSBtZWV0aW5ncyBmb3IuLi4NQnJpYW46IHdvdWxkIGFncmVlLCBidXQgbm90IGFn cmVlIHRvIGhhdmluZyBhIHNpbmdsZSAyaHIgbWVldGluZyBmb3Igb25lIGRvY3VtZW50IG9ubHku DQ0tLQ0NL2VuZC4NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAABfCAAAiAgAABcJAAAYCQAA UwkAAFQJAACBCQAAggkAADwlAAA9JQAA8u7y3PLczNzyyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmgrOn4AAB4WaIcZHgAwSg8A Q0oUAE9KAgBRSgIAXkoCAGFKFAAAIwNqAAAAABZohxkeAENKFABPSgIAUUoCAFUIAV5KAgBhShQA BhZohxkeAAAaFmiHGR4AQ0oUAE9KAgBRSgIAXkoCAGFKFAAKAAgAACgIAABfCAAAiAgAAIkIAACU CAAAnwgAAKUIAACrCAAAswgAAL0IAADECAAAyggAAM4IAADUCAAA2wgAAOIIAADpCAAA7QgAAPsI AAD8CAAA/QgAAIMJAACECQAApgkAAKcJAADDCQAAxAkAAGgKAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPEAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAAAAAABAAAZ2SHGR4ACQAANyQAOCQASCQAZ2SHGR4AABxoCgAAaQoAAEgMAABJDAAAJw0AACgN AAB1DQAAdg0AALYNAAC3DQAADQ4AAA4OAAA4DgAAOQ4AAGUOAABmDgAA4w4AAOQOAACCDwAAgw8A AKEPAACiDwAAzg8AAM8PAAAwEAAAMRAAADQQAAA1EAAAaxAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA APYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAJAAA3JAA4JABIJABnZIcZHgAAHGsQAABsEAAAbxAAAHAQAACEEAAAhRAA ALIQAADfEAAAJREAACYRAABhEQAAYhEAAGYRAABnEQAAeBEAAK4RAADYEQAA9hEAACkSAABKEgAA txIAANcSAAB+EwAAhRMAANMTAAADFAAAchQAALcUAAC4FAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAkAADckADgkAEgkAGdkhxkeAAAcuBQAALsUAAC8FAAA3BQAAN0UAAD4FAAA ZRUAALMVAAC0FQAAFxYAABgWAACoFgAAqRYAAAYXAAAWFwAAFxcAABoXAAAbFwAANxcAADgXAABL FwAAZBcAAI0XAACOFwAAvhcAAA8YAAAVGAAAFhgAAGYYAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAANyQAOCQASCQAZ2SHGR4AABxmGAAAfxgAAIAYAACDGAAAhBgAAIwYAACw GAAAsRgAALQYAAC1GAAAvRgAAL4YAADBGAAAwhgAAOgYAADpGAAA8xgAADAZAAAxGQAAXRkAAMcZ AADIGQAA+xkAAD4aAABLGgAAfxoAAIAaAACEGgAAhRoAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA APYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAJAAA3JAA4JABIJABnZIcZHgAAHIUaAACiGgAAoxoAAN0aAAAqGwAAVhsAAFcb AAB/GwAAgBsAAKAbAAAEHAAABRwAABMcAAAUHAAANBwAAJEcAADCHAAAwxwAADQdAACMHQAAjR0A ANgdAAAbHgAAHB4AAEQeAACxHgAA8x4AABQfAABRHwAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAkAADckADgkAEgkAGdkhxkeAAAcUR8AAFIfAABVHwAAVh8AAGQfAABlHwAAhB8A AIUfAACdHwAAhCAAAJIgAADvIAAABSEAAFYhAADFIQAALSIAAFoiAABiIgAAjSIAAPciAABZIwAA WiMAAHsjAAB8IwAAfyMAAIAjAACbIwAA+SMAAPojAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA APYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACQAANyQAOCQASCQAZ2SHGR4AABz6IwAA/SMAAP4jAAAgJAAAISQAADgkAACtJAAA riQAANkkAAAxJQAAMiUAADUlAAA2JQAAPCUAAD0lAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA APYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAJAAA3JAA4JABIJABnZIcZHgAADjIAMZBoATpwxwrQAB+w0C8gsOA9IbCgBSKwoAUj kKAFJJCgBSWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGoEEQASAAEACwEPAAcAAwADAAMAAAAEAAgAAACYAAAAngAAAJ4A AACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA+AgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAAqAAAADYGAAA2BgAAFgAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAuAAA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAGgBAABIAQAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACwAwAANgYAADIGAAAYAAAAwAMAANADAADg AwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOAD AADwAwAAAAQAABAEAAAyBgAAKAIAANgBAADoAQAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQA AJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAA kAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQ BAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAE AADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQA AMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAA OAEAAFgBAAD4AQAACAIAABgCAABWAgAAfgIAACAAAABPSgMAUEoDAFFKAwBfSAEEbUgJBG5ICQRz SAkEdEgJBAAAAABKAABg8f8CAEoADBAAAMcK0AAAAAYATgBvAHIAbQBhAGwAAAAMAAAAEmQUAQEA FKTIABgAQ0oWAF9IAQRhShYAbUgJBHNICQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAARABBYPL/oQBE AAwNAAAAAAAAEAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQA AAAAAFIAaQDz/7MAUgAMHQAAAAAAADAGDABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YD AAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACgAayD0/8EAKAAADQAAAAAAADAGBwBOAG8A IABMAGkAcwB0AAAAAgAMAAAAAABCAFVAogDxAEIADAkAACs6fgAwBgkASAB5AHAAZQByAGwAaQBu AGsAAAAYAD4qAU9KAABRSgAAXkoAAG8oAHBoAAD/AEYAVgCiAAEBRgAMDQAAhxkeADAGEQBGAG8A bABsAG8AdwBlAGQASAB5AHAAZQByAGwAaQBuAGsAAAAMAD4qAUIqB3BogACAAFBLAwQUAAYACAAA ACEAgoq8E/oAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF/oPQtthyuiil 2M6iSXd9LNIPGOSxLWqPhDQJyd937LhQuggtdCMQYs6Ze1Wuj+OgDhiT81TpVV5ohWR946ir9Pvu KbvXKjFQA4MnrPQJk17X11fl7hQwKZmmVOmeOTwYk2yPI6TcByR5aX0cgeUaOxPAfkCH5rYo7oz1 xEic8cTQdfkqC0TXoHqDyC8wisewoPD7+QwkgJgLWKvHM2FaotIQwuAssEQwB2p+6DPfts5i4+1+ FGk+gxfYzQQzv1xg9T/qL+cGW9gPrLZH6eJcf8Qh/S3bUmsuk3P+1LuQLhgul7e0Yea/rT8BAAD/ /wMAUEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89qwzAMh++FvYPR fVHSwxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcgFpqqBsPiQz/LaOF2 Pb9/gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk0ckQ0kpF2zRiJH+nkXFf 1x+YnhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGoL+NTvZCoZarUHtC1uPnW /QEAAP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0aGVtZS90aGVtZS90aGVtZU1h bmFnZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpBx6DSn9vX5eODN87fFNWbSw1Z LJwHDYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9I9WQha213SDWtSvVIe8s3V65 JGo9i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABYAAAB0 aGVtZS90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQ okDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fu xwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uU SteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+J knrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+ 2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1 XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI 0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4 JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITl VS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDG RKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8R eBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcY ThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6 ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQ sSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67 T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7 WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgN aZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2H Jl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOt UBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDY qfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZ Fh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzL TTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKu JkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG /zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat 4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBO xp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2 glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqS bTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGp wbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsD BBQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2Vy LnhtbC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5ed yRNjMt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU +YCuOKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLG zOAjm6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEAgoq8E/oAAAAcAgAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAAL AAAAAAAAAAAAAAAAACsBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAc AAAAAAAAAAAAAAAAABQCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgA AAAhAJa1reKWBgAAUBsAABYAAAAAAAAAAAAAAAAA0QIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQ SwECLQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAACbCQAAdGhlbWUvdGhlbWUv X3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAAJYKAAAAADw/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1h cCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIw MDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9 ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFj Y2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIg Zm9sSGxpbms9ImZvbEhsaW5rIi8+AAAAAD0dAAAMAAA4AAAAAP////8ACAAAPSUAABMAAAAACAAA aAoAAGsQAAC4FAAAZhgAAIUaAABRHwAA+iMAAD0lAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAa AAAAGwAAABcBAABTAQAAgQEAAD0dAAATWBT/FYwPAADwOAAAAAAABvAYAAAAAggAAAIAAAABAAAA AQAAAAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAA AQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAF AAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkA AAA/AwEAAQAAABHwBAAAAAEAAAAAAAAAIgAAACcAAADiAAAA6AAAAKcBAACvAQAAaQIAAHECAACf AgAApQIAAAYDAAAHAwAAZgMAAGoDAABSBAAAWgQAAJYEAACaBAAApwQAAKsEAADiBQAA7QUAAFwG AABjBgAAzwYAANYGAAA1CAAAPQgAAJkJAACeCQAAEwoAABUKAAA9CgAAPwoAAMgKAADKCgAA6woA AO0KAABJCwAASwsAAJgLAACaCwAA2AsAAN0LAACvDAAAtQwAABsPAAAeDwAAwhAAAMYQAADcEAAA 5RAAAAIRAAAFEQAAjxIAAJgSAADxFQAA+BUAAAsXAAANFwAAfRkAAIgZAAA/HQAABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAB0ABwAcAAcAHAAHABwABwAc AAcAAAAAAIgAAACJAAAA7gAAAPQAAABpAgAAhQIAAPkCAAA7AwAAZgMAAGoDAADjAwAA5QMAAEoE AABQBAAAdgUAALUFAAAJBgAADAYAAOkGAADvBgAANQcAAIEHAABGCwAASAsAAGcLAAB9CwAAZQ0A ALINAABLDwAAVQ8AAN0SAAAoEwAA2BMAAOQTAABEFgAAdxYAAHkWAACwFgAAEBgAABUYAACAGwAA mhsAAP4cAAAEHQAAPx0AAAcABAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAAAAAA8HQAA Px0AAAQAAwABAPdNZhsAAAAAAAAAAAABAgACABMAAAAEAAAACAAAAOUAAAAAAAAAEAAAAA54EgCH GR4AQRYoAPIoQACkNkgAKzp+AFtXfgD7X38AuEKNAFtttQASb7cAlhC5AAZFvwCxacAA6kzMAMcK 0AB+fd4AhjPpAIg59AAAAAAAPR0AAD8dAAAAAAAAAQAAAP9AA4ABAIgAAACIAAAAALiCAwEAAACI AAAAAAAAAIgAAAAAAAAAAhAAAAAAAAAAPR0AAGAAABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBu AP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAUAAABHHpAB AAACAgYDBQQFAgMEhyoAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABS AG8AbQBhAG4AAAA1HpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0A YgBvAGwAAAAzLpABAAACCwYEAgICAgIEhyoAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBs AAAANy6QAQAAAg8FAgICBAMCBO8CAKB7IABAAAAAAAAAAACfAAAAAAAAAEMAYQBsAGkAYgByAGkA AABBHpABAAACBAUDBQQGAwIE7wIAoOsgAEIAAAAAAAAAAJ8AAAAAAAAAQwBhAG0AYgByAGkAYQAg AE0AYQB0AGgAAAAiAAQAcQiIGADw0ALkBGgBAAAAAAiE1kYIhNZGAAAAAAIAAQAAAF0EAADgGAAA CAAOAAAABAADkDUAAABdBAAA4BgAAAgADgAAADUAAAAAAAAAcQMA8BAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAoAWgBbQAtACBgTIwAAAAAAAAAAAAAAAAAAAvHQAALx0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAA AAAAMoNRAPAQAAgA/P0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEhQAAAAAAnw/w8BCCRQAADk BAAA////f////3////9/////f////3////9/////fys6fgAABAAAMgAAAAAAAAAAAAAAAAAAAAAA AAAAACEEAAAAAAAAAAAAAAAAAAAAAAAAEBwAAAQAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUA AP//EgAAAAAAAAAAAAAAAAAAAAkAcgBtAGEAcgBzAGgAYQBsAGwACQByAG0AYQByAHMAaABhAGwA bAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHQBAAAR AAAAAQAAAJAAAAACAAAAmAAAAAMAAACkAAAABAAAALAAAAAFAAAAxAAAAAYAAADQAAAABwAAANwA AAAIAAAA8AAAAAkAAAAEAQAAEgAAABABAAAKAAAAMAEAAAwAAAA8AQAADQAAAEgBAAAOAAAAVAEA AA8AAABcAQAAEAAAAGQBAAATAAAAbAEAAAIAAADkBAAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAA HgAAAAwAAABybWFyc2hhbGwAAAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAADAAAAE5vcm1h bC5kb3RtAB4AAAAMAAAAcm1hcnNoYWxsAAAAHgAAAAQAAAAyAAAAHgAAABgAAABNaWNyb3NvZnQg T2ZmaWNlIFdvcmQAAABAAAAAAEbDIwAAAABAAAAAAEj5StfuyQFAAAAAAEj5StfuyQEDAAAACAAA AAMAAABdBAAAAwAAAOAYAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAA BQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAAr LPmuSAEAAAQBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcA AACwAAAACwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwAAADlAAAAAgAA AOQEAAAeAAAAIAAAAFRlbGVDb21tdW5pY2F0aW9uIFN5c3RlbXMsIEluYy4AAwAAADUAAAADAAAA DgAAAAMAAAAvHQAAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAB AAAAAQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAA3AAAAAMAAAAAAAAAIAAAAAEA AAA4AAAAAgAAAEAAAAABAAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEAAACUAAAABgAA AAMAAABJAEYAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAAAC4AAABoAHQAdABwADoALwAvAHQA cgBhAGMALgB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcALwB3AGcALwBlAGMAcgBpAHQALwB0 AHIAYQBjAC8AdwBpAGsAaQAAAB8AAAABAAAAAAB/CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAAS AAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAP7///8eAAAAHwAAACAA AAAhAAAAIgAAACMAAAAkAAAA/v///yYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAA AC8AAAAwAAAAMQAAADIAAAAzAAAA/v///zUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAD+//// PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAP7////9////RgAAAP7////+/////v////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////9SAG8AbwB0ACAARQBu AHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAADw1IFZ1+7JAUgAAACAAAAAAAAA AEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAHQAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAlAAAAgxwAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0OAAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAAAAQAAAAAAAA BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA8AAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIA AAAAAMAAAAAAAABGJwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCA5Ny0yMDAzIERvY3VtZW50AAoA AABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_001_01C9EED9.1B33F2F2-- From Martin.Thomson@andrew.com Mon Jun 22 18:01:36 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 CBBD43A6B05 for ; Mon, 22 Jun 2009 18:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 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 hhewWq6lMioC for ; Mon, 22 Jun 2009 18:01:36 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 01B0A3A687C for ; Mon, 22 Jun 2009 18:01:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_22_20_23_41 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, 22 Jun 2009 20:23:41 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 20:01:51 -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: Mon, 22 Jun 2009 20:01:49 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Direction of holes draft Thread-Index: AcnznjBhT/1RasU6TL6m/Y3jjLSIDw== From: "Thomson, Martin" To: "ECRIT" X-OriginalArrivalTime: 23 Jun 2009 01:01:51.0623 (UTC) FILETIME=[316AB970:01C9F39E] Subject: [Ecrit] Direction of holes 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, 23 Jun 2009 01:01:36 -0000 Q3VsbGVuIHJhaXNlZCBzb21lIGNvbmNlcm5zIGFib3V0IHRoZSBhZGRpdGlvbmFsIGZlYXR1cmUg dGhhdCB0aGlzIGRvY3VtZW50IHJlcXVpcmVzLiAgSGUgc3VnZ2VzdGVkIHRoYXQgYW4gYWx0ZXJu YXRpdmUgd291bGQgbm90IHJlcXVpcmUgc3VwcG9ydCBvZiBpbnRlcmlvciBwb2x5Z29ucywgb3Ig aG9sZXMuDQoNCkknZCBsaWtlIHRvIGNvbmZpcm0gdGhhdCB0aGUgV0cgaXMgT0sgd2l0aCB0YWtp bmcgdGhlIGRvY3VtZW50IGFzIGlzLCB3aXRob3V0IG1ha2luZyB0aGlzIHByb3Bvc2VkIGNoYW5n ZS4NCg0KVGhhbmtzLA0KTWFydGluDQoNCkJlbG93IGlzIGEgc3VtbWFyeSBvZiBvdXIgZGlzY3Vz c2lvbjoNCi0tDQpUaGUgYWx0ZXJuYXRpdmUgZG9lcyBub3QgdXNlIHRoZSA8aW50ZXJpb3I+IGVs ZW1lbnQgb2YgdGhlIHBvbHlnb24gdG8gY3JlYXRlIGhvbGVzLiAgSW5zdGVhZCwgcG9seWdvbnMg YXJlIHNsaWNlZCBpbnRvIHR3byBvciBtb3JlIHNlY3Rpb25zIHNvIHRoYXQgdGhlIOKAnGhvbGVz 4oCdIGJlY2FtZSBleHRlcm5hbCB0byBlYWNoIHNlY3Rpb24uICBFYWNoIHNlY3Rpb24gaXMgY3Jl YXRlZCBhcyBhIHNlcGFyYXRlIG1hcHBpbmcuDQoNCldlIGNvbmNsdWRlZCB0aGF0IHRoZSBhbHRl cm5hdGl2ZSBzb2x1dGlvbiBwcm9wb3NlZCBpcyB2aWFibGUsIGJ1dCB0aGUgZXhpc3RpbmcgbWV0 aG9kIGlzIGJlc3Qgd2hlbiBjb25zaWRlcmluZyB0aGUgZGVwbG95bWVudCBpbXBsaWNhdGlvbnMu DQoNCkFsdGVybmF0aXZlIHByb3M6DQoNCk5vIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHJlcXVpcmVk IGJ5IHRoZSBwcm90b2NvbC4NCk5vIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHJlcXVpcmVkIGJ5IExv U1QgaW1wbGVtZW50YXRpb25zLg0KDQpBbHRlcm5hdGl2ZSBjb25zOg0KDQpUaGlzIGlzbuKAmXQg aG93IHBlb3BsZSB0aGluayBhYm91dCB0aGUgcHJvYmxlbS4NClJlZ2lvbnMgd2l0aCBob2xlcyB3 b3VsZCBuZWVkIHRvIGJlIGRpdmlkZWQgdXAgYnkgYSBwcm92aXNpb25pbmcgc3lzdGVtIGludG8g bXVsdGlwbGUgcmVnaW9ucyB3aXRoIHNlcGFyYXRlIG1hcHBpbmdzLg0KVGhpcyBsaWtlbHkgcmVx dWlyZXMgY2hhbmdlcyB0byB0aGUgcHJvdmlzaW9uaW5nIGFuZCBHSVMgc3lzdGVtcyB0aGF0IGZl ZWQgTG9TVCwgdGhlc2Ugc3lzdGVtcyBhbHJlYWR5IGV4aXN0IGFuZCB0aGVyZWZvcmUgdGhlIGNv c3QgaXMgaGlnaGVyIChhdCBsZWFzdCB3ZSBrbm93IHRoYXQgTG9TVCBpbXBsZW1lbnRhdGlvbnMg YmFyZWx5IGV4aXN0KS4NClRoZSBleGlzdGluZyBzb2x1dGlvbiBpcyBhbHJlYWR5IGRvY3VtZW50 ZWQgYW5kIGFncmVlZC4NCg0KLS0NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5 IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBw cml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmln aW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQu DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= From MBerryman@911.org Mon Jun 22 18:09:07 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 3DCF83A6E0A for ; Mon, 22 Jun 2009 18:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 mjlLQVemiIrh for ; Mon, 22 Jun 2009 18:09:06 -0700 (PDT) Received: from mail1.911.org (mail1.911.org [65.67.130.186]) by core3.amsl.com (Postfix) with ESMTP id 3BC183A6E15 for ; Mon, 22 Jun 2009 18:08:56 -0700 (PDT) Received: from ghcmail [65.67.130.172] by mail1.911.org - SurfControl E-mail Filter (5.5.0); Mon, 22 Jun 2009 20:09:02 -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: Mon, 22 Jun 2009 20:09:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Direction of holes draft Thread-Index: AcnznjBhT/1RasU6TL6m/Y3jjLSIDwAAQbuV From: "Marc Berryman" To: , X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-Processed: 5_5_0_191__2009_06_22_20_09_02 Subject: Re: [Ecrit] Direction of holes 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, 23 Jun 2009 01:09:07 -0000 VW5mb3J0dW5hdGVseSBpbiB0aGUgcmVhbCB3b3JsZCB0aGVyZSBhcmUgaG9sZXMgYW5kIGludGVy aW9yIHBvbHlnb24gaW4gbWFueSBwbGFjZXMgYW5kIHRoaXMgZmVhdHVyZSBuZWVkcyB0byByZW1h aW4gaW4gdGhlIGRvY3VtZW50IGFzIHByb3Zpc2lvbmluZyBhcyBkaXNjdXNzZWQgaW4gYSBuaWdo dG1hcmUgZm9yIEdJUyB1c2VycyBhbmQgKGl0IGlzIHRydWUpIG5vdCB0aGUgd2F5IG1vc3QgdGhp bmsgb2YgdGhlIGlzc3VlLg0KDQpUaGFua3MsDQpNYXJjIEIuDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgPGVjcml0LWJvdW5jZXNA aWV0Zi5vcmc+DQpUbzogRUNSSVQgPGVjcml0QGlldGYub3JnPg0KU2VudDogTW9uIEp1biAyMiAy MDowMTo0OSAyMDA5DQpTdWJqZWN0OiBbRWNyaXRdIERpcmVjdGlvbiBvZiBob2xlcyBkcmFmdA0K DQpDdWxsZW4gcmFpc2VkIHNvbWUgY29uY2VybnMgYWJvdXQgdGhlIGFkZGl0aW9uYWwgZmVhdHVy ZSB0aGF0IHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMuICBIZSBzdWdnZXN0ZWQgdGhhdCBhbiBhbHRl cm5hdGl2ZSB3b3VsZCBub3QgcmVxdWlyZSBzdXBwb3J0IG9mIGludGVyaW9yIHBvbHlnb25zLCBv ciBob2xlcy4NCg0KSSdkIGxpa2UgdG8gY29uZmlybSB0aGF0IHRoZSBXRyBpcyBPSyB3aXRoIHRh a2luZyB0aGUgZG9jdW1lbnQgYXMgaXMsIHdpdGhvdXQgbWFraW5nIHRoaXMgcHJvcG9zZWQgY2hh bmdlLg0KDQpUaGFua3MsDQpNYXJ0aW4NCg0KQmVsb3cgaXMgYSBzdW1tYXJ5IG9mIG91ciBkaXNj dXNzaW9uOg0KLS0NClRoZSBhbHRlcm5hdGl2ZSBkb2VzIG5vdCB1c2UgdGhlIDxpbnRlcmlvcj4g ZWxlbWVudCBvZiB0aGUgcG9seWdvbiB0byBjcmVhdGUgaG9sZXMuICBJbnN0ZWFkLCBwb2x5Z29u cyBhcmUgc2xpY2VkIGludG8gdHdvIG9yIG1vcmUgc2VjdGlvbnMgc28gdGhhdCB0aGUg4oCcaG9s ZXPigJ0gYmVjYW1lIGV4dGVybmFsIHRvIGVhY2ggc2VjdGlvbi4gIEVhY2ggc2VjdGlvbiBpcyBj cmVhdGVkIGFzIGEgc2VwYXJhdGUgbWFwcGluZy4NCg0KV2UgY29uY2x1ZGVkIHRoYXQgdGhlIGFs dGVybmF0aXZlIHNvbHV0aW9uIHByb3Bvc2VkIGlzIHZpYWJsZSwgYnV0IHRoZSBleGlzdGluZyBt ZXRob2QgaXMgYmVzdCB3aGVuIGNvbnNpZGVyaW5nIHRoZSBkZXBsb3ltZW50IGltcGxpY2F0aW9u cy4NCg0KQWx0ZXJuYXRpdmUgcHJvczoNCg0KTm8gYWRkaXRpb25hbCBmdW5jdGlvbnMgcmVxdWly ZWQgYnkgdGhlIHByb3RvY29sLg0KTm8gYWRkaXRpb25hbCBmdW5jdGlvbnMgcmVxdWlyZWQgYnkg TG9TVCBpbXBsZW1lbnRhdGlvbnMuDQoNCkFsdGVybmF0aXZlIGNvbnM6DQoNClRoaXMgaXNu4oCZ dCBob3cgcGVvcGxlIHRoaW5rIGFib3V0IHRoZSBwcm9ibGVtLg0KUmVnaW9ucyB3aXRoIGhvbGVz IHdvdWxkIG5lZWQgdG8gYmUgZGl2aWRlZCB1cCBieSBhIHByb3Zpc2lvbmluZyBzeXN0ZW0gaW50 byBtdWx0aXBsZSByZWdpb25zIHdpdGggc2VwYXJhdGUgbWFwcGluZ3MuDQpUaGlzIGxpa2VseSBy ZXF1aXJlcyBjaGFuZ2VzIHRvIHRoZSBwcm92aXNpb25pbmcgYW5kIEdJUyBzeXN0ZW1zIHRoYXQg ZmVlZCBMb1NULCB0aGVzZSBzeXN0ZW1zIGFscmVhZHkgZXhpc3QgYW5kIHRoZXJlZm9yZSB0aGUg Y29zdCBpcyBoaWdoZXIgKGF0IGxlYXN0IHdlIGtub3cgdGhhdCBMb1NUIGltcGxlbWVudGF0aW9u cyBiYXJlbHkgZXhpc3QpLg0KVGhlIGV4aXN0aW5nIHNvbHV0aW9uIGlzIGFscmVhZHkgZG9jdW1l bnRlZCBhbmQgYWdyZWVkLg0KDQotLQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9u bHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl IHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9y aWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRl ZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5n IGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Vjcml0DQo= From Martin.Thomson@andrew.com Mon Jun 22 18:46:39 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 58F2C3A6B89 for ; Mon, 22 Jun 2009 18:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 pTmGKaqtF7JK for ; Mon, 22 Jun 2009 18:46:38 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 511323A6AB3 for ; Mon, 22 Jun 2009 18:46:38 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_22_20_52_56 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, 22 Jun 2009 20:52:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 20:31:06 -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: Mon, 22 Jun 2009 20:31:04 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Direction of holes draft Thread-Index: AcnznjBhT/1RasU6TL6m/Y3jjLSIDwAAQbuVAAC4b8A= References: From: "Thomson, Martin" To: "Marc Berryman" , X-OriginalArrivalTime: 23 Jun 2009 01:31:06.0344 (UTC) FILETIME=[474FE680:01C9F3A2] Subject: Re: [Ecrit] Direction of holes 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, 23 Jun 2009 01:46:39 -0000 VGhhbmtzIE1hcmMsDQoNClRoaXMgd2FzIGEgbWFqb3IgcG9pbnQgaW4gZmF2b3VyIG9mIGtlZXBp bmcgdGhlIGRyYWZ0IGFzIGl0IGlzOiB3ZSB3YW50IHRvIHRyeSB0byBtaW5pbWl6ZSB0aGUgaW1w YWN0IG9uIGV4aXN0aW5nIEdJUyBzeXN0ZW1zLiAgVGhleSB1c2UgaG9sZXM7IHRoZXJlZm9yZSwg d2UgbmVlZCB0byB1c2UgaG9sZXMgdG9vLg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmMgQmVycnltYW4gW21haWx0bzpNQmVycnltYW5AOTEx Lm9yZ10NCj4gU2VudDogVHVlc2RheSwgMjMgSnVuZSAyMDA5IDExOjA5IEFNDQo+IFRvOiBUaG9t c29uLCBNYXJ0aW47IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIERpcmVj dGlvbiBvZiBob2xlcyBkcmFmdA0KPiANCj4gVW5mb3J0dW5hdGVseSBpbiB0aGUgcmVhbCB3b3Js ZCB0aGVyZSBhcmUgaG9sZXMgYW5kIGludGVyaW9yIHBvbHlnb24gaW4NCj4gbWFueSBwbGFjZXMg YW5kIHRoaXMgZmVhdHVyZSBuZWVkcyB0byByZW1haW4gaW4gdGhlIGRvY3VtZW50IGFzDQo+IHBy b3Zpc2lvbmluZyBhcyBkaXNjdXNzZWQgaW4gYSBuaWdodG1hcmUgZm9yIEdJUyB1c2VycyBhbmQg KGl0IGlzIHRydWUpDQo+IG5vdCB0aGUgd2F5IG1vc3QgdGhpbmsgb2YgdGhlIGlzc3VlLg0KPiAN Cj4gVGhhbmtzLA0KPiBNYXJjIEIuDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t DQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+ DQo+IFRvOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+DQo+IFNlbnQ6IE1vbiBKdW4gMjIgMjA6MDE6 NDkgMjAwOQ0KPiBTdWJqZWN0OiBbRWNyaXRdIERpcmVjdGlvbiBvZiBob2xlcyBkcmFmdA0KPiAN Cj4gQ3VsbGVuIHJhaXNlZCBzb21lIGNvbmNlcm5zIGFib3V0IHRoZSBhZGRpdGlvbmFsIGZlYXR1 cmUgdGhhdCB0aGlzDQo+IGRvY3VtZW50IHJlcXVpcmVzLiAgSGUgc3VnZ2VzdGVkIHRoYXQgYW4g YWx0ZXJuYXRpdmUgd291bGQgbm90IHJlcXVpcmUNCj4gc3VwcG9ydCBvZiBpbnRlcmlvciBwb2x5 Z29ucywgb3IgaG9sZXMuDQo+IA0KPiBJJ2QgbGlrZSB0byBjb25maXJtIHRoYXQgdGhlIFdHIGlz IE9LIHdpdGggdGFraW5nIHRoZSBkb2N1bWVudCBhcyBpcywNCj4gd2l0aG91dCBtYWtpbmcgdGhp cyBwcm9wb3NlZCBjaGFuZ2UuDQo+IA0KPiBUaGFua3MsDQo+IE1hcnRpbg0KPiANCj4gQmVsb3cg aXMgYSBzdW1tYXJ5IG9mIG91ciBkaXNjdXNzaW9uOg0KPiAtLQ0KPiBUaGUgYWx0ZXJuYXRpdmUg ZG9lcyBub3QgdXNlIHRoZSA8aW50ZXJpb3I+IGVsZW1lbnQgb2YgdGhlIHBvbHlnb24gdG8NCj4g Y3JlYXRlIGhvbGVzLiAgSW5zdGVhZCwgcG9seWdvbnMgYXJlIHNsaWNlZCBpbnRvIHR3byBvciBt b3JlIHNlY3Rpb25zDQo+IHNvIHRoYXQgdGhlIOKAnGhvbGVz4oCdIGJlY2FtZSBleHRlcm5hbCB0 byBlYWNoIHNlY3Rpb24uICBFYWNoIHNlY3Rpb24gaXMNCj4gY3JlYXRlZCBhcyBhIHNlcGFyYXRl IG1hcHBpbmcuDQo+IA0KPiBXZSBjb25jbHVkZWQgdGhhdCB0aGUgYWx0ZXJuYXRpdmUgc29sdXRp b24gcHJvcG9zZWQgaXMgdmlhYmxlLCBidXQgdGhlDQo+IGV4aXN0aW5nIG1ldGhvZCBpcyBiZXN0 IHdoZW4gY29uc2lkZXJpbmcgdGhlIGRlcGxveW1lbnQgaW1wbGljYXRpb25zLg0KPiANCj4gQWx0 ZXJuYXRpdmUgcHJvczoNCj4gDQo+IE5vIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHJlcXVpcmVkIGJ5 IHRoZSBwcm90b2NvbC4NCj4gTm8gYWRkaXRpb25hbCBmdW5jdGlvbnMgcmVxdWlyZWQgYnkgTG9T VCBpbXBsZW1lbnRhdGlvbnMuDQo+IA0KPiBBbHRlcm5hdGl2ZSBjb25zOg0KPiANCj4gVGhpcyBp c27igJl0IGhvdyBwZW9wbGUgdGhpbmsgYWJvdXQgdGhlIHByb2JsZW0uDQo+IFJlZ2lvbnMgd2l0 aCBob2xlcyB3b3VsZCBuZWVkIHRvIGJlIGRpdmlkZWQgdXAgYnkgYSBwcm92aXNpb25pbmcgc3lz dGVtDQo+IGludG8gbXVsdGlwbGUgcmVnaW9ucyB3aXRoIHNlcGFyYXRlIG1hcHBpbmdzLg0KPiBU aGlzIGxpa2VseSByZXF1aXJlcyBjaGFuZ2VzIHRvIHRoZSBwcm92aXNpb25pbmcgYW5kIEdJUyBz eXN0ZW1zIHRoYXQNCj4gZmVlZCBMb1NULCB0aGVzZSBzeXN0ZW1zIGFscmVhZHkgZXhpc3QgYW5k IHRoZXJlZm9yZSB0aGUgY29zdCBpcyBoaWdoZXINCj4gKGF0IGxlYXN0IHdlIGtub3cgdGhhdCBM b1NUIGltcGxlbWVudGF0aW9ucyBiYXJlbHkgZXhpc3QpLg0KPiBUaGUgZXhpc3Rpbmcgc29sdXRp b24gaXMgYWxyZWFkeSBkb2N1bWVudGVkIGFuZCBhZ3JlZWQuDQo+IA0KPiAtLQ0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIG1lc3NhZ2Ug aXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gY29udGFpbiBw cml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24u DQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXINCj4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRo b3JpemVkIHVzZSBvZg0KPiB0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gW21mMl0NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0 DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBt ZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250 YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1h dGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5h dXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K