Re: [Ecrit] HUM on PhoneBCP

[<[e-mail]>]

 
John, 

It depends on who operates the device. An IMS mobile operator will support this because the P-CSCF will be in Germany and will recognize 112 as an EC. For the fixed networks, we are not aware of any requirements to support non-IMS nomadic devices operated from the US. It is in principle a nice thing, but we do not have requirements for this.   

More than that, the new German law (March 2009) is more restrictive then the old one. EC from mobile phones without valid SIM-card are no longer allowed and carriers must ensure that they do not route calls originated outside Germany to german PSAPs.   This is because PSAPs have problems to distinguish between real and bogus ECs. The real problem is the PSAPs overload, they just do not have enough people to answer the calls they get. Other than in US and Canada, there is no "112 access fee" in Germany.       

Laura


-----Original Message-----
From: Elwell, John [mailto:[e-mail]] 
Sent: Tuesday, August 11, 2009 9:56 AM
To: Liess, Laura; [e-mail]; [e-mail]; Jesske, Roland; [e-mail]
Cc: [e-mail]
Subject: RE: [Ecrit] HUM on PhoneBCP

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of [e-mail]
> Sent: 10 August 2009 14:58
> To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> Brian,
>  
> My expectation was that framework and phonepcb contain enough 
> options to cover also short term scenarios and help us to 
> implement VoIP emergency calling now. This seems not to be 
> the case. We can not require now from our SIP-proxy vendors 
> to comply with the framework and phone-pcb because this does 
> not work with the existing EDs.  Currently, ECRIT does not 
> offer all components to build an EC architecture which works 
> now. As a result, DT and other carriers must build and 
> require from their vendors proprietary solutions which work now.
>  
> We can take the approach that Hannes describes and do it 
> later, it's better than not at all. However, when people 
> already have proprietary solutions in place, it is difficult 
> change them.
>  
> Concerning the local dial string, we do not have currently 
> any plans for something different from 112 and the national 
> EC dial string (110) or to allow the nomadic usage of the 
> VoIP service outside Germany. 
[JRE] But how does a visiting device from the US, say, discover that the local dial string in Germany is 112?

John


>  
> Laura
>  
> 
> 
> ________________________________
> 
> 	From: Brian Rosen [mailto:[e-mail]] 
> 	Sent: Friday, August 07, 2009 5:46 PM
> 	To: Liess, Laura; [e-mail]; Jesske, 
> Roland; [e-mail]
> 	Cc: [e-mail]
> 	Subject: RE: [Ecrit] HUM on PhoneBCP
> 	
> 	
> 
> 	Laura
> 
> 	 
> 
> 	I don't think we're going to get to the point where the 
> IETF rolls back -framework and -phonebcp far enough to suit 
> you.  The approach that Hannes described, which is to finish 
> the current work as is, and then go back and see if we can 
> standardize a way for VoIP services to connect to older 
> systems with more limited capabilities using OBO and other 
> tricks, makes some sense to me.  
> 
> 	 
> 
> 	However, device vendors have to build devices that work 
> in countries that are more aggressively upgrading their 
> emergency systems, without unduly burdening you.  What I'm 
> attempting to do is to figure out a way that you can work 
> with a -phonebcp compliant device, without incurring a lot of cost.
> 
> 	 
> 
> 	We're not going to make it zero.
> 
> 	 
> 
> 	If you don't like a poly, return any street address in 
> the area code.  In most cases, it could be a PIDF with a 
> couple of A levels that works for the town.
> 
> 	 
> 
> 	All that matters is that if a -phonebcp client queries 
> an LCP, it should get a location that, when passed to LoST, 
> gets the right URI.  If the location is coarse, that is okay; 
> it works.  I'd like you to deploy HELD and LoST servers in 
> your networks that return the right thing to the endpoint and 
> not just to the OBO proxy, but even if you don't, phonebcp 
> compliant end devices will "work" in your network: their 
> attempts to reach LIS and LoST servers will fail, and they 
> will send emergency calls without location and PSAP URI, and 
> your proxy can fill in the right stuff.
> 
> 	 
> 
> 	You don't need -phonebcp compliant endpoints.  Good for 
> you.  However, vendors ought to make phonebcp compliant 
> endpoints so that they work everywhere.
> 
> 	 
> 
> 	If you want less that that, then I'm not sure IETF can 
> oblige, since we don't do nation specific solutions and some 
> nations need the full -phonebcp spec.
> 
> 	 
> 
> 	One complication you should consider: devices need to 
> know the local dial string(s) for emergency calls.  In the 
> IETF architecture, LoST provides that.  What were you 
> planning on doing?
> 
> 	 
> 
> 	Brian
> 
> 	 
> 
> 	 
> 
> 	From: [e-mail] [mailto:[e-mail]] 
> 	Sent: Friday, August 07, 2009 10:45 AM
> 	To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> 	Cc: [e-mail]
> 	Subject: RE: [Ecrit] HUM on PhoneBCP
> 
> 	 
> 
> 	Hi Brian,
> 
> 	 
> 
> 	Please see comments inline.  
> 
> 	 
> 
> 		 
> 
> 		________________________________
> 
> 				From: Brian Rosen 
> [mailto:[e-mail]] 
> 		Sent: Friday, August 07, 2009 3:05 PM
> 		To: Liess, Laura; [e-mail]; 
> Jesske, Roland; [e-mail]
> 		Cc: [e-mail]
> 		Subject: RE: [Ecrit] HUM on PhoneBCP
> 
> 		Actually, the PIDF-LO is designed to cater for 
> all the variations in addressing.  You don't mean "location 
> used for emergency calls", you mean "key for location used 
> for emergency calls".  The area code is not the location, it 
> is a key that is mapped to PSAP URI. 
> 		[[LLi]]  This is correct.
> 
> 		 
> 
> 		  The telephone number (with its area code) is 
> the identifier you would use with HELD to get the location,  
> from which LoST would get you a PSAP URI.
> 		[[LLi]] Here we don't use the phone number. The 
> proxy sends the IP-address to the LIS. The LIS finds out the 
> access hardware (DSLAM port)  corresponding to the IP-address 
> and assigns a temporary string to it (kind of LbyR). It also 
> finds out the phone area code for this hardware. With the 
> phone area code, the LIS queries a table which contains the 
> phone area codes and the corresponding PSAP URI,  then 
> delivers the the string (LbyR) and the PSAP-URI to the SIP 
> proxy. The SIP proxy routes the call and sends the LbyR to 
> the PSAP. In very few cases, PSAPs dereference  the the LyBR 
> to a civic address. 
> 
> 		We do not have any kind of geo data or poligons 
> in our database. In principle we have the the civic address, 
> but the access to this data is quite slow.  I think other 
> fixed networks carriers here have more or less the same. 
> 
> 		 
> 
> 		This seems trivial for you to implement: you 
> deploy a HELD server that takes telephone number and returns 
> a polygon representing the area code boundary, and you deploy 
> a LoST server that takes that polygon and returns the PSAP 
> URI associated with it.   
> 
> 		  This would be no more expensive than what you 
> are proposing.  Proxies could use this or phonebcp compatible 
> endpoints could use it.  
> 
> 		 
> 
> 		NENA is planning on doing pretty much this same 
> thing to handle legacy wireline networks where telephone 
> number is currently the key to the location database (ALI).  
> The LIS will store location as the key (using held-identity), 
> and a gateway will construct an LbyR from the phone number.  
> All the rest of the ecrit compatible infrastructure can then 
> use the Location URI to get location, route, etc.
> 
> 		 
> 
> 		Making what you now see as a one step mapping 
> (area code to PSAP URI) into a two step (telephone number to 
> polygon, polygon to PSAP URI) is a bit more complex, but not 
> any significant difference in deployment.  It also works for 
> wireless (cell sector/ID to polygon, polygon to PSAP URI), 
> and of course, would be upwardly compatible with real 
> location based routing, should your systems evolve as we 
> expect they evolve, or something like EU regulations compel 
> more accurate location services.
> 
> 		[[LLi]] Nobody here is willing to putting 
> geodata or poligons into the access databases.  And we could 
> avoid doing this just by allowing the LIS to query the local 
> LOST with the LbyR and to deliver the PSAP URI to the SIP proxy.  
> 
> 		 
> 
> 		Kind regards
> 
> 		Laura
> 
> 		 
> 
> 		Brian
> 
> 		 
> 
> 		From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> 		Sent: Friday, August 07, 2009 7:59 AM
> 		To: [e-mail]; 
> [e-mail]; [e-mail]
> 		Cc: [e-mail]
> 		Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> 		 
> 
> 		 
> 
> 		Hi Martin,  
> 
> 		Hi Laura,
> 
> 			 
> 
> 			I regard it as a goal of ECRIT - as 
> derived from the goals of the IETF generally - to define a 
> structure that will allow an Internet capable device to 
> connect to a network anywhere in the world and be able to 
> make emergency calls. Just as FTP, email protocols, SIP and 
> etc. all work regardless of which network the devices attach 
> to. I don't understand how the kind of variations that you 
> are requesting be added to the specification will allow that to occur.
> 
> 			[[LLi]] This is fine and usefull. Just 
> that every country uses today different formats for the 
> location used for emergency calls. Changing this will take 
> time and costs money. 
> 
> 			What is the harm in allowing ECs to 
> work with local location formats which are understood only by 
> the LIS and the PSAP ?. I dont see why a common location 
> format must be implemented by everybody. 
> 
> 			Maybe the EC could work like this : 
> 
> 			·         The proxy discovers the LIS 
> based on EDs IP-address using reverse-DNS and SRV record 
> (this is possible with "identity extenssions") 
> 
> 			·         It retrieves the location ( 
> e.g. using HELD) in a local format understood only by the LIS 
> and the PSAP, which are in the same country. The location is 
> just a string which is passed transparently through the 
> network to the PSAP. In my opinion, it would be in principle  
> posible to use LbyR to transport local location identidfiers, 
> e. g.  [e-mail] , but this is currently my 
> personal opinion, I didn' found any statemant or example in 
> the drafts.    
> 
> 			·         The LIS delivers, together 
> with the LbyR above, the PSAP URI.  As far as I know there is 
> currently no way to do this in HELD (or did I miss 
> something?).        
> 			  
> 
> 			It would be an alternative which is 
> interoperable and quite easy to implement, without the need 
> for the operators to change their location databases. I think 
> by allowing this scenario, interoperable EC could be achieved 
> earlier. And this does not exclude the scenario described in 
> the framework and phone-bcp, where the EDs retrieve deo or 
> civic location, which is needed for EC to work in 
> private/enterprise networks.  
> 			  
> 
> 			    
> 
> 			 
> 
> 			The position appears to be that the 
> German regulator doesn't require anything - and the operators 
> will not be proactive in following a specification if it 
> doesn't include what already exists. In that context, I don't 
> understand why there is a need for the BCP at all. There may 
> be no need to endorse it but, similarly, there should be no 
> need to object to it - since the operators will only put in 
> place their preferred version of the service in any case. 
> 			[[LLi]]  This is not quite true. We 
> have to ensure that EC works for different AN- and 
> VoIP-provider and for nomadic users in Germany by 2013. Our 
> current solution does not allow this and there is the same 
> for other carriers. We definitively need to define in Germany 
> an architecture which fullfills this requirements. It would 
> be very usefull if we can use standard protocols. But nobody 
> will be willing to change everything at once.  Having a 
> standard based architecture which is low cost would be a 
> great advantage. 
> 
> 			 
> 
> 			Kind regards
> 
> 			Laura     
> 
> 			 
> 
> 			 That's OK... insofar as it just means 
> German networks aren't ECRIT compatible - "compatibility" 
> isn't a worthy goal in and of itself; it has to actually mean 
> any device can work anywhere.
> 
> 			 
> 
> 			Cheers,
> 
> 			Martin
> 
> 			 
> 
> ________________________________
> 
> 			From: [e-mail] 
> [mailto:[e-mail]] 
> 			Sent: Friday, 7 August 2009 12:29 AM
> 			To: Dawson, Martin; 
> [e-mail]; [e-mail]
> 			Cc: [e-mail]
> 			Subject: RE: [Ecrit] HUM on PhoneBCP
> 
> 			 
> 
> 			Hi Martin, 
> 
> 			 
> 
> 			See comments inline [[LLi]].
> 
> 			 
> 
> 			 
> 
> 			Laura
> 
> 				From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dawson, Martin
> 				Sent: Wednesday, August 05, 
> 2009 11:00 AM
> 				To: Jesske, Roland; [e-mail]
> 				Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> 				Hi Roland,
> 
> 				 
> 
> 				I think what you're saying is 
> that you don't think that Germany will go on to implement 
> full ECRIT support but will peg development at an interim phase. 
> 				[[LLi]]  We don't know how the 
> realtime application networks or EC will look like in 20 
> years. Roland's answer only applies to the next 5 to 10 years. 
> 
> 				 
> 
> 				 That would be disappointing - 
> not least because full ECRIT compliance would ultimately 
> decrease the overhead associated with emergency service 
> support for operators as well as providing a more universal service.
> 				
> 				[[LLi]]  This may be true for 
> "green field" ISPs and VSPs but not for incumbent carriers 
> with existing infrastructure.  And universal service is not a 
> requirement for us. Neither the German regulator requires it 
> nor is it a busines case.   
> 
> 				 
> 
> 				Nevertheless, I don't think 
> that decision invalidates the BCP; 
> 				[[LLi]]  We think it does, 
> because some of the requirements are not flexible enough to 
> cover the deployments within the next years.  The BCP should 
> be more flexible:  
> 
> 				·         Allow additional 
> location identifiers  
> 
> 				·         Allow AN operated LOST 
> 
> 				·         Provide a way to 
> enable LOST-query based on national or domain-specific 
> location identifier. One posiblility is to allow the LIS to 
> query the LOST , but there are also other alternatives.  
> 
> 				·         Allow and describe 
> also network-centric, not only ED-centric architectures. If I 
>  remember correctly, John Medland from BT also recomended to 
> use a more network- centric architecture, at least for the 
> next years. 
> 
> 				 
> 
> 				I think it just means that the 
> German regulator and technical advisory committees would 
> point out the subset aspects of compliance that would be 
> applicable to that jurisdiction.  
> 				[[LLi]]  Again, the draft is 
> not flexible enough for it.  If the BCP contains requirements 
> which are not realistic, people will just discard the BCP and 
> implement proprietary stuff. My expectation from a standard 
> body is to define protocols and architecture which people are 
> willing to implement in their network or products , not only 
> in the lab.
> 
> 				 
> 
> 				[[LLi]]  
> 
> 				We are not against the draft in 
> principle. ECRIT provides  us with very valuable 
> specifications as LbyR, HELD, identity extensions. But 
> targeting an architecture which requires everbody to invest 
> without a business case will not help the draft in the end, 
> also if it becomes a BCP.  It would make sense to make it 
> more flexible so people are willing to adopt it.    
> 
> 				 
> 
> 				 Actually, based on your 
> description below, the NENA i2 architecture would probably be 
> a more straightforward baseline for analysis - as has been 
> done in the UK and Canada. Of course, it's generally 
> recognized as only an interim step, even in those jurisdictions.
> 
> 				Other comments below.
> 
> 				 
> 
> 				Cheers,
> 
> 				Martin
> 
> 				 
> 
> ________________________________
> 
> 				From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> 				Sent: Wednesday, 5 August 2009 6:19 PM
> 				To: [e-mail]
> 				Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> 				 
> 
> 				 
> 
> 				Dear all, 
> 				We would like the document to 
> become a BCP as soon as possible so the group can move on 
> with other documents related to emergency calling based on 
> location-by-reference and ED's IP-address. 
> 
> 				[[MCD]] I think you might mean 
> "identity extensions" rather than location-by-reference 
> because LbyR still requires the ED to obtain the reference - 
> e.g. by HELD.
> 				[[LLi]] We use both, the 
> IP-address as UE identity and LbyR. The SIP-proxy uses the 
> IP-address to query the LIS using HTTP (it's not HELD but 
> SOAP over HTTP, but anyway similar). The LIS responds with a 
> numeric string associated to the caller location, in 
> principle a LbyR and with the PSAP number. The proxy inserts 
> the LbyR into the SIP-message (as P-Asserted-ID because the 
> PSAPs are in PSTN) and routes the message to the PSAP.  It's 
> a low cost solution. 
> 
> 				But we can not HUM for the 
> current form of the document. 
> 
> 				Back to the document: Some 
> requirements are far form being realistic, at least in 
> Germany, some are not realistic at all. Implementing these 
> requirements cost a carrier a lot of money and there is no 
> ROI for it. 
> 
> 				Just a few examples: 
> 
> 				·       Requiring either geo or 
> civic location does not provide carriers with enough 
> flexibility to reuse their existing mechanisms and location 
> databases. Routing of emergency calls is currently done in 
> Germany based on phone area code not on geo or civic 
> location, at least for the fixed network. For mobile networks 
> the cell-id is used in common. This is regulated by the 
> german regulator. 
> 
> 				[[MCD]] How many unique PSAP 
> routes are required in Germany? The US has lots (6000 plus) 
> and Australia has two (and they are redundant so it doesn't 
> matter which one). Presumably geographic information, for 
> PSAP catchment areas, is the basis for determining which area 
> codes are relevant to begin with? After all, an area code is 
> not intrinsically geographic; it's a network routing value. 
> If so, then some geographic discriminator is already in play 
> in terms of constructing the area code based routing data 
> (something like zip codes perhaps?) - and in that case, it 
> should be straightforward to by-pass the area code step in 
> the construction of routing that goes the correct PSAP URI. 
> 				[[LLi]] Currently, fixed 
> networks carriers in Germany route the ECs based only on the 
> caller's area code. Sometime in the past, the carriers, the 
> regulator and the PSAPs operators (police, the Red Cross) 
> agreed to do so. This may change in the future, but it will 
> take a quite long time.      
> 
> 				 With nomadic VoIP devices (and 
> it's no good being in denial about this being the norm in the 
> future) area code is no more reliable than it is for 
> conventional mobile phones. And, presumably, area code is not 
> used for conventional cellular emergency call routing?
> 				[[LLi]]  As far as I know, 
> mobile networks use the Cell-ID, not the area code, and have 
> a different table than the fixed network operators. They are 
> not going to change this.  As to the nomadic SIP-users...if 
> we like it or not, very few of our customers use our SIP 
> service nomadic, let alone call EC from their laptop.         
> 
> 				1              LOST as a 
> national, let alone as a global directory is not going to be 
> implemented. The regulator will provide in the web a static 
> table which contains the PSAPs and the area for which they 
> are responsible (one or more area codes). Every carrier has 
> to implement its own routing database for emergency calls. 
> 
> 					[[MCD]] Whatever the 
> carriers implement (and they have to implement something) 
> could just as readily be done using LoST. Then visiting 
> devices, with no association with any local VoIP proxy server 
> would still be able to determine a route to the correct PSAP. 
> Alternatively, as long as the regulator is maintaining a web 
> service with the routing information, why not make that 
> directly accessible using LoST and save the operators the 
> cost of duplicating the service at all?
> 					[[LLi]]  There is a big 
> difference between maintaining a web page with a table which 
> operator can print and implement in their darabases and 
> operating a database which is queried for every emergency 
> call in Germany, must have an availablity of 99,99...% ,  is 
> secure enough...you know. The regulator will not do this.
> 
> 					
> 					2       We have no 
> intention to rely on end devices for location information because: 
> 					·       ED provided 
> location info is not trusted 
> 
> 				[[MCD]] Location by reference 
> mitigates this trust issue. The emergency network can 
> (automatically and before human resources are engaged) assess 
> the source of the reference, and the validity of the location 
> by dereference, without having to trust location provided 
> directly from the ED. There are more sophisticated approaches 
> to trustability even using LbyV - based on digital signatures 
> across appropriate attributes. This WG and Geopriv haven't 
> really got to grips with that... yet.
> 				[[LLi]]  We build the 
> SIP-network and EC now. ED-provided location is needed if EC 
> must work for private and enterprise networks and VPNs.  We 
> have no such regulatory requirements.  And we don't know of 
> any verdor of DSL-EDs which provides today SIP with LbyR and 
> is as cheap as the devices without it. If you do, please let me know. 
> 
> 				The regulator ask us to 
> guarantee that EC works. What if a customer dials 112 and his 
> end device does not send the location? So I have to implement 
> both solutions, with and without ED provided location, anyway.  
> 				1       There are already a lot 
> of existing EDs in usage which don't send location.    
> 
> 				[[MCD]] Quite right. ECRIT 
> doesn't overly concern itself with that interim situation. 
> The UK and Canadian definitions for an interim solution 
> (limiting service to in-country VoIP proxy operators) both 
> assume third-party query via identity-extension to allow the 
> proxy or the VPC to make the query to the LIS. This isn't 
> extensible to universal emergency service access by all 
> visiting devices but it does put the necessary LIS 
> functionality in place as a very good starting point.  It 
> would be a pity if Germany were to cease the evolution there 
> as it would not fulfil the real promise of the Internet and 
> the ECRIT model. 
> 				[[LLi]]  I wonder who will 
> drive and pay for upgrading the interim solutions.  
> Unfortunatelly, it's all about money...
> 
> 				 Think about it; all the 
> complexity of putting location determination infrastructure 
> in place for the purposes of dispatch is done - and then the 
> next, simpler step, of using that to support the routing 
> procedure isn't taken... that would be a waste.
> 				
> 				[[LLi]]  Do you think this is 
> an argument for a product manager? They need a business case.  
> 
> 				 
> 
> 				 
> 
> 				  We don't intend to require 
> our ED-vendors to provide location because it is useless to us.   
> 
> 				We could agree with the 
> document with following changes: 
> 
> 				o    Other location identifiers 
> then geo or civil are allowed. It must be possibe that the 
> data foermat is flexible due to different requirements from 
> regulators over the whole world. (e.G Germany area codes for 
> fixed- and Cell-Id for moile- providers) 
> 
> 				o    The MUST for the end 
> devices to support location information, DHCP location 
> options and HELD shall be removed 
> 
> 				o    It must be possible for 
> the VoIP-provider's proxy to use a LOST (or an ESRP) provided 
> by the AN or by other local provider on behalf of the AN.  
> 
> 				 
> 
> 				 There is no value in Hum-ing 
> documents which one is not going to implement and does not 
> fit into regulated schemes like in Germany. Currently, 
> neither the IETF- nor the 3GPP-architecture for emergency 
> calling covers our real needs for the next 2 to 5 years and 
> in the end everybody still has its own proprietary implementation.    
> 
> 				Best regards 
> 
> 				Roland 
> 
> 				 
> 
> 				Deutsche Telekom Netzproduktion GmbH
> 				Zentrum Technik Einführung
> 				Roland Jesske
> 				Gateways, Protokolle, Konvergenz, TE32-1
> 				Heinrich-Hertz-Str. 3-7, 64295 
> Darmstadt,
> 				Postfach, 64307 Darmstadt 
> (Postanschrift)
> 				[phone] (Tel)
> 				[phone] (Mobile)
> 				E-Mail: [e-mail] 
> <mailto:[e-mail]>  
> 				http://www.telekom.de 
> <http://www.telekom.de/>  
> 
> 				 
> 
> 				Registerrechtliche Unternehmensangaben:
> 				Deutsche Telekom Netzproduktion 
> (DT NP) GmbH
> 				Aufsichtsrat: Timotheus Höttges 
> (Vorsitzender)
> 				Geschäftsführung: Dr. Bruno 
> Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
> 				Handelsregister: Amtsgericht 
> Bonn HRB 14190
> 				Sitz der Gesellschaft: Bonn
> 				USt-IdNr.: DE 814645262 
> 
> 				 
> 
> 				 
> 
> 				
> 				
> --------------------------------------------------------------
> ----------------------------------
> 				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]
> 
> 				
> 
> 			 
> 
>