AW: AW: [Ecrit] Location Hiding -- State of the Art

Interested in going to a pub together on Thursday
evening?

We are going to meet after the plenary in front of the IETF Registration

Desk

Please indicate your preference here:

http://www.doodle.ch/6p9er8b3hnyinqg8 

<http://service.gmx.net/de/cgi/derefer?TYPE=3&DEST=http%3A%2F%2Fwww.doodle.ch%2F6p9er8b3hnyinqg8>

Ciao

Hannes

_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

https://www1.ietf.org/mailman/listinfo/ecrit

Interested=0D=0Ain goin=
g to a pub together on Thursday evening=3F
We are going to meet after=
 the plenary in front of=0D=0Athe IETF Registration 
Please indicate your preference here:
http://www.doodle.ch/6p9er8b3hnyinqg8 
<http://service.gmx.ne=
t/de/cgi/derefer=3FTYPE=3D3&DEST=3Dhttp%3A%2F%2Fwww.doodle.ch%2F6p9er8b=
3hnyinqg8>
Ciao
Hannes
=0D=0A
=0D=0A
=0D=0A_____________=
__________________________________
=0D=0AEcrit mailing list
=0D=0AEcrit@ietf.org
=0D=0A=
https://www1.ietf.org/mailman/listinfo/ecrit
=

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

---------------------------=
---------------------------------------------------------------------
=0D=
=0AThis message is for the designated recipie=
nt only and may
=0D=0Acontain privileged, propr=
ietary, or otherwise private information.  =0D=0AIf you have received it in error,&nbs=
p;please notify the sender
=0D=0Aimmediately and&nbs=
p;delete the original.  Any unauthorized use&=
nbsp;of
=0D=0Athis email is prohibited.
=0D=0A--------=
---------------------------------------------------------------------------=
-------------
=0D=0A[mf2]=0D=0A=0D=0A=0D=
=0A
------_=_NextPart_001_01C837A3.EB913F3E--

--===============2054452298==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--===============2054452298==--

From ecrit-bounces@ietf.org Wed Dec 05 20:21:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J05R8-0002fC-TR; Wed, 05 Dec 2007 20:21:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J05R6-0002dL-IK; Wed, 05 Dec 2007 20:21:56 -0500
Received: from smtp.mitel.com ([216.191.234.102])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J05R5-0007ir-RU; Wed, 05 Dec 2007 20:21:56 -0500
Received: from localhost (smtp.mitel.com [127.0.0.1])
	by smtp.mitel.com (Postfix) with ESMTP id AE1992C055;
	Wed,  5 Dec 2007 20:21:55 -0500 (EST)
X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com
Received: from smtp.mitel.com ([127.0.0.1])
	by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id eXaCFocNLt9N; Wed,  5 Dec 2007 20:21:54 -0500 (EST)
Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58])
	by smtp.mitel.com (Postfix) with ESMTP id 750C12C027;
	Wed,  5 Dec 2007 20:21:54 -0500 (EST)
In-Reply-To: 
To: "Winterbottom, James" 
Subject: RE: [Geopriv] Re: [Ecrit] Pub?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: 
From: peter_blatherwick@mitel.com
Date: Wed, 5 Dec 2007 20:21:51 -0500
X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13,
	2003) at 12/05/2007 08:21:54 PM,
	Serialize complete at 12/05/2007 08:21:54 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
Cc: GEOPRIV , ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1997512444=="
Errors-To: ecrit-bounces@ietf.org

This is a multipart message in MIME format.
--===============1997512444==
Content-Type: multipart/alternative;
	boundary="=_alternative 00077E94852573A9_="

This is a multipart message in MIME format.
--=_alternative 00077E94852573A9_=
Content-Type: text/plain; charset="US-ASCII"

Are you presupposing we want to be awake for it ? 

"Winterbottom, James" 
05.12.07 20:04

        To:     , "Hannes Tschofenig" 

        cc:     "GEOPRIV" , "ECRIT" 
        Subject:        RE: [Geopriv] Re: [Ecrit] Pub?

No stagger back.. Geopriv in the morning.. *8)

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] 
Sent: Thursday, 6 December 2007 12:03 PM
To: Hannes Tschofenig
Cc: GEOPRIV; ECRIT
Subject: [Geopriv] Re: [Ecrit] Pub?

I do not know whether I will make it but ...  Best local beer is to be had 
at The Steamworks Brewing Company.  In-house brewed, and good pub-grub.  A 
bit of a walk, about 2 x distance to Marriott / Renaissance hotels.  (The 
stagger back could be somewhat longer    q;*) 

375 Water Street 
http://www.steamworks.com/ 

Note there are 3 of them these days, apparently -- go to the original as 
above, where they make the brew.   

BTW, downstairs tends to be a bit quieter... 

-- Peter Blatherwick 

Hannes Tschofenig  
05.12.07 12:25 

        To:        GEOPRIV , ECRIT  
        cc:         
        Subject:        [Ecrit] Pub?

Interested in going to a pub together on Thursday evening?
We are going to meet after the plenary in front of the IETF Registration 
Desk

Please indicate your preference here:
http://www.doodle.ch/6p9er8b3hnyinqg8 
<
http://service.gmx.net/de/cgi/derefer?TYPE=3&DEST=http%3A%2F%2Fwww.doodle.ch%2F6p9er8b3hnyinqg8
>

Ciao
Hannes

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information. 
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

--=_alternative 00077E94852573A9_=
Content-Type: text/html; charset="US-ASCII"

Are you presupposing we want to be awake
for it ?   

"Winterbottom, James" <James.Winterbottom@andrew.com>
05.12.07 20:04

        To:
       <peter_blatherwick@mitel.com>,
"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>

        cc:
       "GEOPRIV" <geopriv@ietf.org>,
"ECRIT" <ecrit@ietf.org>

        Subject:
       RE: [Geopriv] Re: [Ecrit] Pub?

No stagger back.. Geopriv in
the morning.. *8)

From: peter_blatherwick@mitel.com
[mailto:peter_blatherwick@mitel.com] 

Sent: Thursday, 6 December 2007 12:03 PM

To: Hannes Tschofenig

Cc: GEOPRIV; ECRIT

Subject: [Geopriv] Re: [Ecrit] Pub?

I do not know whether I will make it but ...  Best local beer is to
be had at The Steamworks Brewing Company.  In-house brewed, and good
pub-grub.  A bit of a walk, about 2 x distance to Marriott / Renaissance
hotels.  (The stagger back could be somewhat longer    q;*)

375 Water Street 

http://www.steamworks.com/ 

Note there are 3 of them these days, apparently -- go to the original as
above, where they make the brew.  

BTW, downstairs tends to be a bit quieter...

-- Peter Blatherwick 

Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

05.12.07 12:25

        To:        GEOPRIV <geopriv@ietf.org>,
ECRIT <ecrit@ietf.org>

        cc:        

        Subject:        [Ecrit]
Pub?

Interested in going to a pub together on Thursday evening?

We are going to meet after the plenary in front of the IETF Registration

Desk

Please indicate your preference here:

http://www.doodle.ch/6p9er8b3hnyinqg8 

<http://service.gmx.net/de/cgi/derefer?TYPE=3&DEST=http%3A%2F%2Fwww.doodle.ch%2F6p9er8b3hnyinqg8>

Ciao

Hannes

_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------

This message is for the designated recipient only and may

contain privileged, proprietary, or otherwise private information.  

If you have received it in error, please notify the sender

immediately and delete the original.  Any unauthorized use of

this email is prohibited.

------------------------------------------------------------------------------------------------

[mf2]

--=_alternative 00077E94852573A9_=--

--===============1997512444==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--===============1997512444==--

From ecrit-bounces@ietf.org Wed Dec 05 20:24:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J05Tr-0005hb-1A; Wed, 05 Dec 2007 20:24:47 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J05Tp-0005YP-6b; Wed, 05 Dec 2007 20:24:45 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J05To-0007xo-7B; Wed, 05 Dec 2007 20:24:45 -0500
X-SEF-Processed: 5_0_0_910__2007_12_05_19_35_42
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Wed, 05 Dec 2007 19:35:42 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Dec 2007 19:24:43 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Geopriv] Re: [Ecrit] Pub?
Date: Wed, 5 Dec 2007 19:24:41 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Geopriv] Re: [Ecrit] Pub?
Thread-Index: Acg3pmTBOP0CV1mpSXymDlJ6tnwnEwAAFB+Q
References: 

From: "Winterbottom, James" 
To: 
X-OriginalArrivalTime: 06 Dec 2007 01:24:43.0477 (UTC)
	FILETIME=[C7B64850:01C837A6]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d
Cc: GEOPRIV , ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1234325831=="
Errors-To: ecrit-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1234325831==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C837A6.C75AA1BE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C837A6.C75AA1BE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think I have to be awake.. *8)=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A_=
_______________________________=0D=0A=0D=0AFrom: peter_blatherwick@mitel.co=
m [mailto:peter_blatherwick@mitel.com]=20=0D=0ASent: Thursday, 6 December 2=
007 12:22 PM=0D=0ATo: Winterbottom, James=0D=0ACc: GEOPRIV; ECRIT=0D=0ASubj=
ect: RE: [Geopriv] Re: [Ecrit] Pub=3F=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0AAre y=
ou presupposing we want to be awake for it =3F  =20=0D=0A=0D=0A=0D=0A=0D=0A=0D=
=0A=20=0D=0A=0D=0A"Winterbottom, James" =20=0D=
=0A=0D=0A05.12.07 20:04=20=0D=0A=0D=0A       =20=0D=0A        To:        , "Hannes Tschofenig"=0D=0A=20=0D=0A        cc:        "GEOPRIV" , "ECRIT"=0D=0A=
=20=0D=0A        Subject:        RE: [Geopriv] Re: [Ecrit] =
Pub=3F=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ANo stagger back.. Geopriv in the mornin=
g.. *8)=20=0D=0A =20=0D=0A =20=0D=0A=0D=0A=20=0D=0A=0D=0A__________________=
______________=0D=0A=0D=0A=0D=0AFrom: peter_blatherwick@mitel.com [mailto:p=
eter_blatherwick@mitel.com]=20=0D=0ASent: Thursday, 6 December 2007 12:03 P=
M=0D=0ATo: Hannes Tschofenig=0D=0ACc: GEOPRIV; ECRIT=0D=0ASubject: [Geopriv=
] Re: [Ecrit] Pub=3F=20=0D=0A =20=0D=0A=0D=0AI do not know whether I will m=
ake it but ...  Best local beer is to be=0D=0Ahad at The Steamworks Brewing=
 Company.  In-house brewed, and good=0D=0Apub-grub.  A bit of a walk, about=
 2 x distance to Marriott / Renaissance=0D=0Ahotels.  (The stagger back cou=
ld be somewhat longer    q;*)=20=0D=0A=0D=0A375 Water Street=20=0D=0Ahttp:/=
/www.steamworks.com/=20=0D=0A=0D=0ANote there are 3 of them these days, app=
arently -- go to the original as=0D=0Aabove, where they make the brew.   =0D=
=0A=0D=0ABTW, downstairs tends to be a bit quieter...=20=0D=0A=0D=0A-- Pete=
r Blatherwick=20=0D=0A=0D=0A=0D=0A=0D=0A =20=0D=0A=0D=0AHannes Tschofenig <=
Hannes.Tschofenig@gmx.net>=20=0D=0A=0D=0A05.12.07 12:25=20=0D=0A=0D=0A     =
  =20=0D=0A       To:        GEOPRIV , ECRIT =20=0D=0A       cc:        =20=0D=0A       Subject:        [Ecrit] Pub=3F=0D=
=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AInterested in going to a pub together on T=
hursday evening=3F=0D=0AWe are going to meet after the plenary in front of =
the IETF Registration=0D=0A=0D=0ADesk=0D=0A=0D=0APlease indicate your prefe=
rence here:=0D=0Ahttp://www.doodle.ch/6p9er8b3hnyinqg8=20=0D=0A=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0A=0D=0A_______=
________________________________________=0D=0AEcrit mailing list=0D=0AEcrit=
@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=20=0D=0A=0D=0A =0D=
=0A=0D=0A=0D=0A------------------------------------------------------------=
------------=0D=0A------------------------=0D=0AThis message is for the des=
ignated recipient only and may=0D=0Acontain privileged, proprietary, or oth=
erwise private information. =20=0D=0AIf you have received it in error, plea=
se notify the sender=0D=0Aimmediately and delete the original.  Any unautho=
rized use of=0D=0Athis email is prohibited.=0D=0A--------------------------=
----------------------------------------------=0D=0A-----------------------=
-=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A------------------------------------=
------------------------------------------------------------=0D=0AThis mess=
age is for the designated recipient only and may=0D=0Acontain privileged, p=
roprietary, or otherwise private information. =20=0D=0AIf you have received=
 it in error, please notify the sender=0D=0Aimmediately and delete the orig=
inal.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------=
---------------------------------------------------------------------------=
-------------=0D=0A[mf2]=0D=0A
------_=_NextPart_001_01C837A6.C75AA1BE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=
=0D=0A=
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0AI think I have to be awake.. *8)<=
/o:p>
=0D=0A=0D=0A 
=0D=0A=0D=0A =0D=
=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0AFrom:=0D=0Apeter_blatherwick@=
mitel.com [mailto:peter_blatherwick@mitel.com] 
=0D=0ASent: Thursday, 6 December 2007=0D=0A12:22 PM<=
br>=0D=0ATo: Winterbottom, J=
ames
=0D=0ACc: GEOPRIV; E=
CRIT
=0D=0ASubject: RE: [=
Geopriv] Re: [Ecrit]=0D=0APub=3F
=0D=0A=0D=0A
=0D=0A=0D=0A&nbs=
p;
=0D=0A=0D=0A
=0D=0A=
Are you presu=
pposing we want to be awake for it =3F  =0D=0A
=0D=0A=

=0D=0A
=0D=0A=0D=0A=0D=0A=0D=
=0A =0D=0A  =0D=0A  =0D=0A =0D=0A=0D=
=0A   
=0D=0A  =0D=0A  =0D=0A=
  "Winte=
rbottom,=0D=0A  James" <James.Winterbottom@andrew.com> 
=0D=0A  05.12.07 20:04 
=0D=0A  =0D=0A   =
;       
=0D=0A   =0D=0A =
       To:        <peter_blatherwick@=
mitel.com>,=0D=0A  "Hannes Tschofenig" <Hannes.Tschofenig@g=
mx.net>=0D=0A  
=0D=0A   =0D=0A  &nbs=
p;     cc:        "GEOPRIV"=0D=0A  =
<geopriv@ietf.org>, "ECRIT" <ecrit@ietf.org>=0D=0A  
=0D=0A   =0D=0A        Su=
bject:        RE: [Geopriv] Re:=0D=0A  [Ecrit] Pub=3F
=0D=0A  =0D=0A=0D=
=0A
=0D=0A
=0D=0A
=0D=0ANo stagger back.. Geopriv in the morning.. *8=
)=0D=0A
=0D=0A  
=0D=0A  =
=0D=0A=0D=0A 
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=
=0A
=0D=0A=
From:=0D=0A=
peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] 
=0D=0ASent: Thursday, 6 Decemb=
er 2007 12:03 PM
=0D=0ATo: Hannes Tschofenig
=0D=0ACc:<=
/span> GEOPRIV; ECRIT
=0D=0ASubj=
ect: [Geopriv] Re: [Ecrit] Pub=3F 
=0D=0A =

=0D=0A
=0D=0AI do not know whether I will make it but=
 ...  Best local beer is to be had=0D=0Aat The Steamworks Brewing Comp=
any.  In-house brewed, and good pub-grub.  A=0D=0Abit of a walk, =
about 2 x distance to Marriott / Renaissance hotels.  (The=0D=0Astagge=
r back could be somewhat longer    q;*) 
=0D=0A<=
font size=3D2 face=3Dsans-serif>
=0D=0A375 Water Street =0D=0Ahttp://www.steamworks.com/ 
=0D=0A=0D=0ANote there are 3 of them these days, apparently -- go to the origina=
l as above,=0D=0Awhere they make the brew.   
=0D=0A<=
font size=3D2 face=3Dsans-serif>
=0D=0ABTW, downstairs tends to be a bit quieter...<=
/font> 
=0D=0A
=0D=0A-- Peter Blatherwick=

=0D=0A
=0D=0A=0D=0A=0D=0A=0D=
=0A =0D=0A  =0D=0A  =0D=0A=
  =0D=
=0A =0D=0A=0D=0A    <=
/span>
=0D=0A  =0D=0A  =
Hannes Tschofenig=0D=0A  <Hanne=
s.Tschofenig@gmx.net> 
=0D=0A  05.12.07 12:25 
=0D=0A  =0D=0A        &n=
bsp; 
=0D=0A        &nb=
sp;To:        GEOPRIV=0D=0A  <geopriv@ietf.org>, =
ECRIT <ecrit@ietf.org> 
=0D=0A  =
       cc:         
=0D=0A         Subject:   &n=
bsp;    [Ecrit] Pub=3F
=0D=0A  
=0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0AInterested in going to a pub togeth=
er on Thursday evening=3F
=0D=0AWe are going to meet after the plenary i=
n front of the IETF Registration 
=0D=0ADesk
=0D=0A
=0D=0APlease i=
ndicate your preference here:
=0D=0Ahttp://www.doodle.ch/6p9er8b3hnyinqg=
8 
=0D=0A<http://service.gmx.net/de/cgi/derefer=3FTYPE=3D3&DEST=3D=
http%3A%2F%2Fwww.doodle.ch%2F6p9er8b3hnyinqg8>
=0D=0A
=0D=0ACiao=0D=0AHannes
=0D=0A
=0D=0A
=0D=0A_______________________________=
________________
=0D=0AEcrit mailing list
=0D=0AEcrit@ietf.org
=0D=
=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit =0D=0A=0D=0A

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

=0D=0A  -----------------------------------=
-------------------------------------------------------------
=0D=0A  Th=
is message is for the designated recipient only and may
=0D=0A  contain =
privileged, proprietary, or otherwise private information.  
=0D=0A=
  If you have received it in error, please notify the sender
=0D=0A  imm=
ediately 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=0AThis =
;message is for the designated recipient only=
 and may
=0D=0Acontain privileged, proprietary, =
;or otherwise private information.  
=0D=0AIf&n=
bsp;you have received it in error, please&nbs=
p;notify the sender
=0D=0Aimmediately and delete&nbs=
p;the original.  Any unauthorized use of
=0D=
=0Athis email is prohibited.
=0D=0A----------------------=
--------------------------------------------------------------------------<=
br>=0D=0A[mf2]=0D=0A=0D=0A=0D=0A
------_=_NextPart_001_01C837A6.C75AA1BE--

--===============1234325831==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--===============1234325831==--

From ecrit-bounces@ietf.org Thu Dec 06 22:11:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0TcB-0005Pq-EA; Thu, 06 Dec 2007 22:10:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TcA-0005N9-PE
	for ecrit@ietf.org; Thu, 06 Dec 2007 22:10:58 -0500
Received: from tcmail31.telekom.de ([217.6.95.238])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Tc9-0000MW-P0
	for ecrit@ietf.org; Thu, 06 Dec 2007 22:10:58 -0500
Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP;
	Fri, 7 Dec 2007 04:10:55 +0100
Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by
	s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); 
	Fri, 7 Dec 2007 04:10:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Ecrit] Location Hiding -- State of the Art
Date: Fri, 7 Dec 2007 04:10:52 +0100
Message-Id: <182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de>
In-Reply-To: <06c501c8368b$96348ec0$0e99f544@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg2JyOpSZap0rdoR5GmFIORRq6LowAFGi8AAJCWfeA=
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net>
	<06c501c8368b$96348ec0$0e99f544@cis.neustar.com>
From: "Liess, Laura" 
To: 
X-OriginalArrivalTime: 07 Dec 2007 03:10:54.0558 (UTC)
	FILETIME=[C795D7E0:01C8387E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Brian,

I checked with my company and we need LH for both civic and geo for =
fixed and mobile access. Only DSL and civic is not an option.=20

I would support sending the ESRP/PSAP URI to the UA, as proposed by =
Barbara and James some weeks ago.=20

Laura

-----Urspr=FCngliche Nachricht-----
Von: Brian Rosen [mailto:br@brianrosen.net]=20
Gesendet: Dienstag, 4. Dezember 2007 16:37
An: 'Hannes Tschofenig'
Cc: 'ECRIT'
Betreff: RE: [Ecrit] Location Hiding -- State of the Art

Proposed text for framework

Some access networks wish to restrict who can get a high quality =
location,
possibly based on a payment arrangement.  For emergency calls, high =
quality
location must be provided.  An access network can reasonably be expected =
to
have a relationship with the PSAPs in its catchment area, so giving =
location
to the PSAP will be straightforward

However, an endpoint may need location
for routing, and a proxy may need to verify that a purported emergency =
call
is targeted at a bona fide PSAP.  To do so, it may take the location =
passed
with the call and query LoST to confirm that the URI is genuine.  =
"Hiding"
location interferes with this check.  To achieve location hiding, the =
LIS
can return a coarse location which is good enough to elicit the same
response from LoST as the actual location would.  The endpoint and the =
proxy
can use this location to route and verify.  A suitable location for a =
geo is
a polygon calculated by intersecting the service boundaries of all of =
the
emergency services that respond to the actual location.  A suitable =
location
for a civic is any civic location within the intersection of the service
boundaries of emergency services.  In a great many cases, a country code =
is
sufficient.  In others a state/province or a city name is sufficient.  =
Of
course, the LIS would always return a location reference, which would =
return
high quality location for a PSAP and coarse location to the endpoint or =
any
proxy unknown to the LIS.

Proposed text for phonebcp:

A LIS who wishes to hide location returns a location reference.  When
dereferenced by the endpoint or proxy:
1. For LIS's returning geo:
    For each location served by the LIS, compute the intersection of the
    service boundaries for all emergency services known to LoST for the=20
    location. Return the resulting polygon, or any point in the polygon =
as
    the value during a dereference=20
2. For LIS's returning civic:
    Determine a civic location which is within the service boundary of =
all
    emergency services known to LoST for the location.  In a great many
    cases, this will be a country code, province/state or city. Return =
this
    coarse civic location as the value during a dereference
Note that the service boundaries returned from LoST have a TTL, the
intersections MUST recalculated if the service boundary changes.  The =
LIS
MUST return high quality location to a PSAP or ESRP.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Monday, December 03, 2007 1:38 PM
> To: Brian Rosen
> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> Subject: Re: [Ecrit] Location Hiding -- State of the Art
>=20
> Hi Brian,
>=20
> Brian Rosen wrote:
> > It's fine with me if there is a separate doc, but framework and =
phonebcp
> > have to reference it.
> >
> Are we talking about informative or normative references?
> > I think it can be solved with a one paragraph description of the =
problem
> in
> > framework and a one paragraph solution in phonebcp, but if there is =
a
> > separate doc and a reference, I will be happy.
> >
> That does not make sense.
> The solution is not one paragraph and the text in phone bcp is =
normative.
>=20
> Ciao
> Hannes
>=20
> > Brian
> >
> >
> >> -----Original Message-----
> >> From: James M. Polk [mailto:jmpolk@cisco.com]
> >> Sent: Monday, December 03, 2007 7:37 PM
> >> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> >> Subject: RE: [Ecrit] Location Hiding -- State of the Art
> >>
> >> Currently, the WG (and document editors!) should be operating under
> >> the consensus direction that Location Hiding *not* be in PhoneBCP =
or
> >> Framework.  This was a clear consensus call in Chicago - and not by
> >> default, but by most people voicing actively against having this
> >> Hiding in either core ECRIT documents, and I haven't yet talked to
> >> anyone here in Vancouver that thinks otherwise.
> >>
> >> Location Hiding is something that needs to be addressed BY ITSELF
> >> (i.e., in its own doc) so everyone can focus on the singular topic,
> >> and work towards not talking past each other (not like that's
> >> happened before in ECRIT....  :-/
> >>
> >> Who disagrees with this?
> >>
> >> BTW - if someone thinks Location Hiding should be put back into
> >> PhoneBCP or Framework, then they can attempt to gain WG consensus =
on
> >> that, but that's different than a direction of this inevitability =
or
> >> that there is not consensus on this.
> >>
> >>
> >> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> >>
> >>> If people felt this was good enough so that access providers would =
not
> >>> need to be required to build the infrastructure to provide =
location
> >>> (because people could use this method instead of getting location =
from
> >>> access providers), then location hiding would be dead. If people =
still
> >>> want to place a requirement on access providers to provide =
location,
> >>> then location hiding is not dead.
> >>> Barbara
> >>>
> >>> -----Original Message-----
> >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >>> Sent: Saturday, December 01, 2007 3:34 PM
> >>> To: ECRIT
> >>> Subject: [Ecrit] Location Hiding -- State of the Art
> >>>
> >>> I thought that the following article would be of interest for you:
> >>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
> >>>
> >>> Here is text from
> >>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-
> your
> >>> -map.html
> >>> "
> >>> My Location is a new beta technology from Google that uses cell =
tower
> >>> identification to provide you with approximate location =
information,
> so
> >>> it will work on phones without GPS.
> >>> "
> >>> Note that this stuff is not really new technology. It existed =
already
> >>> for some time but the availability of GPS devices made it possible =
to
> >>> setup the database in a more efficient way.
> >>>
> >>> Anyway, this mechanism allows you to obtain location information =
with
> >>> your cell phone (using the cell id) without interacting with the
> >>> cellular operator.
> >>> In short: operator cannot charge for location
> >>>
> >>> While the location information is not really useful for first
> responders
> >>>
> >>> it is still good enough for finding the closest PSAP.
> >>>
> >>> Is this the dead of location hiding?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> Ecrit@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/ecrit
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> Ecrit@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/ecrit
> >>>
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ecrit
> >>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 12:14:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0gmB-00078F-4H; Fri, 07 Dec 2007 12:14:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gm9-000786-GR
	for ecrit@ietf.org; Fri, 07 Dec 2007 12:14:09 -0500
Received: from brinza.cc.columbia.edu ([128.59.29.8])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0gm8-0001gp-Kc
	for ecrit@ietf.org; Fri, 07 Dec 2007 12:14:09 -0500
Received: from [130.129.85.85] ([130.129.85.85]) (user=hgs10 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lB7HDS0o003312
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 7 Dec 2007 12:13:45 -0500 (EST)
Message-Id: <45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu>
From: Henning Schulzrinne 
To: "Liess, Laura" 
In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
Date: Fri, 7 Dec 2007 12:13:27 -0500
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net>
	<06c501c8368b$96348ec0$0e99f544@cis.neustar.com>
	<182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de>
X-Mailer: Apple Mail (2.915)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5bfa71b340354e384155def5e70b13b
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Laura,

just because somebody says "we need it" doesn't make it an IETF =20
requirement. Please justify why mobile access cannot provide locations =20=

to end users.

Henning

On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:

> Brian,
>
> I checked with my company and we need LH for both civic and geo for =20=

> fixed and mobile access. Only DSL and civic is not an option.
>
> I would support sending the ESRP/PSAP URI to the UA, as proposed by =20=

> Barbara and James some weeks ago.
>
> Laura
>
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Brian Rosen [mailto:br@brianrosen.net]
> Gesendet: Dienstag, 4. Dezember 2007 16:37
> An: 'Hannes Tschofenig'
> Cc: 'ECRIT'
> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
>
> Proposed text for framework
>
> Some access networks wish to restrict who can get a high quality =20
> location,
> possibly based on a payment arrangement.  For emergency calls, high =20=

> quality
> location must be provided.  An access network can reasonably be =20
> expected to
> have a relationship with the PSAPs in its catchment area, so giving =20=

> location
> to the PSAP will be straightforward
>
>
> However, an endpoint may need location
> for routing, and a proxy may need to verify that a purported =20
> emergency call
> is targeted at a bona fide PSAP.  To do so, it may take the location =20=

> passed
> with the call and query LoST to confirm that the URI is genuine.  =20
> "Hiding"
> location interferes with this check.  To achieve location hiding, =20
> the LIS
> can return a coarse location which is good enough to elicit the same
> response from LoST as the actual location would.  The endpoint and =20
> the proxy
> can use this location to route and verify.  A suitable location for =20=

> a geo is
> a polygon calculated by intersecting the service boundaries of all =20
> of the
> emergency services that respond to the actual location.  A suitable =20=

> location
> for a civic is any civic location within the intersection of the =20
> service
> boundaries of emergency services.  In a great many cases, a country =20=

> code is
> sufficient.  In others a state/province or a city name is =20
> sufficient.  Of
> course, the LIS would always return a location reference, which =20
> would return
> high quality location for a PSAP and coarse location to the endpoint =20=

> or any
> proxy unknown to the LIS.
>
> Proposed text for phonebcp:
>
> A LIS who wishes to hide location returns a location reference.  When
> dereferenced by the endpoint or proxy:
> 1. For LIS's returning geo:
>    For each location served by the LIS, compute the intersection of =20=

> the
>    service boundaries for all emergency services known to LoST for the
>    location. Return the resulting polygon, or any point in the =20
> polygon as
>    the value during a dereference
> 2. For LIS's returning civic:
>    Determine a civic location which is within the service boundary =20
> of all
>    emergency services known to LoST for the location.  In a great many
>    cases, this will be a country code, province/state or city. =20
> Return this
>    coarse civic location as the value during a dereference
> Note that the service boundaries returned from LoST have a TTL, the
> intersections MUST recalculated if the service boundary changes.  =20
> The LIS
> MUST return high quality location to a PSAP or ESRP.
>
> Brian
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Monday, December 03, 2007 1:38 PM
>> To: Brian Rosen
>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
>>
>> Hi Brian,
>>
>> Brian Rosen wrote:
>>> It's fine with me if there is a separate doc, but framework and =20
>>> phonebcp
>>> have to reference it.
>>>
>> Are we talking about informative or normative references?
>>> I think it can be solved with a one paragraph description of the =20
>>> problem
>> in
>>> framework and a one paragraph solution in phonebcp, but if there =20
>>> is a
>>> separate doc and a reference, I will be happy.
>>>
>> That does not make sense.
>> The solution is not one paragraph and the text in phone bcp is =20
>> normative.
>>
>> Ciao
>> Hannes
>>
>>> Brian
>>>
>>>
>>>> -----Original Message-----
>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
>>>> Sent: Monday, December 03, 2007 7:37 PM
>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
>>>>
>>>> Currently, the WG (and document editors!) should be operating under
>>>> the consensus direction that Location Hiding *not* be in PhoneBCP =20=

>>>> or
>>>> Framework.  This was a clear consensus call in Chicago - and not by
>>>> default, but by most people voicing actively against having this
>>>> Hiding in either core ECRIT documents, and I haven't yet talked to
>>>> anyone here in Vancouver that thinks otherwise.
>>>>
>>>> Location Hiding is something that needs to be addressed BY ITSELF
>>>> (i.e., in its own doc) so everyone can focus on the singular topic,
>>>> and work towards not talking past each other (not like that's
>>>> happened before in ECRIT....  :-/
>>>>
>>>> Who disagrees with this?
>>>>
>>>> BTW - if someone thinks Location Hiding should be put back into
>>>> PhoneBCP or Framework, then they can attempt to gain WG consensus =20=

>>>> on
>>>> that, but that's different than a direction of this inevitability =20=

>>>> or
>>>> that there is not consensus on this.
>>>>
>>>>
>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
>>>>
>>>>> If people felt this was good enough so that access providers =20
>>>>> would not
>>>>> need to be required to build the infrastructure to provide =20
>>>>> location
>>>>> (because people could use this method instead of getting =20
>>>>> location from
>>>>> access providers), then location hiding would be dead. If people =20=

>>>>> still
>>>>> want to place a requirement on access providers to provide =20
>>>>> location,
>>>>> then location hiding is not dead.
>>>>> Barbara
>>>>>
>>>>> -----Original Message-----
>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>>> Sent: Saturday, December 01, 2007 3:34 PM
>>>>> To: ECRIT
>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
>>>>>
>>>>> I thought that the following article would be of interest for you:
>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
>>>>>
>>>>> Here is text from
>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-
>> your
>>>>> -map.html
>>>>> "
>>>>> My Location is a new beta technology from Google that uses cell =20=

>>>>> tower
>>>>> identification to provide you with approximate location =20
>>>>> information,
>> so
>>>>> it will work on phones without GPS.
>>>>> "
>>>>> Note that this stuff is not really new technology. It existed =20
>>>>> already
>>>>> for some time but the availability of GPS devices made it =20
>>>>> possible to
>>>>> setup the database in a more efficient way.
>>>>>
>>>>> Anyway, this mechanism allows you to obtain location information =20=

>>>>> with
>>>>> your cell phone (using the cell id) without interacting with the
>>>>> cellular operator.
>>>>> In short: operator cannot charge for location
>>>>>
>>>>> While the location information is not really useful for first
>> responders
>>>>>
>>>>> it is still good enough for finding the closest PSAP.
>>>>>
>>>>> Is this the dead of location hiding?
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 15:33:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0jsg-0003wD-Vd; Fri, 07 Dec 2007 15:33:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0jsg-0003w7-7i
	for ecrit@ietf.org; Fri, 07 Dec 2007 15:33:06 -0500
Received: from aismt06p.bellsouth.com ([139.76.165.211])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0jsf-0007oK-P2
	for ecrit@ietf.org; Fri, 07 Dec 2007 15:33:06 -0500
Received: from ([139.76.131.79])
	by aismt06p.bellsouth.com with ESMTP  id KP-AXPRN.35526625;
	Fri, 07 Dec 2007 15:32:55 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by
	01GAF5142010621.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Fri, 7 Dec 2007 15:32:54 -0500
Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by
	01NC27689010627.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Fri, 7 Dec 2007 15:32:54 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 7 Dec 2007 15:32:54 -0500
Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Location Hiding
thread-index: Acg5EFgQnjDlWcp4R4+TmTuoaV9AJA==
From: "Stark, Barbara" 
To: "ECRIT" 
X-OriginalArrivalTime: 07 Dec 2007 20:32:54.0934 (UTC)
	FILETIME=[58A22360:01C83910]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Subject: [Ecrit] Location Hiding
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Now that I've had a few days to calm down after having been accused of
unethical behavior, I'd like to state that:

Location Hiding is a required for me to support (and convince my company
to support) the IETF location configuration methodology and its use in
the ecrit architecture.

For the near-term, I'm willing to accept the "coarse location" method
for civic-only.

This is because my near-term needs deal largely with civic locations:
 - cellular is handled by current cellular technology; emergency calls
over the cellular data network are not supported and not mandated at
this time
 - Wi-Fi hotspots and mesh can be handled with civic location of the
access point
 - the few places where fixed pre-WiMAX is offered will need to be
handled with static (stored by the VSP) or manual location, or through
some other method; there aren't that many, so we can perhaps have a
special solution for them, if necessary

If and when we really support emergency calls over WiMAX and/or the data
cellular connection, it is likely that we would not want to hand out
precise location values to end devices.

If this upsets some people and they go and get devices that can
completely do their own GPS location determination, then so be it.
People are free to use whatever devices they want to, that can accept a
SIM card.

But if some agency wants to place a new mandate on the wireless
provider, to provide location to be used for emergency calling over a
data connection, then we will want location hiding supported in the
wireless environment.=20

If IETF doesn't want to work this case, we can probably work it in 3GPP
and the WiMAX Forum. My understanding is, it's been a known item in 3GPP
IMS for awhile -- just not a high enough priority to actually get worked
on.

If IETF does want to work it, I would like to see the following new work
items (which do not need to hold up existing work):
 - Once LoST is published, I would like to see work done to provide a
mechanism to verify if a particular URI is valid for a given service.=20
 - I'd like to see a HELD extension defined that would send back LoST
response items

Barbara

*****

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

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 16:25:15 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0kh4-0001Um-Ja; Fri, 07 Dec 2007 16:25:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kh3-0001Ue-7R
	for ecrit@ietf.org; Fri, 07 Dec 2007 16:25:09 -0500
Received: from aismt07p.bellsouth.com ([139.76.165.213])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0kh2-0003zK-0p
	for ecrit@ietf.org; Fri, 07 Dec 2007 16:25:09 -0500
Received: from ([139.76.131.83])
	by aismt07p.bellsouth.com with ESMTP  id KP-AXPTB.190397391;
	Fri, 07 Dec 2007 16:24:54 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by
	01GAF5142010622.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Fri, 7 Dec 2007 16:24:54 -0500
Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by
	01NC27689010627.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Fri, 7 Dec 2007 16:24:53 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Fri, 7 Dec 2007 16:24:52 -0500
Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
In-Reply-To: <45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
thread-index: Acg49Kor7aEnaYX8SN+92341Ptw6XAAG+BQg
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de>
	<45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu>
From: "Stark, Barbara" 
To: "Henning Schulzrinne" , "Liess,
	Laura" 
X-OriginalArrivalTime: 07 Dec 2007 21:24:53.0814 (UTC)
	FILETIME=[9BA17560:01C83917]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 142a000676f5977e1797396caab8b611
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

[The following statements are my opinion, and should not be attributed =
to the company I work for.]

Henning,
It's true that the IETF doesn't have to do something just because =
someone wants it. It's also true that the IETF has no authority or =
ability to force implementation of RFCs by companies who refuse to =
implement them. You cannot shove a solution down the throats of access =
providers that they are unwilling to buy in to. In my opinion, even =
attempting to do so would be, well, unethical.

So, you have a choice:=20
1) create a solution that you like that major stakeholders are unwilling =
to implement
2) create a solution that you don't quite like, but that's better than =
what we have today, and which major stakeholders are willing to =
implement

Believe it or not, major telecom companies in the US and Europe put a =
lot of effort into lobbying regulatory bodies, to achieve desirable =
outcomes. The IETF doesn't put in such effort. If you want to make a go =
at pushing through a solution that stakeholders in these regions are set =
against, and see if you can get regulatory agencies to bless it, then go =
for it. I think the odds are stacked against you, though. Especially =
since there are workable solutions that these companies have said they =
would be willing to accept.

Here is why mobile access providers "cannot" provide the best available =
location directly to end user devices: They don't want to. At this point =
in time, it's their network, their data, and their choice.

In free market economies, you generally have to be able to *prove* (and =
not just say it without proof) massive benefit or massive harm before =
you can force companies to do what they don't want to do, through =
regulation. Again, if you think you can take on that battle and win, go =
for it.

I, for one, believe that not providing the "real" location value to end =
devices would not cause such benefit or harm. If users want to know what =
location PSAPs get on their behalf, and regulators believe such a =
capability is needed, then we can let the phonebcp-described test =
mechanism voice it back over the voice medium (this would only work for =
civic), or return a JPEG map with a dot on it. This would provide =
location in a format that's usable by a human being, but not an =
application. Or maybe, in some countries, the regulators do require =
access providers to give out the best possible location values to end =
devices. But it's really improbable that you could force the regulators =
of all countries to see things your way.

But, this is all just my opinion.
Barbara

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20
Sent: Friday, December 07, 2007 12:13 PM
To: Liess, Laura
Cc: ecrit@ietf.org
Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art

Laura,

just because somebody says "we need it" doesn't make it an IETF =20
requirement. Please justify why mobile access cannot provide locations =20
to end users.

Henning

On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:

> Brian,
>
> I checked with my company and we need LH for both civic and geo for =20
> fixed and mobile access. Only DSL and civic is not an option.
>
> I would support sending the ESRP/PSAP URI to the UA, as proposed by =20
> Barbara and James some weeks ago.
>
> Laura
>
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Brian Rosen [mailto:br@brianrosen.net]
> Gesendet: Dienstag, 4. Dezember 2007 16:37
> An: 'Hannes Tschofenig'
> Cc: 'ECRIT'
> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
>
> Proposed text for framework
>
> Some access networks wish to restrict who can get a high quality =20
> location,
> possibly based on a payment arrangement.  For emergency calls, high =20
> quality
> location must be provided.  An access network can reasonably be =20
> expected to
> have a relationship with the PSAPs in its catchment area, so giving =20
> location
> to the PSAP will be straightforward
>
>
> However, an endpoint may need location
> for routing, and a proxy may need to verify that a purported =20
> emergency call
> is targeted at a bona fide PSAP.  To do so, it may take the location =20
> passed
> with the call and query LoST to confirm that the URI is genuine.  =20
> "Hiding"
> location interferes with this check.  To achieve location hiding, =20
> the LIS
> can return a coarse location which is good enough to elicit the same
> response from LoST as the actual location would.  The endpoint and =20
> the proxy
> can use this location to route and verify.  A suitable location for =20
> a geo is
> a polygon calculated by intersecting the service boundaries of all =20
> of the
> emergency services that respond to the actual location.  A suitable =20
> location
> for a civic is any civic location within the intersection of the =20
> service
> boundaries of emergency services.  In a great many cases, a country =20
> code is
> sufficient.  In others a state/province or a city name is =20
> sufficient.  Of
> course, the LIS would always return a location reference, which =20
> would return
> high quality location for a PSAP and coarse location to the endpoint =20
> or any
> proxy unknown to the LIS.
>
> Proposed text for phonebcp:
>
> A LIS who wishes to hide location returns a location reference.  When
> dereferenced by the endpoint or proxy:
> 1. For LIS's returning geo:
>    For each location served by the LIS, compute the intersection of =20
> the
>    service boundaries for all emergency services known to LoST for the
>    location. Return the resulting polygon, or any point in the =20
> polygon as
>    the value during a dereference
> 2. For LIS's returning civic:
>    Determine a civic location which is within the service boundary =20
> of all
>    emergency services known to LoST for the location.  In a great many
>    cases, this will be a country code, province/state or city. =20
> Return this
>    coarse civic location as the value during a dereference
> Note that the service boundaries returned from LoST have a TTL, the
> intersections MUST recalculated if the service boundary changes.  =20
> The LIS
> MUST return high quality location to a PSAP or ESRP.
>
> Brian
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Monday, December 03, 2007 1:38 PM
>> To: Brian Rosen
>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
>>
>> Hi Brian,
>>
>> Brian Rosen wrote:
>>> It's fine with me if there is a separate doc, but framework and =20
>>> phonebcp
>>> have to reference it.
>>>
>> Are we talking about informative or normative references?
>>> I think it can be solved with a one paragraph description of the =20
>>> problem
>> in
>>> framework and a one paragraph solution in phonebcp, but if there =20
>>> is a
>>> separate doc and a reference, I will be happy.
>>>
>> That does not make sense.
>> The solution is not one paragraph and the text in phone bcp is =20
>> normative.
>>
>> Ciao
>> Hannes
>>
>>> Brian
>>>
>>>
>>>> -----Original Message-----
>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
>>>> Sent: Monday, December 03, 2007 7:37 PM
>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
>>>>
>>>> Currently, the WG (and document editors!) should be operating under
>>>> the consensus direction that Location Hiding *not* be in PhoneBCP =20
>>>> or
>>>> Framework.  This was a clear consensus call in Chicago - and not by
>>>> default, but by most people voicing actively against having this
>>>> Hiding in either core ECRIT documents, and I haven't yet talked to
>>>> anyone here in Vancouver that thinks otherwise.
>>>>
>>>> Location Hiding is something that needs to be addressed BY ITSELF
>>>> (i.e., in its own doc) so everyone can focus on the singular topic,
>>>> and work towards not talking past each other (not like that's
>>>> happened before in ECRIT....  :-/
>>>>
>>>> Who disagrees with this?
>>>>
>>>> BTW - if someone thinks Location Hiding should be put back into
>>>> PhoneBCP or Framework, then they can attempt to gain WG consensus =20
>>>> on
>>>> that, but that's different than a direction of this inevitability =20
>>>> or
>>>> that there is not consensus on this.
>>>>
>>>>
>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
>>>>
>>>>> If people felt this was good enough so that access providers =20
>>>>> would not
>>>>> need to be required to build the infrastructure to provide =20
>>>>> location
>>>>> (because people could use this method instead of getting =20
>>>>> location from
>>>>> access providers), then location hiding would be dead. If people =20
>>>>> still
>>>>> want to place a requirement on access providers to provide =20
>>>>> location,
>>>>> then location hiding is not dead.
>>>>> Barbara
>>>>>
>>>>> -----Original Message-----
>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>>> Sent: Saturday, December 01, 2007 3:34 PM
>>>>> To: ECRIT
>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
>>>>>
>>>>> I thought that the following article would be of interest for you:
>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
>>>>>
>>>>> Here is text from
>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-
>> your
>>>>> -map.html
>>>>> "
>>>>> My Location is a new beta technology from Google that uses cell =20
>>>>> tower
>>>>> identification to provide you with approximate location =20
>>>>> information,
>> so
>>>>> it will work on phones without GPS.
>>>>> "
>>>>> Note that this stuff is not really new technology. It existed =20
>>>>> already
>>>>> for some time but the availability of GPS devices made it =20
>>>>> possible to
>>>>> setup the database in a more efficient way.
>>>>>
>>>>> Anyway, this mechanism allows you to obtain location information =20
>>>>> with
>>>>> your cell phone (using the cell id) without interacting with the
>>>>> cellular operator.
>>>>> In short: operator cannot charge for location
>>>>>
>>>>> While the location information is not really useful for first
>> responders
>>>>>
>>>>> it is still good enough for finding the closest PSAP.
>>>>>
>>>>> Is this the dead of location hiding?
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

*****

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

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 16:36:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0kre-0000bb-Sz; Fri, 07 Dec 2007 16:36:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0krd-0000bV-MF
	for ecrit@ietf.org; Fri, 07 Dec 2007 16:36:05 -0500
Received: from ironportdmz5.qualcomm.com ([199.106.114.254]
	helo=wolverine01.qualcomm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0krd-0004rP-7E
	for ecrit@ietf.org; Fri, 07 Dec 2007 16:36:05 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Content-Type;
	b=RT6yfki59R3nfiQ8RqL3/v/WfuYy8ytr4fcfRqYASiKLe70T7xid389p
	7liXUilis5OHTahijiYMzsnz9kE83KunwJJYrwhc17MSd7d9hb8eAP+bq
	SgabB49I53QZo++C7GKIOsF32Oujm65+MmDmcKHqie1KVaYkALsLGF4oP
	c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CACVLWUeBLjM6/2dsb2JhbAA
X-IronPort-AV: E=McAfee;i="5100,188,5180"; a="26325"
Received: from numenor.qualcomm.com ([129.46.51.58])
	by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	07 Dec 2007 13:36:04 -0800
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lB7La3WF018989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Dec 2007 13:36:04 -0800
Received: from [130.129.17.237] (vpn-10-50-0-8.qualcomm.com [10.50.0.8])
	by neophyte.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lB7La2QI029677; Fri, 7 Dec 2007 13:36:03 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p>
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p>
Date: Fri, 7 Dec 2007 13:36:01 -0800
To: "Stark, Barbara" , "ECRIT" 
From: Ted Hardie 
Subject: Re: [Ecrit] Location Hiding
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 3:32 PM -0500 12/7/07, Stark, Barbara wrote:
>
> - Once LoST is published, I would like to see work done to provide a
>mechanism to verify if a particular URI is valid for a given service.
> - I'd like to see a HELD extension defined that would send back LoST
>response items
>
>Barbara
>

So I'm a bit confused about what you mean by the first, can you
clarify?

I also think that what you are asking for the second is actually
two services (held/lost) that may happen to be on the same box.
Doing  that combination in a single box is no problem; combining
the protocol interfaces may not make sense.
			regards,
				Ted

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 16:56:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0lAw-0007VS-0L; Fri, 07 Dec 2007 16:56:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lAv-0007Qp-Bt
	for ecrit@ietf.org; Fri, 07 Dec 2007 16:56:01 -0500
Received: from jalapeno.cc.columbia.edu ([128.59.29.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0lAu-0006Wy-46
	for ecrit@ietf.org; Fri, 07 Dec 2007 16:56:01 -0500
Received: from dhcp21.cs.columbia.edu (dhcp21.cs.columbia.edu [128.59.19.221])
	(user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id
	lB7Ltln8010372
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 7 Dec 2007 16:55:50 -0500 (EST)
Message-Id: 
From: Henning Schulzrinne 
To: "Stark, Barbara" 
In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
Date: Fri, 7 Dec 2007 16:55:46 -0500
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de>
	<45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
X-Mailer: Apple Mail (2.915)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: -1.0 (-)
X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Translation: You have more lobbyists than I (or the IETF), so give me. =20=

Thanks for clarifying that.

Henning

On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:

> [The following statements are my opinion, and should not be =20
> attributed to the company I work for.]
>
> Henning,
> It's true that the IETF doesn't have to do something just because =20
> someone wants it. It's also true that the IETF has no authority or =20
> ability to force implementation of RFCs by companies who refuse to =20
> implement them. You cannot shove a solution down the throats of =20
> access providers that they are unwilling to buy in to. In my =20
> opinion, even attempting to do so would be, well, unethical.
>
> So, you have a choice:
> 1) create a solution that you like that major stakeholders are =20
> unwilling to implement
> 2) create a solution that you don't quite like, but that's better =20
> than what we have today, and which major stakeholders are willing to =20=

> implement
>
> Believe it or not, major telecom companies in the US and Europe put =20=

> a lot of effort into lobbying regulatory bodies, to achieve =20
> desirable outcomes. The IETF doesn't put in such effort. If you want =20=

> to make a go at pushing through a solution that stakeholders in =20
> these regions are set against, and see if you can get regulatory =20
> agencies to bless it, then go for it. I think the odds are stacked =20
> against you, though. Especially since there are workable solutions =20
> that these companies have said they would be willing to accept.
>
> Here is why mobile access providers "cannot" provide the best =20
> available location directly to end user devices: They don't want to. =20=

> At this point in time, it's their network, their data, and their =20
> choice.
>
> In free market economies, you generally have to be able to *prove* =20
> (and not just say it without proof) massive benefit or massive harm =20=

> before you can force companies to do what they don't want to do, =20
> through regulation. Again, if you think you can take on that battle =20=

> and win, go for it.
>
> I, for one, believe that not providing the "real" location value to =20=

> end devices would not cause such benefit or harm. If users want to =20
> know what location PSAPs get on their behalf, and regulators believe =20=

> such a capability is needed, then we can let the phonebcp-described =20=

> test mechanism voice it back over the voice medium (this would only =20=

> work for civic), or return a JPEG map with a dot on it. This would =20
> provide location in a format that's usable by a human being, but not =20=

> an application. Or maybe, in some countries, the regulators do =20
> require access providers to give out the best possible location =20
> values to end devices. But it's really improbable that you could =20
> force the regulators of all countries to see things your way.
>
> But, this is all just my opinion.
> Barbara
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, December 07, 2007 12:13 PM
> To: Liess, Laura
> Cc: ecrit@ietf.org
> Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
>
> Laura,
>
> just because somebody says "we need it" doesn't make it an IETF
> requirement. Please justify why mobile access cannot provide locations
> to end users.
>
> Henning
>
> On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
>
>> Brian,
>>
>> I checked with my company and we need LH for both civic and geo for
>> fixed and mobile access. Only DSL and civic is not an option.
>>
>> I would support sending the ESRP/PSAP URI to the UA, as proposed by
>> Barbara and James some weeks ago.
>>
>> Laura
>>
>>
>>
>> -----Urspr=FCngliche Nachricht-----
>> Von: Brian Rosen [mailto:br@brianrosen.net]
>> Gesendet: Dienstag, 4. Dezember 2007 16:37
>> An: 'Hannes Tschofenig'
>> Cc: 'ECRIT'
>> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
>>
>> Proposed text for framework
>>
>> Some access networks wish to restrict who can get a high quality
>> location,
>> possibly based on a payment arrangement.  For emergency calls, high
>> quality
>> location must be provided.  An access network can reasonably be
>> expected to
>> have a relationship with the PSAPs in its catchment area, so giving
>> location
>> to the PSAP will be straightforward
>>
>>
>> However, an endpoint may need location
>> for routing, and a proxy may need to verify that a purported
>> emergency call
>> is targeted at a bona fide PSAP.  To do so, it may take the location
>> passed
>> with the call and query LoST to confirm that the URI is genuine.
>> "Hiding"
>> location interferes with this check.  To achieve location hiding,
>> the LIS
>> can return a coarse location which is good enough to elicit the same
>> response from LoST as the actual location would.  The endpoint and
>> the proxy
>> can use this location to route and verify.  A suitable location for
>> a geo is
>> a polygon calculated by intersecting the service boundaries of all
>> of the
>> emergency services that respond to the actual location.  A suitable
>> location
>> for a civic is any civic location within the intersection of the
>> service
>> boundaries of emergency services.  In a great many cases, a country
>> code is
>> sufficient.  In others a state/province or a city name is
>> sufficient.  Of
>> course, the LIS would always return a location reference, which
>> would return
>> high quality location for a PSAP and coarse location to the endpoint
>> or any
>> proxy unknown to the LIS.
>>
>> Proposed text for phonebcp:
>>
>> A LIS who wishes to hide location returns a location reference.  When
>> dereferenced by the endpoint or proxy:
>> 1. For LIS's returning geo:
>>   For each location served by the LIS, compute the intersection of
>> the
>>   service boundaries for all emergency services known to LoST for the
>>   location. Return the resulting polygon, or any point in the
>> polygon as
>>   the value during a dereference
>> 2. For LIS's returning civic:
>>   Determine a civic location which is within the service boundary
>> of all
>>   emergency services known to LoST for the location.  In a great many
>>   cases, this will be a country code, province/state or city.
>> Return this
>>   coarse civic location as the value during a dereference
>> Note that the service boundaries returned from LoST have a TTL, the
>> intersections MUST recalculated if the service boundary changes.
>> The LIS
>> MUST return high quality location to a PSAP or ESRP.
>>
>> Brian
>>
>>> -----Original Message-----
>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>> Sent: Monday, December 03, 2007 1:38 PM
>>> To: Brian Rosen
>>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
>>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
>>>
>>> Hi Brian,
>>>
>>> Brian Rosen wrote:
>>>> It's fine with me if there is a separate doc, but framework and
>>>> phonebcp
>>>> have to reference it.
>>>>
>>> Are we talking about informative or normative references?
>>>> I think it can be solved with a one paragraph description of the
>>>> problem
>>> in
>>>> framework and a one paragraph solution in phonebcp, but if there
>>>> is a
>>>> separate doc and a reference, I will be happy.
>>>>
>>> That does not make sense.
>>> The solution is not one paragraph and the text in phone bcp is
>>> normative.
>>>
>>> Ciao
>>> Hannes
>>>
>>>> Brian
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
>>>>> Sent: Monday, December 03, 2007 7:37 PM
>>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
>>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
>>>>>
>>>>> Currently, the WG (and document editors!) should be operating =20
>>>>> under
>>>>> the consensus direction that Location Hiding *not* be in PhoneBCP
>>>>> or
>>>>> Framework.  This was a clear consensus call in Chicago - and not =20=

>>>>> by
>>>>> default, but by most people voicing actively against having this
>>>>> Hiding in either core ECRIT documents, and I haven't yet talked to
>>>>> anyone here in Vancouver that thinks otherwise.
>>>>>
>>>>> Location Hiding is something that needs to be addressed BY ITSELF
>>>>> (i.e., in its own doc) so everyone can focus on the singular =20
>>>>> topic,
>>>>> and work towards not talking past each other (not like that's
>>>>> happened before in ECRIT....  :-/
>>>>>
>>>>> Who disagrees with this?
>>>>>
>>>>> BTW - if someone thinks Location Hiding should be put back into
>>>>> PhoneBCP or Framework, then they can attempt to gain WG consensus
>>>>> on
>>>>> that, but that's different than a direction of this inevitability
>>>>> or
>>>>> that there is not consensus on this.
>>>>>
>>>>>
>>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
>>>>>
>>>>>> If people felt this was good enough so that access providers
>>>>>> would not
>>>>>> need to be required to build the infrastructure to provide
>>>>>> location
>>>>>> (because people could use this method instead of getting
>>>>>> location from
>>>>>> access providers), then location hiding would be dead. If people
>>>>>> still
>>>>>> want to place a requirement on access providers to provide
>>>>>> location,
>>>>>> then location hiding is not dead.
>>>>>> Barbara
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>>>> Sent: Saturday, December 01, 2007 3:34 PM
>>>>>> To: ECRIT
>>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
>>>>>>
>>>>>> I thought that the following article would be of interest for =20
>>>>>> you:
>>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
>>>>>>
>>>>>> Here is text from
>>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-
>>> your
>>>>>> -map.html
>>>>>> "
>>>>>> My Location is a new beta technology from Google that uses cell
>>>>>> tower
>>>>>> identification to provide you with approximate location
>>>>>> information,
>>> so
>>>>>> it will work on phones without GPS.
>>>>>> "
>>>>>> Note that this stuff is not really new technology. It existed
>>>>>> already
>>>>>> for some time but the availability of GPS devices made it
>>>>>> possible to
>>>>>> setup the database in a more efficient way.
>>>>>>
>>>>>> Anyway, this mechanism allows you to obtain location information
>>>>>> with
>>>>>> your cell phone (using the cell id) without interacting with the
>>>>>> cellular operator.
>>>>>> In short: operator cannot charge for location
>>>>>>
>>>>>> While the location information is not really useful for first
>>> responders
>>>>>>
>>>>>> it is still good enough for finding the closest PSAP.
>>>>>>
>>>>>> Is this the dead of location hiding?
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> Ecrit@ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> Ecrit@ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ecrit
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ecrit
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>
> *****
>
> The information transmitted is intended only for the person or =20
> entity to which it is addressed and may contain confidential, =20
> proprietary, and/or privileged material. Any review, retransmission, =20=

> dissemination or other use of, or taking of any action in reliance =20
> upon this information by persons or entities other than the intended =20=

> recipient is prohibited. If you received this in error, please =20
> contact the sender and delete the material from all computers. GA622
>
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 17:00:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0lFU-00066S-QG; Fri, 07 Dec 2007 17:00:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lFT-00062H-6t
	for ecrit@ietf.org; Fri, 07 Dec 2007 17:00:43 -0500
Received: from mx12.bbn.com ([128.33.0.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0lFR-0006sK-1V
	for ecrit@ietf.org; Fri, 07 Dec 2007 17:00:43 -0500
Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1])
	by mx12.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1J0lFQ-0000dH-4N; Fri, 07 Dec 2007 17:00:40 -0500
Message-ID: <4759C282.8080200@bbn.com>
Date: Fri, 07 Dec 2007 14:00:34 -0800
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Ted Hardie 
Subject: Re: [Ecrit] Location Hiding
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p>

In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Ted,

I think I can answer your questions by paraphrasing what Barbara said:

>> - Once LoST is published, I would like to see work done to provide a
>> mechanism to verify if a particular URI is valid for a given service.

This mechanism has sometimes gone under the name "reverse LoST". 
Currently, in order to ask LoST whether a URI is a PSAP URI, you have to 
know a URN and a location to ask for in order to obtain that URI (as the 
URI for that service at that location).  "Reverse LoST" would remove the 
need for the URN+location by having an explicit request/response where 
the request contains a URI and the response contains a 
URN+serviceBoundary if the URI is known, and an error if it's not.

>> - I'd like to see a HELD extension defined that would send back LoST
>> response items

In talking with James about this, we've referred to it as "tunneling 
LoST through HELD".  The major problem with location hiding is that you 
want the LoST server to have access to precise location, but not the 
user.  Tunneling LoST through HELD enables this by using the HELD server 
as a "dereferencing proxy" -- it dereferences the location, does the 
LoST query with the precise location, and returns the results.

I much prefer a "mirror image" approach, where we add location URIs as a 
location profile to LoST -- adding LbyR to LoST instead of the other way 
around.  At the cost of requiring a mechanism to discover the local LoST 
server, it maintains the greatest possible degree of separation between 
the two interfaces.

--Richard

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 17:18:38 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0lWl-0002Qs-Uv; Fri, 07 Dec 2007 17:18:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lWj-0002Qh-SY
	for ecrit@ietf.org; Fri, 07 Dec 2007 17:18:33 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0lWj-0008LV-CR
	for ecrit@ietf.org; Fri, 07 Dec 2007 17:18:33 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J0lWZ-0001se-Ex; Fri, 07 Dec 2007 16:18:24 -0600
From: "Brian Rosen" 
To: "'Richard Barnes'" , "'Ted Hardie'" 
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p>
	<4759C282.8080200@bbn.com>
Subject: RE: [Ecrit] Location Hiding
Date: Fri, 7 Dec 2007 17:18:25 -0500
Message-ID: <10e901c8391f$186523b0$0e99f544@cis.neustar.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acg5HJt0LtOh/J1wSuOtFIIK0DKwHQAAYVQQ
In-Reply-To: <4759C282.8080200@bbn.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1
Cc: 'ECRIT' 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0951716216=="
Errors-To: ecrit-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0951716216==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_10EA_01C838F5.2F8F1BB0"

This is a multi-part message in MIME format.

------=_NextPart_000_10EA_01C838F5.2F8F1BB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

To expand on this, there are three mechanisms that have been proposed for
location hiding:

1. Deliver coarse location to anyone but a PSAP.  No protocol changes
needed.

2. Don't ask anyone but a PSAP to dereference.  This requires two changes.
One returns the LoST response with the LCP return (HELD) so the endpoint
never needs location.  However, it also requires a reverse LoST lookup
(validate a PSAP URI) so that a VSP can validate that the call is a bona
fide emergency call

3. Allow location reference in the query to LoST, LoST can get high accuracy
location.

The arguments around these have to do with who has the burden to support
location hiding.  In the first case (coarse location), the LIS has the
burden.  Everyone else pays nothing.  James W doesn't like this, because he
wants the VSP to pay for the necessity to validate that the call is bona
fide.  In the second case, the LoST server has to support the reverse
lookup.  It requires the LIS to support the combination of HELD+LoST.  Of
course, it makes HELD the only LCP that can support location hiding, but
that may not be a problem.  The third approach puts all of the burden on the
LoST server.

Brian

> -----Original Message-----

> From: Richard Barnes [mailto:rbarnes@bbn.com]

> Sent: Friday, December 07, 2007 5:01 PM

> To: Ted Hardie

> Cc: ECRIT

> Subject: Re: [Ecrit] Location Hiding

> 

> Ted,

> 

> I think I can answer your questions by paraphrasing what Barbara said:

> 

> >> - Once LoST is published, I would like to see work done to provide a

> >> mechanism to verify if a particular URI is valid for a given service.

> 

> This mechanism has sometimes gone under the name "reverse LoST".

> Currently, in order to ask LoST whether a URI is a PSAP URI, you have to

> know a URN and a location to ask for in order to obtain that URI (as the

> URI for that service at that location).  "Reverse LoST" would remove the

> need for the URN+location by having an explicit request/response where

> the request contains a URI and the response contains a

> URN+serviceBoundary if the URI is known, and an error if it's not.

> 

> 

> >> - I'd like to see a HELD extension defined that would send back LoST

> >> response items

> 

> In talking with James about this, we've referred to it as "tunneling

> LoST through HELD".  The major problem with location hiding is that you

> want the LoST server to have access to precise location, but not the

> user.  Tunneling LoST through HELD enables this by using the HELD server

> as a "dereferencing proxy" -- it dereferences the location, does the

> LoST query with the precise location, and returns the results.

> 

> I much prefer a "mirror image" approach, where we add location URIs as a

> location profile to LoST -- adding LbyR to LoST instead of the other way

> around.  At the cost of requiring a mechanism to discover the local LoST

> server, it maintains the greatest possible degree of separation between

> the two interfaces.

> 

> --Richard

> 

> 

> 

> 

> _______________________________________________

> Ecrit mailing list

> Ecrit@ietf.org

> https://www1.ietf.org/mailman/listinfo/ecrit

------=_NextPart_000_10EA_01C838F5.2F8F1BB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

To expand on this, there are three mechanisms that have been =
proposed
for location hiding:

1. Deliver coarse location to anyone but a PSAP.  No =
protocol
changes needed.

2. Don't ask anyone but a PSAP to dereference.  This =
requires two
changes.  One returns the LoST response with the LCP return (HELD) =
so the
endpoint never needs location.  However, it also requires a reverse =
LoST
lookup (validate a PSAP URI) so that a VSP can validate that the call is =
a bona
fide emergency call

3. Allow location reference in the query to LoST, LoST can get =
high
accuracy location.

The arguments around these have to do with who has the burden to
support location hiding.  In the first case (coarse location), the =
LIS has
the burden.  Everyone else pays nothing.  James W =
doesn’t like
this, because he wants the VSP to pay for the necessity to validate that =
the
call is bona fide.  In the second case, the LoST server has to =
support the
reverse lookup.  It requires the LIS to support the combination of
HELD+LoST.  Of course, it makes HELD the only LCP that can support
location hiding, but that may not be a problem.  The third approach =
puts
all of the burden on the LoST server.

Brian

> -----Original Message-----

> From: Richard Barnes =
[mailto:rbarnes@bbn.com]

> Sent: Friday, December 07, 2007 5:01 PM

> To: Ted Hardie

> Cc: ECRIT

> Subject: Re: [Ecrit] Location Hiding

> 

> Ted,

> 

> I think I can answer your questions by paraphrasing what =
Barbara
said:

> 

> >> - Once LoST is published, I would like to see work =
done
to provide a

> >> mechanism to verify if a particular URI is valid =
for a
given service.

> 

> This mechanism has sometimes gone under the name =
"reverse
LoST".

> Currently, in order to ask LoST whether a URI is a PSAP =
URI, you
have to

> know a URN and a location to ask for in order to obtain =
that URI
(as the

> URI for that service at that location).  "Reverse
LoST" would remove the

> need for the URN+location by having an explicit =
request/response
where

> the request contains a URI and the response contains =
a

> URN+serviceBoundary if the URI is known, and an error if =
it's not.

> 

> 

> >> - I'd like to see a HELD extension defined that =
would
send back LoST

> >> response items

> 

> In talking with James about this, we've referred to it as
"tunneling

> LoST through HELD".  The major problem with =
location
hiding is that you

> want the LoST server to have access to precise location, =
but not
the

> user.  Tunneling LoST through HELD enables this by =
using the
HELD server

> as a "dereferencing proxy" -- it dereferences the
location, does the

> LoST query with the precise location, and returns the =
results.

> 

> I much prefer a "mirror image" approach, where we =
add
location URIs as a

> location profile to LoST -- adding LbyR to LoST instead of =
the
other way

> around.  At the cost of requiring a mechanism to =
discover the
local LoST

> server, it maintains the greatest possible degree of =
separation
between

> the two interfaces.

> 

> --Richard

> 

> 

> 

> 

> =
_______________________________________________

> Ecrit mailing list

> Ecrit@ietf.org

> =
https://www1.ietf.org/mailman/listinfo/ecrit

------=_NextPart_000_10EA_01C838F5.2F8F1BB0--

--===============0951716216==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--===============0951716216==--

From ecrit-bounces@ietf.org Fri Dec 07 17:24:22 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0lcJ-0002IV-Mw; Fri, 07 Dec 2007 17:24:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lcI-0002IK-Vu
	for ecrit@ietf.org; Fri, 07 Dec 2007 17:24:18 -0500
Received: from ironportdmz5.qualcomm.com ([199.106.114.254]
	helo=wolverine01.qualcomm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0lcH-0000Re-5W
	for ecrit@ietf.org; Fri, 07 Dec 2007 17:24:18 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Cc:Content-Type;
	b=lx6LGgtOV/81m8j+z3bNOpxqg0J1pMxN+bfryyI8iMrwV7nSdBxdywR/
	RhQvsfaWIVXp0VEk0WjuurY2QX6fiZF0rV8OZavjSvuVP/zbQxgnf47kH
	V2U5XtN8xZ49d148EG68fhHYwjTduG9h4xFcuhVSSzIpzvNCptTh9AyFd
	Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAM5WWUeBLjM7/2dsb2JhbACRKg
X-IronPort-AV: E=McAfee;i="5100,188,5180"; a="27576"
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	07 Dec 2007 14:24:16 -0800
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lB7MOFqZ009808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Dec 2007 14:24:15 -0800
Received: from [130.129.17.237] (vpn-10-50-0-8.qualcomm.com [10.50.0.8])
	by neophyte.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lB7MOCGU008800; Fri, 7 Dec 2007 14:24:14 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4759C282.8080200@bbn.com>
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p>
	 <4759C282.8080200@bbn.com>
Date: Fri, 7 Dec 2007 14:24:11 -0800
To: Richard Barnes 
From: Ted Hardie 
Subject: Re: [Ecrit] Location Hiding
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 2:00 PM -0800 12/7/07, Richard Barnes wrote:
>Ted,
>
>I think I can answer your questions by paraphrasing what Barbara said:
>
>>>- Once LoST is published, I would like to see work done to provide a
>>>mechanism to verify if a particular URI is valid for a given service.
>
>This mechanism has sometimes gone under the name "reverse LoST". Currently, in order to ask LoST whether a URI is a PSAP URI, you have to know a URN and a location to ask for in order to obtain that URI (as the URI for that service at that location).  "Reverse LoST" would remove the need for the URN+location by having an explicit request/response where the request contains a URI and the response contains a URN+serviceBoundary if the URI is known, and an error if it's not.

I will leave it to others who deal with PSAPs to see whether they would really
be very happy about this, but I'll note that having the request be URI + service
is far more likely to give you a reasonable answer than the URI alone.  A URI
alone would force a full-scale search of all the service space to get a full result.
Even with a service urn, any answer that doesn't happen to already be in
the cache of the LoST server is going to be ugly to determine; the only way
around it being a flood is to force people to store the information that way.
That gets into jurisdictional issues fast.

>
>>>- I'd like to see a HELD extension defined that would send back LoST
>>>response items
>
>In talking with James about this, we've referred to it as "tunneling LoST through HELD".  The major problem with location hiding is that you want the LoST server to have access to precise location, but not the user.  Tunneling LoST through HELD enables this by using the HELD server as a "dereferencing proxy" -- it dereferences the location, does the LoST

This is still a 2 service approach, combining them into a single box.  In this case,
the HELD server acts as a LIS and LoST proxy. 

>query with the precise location, and returns the results.
>
>I much prefer a "mirror image" approach, where we add location URIs as a location profile to LoST -- adding LbyR to LoST instead of the other way around.  At the cost of requiring a mechanism to discover the local LoST server, it maintains the greatest possible degree of separation between the two interfaces.

I'd need to see something concrete on this, but my initial reaction is that
both tunneling and location URIs as a location profile don't make much sense.
But I may well be misunderstanding your intent, based on a misreading of the
email.
			regards,
				Ted

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 19:16:46 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0nN3-0005ks-Pi; Fri, 07 Dec 2007 19:16:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nN2-0005ka-Iq
	for ecrit@ietf.org; Fri, 07 Dec 2007 19:16:40 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0nMt-0008NY-O7
	for ecrit@ietf.org; Fri, 07 Dec 2007 19:16:40 -0500
X-SEF-Processed: 5_0_0_910__2007_12_07_18_27_31
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Fri, 07 Dec 2007 18:27:31 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 18:16:30 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ecrit] Location Hiding
Date: Fri, 7 Dec 2007 18:16:24 -0600
Message-ID: 
In-Reply-To: <10e901c8391f$186523b0$0e99f544@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Location Hiding
Thread-Index: Acg5HJt0LtOh/J1wSuOtFIIK0DKwHQAAYVQQAAP6/iA=
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p><4759C282.8080200@bbn.com>
	<10e901c8391f$186523b0$0e99f544@cis.neustar.com>
From: "Winterbottom, James" 
To: "Brian Rosen" , "Richard Barnes" ,
	"Ted Hardie" 
X-OriginalArrivalTime: 08 Dec 2007 00:16:30.0737 (UTC)
	FILETIME=[95133810:01C8392F]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e
Cc: ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0147902172=="
Errors-To: ecrit-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0147902172==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8392F.94E5296E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8392F.94E5296E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Okay there is another problem that seems not be being talked about here.=0D=
=0A=0D=0A=20=0D=0A=0D=0AOne of the key aims of location hiding is being abl=
e to restrict who can=0D=0Aget access to location. And one reason that you =
may want to do this is=0D=0Aso you can charge the recipient. I am not sayin=
g that this is the only=0D=0Areason.=0D=0A=0D=0A=20=0D=0A=0D=0AFor this to =
work, the Target, the thing retrieving the token (URI) that=0D=0Apoints to =
their location, needs to know what can dereference the=0D=0Alocation. To my=
 mind this translates to a destination URI and a URN.=0D=0AThis is the reas=
on that I have suggested tunnelling LoST through HELD.=0D=0AThe LIS knows, =
or can find out where the Target it. It gives the Target=0D=0Aa location UR=
I set, and a set of service URNs and associated destination=0D=0AURIs.=0D=0A=0D=
=0A=20=0D=0A=0D=0AProviding a coarse location as has been suggested by simp=
ly won't work=0D=0Afor the majority of value added cases, or the LIS is goi=
ng to have to=0D=0Asuck down every single service boundary for every single=
 possible=0D=0Aservice, intersect them, and then pass that on to the Target=
=2E This is=0D=0Acrazy particularly if the LIS has some 2 million or so dev=
ices hanging=0D=0Aoff it.=0D=0A=0D=0A=20=0D=0A=0D=0AUsing this approach the=
 only VSP issue is now how it determines whether=0D=0Athe call is really em=
ergency or not. There is no issue with calls bound=0D=0Ato non-emergency se=
rvice URNs. Henning and Hannes presented the solution=0D=0Ato this yesterda=
y with their unauthenticated access slide. The Device=0D=0Ahas the address =
of the ESRP, and a location URI, simple send it=0D=0Adirectly. I would stre=
ss also that if we are worried about hop counters=0D=0Aetc, this is going t=
o be far safer than trunking emergency signalling=0D=0Aaround the globe, an=
d keeps the local service local.=0D=0A=0D=0A=20=0D=0A=0D=0ASo when we consi=
der this location hiding we need to consider why we are=0D=0Adoing, and the=
 solution must work for final intent, which is incremental=0D=0Avalue added=
 services.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A  =0D=
=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: B=
rian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Saturday, 8 December 20=
07 9:18 AM=0D=0ATo: 'Richard Barnes'; 'Ted Hardie'=0D=0ACc: 'ECRIT'=0D=0ASu=
bject: RE: [Ecrit] Location Hiding=0D=0A=0D=0A=20=0D=0A=0D=0ATo expand on t=
his, there are three mechanisms that have been proposed=0D=0Afor location h=
iding:=0D=0A=0D=0A1. Deliver coarse location to anyone but a PSAP.  No prot=
ocol changes=0D=0Aneeded.=0D=0A=0D=0A2. Don't ask anyone but a PSAP to dere=
ference.  This requires two=0D=0Achanges.  One returns the LoST response wi=
th the LCP return (HELD) so=0D=0Athe endpoint never needs location.  Howeve=
r, it also requires a reverse=0D=0ALoST lookup (validate a PSAP URI) so tha=
t a VSP can validate that the=0D=0Acall is a bona fide emergency call=0D=0A=0D=
=0A3. Allow location reference in the query to LoST, LoST can get high=0D=0A=
accuracy location.=0D=0A=0D=0A=20=0D=0A=0D=0AThe arguments around these hav=
e to do with who has the burden to support=0D=0Alocation hiding.  In the fi=
rst case (coarse location), the LIS has the=0D=0Aburden.  Everyone else pay=
s nothing.  James W doesn't like this, because=0D=0Ahe wants the VSP to pay=
 for the necessity to validate that the call is=0D=0Abona fide.  In the sec=
ond case, the LoST server has to support the=0D=0Areverse lookup.  It requi=
res the LIS to support the combination of=0D=0AHELD+LoST.  Of course, it ma=
kes HELD the only LCP that can support=0D=0Alocation hiding, but that may n=
ot be a problem.  The third approach puts=0D=0Aall of the burden on the LoS=
T server.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A> -----=
Original Message-----=0D=0A=0D=0A> From: Richard Barnes [mailto:rbarnes@bbn=
=2Ecom]=0D=0A=0D=0A> Sent: Friday, December 07, 2007 5:01 PM=0D=0A=0D=0A> T=
o: Ted Hardie=0D=0A=0D=0A> Cc: ECRIT=0D=0A=0D=0A> Subject: Re: [Ecrit] Loca=
tion Hiding=0D=0A=0D=0A>=20=0D=0A=0D=0A> Ted,=0D=0A=0D=0A>=20=0D=0A=0D=0A> =
I think I can answer your questions by paraphrasing what Barbara said:=0D=0A=0D=
=0A>=20=0D=0A=0D=0A> >> - Once LoST is published, I would like to see work =
done to provide=0D=0Aa=0D=0A=0D=0A> >> mechanism to verify if a particular =
URI is valid for a given=0D=0Aservice.=0D=0A=0D=0A>=20=0D=0A=0D=0A> This me=
chanism has sometimes gone under the name "reverse LoST".=0D=0A=0D=0A> Curr=
ently, in order to ask LoST whether a URI is a PSAP URI, you have=0D=0Ato=0D=
=0A=0D=0A> know a URN and a location to ask for in order to obtain that URI=
 (as=0D=0Athe=0D=0A=0D=0A> URI for that service at that location).  "Revers=
e LoST" would remove=0D=0Athe=0D=0A=0D=0A> need for the URN+location by hav=
ing an explicit request/response where=0D=0A=0D=0A> the request contains a =
URI and the response contains a=0D=0A=0D=0A> URN+serviceBoundary if the URI=
 is known, and an error if it's not.=0D=0A=0D=0A>=20=0D=0A=0D=0A>=20=0D=0A=0D=
=0A> >> - I'd like to see a HELD extension defined that would send back=0D=0A=
LoST=0D=0A=0D=0A> >> response items=0D=0A=0D=0A>=20=0D=0A=0D=0A> In talking=
 with James about this, we've referred to it as "tunneling=0D=0A=0D=0A> LoS=
T through HELD".  The major problem with location hiding is that=0D=0Ayou=0D=
=0A=0D=0A> want the LoST server to have access to precise location, but not=
 the=0D=0A=0D=0A> user.  Tunneling LoST through HELD enables this by using =
the HELD=0D=0Aserver=0D=0A=0D=0A> as a "dereferencing proxy" -- it derefere=
nces the location, does the=0D=0A=0D=0A> LoST query with the precise locati=
on, and returns the results.=0D=0A=0D=0A>=20=0D=0A=0D=0A> I much prefer a "=
mirror image" approach, where we add location URIs as=0D=0Aa=0D=0A=0D=0A> l=
ocation profile to LoST -- adding LbyR to LoST instead of the other=0D=0Awa=
y=0D=0A=0D=0A> around.  At the cost of requiring a mechanism to discover th=
e local=0D=0ALoST=0D=0A=0D=0A> server, it maintains the greatest possible d=
egree of separation=0D=0Abetween=0D=0A=0D=0A> the two interfaces.=0D=0A=0D=0A=
>=20=0D=0A=0D=0A> --Richard=0D=0A=0D=0A>=20=0D=0A=0D=0A>=20=0D=0A=0D=0A> =0D=
=0A=0D=0A>=20=0D=0A=0D=0A> _______________________________________________=0D=
=0A=0D=0A> Ecrit mailing list=0D=0A=0D=0A> Ecrit@ietf.org=0D=0A=0D=0A> http=
s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------=
-------------------------------------------------------------------------=0D=
=0AThis message is for the designated recipient only and may=0D=0Acontain p=
rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h=
ave received it in error, please notify the sender=0D=0Aimmediately and del=
ete the original.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=
=0A------------------------------------------------------------------------=
------------------------=0D=0A[mf2]=0D=0A
------_=_NextPart_001_01C8392F.94E5296E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=
=0D=0A=
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AOkay there is another problem that =
seems=0D=0Anot be being talked about here.=0D=0A=0D=
=0A =
=0D=0A=0D=0AOne of the key aims of location hiding is=0D=0Abeing able to rest=
rict who can get access to location. And one reason that you=0D=0Amay want =
to do this is so you can charge the recipient. I am not saying that=0D=0Ath=
is is the only reason.
=0D=0A=0D=0A =0D=
=0A=0D=0AFor this to=
 work, the Target, the thing=0D=0Aretrieving the token (URI) that points to=
 their location, needs to know what=0D=0Acan dereference the location. To m=
y mind this translates to a destination URI=0D=0Aand a URN. This is the rea=
son that I have suggested tunnelling LoST through=0D=0AHELD. The LIS knows,=
 or can find out where the Target it. It gives the Target a=0D=0Alocation U=
RI set, and a set of service URNs and associated destination URIs.
=0D=0A=0D=0A 
=0D=0A=0D=0AProviding a coarse location as has bee=
n=0D=0Asuggested by simply won’t work for the majority of value added=
 cases, or=0D=0Athe LIS is going to have to suck down every single service =
boundary for every=0D=0Asingle possible service, intersect them, and then p=
ass that on to the Target.=0D=0AThis is crazy particularly if the LIS has s=
ome 2 million or so devices hanging=0D=0Aoff it.=0D=0A=0D=0A
&=
nbsp;
=0D=0A=0D=0AUsing this approach the only VSP issue is=0D=0Anow how=
 it determines whether the call is really emergency or not. There is no=0D=0A=
issue with calls bound to non-emergency service URNs. Henning and Hannes=0D=
=0Apresented the solution to this yesterday with their unauthenticated acce=
ss=0D=0Aslide. The Device has the address of the ESRP, and a location URI, =
simple send=0D=0Ait directly. I would stress also that if we are worried ab=
out hop counters etc,=0D=0Athis is going to be far safer than trunking emer=
gency signalling around the=0D=0Aglobe, and keeps the local service local.<=
o:p>
=0D=0A=0D=0A 
=0D=0A=0D=0ASo when we consider this loc=
ation hiding=0D=0Awe need to consider why we are doing, and the solution mu=
st work for final=0D=0Aintent, which is incremental value added services.
=0D=0A=0D=0A 
=0D=0A=0D=0ACheers=
=0D=0A=0D=0AJame=
s
=0D=0A=0D=0A  =0D=0A=0D=0A<=
p class=3DMsoNormal> 
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=
=0A
=0D=0A=0D=0A
=0D=0A=0D=0AFrom:=0D=0ABri=
an Rosen [mailto:br@brianrosen.net] 
=0D=0ASent: Saturday, 8 December 2007=0D=0A9:18 AM
=0D=0A=
To: 'Richard Barnes'; 'Ted Hard=
ie'
=0D=0ACc: 'ECRIT'
=0D=
=0ASubject: RE: [Ecrit] Loca=
tion=0D=0AHiding=0D=0A=0D=
=0A
=0D=0A=0D=0A 
=0D=0A=0D=0ATo expand on this, th=
ere are three mechanisms that=0D=0Ahave been proposed for location hiding:<=
o:p>
=0D=0A=0D=0A1=
=2E Deliver coarse location to anyone but a PSAP. =0D=0ANo protocol ch=
anges needed.
=0D=0A=0D=0A2. Don't ask anyone but a PSAP to dereference. =0D=0ATh=
is requires two changes.  One returns the LoST response with the LCP=0D=
=0Areturn (HELD) so the endpoint never needs location.  However, it al=
so=0D=0Arequires a reverse LoST lookup (validate a PSAP URI) so that a VSP =
can validate=0D=0Athat the call is a bona fide emergency call
=0D=0A=0D=0A3. Allow loc=
ation reference in the query to LoST, LoST=0D=0Acan get high accuracy locat=
ion.
=0D=0A=0D=0A 
=0D=0A=0D=0AThe arguments around these have to do with who has the=0D=0A=
burden to support location hiding.  In the first case (coarse location=
),=0D=0Athe LIS has the burden.  Everyone else pays nothing.  Jam=
es W=0D=0Adoesn’t like this, because he wants the VSP to pay for the =
necessity to=0D=0Avalidate that the call is bona fide.  In the second =
case, the LoST server=0D=0Ahas to support the reverse lookup.  It requ=
ires the LIS to support the=0D=0Acombination of HELD+LoST.  Of course,=
 it makes HELD the only LCP that can=0D=0Asupport location hiding, but that=
 may not be a problem.  The third=0D=0Aapproach puts all of the burden=
 on the LoST server.
=0D=0A=0D=0A 
=0D=0A=0D=0ABrian=0D=0A=0D=0A=
 =0D=0A=0D=
=0A> -----Original Message-----<=
/o:p>
=0D=0A=0D=0A>=
 From: Richard Barnes [mailto:rbarnes@bbn.com]=0D=
=0A=0D=0A> Sent: Friday, December 07=
, 2007 5:01 PM
=0D=0A=0D=0A> To: Ted Hardie=0D=0A=0D=0A=
> Cc: ECRIT=
=0D=0A=0D=0A> Subject: Re: [Ecri=
t] Location Hiding
=0D=0A=0D=0A> 
=0D=0A=0D=0A> Ted,=0D=0A=0D=0A=
> =0D=0A=0D=
=0A> I think I can answer your questi=
ons by=0D=0Aparaphrasing what Barbara said:=0D=
=0A=0D=0A> =
=0D=0A=0D=0A> >> - Once Lo=
ST is published, I would like=0D=0Ato see work done to provide a=
=0D=0A=0D=0A> >&=
gt; mechanism to verify if a particular URI=0D=0Ais valid for a given servi=
ce.
=0D=0A=0D=0A> 
=0D=0A=0D=0A=
> This mechanism has sometimes gone under the name=0D=0A&quo=
t;reverse LoST".
=0D=0A=0D=0A> Currently, in order to ask LoST whether a URI i=
s=0D=0Aa PSAP URI, you have to
=0D=0A=0D=0A> know a URN and a location to ask for in =
order to=0D=0Aobtain that URI (as the=0D=0A=0D=
=0A> URI for that service at that loc=
ation). =0D=0A"Reverse LoST" would remove the
=0D=0A=0D=0A> need for=
 the URN+location by having an explicit=0D=0Arequest/response where
=0D=0A=0D=0A> t=
he request contains a URI and the response=0D=0Acontains a
=0D=0A=0D=0A> URN+servic=
eBoundary if the URI is known, and an=0D=0Aerror if it's not.
=0D=0A=0D=0A> 
=0D=0A=0D=0A> =
=0D=0A=0D=0A> >> - I'd like to see a HELD extension=0D=0Adefined that would =
send back LoST
=0D=0A=0D=0A> >> response items=0D=
=0A=0D=0A> =
=0D=0A=0D=0A> In talking with Ja=
mes about this, we've referred=0D=0Ato it as "tunneling
=0D=0A=0D=0A> LoST thr=
ough HELD".  The major problem=0D=0Awith location hiding is that =
you
=0D=0A=0D=0A> want the LoST server to have access to precise=0D=0Alocation, but=
 not the
=0D=0A=0D=0A> user.  Tunneling LoST through HELD enables=0D=0Athis by=
 using the HELD server
=0D=0A=0D=0A> as a "dereferencing proxy" -- it=0D=0A=
dereferences the location, does the=0D=0A=0D=0A=
> LoST query with the precise locati=
on, and returns=0D=0Athe results.=0D=0A=0D=0A<=
p class=3DMsoPlainText>> =0D=0A=0D=
=0A> I much prefer a "mirror ima=
ge"=0D=0Aapproach, where we add location URIs as a
=0D=0A=0D=0A> location prof=
ile to LoST -- adding LbyR to LoST=0D=0Ainstead of the other way=
=0D=0A=0D=0A> aroun=
d.  At the cost of requiring a=0D=0Amechanism to discover the local Lo=
ST
=0D=0A=0D=0A> server, it maintains the greatest possible degree=0D=0Aof separati=
on between
=0D=0A=0D=0A=
> the two interfaces.=0D=0A=0D=0A=
> =0D=0A=0D=
=0A> --Richard
=0D=0A=0D=0A> 
=0D=0A=0D=0A> 
=0D=0A=0D=0A> 
=0D=0A=0D=0A&=
gt; 
=0D=0A=0D=0A> _______________________________________________
=0D=0A=0D=0A> Ecrit ma=
iling list
=0D=0A=0D=0A=
> Ecrit@ietf.org
=0D=0A=0D=0A> https://www1.ietf.org/mailman/listinfo/e=
crit
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=
=0A

-------=
---------------------------------------------------------------------------=
--------------
=0D=0AThis message is for the de=
signated recipient only and may
=0D=0Acontain p=
rivileged, proprietary, or otherwise private infor=
mation.  
=0D=0AIf you have received it&nb=
sp;in error, please notify the sender
=0D=0Aimm=
ediately and delete the original.  Any u=
nauthorized use of
=0D=0Athis email is prohibit=
ed.
=0D=0A--------------------------------------------------------------=
----------------------------------
=0D=0A[mf2]=0D=
=0A=0D=0A=0D=0A
------_=_NextPart_001_01C8392F.94E5296E--

--===============0147902172==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--===============0147902172==--

From ecrit-bounces@ietf.org Fri Dec 07 19:33:14 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0nd3-0004rf-NW; Fri, 07 Dec 2007 19:33:13 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nd2-0004rX-2Z
	for ecrit@ietf.org; Fri, 07 Dec 2007 19:33:12 -0500
Received: from ironportdmz5.qualcomm.com ([199.106.114.254]
	helo=wolverine01.qualcomm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0nd0-0001Zy-Nh
	for ecrit@ietf.org; Fri, 07 Dec 2007 19:33:11 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Cc:Content-Type;
	b=LLkNOKUImDO1zd5l36OBjSo2qeEDExQ0Fp7pSdK1YEVegKAnjBRW7yjj
	wQy19mzBiDUaR3f47G3QjvkwTVFtT5PFbxErHbOFfnqktBAVAfH52q+EO
	5JuNggWCR8qbA5fWkyTkWGagCH+urgrcico15Rfc9BIvhMv5xjGmFHmBa
	k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAEZ1WUeBLjM6/2dsb2JhbACRKg
X-IronPort-AV: E=McAfee;i="5100,188,5180"; a="30827"
Received: from numenor.qualcomm.com ([129.46.51.58])
	by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	07 Dec 2007 16:33:09 -0800
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lB80X84V007367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Dec 2007 16:33:08 -0800
Received: from [130.129.17.237] (vpn-10-50-0-8.qualcomm.com [10.50.0.8])
	by sabrina.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lB80X5X5016947; Fri, 7 Dec 2007 16:33:05 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p><4759C282.8080200@bbn.com>
	<10e901c8391f$186523b0$0e99f544@cis.neustar.com>

Date: Fri, 7 Dec 2007 16:32:55 -0800
To: "Winterbottom, James" ,
	"Brian Rosen" , "Richard Barnes" 
From: Ted Hardie 
Subject: RE: [Ecrit] Location Hiding
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 6:16 PM -0600 12/7/07, Winterbottom, James wrote:
>Okay there is another problem that seems not be being talked about here.
> 
>One of the key aims of location hiding is being able to restrict who can get access to location. And one reason that you may want to do this is so you can charge the recipient. I am not saying that this is the only reason.

Nothing says you can't charge people for their location even if it is an emergency
call, refund the usual charge if they make an emergency call, or do something
else on the billing side to make this work (give it free twice a month, then charge
for it, as used to be the case for 411 calls).  If this is a billing problem, please be
willing to consider solving it in the billing domain. 

I think you have been given ways to solve this problem that do not induce
fragility in the overall system and require no protocol changes.  Pushing for
more seems like it is going to make the system even more fragile, without
any gain but systems simplicity in billing.

Possibly, of course, I am misunderstanding you, but that seems like the upshot
of your message.
				regards,
					Ted

>For this to work, the Target, the thing retrieving the token (URI) that points to their location, needs to know what can dereference the location. To my mind this translates to a destination URI and a URN. This is the reason that I have suggested tunnelling LoST through HELD. The LIS knows, or can find out where the Target it. It gives the Target a location URI set, and a set of service URNs and associated destination URIs.
> 
>Providing a coarse location as has been suggested by simply won't work for the majority of value added cases, or the LIS is going to have to suck down every single service boundary for every single possible service, intersect them, and then pass that on to the Target. This is crazy particularly if the LIS has some 2 million or so devices hanging off it.
> 
>Using this approach the only VSP issue is now how it determines whether the call is really emergency or not. There is no issue with calls bound to non-emergency service URNs. Henning and Hannes presented the solution to this yesterday with their unauthenticated access slide. The Device has the address of the ESRP, and a location URI, simple send it directly. I would stress also that if we are worried about hop counters etc, this is going to be far safer than trunking emergency signalling around the globe, and keeps the local service local.
> 
>So when we consider this location hiding we need to consider why we are doing, and the solution must work for final intent, which is incremental value added services.
> 
>Cheers
>James
>  
> 
>
>From: Brian Rosen [mailto:br@brianrosen.net]
>Sent: Saturday, 8 December 2007 9:18 AM
>To: 'Richard Barnes'; 'Ted Hardie'
>Cc: 'ECRIT'
>Subject: RE: [Ecrit] Location Hiding
> 
>To expand on this, there are three mechanisms that have been proposed for location hiding:
>1. Deliver coarse location to anyone but a PSAP.  No protocol changes needed.
>2. Don't ask anyone but a PSAP to dereference.  This requires two changes.  One returns the LoST response with the LCP return (HELD) so the endpoint never needs location.  However, it also requires a reverse LoST lookup (validate a PSAP URI) so that a VSP can validate that the call is a bona fide emergency call
>3. Allow location reference in the query to LoST, LoST can get high accuracy location.
> 
>The arguments around these have to do with who has the burden to support location hiding.  In the first case (coarse location), the LIS has the burden.  Everyone else pays nothing.  James W doesn't like this, because he wants the VSP to pay for the necessity to validate that the call is bona fide.  In the second case, the LoST server has to support the reverse lookup.  It requires the LIS to support the combination of HELD+LoST.  Of course, it makes HELD the only LCP that can support location hiding, but that may not be a problem.  The third approach puts all of the burden on the LoST server.
> 
>Brian
> 
> > -----Original Message-----
> > From: Richard Barnes [mailto:rbarnes@bbn.com]
> > Sent: Friday, December 07, 2007 5:01 PM
> > To: Ted Hardie
> > Cc: ECRIT
> > Subject: Re: [Ecrit] Location Hiding
> >
> > Ted,
> >
> > I think I can answer your questions by paraphrasing what Barbara said:
> >
> > >> - Once LoST is published, I would like to see work done to provide a
> > >> mechanism to verify if a particular URI is valid for a given service.
> >
> > This mechanism has sometimes gone under the name "reverse LoST".
> > Currently, in order to ask LoST whether a URI is a PSAP URI, you have to
> > know a URN and a location to ask for in order to obtain that URI (as the
> > URI for that service at that location).  "Reverse LoST" would remove the
> > need for the URN+location by having an explicit request/response where
> > the request contains a URI and the response contains a
> > URN+serviceBoundary if the URI is known, and an error if it's not.
> >
> >
> > >> - I'd like to see a HELD extension defined that would send back LoST
> > >> response items
> >
> > In talking with James about this, we've referred to it as "tunneling
> > LoST through HELD".  The major problem with location hiding is that you
> > want the LoST server to have access to precise location, but not the
> > user.  Tunneling LoST through HELD enables this by using the HELD server
> > as a "dereferencing proxy" -- it dereferences the location, does the
> > LoST query with the precise location, and returns the results.
> >
> > I much prefer a "mirror image" approach, where we add location URIs as a
> > location profile to LoST -- adding LbyR to LoST instead of the other way
> > around.  At the cost of requiring a mechanism to discover the local LoST
> > server, it maintains the greatest possible degree of separation between
> > the two interfaces.
> >
> > --Richard
> >
> >
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.  
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 19:37:17 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0ngy-0007fP-WA; Fri, 07 Dec 2007 19:37:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ngx-0007fH-1s
	for ecrit@ietf.org; Fri, 07 Dec 2007 19:37:15 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ngw-00010M-5x
	for ecrit@ietf.org; Fri, 07 Dec 2007 19:37:15 -0500
X-SEF-Processed: 5_0_0_910__2007_12_07_18_48_14
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Fri, 07 Dec 2007 18:48:14 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 18:37:13 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ecrit] Location Hiding
Date: Fri, 7 Dec 2007 18:37:09 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Location Hiding
Thread-Index: Acg5Menky9ZVu/SfQF+vjc6qpHNq+QAAGFwg
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABB452@crexc41p><4759C282.8080200@bbn.com>
	<10e901c8391f$186523b0$0e99f544@cis.neustar.com>

From: "Winterbottom, James" 
To: "Ted Hardie" , "Brian Rosen" ,
	"Richard Barnes" 
X-OriginalArrivalTime: 08 Dec 2007 00:37:13.0855 (UTC)
	FILETIME=[7A07F8F0:01C83932]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Ted,=0D=0A=0D=0AI think the problems is a billing issue only at the VSP.=0D=
=0AIf charging at the VSP were not an issue I believe that the problem=0D=0A=
largely goes away.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original =
Message-----=0D=0A> From: Ted Hardie [mailto:hardie@qualcomm.com]=0D=0A> Se=
nt: Saturday, 8 December 2007 11:33 AM=0D=0A> To: Winterbottom, James; Bria=
n Rosen; Richard Barnes=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] Locati=
on Hiding=0D=0A>=20=0D=0A> At 6:16 PM -0600 12/7/07, Winterbottom, James wr=
ote:=0D=0A> >Okay there is another problem that seems not be being talked a=
bout=0D=0Ahere.=0D=0A> >=0D=0A> >One of the key aims of location hiding is =
being able to restrict who=0D=0Acan=0D=0A> get access to location. And one =
reason that you may want to do this is=0D=0Aso=0D=0A> you can charge the re=
cipient. I am not saying that this is the only=0D=0A> reason.=0D=0A>=20=0D=0A=
> Nothing says you can't charge people for their location even if it is=0D=0A=
an=0D=0A> emergency=0D=0A> call, refund the usual charge if they make an em=
ergency call, or do=0D=0A> something=0D=0A> else on the billing side to mak=
e this work (give it free twice a=0D=0Amonth,=0D=0A> then charge=0D=0A> for=
 it, as used to be the case for 411 calls).  If this is a billing=0D=0A> pr=
oblem, please be=0D=0A> willing to consider solving it in the billing domai=
n.=0D=0A>=20=0D=0A> I think you have been given ways to solve this problem =
that do not=0D=0Ainduce=0D=0A> fragility in the overall system and require =
no protocol changes.=0D=0APushing=0D=0A> for=0D=0A> more seems like it is g=
oing to make the system even more fragile,=0D=0Awithout=0D=0A> any gain but=
 systems simplicity in billing.=0D=0A>=20=0D=0A> Possibly, of course, I am =
misunderstanding you, but that seems like=0D=0Athe=0D=0A> upshot=0D=0A> of =
your message.=0D=0A> =09=09=09=09regards,=0D=0A> =09=09=09=09=09Ted=0D=0A> =0D=
=0A>=20=0D=0A>=20=0D=0A> >For this to work, the Target, the thing retrievin=
g the token (URI)=0D=0Athat=0D=0A> points to their location, needs to know =
what can dereference the=0D=0Alocation.=0D=0A> To my mind this translates t=
o a destination URI and a URN. This is the=0D=0A> reason that I have sugges=
ted tunnelling LoST through HELD. The LIS=0D=0Aknows,=0D=0A> or can find ou=
t where the Target it. It gives the Target a location=0D=0AURI=0D=0A> set, =
and a set of service URNs and associated destination URIs.=0D=0A> >=0D=0A> =
>Providing a coarse location as has been suggested by simply won't=0D=0Awor=
k=0D=0A> for the majority of value added cases, or the LIS is going to have=
 to=0D=0Asuck=0D=0A> down every single service boundary for every single po=
ssible service,=0D=0A> intersect them, and then pass that on to the Target.=
 This is crazy=0D=0A> particularly if the LIS has some 2 million or so devi=
ces hanging off=0D=0Ait.=0D=0A> >=0D=0A> >Using this approach the only VSP =
issue is now how it determines=0D=0Awhether=0D=0A> the call is really emerg=
ency or not. There is no issue with calls=0D=0Abound to=0D=0A> non-emergenc=
y service URNs. Henning and Hannes presented the solution=0D=0Ato=0D=0A> th=
is yesterday with their unauthenticated access slide. The Device has=0D=0At=
he=0D=0A> address of the ESRP, and a location URI, simple send it directly.=
 I=0D=0Awould=0D=0A> stress also that if we are worried about hop counters =
etc, this is=0D=0Agoing=0D=0A> to be far safer than trunking emergency sign=
alling around the globe,=0D=0Aand=0D=0A> keeps the local service local.=0D=0A=
> >=0D=0A> >So when we consider this location hiding we need to consider wh=
y we=0D=0Aare=0D=0A> doing, and the solution must work for final intent, wh=
ich is=0D=0Aincremental=0D=0A> value added services.=0D=0A> >=0D=0A> >Cheer=
s=0D=0A> >James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >From: Brian Rosen [mailt=
o:br@brianrosen.net]=0D=0A> >Sent: Saturday, 8 December 2007 9:18 AM=0D=0A>=
 >To: 'Richard Barnes'; 'Ted Hardie'=0D=0A> >Cc: 'ECRIT'=0D=0A> >Subject: R=
E: [Ecrit] Location Hiding=0D=0A> >=0D=0A> >To expand on this, there are th=
ree mechanisms that have been proposed=0D=0Afor=0D=0A> location hiding:=0D=0A=
> >1. Deliver coarse location to anyone but a PSAP.  No protocol changes=0D=
=0A> needed.=0D=0A> >2. Don't ask anyone but a PSAP to dereference.  This r=
equires two=0D=0A> changes.  One returns the LoST response with the LCP ret=
urn (HELD) so=0D=0Athe=0D=0A> endpoint never needs location.  However, it a=
lso requires a reverse=0D=0ALoST=0D=0A> lookup (validate a PSAP URI) so tha=
t a VSP can validate that the call=0D=0Ais a=0D=0A> bona fide emergency cal=
l=0D=0A> >3. Allow location reference in the query to LoST, LoST can get hi=
gh=0D=0A> accuracy location.=0D=0A> >=0D=0A> >The arguments around these ha=
ve to do with who has the burden to=0D=0Asupport=0D=0A> location hiding.  I=
n the first case (coarse location), the LIS has the=0D=0A> burden.  Everyon=
e else pays nothing.  James W doesn't like this,=0D=0Abecause=0D=0A> he wan=
ts the VSP to pay for the necessity to validate that the call is=0D=0A> bon=
a fide.  In the second case, the LoST server has to support the=0D=0Arevers=
e=0D=0A> lookup.  It requires the LIS to support the combination of HELD+Lo=
ST.=0D=0AOf=0D=0A> course, it makes HELD the only LCP that can support loca=
tion hiding,=0D=0Abut=0D=0A> that may not be a problem.  The third approach=
 puts all of the burden=0D=0Aon=0D=0A> the LoST server.=0D=0A> >=0D=0A> >Br=
ian=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Richard=
 Barnes [mailto:rbarnes@bbn.com]=0D=0A> > > Sent: Friday, December 07, 2007=
 5:01 PM=0D=0A> > > To: Ted Hardie=0D=0A> > > Cc: ECRIT=0D=0A> > > Subject:=
 Re: [Ecrit] Location Hiding=0D=0A> > >=0D=0A> > > Ted,=0D=0A> > >=0D=0A> >=
 > I think I can answer your questions by paraphrasing what Barbara=0D=0Asa=
id:=0D=0A> > >=0D=0A> > > >> - Once LoST is published, I would like to see =
work done to=0D=0Aprovide=0D=0A> a=0D=0A> > > >> mechanism to verify if a p=
articular URI is valid for a given=0D=0A> service.=0D=0A> > >=0D=0A> > > Th=
is mechanism has sometimes gone under the name "reverse LoST".=0D=0A> > > C=
urrently, in order to ask LoST whether a URI is a PSAP URI, you=0D=0Ahave=0D=
=0A> to=0D=0A> > > know a URN and a location to ask for in order to obtain =
that URI=0D=0A(as=0D=0A> the=0D=0A> > > URI for that service at that locati=
on).  "Reverse LoST" would=0D=0Aremove=0D=0A> the=0D=0A> > > need for the U=
RN+location by having an explicit request/response=0D=0Awhere=0D=0A> > > th=
e request contains a URI and the response contains a=0D=0A> > > URN+service=
Boundary if the URI is known, and an error if it's not.=0D=0A> > >=0D=0A> >=
 >=0D=0A> > > >> - I'd like to see a HELD extension defined that would send=
 back=0D=0A> LoST=0D=0A> > > >> response items=0D=0A> > >=0D=0A> > > In tal=
king with James about this, we've referred to it as=0D=0A"tunneling=0D=0A> =
> > LoST through HELD".  The major problem with location hiding is=0D=0Atha=
t=0D=0A> you=0D=0A> > > want the LoST server to have access to precise loca=
tion, but not=0D=0Athe=0D=0A> > > user.  Tunneling LoST through HELD enable=
s this by using the HELD=0D=0A> server=0D=0A> > > as a "dereferencing proxy=
" -- it dereferences the location, does=0D=0Athe=0D=0A> > > LoST query with=
 the precise location, and returns the results.=0D=0A> > >=0D=0A> > > I muc=
h prefer a "mirror image" approach, where we add location=0D=0AURIs as=0D=0A=
> a=0D=0A> > > location profile to LoST -- adding LbyR to LoST instead of t=
he=0D=0Aother=0D=0A> way=0D=0A> > > around.  At the cost of requiring a mec=
hanism to discover the=0D=0Alocal=0D=0A> LoST=0D=0A> > > server, it maintai=
ns the greatest possible degree of separation=0D=0A> between=0D=0A> > > the=
 two interfaces.=0D=0A> > >=0D=0A> > > --Richard=0D=0A> > >=0D=0A> > >=0D=0A=
> > >=0D=0A> > >=0D=0A> > > _______________________________________________=0D=
=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://ww=
w1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>=0D=0A>=
-----------------------------------------------------------------------=0D=0A=
--=0D=0A> -----------------------=0D=0A> >This message is for the designate=
d recipient only and may=0D=0A> >contain privileged, proprietary, or otherw=
ise private information.=0D=0A> >If you have received it in error, please n=
otify the sender=0D=0A> >immediately and delete the original.  Any unauthor=
ized use of=0D=0A> >this email is prohibited.=0D=0A>=0D=0A>----------------=
-------------------------------------------------------=0D=0A--=0D=0A> ----=
-------------------=0D=0A> >[mf2]=0D=0A>=20=0D=0A=0D=0A--------------------=
---------------------------------------------------------------------------=
-=0D=0AThis message is for the designated recipient only and may=0D=0Aconta=
in privileged, proprietary, or otherwise private information. =20=0D=0AIf y=
ou have received it in error, please notify the sender=0D=0Aimmediately and=
 delete the original.  Any unauthorized use of=0D=0Athis email is prohibite=
d.=0D=0A-------------------------------------------------------------------=
-----------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 07 23:03:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0qur-0000JY-Jc; Fri, 07 Dec 2007 23:03:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J0qup-0000I6-DJ
	for ecrit@ietf.org; Fri, 07 Dec 2007 23:03:47 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0qug-0003Iv-VS
	for ecrit@ietf.org; Fri, 07 Dec 2007 23:03:47 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2007 23:03:38 -0500
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 lB843bm0012889; 
	Fri, 7 Dec 2007 23:03:37 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB843Ua8012631; 
	Sat, 8 Dec 2007 04:03:35 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 7 Dec 2007 23:03:30 -0500
Received: from mlinsnerwxp02 ([10.21.86.90]) by xmb-rtp-205.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 7 Dec 2007 23:03:23 -0500
From: "Marc Linsner" 
To: "'Winterbottom, James'" 
Subject: RE: [Ecrit] Location Hiding
Date: Fri, 7 Dec 2007 23:03:18 -0500
Message-ID: <000001c8394f$49a30840$5a56150a@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acg5HJt0LtOh/J1wSuOtFIIK0DKwHQAAYVQQAAP6/iAAA06mAA==
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 08 Dec 2007 04:03:29.0610 (UTC)
	FILETIME=[4A8E52A0:01C8394F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=30106; t=1197086617;
	x=1197950617; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mlinsner@cisco.com;
	z=From:=20=22Marc=20Linsner=22=20
	|Subject:=20RE=3A=20[Ecrit]=20Location=20Hiding |Sender:=20
	|To:=20=22'Winterbottom,=20James'=22=20; bh=bM/UZKuJbYcojCu8U7+Mgbcy/eE69wVwo1MRoo/O3k8=;
	b=acayjJo3i3ir686FrGzKwwkLV6wSw2V4PuKBHEchQ1oxRpss3uDnITYeDU
	LrQao0+TL9SeJ7JaW/1u+07QZ7Ny4F166KuqCKF25pgydpsS7smijYmNomJB
	aiquy3cl2D;
Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -1.7 (-)
X-Scan-Signature: bc3bb180a340b27ed09032e0ba4ec3ff
Cc: 'ECRIT' 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0907225728=="
Errors-To: ecrit-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0907225728==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C83925.60CD0040"

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C83925.60CD0040
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

James,

in-line...

  _____  

From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] 
Sent: Friday, December 07, 2007 7:16 PM
To: Brian Rosen; Richard Barnes; Ted Hardie
Cc: ECRIT
Subject: RE: [Ecrit] Location Hiding

Okay there is another problem that seems not be being talked about here.

One of the key aims of location hiding is being able to restrict who can get
access to location. And one reason that you may want to do this is so you
can charge the recipient. I am not saying that this is the only reason.

For this to work, the Target, the thing retrieving the token (URI) that
points to their location, needs to know what can dereference the location.
To my mind this translates to a destination URI and a URN. This is the
reason that I have suggested tunnelling LoST through HELD. The LIS knows, or
can find out where the Target it. It gives the Target a location URI set,
and a set of service URNs and associated destination URIs.

Providing a coarse location as has been suggested by simply won't work for
the majority of value added cases, or the LIS is going to have to suck down
every single service boundary for every single possible service, intersect
them, and then pass that on to the Target. This is crazy particularly if the
LIS has some 2 million or so devices hanging off it. 

This may in fact be the burden you are proposing, but this burden is placed
on the entity desiring the cause.

-Marc-

Using this approach the only VSP issue is now how it determines whether the
call is really emergency or not. There is no issue with calls bound to
non-emergency service URNs. Henning and Hannes presented the solution to
this yesterday with their unauthenticated access slide. The Device has the
address of the ESRP, and a location URI, simple send it directly. I would
stress also that if we are worried about hop counters etc, this is going to
be far safer than trunking emergency signalling around the globe, and keeps
the local service local.

So when we consider this location hiding we need to consider why we are
doing, and the solution must work for final intent, which is incremental
value added services.

Cheers

James

  _____  

From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Saturday, 8 December 2007 9:18 AM
To: 'Richard Barnes'; 'Ted Hardie'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Location Hiding

To expand on this, there are three mechanisms that have been proposed for
location hiding:

1. Deliver coarse location to anyone but a PSAP.  No protocol changes
needed.

2. Don't ask anyone but a PSAP to dereference.  This requires two changes.
One returns the LoST response with the LCP return (HELD) so the endpoint
never needs location.  However, it also requires a reverse LoST lookup
(validate a PSAP URI) so that a VSP can validate that the call is a bona
fide emergency call

3. Allow location reference in the query to LoST, LoST can get high accuracy
location.

The arguments around these have to do with who has the burden to support
location hiding.  In the first case (coarse location), the LIS has the
burden.  Everyone else pays nothing.  James W doesn't like this, because he
wants the VSP to pay for the necessity to validate that the call is bona
fide.  In the second case, the LoST server has to support the reverse
lookup.  It requires the LIS to support the combination of HELD+LoST.  Of
course, it makes HELD the only LCP that can support location hiding, but
that may not be a problem.  The third approach puts all of the burden on the
LoST server.

Brian

> -----Original Message-----

> From: Richard Barnes [mailto:rbarnes@bbn.com]

> Sent: Friday, December 07, 2007 5:01 PM

> To: Ted Hardie

> Cc: ECRIT

> Subject: Re: [Ecrit] Location Hiding

> 

> Ted,

> 

> I think I can answer your questions by paraphrasing what Barbara said:

> 

> >> - Once LoST is published, I would like to see work done to provide a

> >> mechanism to verify if a particular URI is valid for a given service.

> 

> This mechanism has sometimes gone under the name "reverse LoST".

> Currently, in order to ask LoST whether a URI is a PSAP URI, you have to

> know a URN and a location to ask for in order to obtain that URI (as the

> URI for that service at that location).  "Reverse LoST" would remove the

> need for the URN+location by having an explicit request/response where

> the request contains a URI and the response contains a

> URN+serviceBoundary if the URI is known, and an error if it's not.

> 

> 

> >> - I'd like to see a HELD extension defined that would send back LoST

> >> response items

> 

> In talking with James about this, we've referred to it as "tunneling

> LoST through HELD".  The major problem with location hiding is that you

> want the LoST server to have access to precise location, but not the

> user.  Tunneling LoST through HELD enables this by using the HELD server

> as a "dereferencing proxy" -- it dereferences the location, does the

> LoST query with the precise location, and returns the results.

> 

> I much prefer a "mirror image" approach, where we add location URIs as a

> location profile to LoST -- adding LbyR to LoST instead of the other way

> around.  At the cost of requiring a mechanism to discover the local LoST

> server, it maintains the greatest possible degree of separation between

> the two interfaces.

> 

> --Richard

> 

> 

> 

> 

> _______________________________________________

> Ecrit mailing list

> Ecrit@ietf.org

> https://www1.ietf.org/mailman/listinfo/ecrit

----------------------------------------------------------------------------
--------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
----------------------------------------------------------------------------
--------------------
[mf2]	

------=_NextPart_000_0001_01C83925.60CD0040
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

James,

in-line...

  From: Winterbottom, James=20
  [mailto:James.Winterbottom@andrew.com] 
Sent: Friday, =
December 07,=20
  2007 7:16 PM
To: Brian Rosen; Richard Barnes; Ted=20
  Hardie
Cc: ECRIT
Subject: RE: [Ecrit] Location=20
  Hiding

  Okay there =
is another=20
  problem that seems not be being talked about=20
here.

  One of the =
key aims=20
  of location hiding is being able to restrict who can get access to =
location.=20
  And one reason that you may want to do this is so you can charge the=20
  recipient. I am not saying that this is the only=20
  reason.

  For this to =
work, the=20
  Target, the thing retrieving the token (URI) that points to their =
location,=20
  needs to know what can dereference the location. To my mind this =
translates to=20
  a destination URI and a URN. This is the reason that I have suggested=20
  tunnelling LoST through HELD. The LIS knows, or can find out where the =
Target=20
  it. It gives the Target a location URI set, and a set of service URNs =
and=20
  associated destination URIs.

  Providing a =
coarse=20
  location as has been suggested by simply won’t work for the =
majority of value=20
  added cases, or the LIS is going to have to suck down every single =
service=20
  boundary for every single possible service, intersect them, and then =
pass that=20
  on to the Target. This is crazy particularly if the LIS has some 2 =
million or=20
  so devices hanging off it. 

This may in fact be the =
burden you=20
are proposing, but this burden is placed on the entity desiring the=20
cause.

-Marc-

   <=
/P>

  Using this =
approach=20
  the only VSP issue is now how it determines whether the call is really =

  emergency or not. There is no issue with calls bound to non-emergency =
service=20
  URNs. Henning and Hannes presented the solution to this yesterday with =
their=20
  unauthenticated access slide. The Device has the address of the ESRP, =
and a=20
  location URI, simple send it directly. I would stress also that if we =
are=20
  worried about hop counters etc, this is going to be far safer than =
trunking=20
  emergency signalling around the globe, and keeps the local service=20
  local.

  So when we =
consider=20
  this location hiding we need to consider why we are doing, and the =
solution=20
  must work for final intent, which is incremental value added=20
  services.

  Cheers
  James

  From: Brian Rosen=20
  [mailto:br@brianrosen.net] 
Sent: Saturday, 8 December 2007 =
9:18=20
  AM
To: 'Richard =
Barnes'; 'Ted=20
  Hardie'
Cc:=20
  'ECRIT'
Subject: =
RE: [Ecrit]=20
  Location Hiding

  To expand on this, there are three =
mechanisms that=20
  have been proposed for location hiding:
  1. Deliver coarse location to anyone but a =
PSAP. =20
  No protocol changes needed.
  2. Don't ask anyone but a PSAP to =
dereference. =20
  This requires two changes.  One returns the LoST response with =
the LCP=20
  return (HELD) so the endpoint never needs location.  However, it =
also=20
  requires a reverse LoST lookup (validate a PSAP URI) so that a VSP can =

  validate that the call is a bona fide emergency=20
  call
  3. Allow location reference in the query to =
LoST, LoST=20
  can get high accuracy location.

  The arguments around these have to do with =
who has the=20
  burden to support location hiding.  In the first case (coarse =
location),=20
  the LIS has the burden.  Everyone else pays nothing.  James =
W=20
  doesn’t like this, because he wants the VSP to pay for the =
necessity to=20
  validate that the call is bona fide.  In the second case, the =
LoST server=20
  has to support the reverse lookup.  It requires the LIS to =
support the=20
  combination of HELD+LoST.  Of course, it makes HELD the only LCP =
that can=20
  support location hiding, but that may not be a problem.  The =
third=20
  approach puts all of the burden on the LoST=20
  server.

  Brian

  > -----Original=20
  Message-----
  > From: Richard Barnes=20
  [mailto:rbarnes@bbn.com]
  > Sent: Friday, December 07, 2007 5:01=20
  PM
  > To: Ted =
Hardie
  > Cc: ECRIT
  > Subject: Re: [Ecrit] Location=20
  Hiding
  > 
  > Ted,
  > 
  > I think I can answer your questions by=20
  paraphrasing what Barbara said:
  > 
  > >> - Once LoST is published, I =
would like=20
  to see work done to provide a
  > >> mechanism to verify if a =
particular URI=20
  is valid for a given service.
  > 
  > This mechanism has sometimes gone under =
the name=20
  "reverse LoST".
  > Currently, in order to ask LoST whether =
a URI is=20
  a PSAP URI, you have to
  > know a URN and a location to ask for in =
order to=20
  obtain that URI (as the
  > URI for that service at that =
location). =20
  "Reverse LoST" would remove the
  > need for the URN+location by having an =
explicit=20
  request/response where
  > the request contains a URI and the =
response=20
  contains a
  > URN+serviceBoundary if the URI is =
known, and an=20
  error if it's not.
  > 
  > 
  > >> - I'd like to see a HELD =
extension=20
  defined that would send back LoST
  > >> response=20
  items
  > 
  > In talking with James about this, we've =
referred=20
  to it as "tunneling
  > LoST through HELD".  The major =
problem with=20
  location hiding is that you
  > want the LoST server to have access to =
precise=20
  location, but not the
  > user.  Tunneling LoST through HELD =
enables=20
  this by using the HELD server
  > as a "dereferencing proxy" -- it =
dereferences the=20
  location, does the
  > LoST query with the precise location, =
and returns=20
  the results.
  > 
  > I much prefer a "mirror image" =
approach, where we=20
  add location URIs as a
  > location profile to LoST -- adding LbyR =
to LoST=20
  instead of the other way
  > around.  At the cost of requiring =
a=20
  mechanism to discover the local LoST
  > server, it maintains the greatest =
possible degree=20
  of separation between
  > the two =
interfaces.
  > 
  > --Richard
  > 
  > 
  > 
  > 
  >=20
  =
_______________________________________________<=
/P>

> Ecrit mailing =
list
  > =
Ecrit@ietf.org
  >=20
  =
https://www1.ietf.org/mailman/listinfo/ecrit=

      =

-----------------------------------------------------------------=
-------------------------------
This message is for&nbs=
p;the designated recipient only and may
conta=
in privileged, proprietary, or otherwise private=
 information.  
If you have received&nbs=
p;it in error, please notify the sender
=
immediately and delete the original.  Any&n=
bsp;unauthorized use of
this email is prohibi=
ted.
-----------------------------------------------------------------=
-------------------------------
[mf2]

------=_NextPart_000_0001_01C83925.60CD0040--

--===============0907225728==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--===============0907225728==--

From ecrit-bounces@ietf.org Sat Dec 08 18:39:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J19Gl-0000x6-G7; Sat, 08 Dec 2007 18:39:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J19Gk-0000x1-0Z
	for ecrit@ietf.org; Sat, 08 Dec 2007 18:39:38 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J19Gh-0000zB-M4
	for ecrit@ietf.org; Sat, 08 Dec 2007 18:39:37 -0500
X-SEF-Processed: 5_0_0_910__2007_12_08_17_50_30
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); Sat, 08 Dec 2007 17:50:30 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Dec 2007 17:39:28 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Sat, 8 Dec 2007 17:39:24 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcg
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>

From: "Dawson, Martin" 
To: "Henning Schulzrinne" ,
	"Stark, Barbara" 
X-OriginalArrivalTime: 08 Dec 2007 23:39:28.0290 (UTC)
	FILETIME=[92CE7820:01C839F3]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: e5bfa71b340354e384155def5e70b13b
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Hi all,=0D=0A=0D=0AEverything is qualified on what ultimately gets regulate=
d. But it's probably time to discuss real world implications of this topic.=0D=
=0A=0D=0AI expect that, if access operators are required to provide locatio=
n, it is only going to be for the purpose of emergency services. I doubt th=
at regulators will even consider mandating that they provide it for all use=
rs for all purposes. There'll be no sledgehammer to force access providers =
to give everyone a free location service - so it won't happen until operato=
rs have their own reasons to do so.=0D=0A=0D=0ASince access providers can't=
 control what client devices actually use location information for, they wi=
ll only implement a system that permits a recognised emergency entity to re=
trieve the actual location value. They'll only give the end subscriber loca=
tion information if that's already paid for as part of the subscription.=0D=
=0A=0D=0AThe fundamental problem with the "do location hiding by providing =
location" proposal is exactly that. It fails to hide location. This is part=
icularly the case in the US (which is a difficult market to ignore). The in=
tersection of every possible service area - also called an ESN or ESZ - in =
the US is a quite granular area; certainly good for quite a lot of services=
=2E For a mobile access provider, in particular, a considerable amount of c=
apital equipment is going to be invoked to provide this quite good location=
 information.=0D=0A=0D=0AOn the other hand, in many other countries (e.g. t=
he UK and Australia) this technique is probably not problematic for the car=
rier, because they are just going to return the country code. That's as gra=
nular as you need to be for emergency services.=0D=0A=0D=0ASo here's what w=
ill happen if this is the official IETF recommendation. It may get adopted =
but operators will limit the provided location information to just the coun=
try indicator. They'll do this in the US as well (they'll refuse to process=
 all the LoST boundary data and take responsibility for consequent routing =
outcome). This means that VSPs dealing with calls originating in the US wil=
l need to use i2. This is because the V2 interface in i2 does support a loc=
ation reference while LoST is unable to do this. The country information wi=
ll certainly be useful for arbitrating which VPC to use though - so that's =
good. It will mean that direct to PSAP calls won't be able to be made in th=
e US. That's a shame. Other jurisdictions that only have a single PSAP rout=
e will be able to support this. OTOH, it might force the US to provide a fe=
deral level URI with proxies that can subsequently do the dereference and l=
ower level routing - so maybe it's not such a shame. It won't result in acc=
ess providers giving free location information until they are ready to do s=
o however.=0D=0A=0D=0AEditorial and a genuine question:=0D=0A=0D=0AIMO, sup=
porting the services URI extension in HELD or adding location reference sup=
port to LoST are both superior engineering solutions. They just aren't driv=
en by the punitive motivations of the "hide by not hiding" proposal. Argume=
nts that they are inferior because they require protocol changes are specio=
us and self-fulfilling. That's why the "reference query" mechanism for LoST=
 was "postponed" in the interest of getting LoST finalized. It continues to=
 be used as a prop for this particular hiding proposal. By this line of arg=
ument, we would never add or modify protocols for anything.=0D=0A=0D=0AIt's=
 very difficult not to lapse into sarcasm in this area (I feel like saying =
it's OK not to have location hiding because Columbia University and Cisco a=
re going to underwrite the cost of providing a 5x9s reliable ubiquitous loc=
ation service in all public access networks out of pure philanthropy.... bu=
t I won't :) ).=0D=0A=0D=0AInsisting on providing location for all applicat=
ions is like insisting that cellular operators let users call anyone just t=
o ensure that they can also make emergency calls. In this hypothetical situ=
ation, refusing to define protocol mechanisms that permit them to distingui=
sh between the scenarios would only result in there being no cellular servi=
ce - or just publicly funded cellular services. It's a counter-productive a=
ttitude.=0D=0A=0D=0AThis provides the opportunity for me to once more ask a=
 question that hasn't been responded to in the past. Why is ECRIT describin=
g a solution that has the VSP involved in the emergency call at all=3F Why =
would the VSP want to be involved in emergency calls - and why would the ca=
ller want them involved=3F It seems to be not in the interest of either par=
ty. There's already an interim architecture for the non "end-to-end IP" sce=
nario called i2. In any circumstance where any of the device, the network, =
or emergency operator are not ECRIT-capable, then the VSP does need to be i=
nvolved and i2 is a valid fallback.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=
=0A-----Original Message-----=0D=0AFrom: Henning Schulzrinne [mailto:hgs@cs=
=2Ecolumbia.edu]=20=0D=0ASent: Saturday, 8 December 2007 8:56 AM=0D=0ATo: S=
tark, Barbara=0D=0ACc: ecrit@ietf.org; Liess, Laura=0D=0ASubject: Re: AW: [=
Ecrit] Location Hiding -- State of the Art=0D=0A=0D=0ATranslation: You have=
 more lobbyists than I (or the IETF), so give me. =20=0D=0AThanks for clari=
fying that.=0D=0A=0D=0AHenning=0D=0A=0D=0AOn Dec 7, 2007, at 4:24 PM, Stark=
, Barbara wrote:=0D=0A=0D=0A> [The following statements are my opinion, and=
 should not be =20=0D=0A> attributed to the company I work for.]=0D=0A>=0D=0A=
> Henning,=0D=0A> It's true that the IETF doesn't have to do something just=
 because =20=0D=0A> someone wants it. It's also true that the IETF has no a=
uthority or =20=0D=0A> ability to force implementation of RFCs by companies=
 who refuse to =20=0D=0A> implement them. You cannot shove a solution down =
the throats of =20=0D=0A> access providers that they are unwilling to buy i=
n to. In my =20=0D=0A> opinion, even attempting to do so would be, well, un=
ethical.=0D=0A>=0D=0A> So, you have a choice:=0D=0A> 1) create a solution t=
hat you like that major stakeholders are =20=0D=0A> unwilling to implement=0D=
=0A> 2) create a solution that you don't quite like, but that's better =20=0D=
=0A> than what we have today, and which major stakeholders are willing to  =0D=
=0A> implement=0D=0A>=0D=0A> Believe it or not, major telecom companies in =
the US and Europe put =20=0D=0A> a lot of effort into lobbying regulatory b=
odies, to achieve =20=0D=0A> desirable outcomes. The IETF doesn't put in su=
ch effort. If you want =20=0D=0A> to make a go at pushing through a solutio=
n that stakeholders in =20=0D=0A> these regions are set against, and see if=
 you can get regulatory =20=0D=0A> agencies to bless it, then go for it. I =
think the odds are stacked =20=0D=0A> against you, though. Especially since=
 there are workable solutions =20=0D=0A> that these companies have said the=
y would be willing to accept.=0D=0A>=0D=0A> Here is why mobile access provi=
ders "cannot" provide the best =20=0D=0A> available location directly to en=
d user devices: They don't want to. =20=0D=0A> At this point in time, it's =
their network, their data, and their =20=0D=0A> choice.=0D=0A>=0D=0A> In fr=
ee market economies, you generally have to be able to *prove* =20=0D=0A> (a=
nd not just say it without proof) massive benefit or massive harm =20=0D=0A=
> before you can force companies to do what they don't want to do, =20=0D=0A=
> through regulation. Again, if you think you can take on that battle =20=0D=
=0A> and win, go for it.=0D=0A>=0D=0A> I, for one, believe that not providi=
ng the "real" location value to =20=0D=0A> end devices would not cause such=
 benefit or harm. If users want to =20=0D=0A> know what location PSAPs get =
on their behalf, and regulators believe =20=0D=0A> such a capability is nee=
ded, then we can let the phonebcp-described =20=0D=0A> test mechanism voice=
 it back over the voice medium (this would only =20=0D=0A> work for civic),=
 or return a JPEG map with a dot on it. This would =20=0D=0A> provide locat=
ion in a format that's usable by a human being, but not =20=0D=0A> an appli=
cation. Or maybe, in some countries, the regulators do =20=0D=0A> require a=
ccess providers to give out the best possible location =20=0D=0A> values to=
 end devices. But it's really improbable that you could =20=0D=0A> force th=
e regulators of all countries to see things your way.=0D=0A>=0D=0A> But, th=
is is all just my opinion.=0D=0A> Barbara=0D=0A>=0D=0A> -----Original Messa=
ge-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A=
> Sent: Friday, December 07, 2007 12:13 PM=0D=0A> To: Liess, Laura=0D=0A> C=
c: ecrit@ietf.org=0D=0A> Subject: Re: AW: [Ecrit] Location Hiding -- State =
of the Art=0D=0A>=0D=0A> Laura,=0D=0A>=0D=0A> just because somebody says "w=
e need it" doesn't make it an IETF=0D=0A> requirement. Please justify why m=
obile access cannot provide locations=0D=0A> to end users.=0D=0A>=0D=0A> He=
nning=0D=0A>=0D=0A> On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:=0D=0A>=0D=
=0A>> Brian,=0D=0A>>=0D=0A>> I checked with my company and we need LH for b=
oth civic and geo for=0D=0A>> fixed and mobile access. Only DSL and civic i=
s not an option.=0D=0A>>=0D=0A>> I would support sending the ESRP/PSAP URI =
to the UA, as proposed by=0D=0A>> Barbara and James some weeks ago.=0D=0A>>=0D=
=0A>> Laura=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>> -----Urspr=FCngliche Nachricht-=
----=0D=0A>> Von: Brian Rosen [mailto:br@brianrosen.net]=0D=0A>> Gesendet: =
Dienstag, 4. Dezember 2007 16:37=0D=0A>> An: 'Hannes Tschofenig'=0D=0A>> Cc=
: 'ECRIT'=0D=0A>> Betreff: RE: [Ecrit] Location Hiding -- State of the Art=0D=
=0A>>=0D=0A>> Proposed text for framework=0D=0A>>=0D=0A>> Some access netwo=
rks wish to restrict who can get a high quality=0D=0A>> location,=0D=0A>> p=
ossibly based on a payment arrangement.  For emergency calls, high=0D=0A>> =
quality=0D=0A>> location must be provided.  An access network can reasonabl=
y be=0D=0A>> expected to=0D=0A>> have a relationship with the PSAPs in its =
catchment area, so giving=0D=0A>> location=0D=0A>> to the PSAP will be stra=
ightforward=0D=0A>>=0D=0A>>=0D=0A>> However, an endpoint may need location=0D=
=0A>> for routing, and a proxy may need to verify that a purported=0D=0A>> =
emergency call=0D=0A>> is targeted at a bona fide PSAP.  To do so, it may t=
ake the location=0D=0A>> passed=0D=0A>> with the call and query LoST to con=
firm that the URI is genuine.=0D=0A>> "Hiding"=0D=0A>> location interferes =
with this check.  To achieve location hiding,=0D=0A>> the LIS=0D=0A>> can r=
eturn a coarse location which is good enough to elicit the same=0D=0A>> res=
ponse from LoST as the actual location would.  The endpoint and=0D=0A>> the=
 proxy=0D=0A>> can use this location to route and verify.  A suitable locat=
ion for=0D=0A>> a geo is=0D=0A>> a polygon calculated by intersecting the s=
ervice boundaries of all=0D=0A>> of the=0D=0A>> emergency services that res=
pond to the actual location.  A suitable=0D=0A>> location=0D=0A>> for a civ=
ic is any civic location within the intersection of the=0D=0A>> service=0D=0A=
>> boundaries of emergency services.  In a great many cases, a country=0D=0A=
>> code is=0D=0A>> sufficient.  In others a state/province or a city name i=
s=0D=0A>> sufficient.  Of=0D=0A>> course, the LIS would always return a loc=
ation reference, which=0D=0A>> would return=0D=0A>> high quality location f=
or a PSAP and coarse location to the endpoint=0D=0A>> or any=0D=0A>> proxy =
unknown to the LIS.=0D=0A>>=0D=0A>> Proposed text for phonebcp:=0D=0A>>=0D=0A=
>> A LIS who wishes to hide location returns a location reference.  When=0D=
=0A>> dereferenced by the endpoint or proxy:=0D=0A>> 1. For LIS's returning=
 geo:=0D=0A>>   For each location served by the LIS, compute the intersecti=
on of=0D=0A>> the=0D=0A>>   service boundaries for all emergency services k=
nown to LoST for the=0D=0A>>   location. Return the resulting polygon, or a=
ny point in the=0D=0A>> polygon as=0D=0A>>   the value during a dereference=0D=
=0A>> 2. For LIS's returning civic:=0D=0A>>   Determine a civic location wh=
ich is within the service boundary=0D=0A>> of all=0D=0A>>   emergency servi=
ces known to LoST for the location.  In a great many=0D=0A>>   cases, this =
will be a country code, province/state or city.=0D=0A>> Return this=0D=0A>>=
   coarse civic location as the value during a dereference=0D=0A>> Note tha=
t the service boundaries returned from LoST have a TTL, the=0D=0A>> interse=
ctions MUST recalculated if the service boundary changes.=0D=0A>> The LIS=0D=
=0A>> MUST return high quality location to a PSAP or ESRP.=0D=0A>>=0D=0A>> =
Brian=0D=0A>>=0D=0A>>> -----Original Message-----=0D=0A>>> From: Hannes Tsc=
hofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>>> Sent: Monday, December =
03, 2007 1:38 PM=0D=0A>>> To: Brian Rosen=0D=0A>>> Cc: 'James M. Polk'; 'St=
ark, Barbara'; 'ECRIT'=0D=0A>>> Subject: Re: [Ecrit] Location Hiding -- Sta=
te of the Art=0D=0A>>>=0D=0A>>> Hi Brian,=0D=0A>>>=0D=0A>>> Brian Rosen wro=
te:=0D=0A>>>> It's fine with me if there is a separate doc, but framework a=
nd=0D=0A>>>> phonebcp=0D=0A>>>> have to reference it.=0D=0A>>>>=0D=0A>>> Ar=
e we talking about informative or normative references=3F=0D=0A>>>> I think=
 it can be solved with a one paragraph description of the=0D=0A>>>> problem=0D=
=0A>>> in=0D=0A>>>> framework and a one paragraph solution in phonebcp, but=
 if there=0D=0A>>>> is a=0D=0A>>>> separate doc and a reference, I will be =
happy.=0D=0A>>>>=0D=0A>>> That does not make sense.=0D=0A>>> The solution i=
s not one paragraph and the text in phone bcp is=0D=0A>>> normative.=0D=0A>=
>>=0D=0A>>> Ciao=0D=0A>>> Hannes=0D=0A>>>=0D=0A>>>> Brian=0D=0A>>>>=0D=0A>>=
>>=0D=0A>>>>> -----Original Message-----=0D=0A>>>>> From: James M. Polk [ma=
ilto:jmpolk@cisco.com]=0D=0A>>>>> Sent: Monday, December 03, 2007 7:37 PM=0D=
=0A>>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT=0D=0A>>>>> Subject: R=
E: [Ecrit] Location Hiding -- State of the Art=0D=0A>>>>>=0D=0A>>>>> Curren=
tly, the WG (and document editors!) should be operating =20=0D=0A>>>>> unde=
r=0D=0A>>>>> the consensus direction that Location Hiding *not* be in Phone=
BCP=0D=0A>>>>> or=0D=0A>>>>> Framework.  This was a clear consensus call in=
 Chicago - and not =20=0D=0A>>>>> by=0D=0A>>>>> default, but by most people=
 voicing actively against having this=0D=0A>>>>> Hiding in either core ECRI=
T documents, and I haven't yet talked to=0D=0A>>>>> anyone here in Vancouve=
r that thinks otherwise.=0D=0A>>>>>=0D=0A>>>>> Location Hiding is something=
 that needs to be addressed BY ITSELF=0D=0A>>>>> (i.e., in its own doc) so =
everyone can focus on the singular =20=0D=0A>>>>> topic,=0D=0A>>>>> and wor=
k towards not talking past each other (not like that's=0D=0A>>>>> happened =
before in ECRIT....  :-/=0D=0A>>>>>=0D=0A>>>>> Who disagrees with this=3F=0D=
=0A>>>>>=0D=0A>>>>> BTW - if someone thinks Location Hiding should be put b=
ack into=0D=0A>>>>> PhoneBCP or Framework, then they can attempt to gain WG=
 consensus=0D=0A>>>>> on=0D=0A>>>>> that, but that's different than a direc=
tion of this inevitability=0D=0A>>>>> or=0D=0A>>>>> that there is not conse=
nsus on this.=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> At 07:23 AM 12/3/2007, Stark=
, Barbara wrote:=0D=0A>>>>>=0D=0A>>>>>> If people felt this was good enough=
 so that access providers=0D=0A>>>>>> would not=0D=0A>>>>>> need to be requ=
ired to build the infrastructure to provide=0D=0A>>>>>> location=0D=0A>>>>>=
> (because people could use this method instead of getting=0D=0A>>>>>> loca=
tion from=0D=0A>>>>>> access providers), then location hiding would be dead=
=2E If people=0D=0A>>>>>> still=0D=0A>>>>>> want to place a requirement on =
access providers to provide=0D=0A>>>>>> location,=0D=0A>>>>>> then location=
 hiding is not dead.=0D=0A>>>>>> Barbara=0D=0A>>>>>>=0D=0A>>>>>> -----Origi=
nal Message-----=0D=0A>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofe=
nig@gmx.net]=0D=0A>>>>>> Sent: Saturday, December 01, 2007 3:34 PM=0D=0A>>>=
>>> To: ECRIT=0D=0A>>>>>> Subject: [Ecrit] Location Hiding -- State of the =
Art=0D=0A>>>>>>=0D=0A>>>>>> I thought that the following article would be o=
f interest for =20=0D=0A>>>>>> you:=0D=0A>>>>>> http://googleblog.blogspot.=
com/2007/11/lost-no-found.html=0D=0A>>>>>>=0D=0A>>>>>> Here is text from=0D=
=0A>>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-=
on-=0D=0A>>> your=0D=0A>>>>>> -map.html=0D=0A>>>>>> "=0D=0A>>>>>> My Locati=
on is a new beta technology from Google that uses cell=0D=0A>>>>>> tower=0D=
=0A>>>>>> identification to provide you with approximate location=0D=0A>>>>=
>> information,=0D=0A>>> so=0D=0A>>>>>> it will work on phones without GPS.=0D=
=0A>>>>>> "=0D=0A>>>>>> Note that this stuff is not really new technology. =
It existed=0D=0A>>>>>> already=0D=0A>>>>>> for some time but the availabili=
ty of GPS devices made it=0D=0A>>>>>> possible to=0D=0A>>>>>> setup the dat=
abase in a more efficient way.=0D=0A>>>>>>=0D=0A>>>>>> Anyway, this mechani=
sm allows you to obtain location information=0D=0A>>>>>> with=0D=0A>>>>>> y=
our cell phone (using the cell id) without interacting with the=0D=0A>>>>>>=
 cellular operator.=0D=0A>>>>>> In short: operator cannot charge for locati=
on=0D=0A>>>>>>=0D=0A>>>>>> While the location information is not really use=
ful for first=0D=0A>>> responders=0D=0A>>>>>>=0D=0A>>>>>> it is still good =
enough for finding the closest PSAP.=0D=0A>>>>>>=0D=0A>>>>>> Is this the de=
ad of location hiding=3F=0D=0A>>>>>>=0D=0A>>>>>> Ciao=0D=0A>>>>>> Hannes=0D=
=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>> _________________________________________=
______=0D=0A>>>>>> Ecrit mailing list=0D=0A>>>>>> Ecrit@ietf.org=0D=0A>>>>>=
> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>>>>>>=0D=0A>>>>>> ____=
___________________________________________=0D=0A>>>>>> Ecrit mailing list=0D=
=0A>>>>>> Ecrit@ietf.org=0D=0A>>>>>> https://www1.ietf.org/mailman/listinfo=
/ecrit=0D=0A>>>>>>=0D=0A>>>>> _____________________________________________=
__=0D=0A>>>>> Ecrit mailing list=0D=0A>>>>> Ecrit@ietf.org=0D=0A>>>>> https=
://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>>>>>=0D=0A>>=0D=0A>>=0D=0A>> =
_______________________________________________=0D=0A>> Ecrit mailing list=0D=
=0A>> Ecrit@ietf.org=0D=0A>> https://www1.ietf.org/mailman/listinfo/ecrit=0D=
=0A>>=0D=0A>> _______________________________________________=0D=0A>> Ecrit=
 mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>> https://www1.ietf.org/mailman/=
listinfo/ecrit=0D=0A>=0D=0A>=0D=0A> _______________________________________=
________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www=
1.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A> *****=0D=0A>=0D=0A> The inf=
ormation transmitted is intended only for the person or =20=0D=0A> entity t=
o which it is addressed and may contain confidential, =20=0D=0A> proprietar=
y, and/or privileged material. Any review, retransmission, =20=0D=0A> disse=
mination or other use of, or taking of any action in reliance =20=0D=0A> up=
on this information by persons or entities other than the intended =20=0D=0A=
> recipient is prohibited. If you received this in error, please =20=0D=0A>=
 contact the sender and delete the material from all computers. GA622=0D=0A=
>=0D=0A>=0D=0A=0D=0A=0D=0A_______________________________________________=0D=
=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailma=
n/listinfo/ecrit=0D=0A=0D=0A-----------------------------------------------=
-------------------------------------------------=0D=0AThis message is for =
the designated recipient only and may=0D=0Acontain privileged, proprietary,=
 or otherwise private information. =20=0D=0AIf you have received it in erro=
r, please notify the sender=0D=0Aimmediately and delete the original.  Any =
unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------=
---------------------------------------------------------------------------=
--=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 09:03:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1jEh-0008He-EJ; Mon, 10 Dec 2007 09:03:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jEg-0008HW-3O
	for ecrit@ietf.org; Mon, 10 Dec 2007 09:03:54 -0500
Received: from tcmail31.telekom.de ([217.6.95.238])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1jEb-0001VJ-C0
	for ecrit@ietf.org; Mon, 10 Dec 2007 09:03:54 -0500
Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP;
	Mon, 10 Dec 2007 15:03:43 +0100
Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by
	s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 10 Dec 2007 15:03:42 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 15:03:41 +0100
Message-Id: <182C63BFBAF131428EA0C16F7FD2191B0355A656@S4DE8PSAAGM.mitte.t-com.de>
In-Reply-To: <45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg49LbEXLdzqg/JRkeHkNx1e/0C6QCJ57JQ
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de>
	<45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu>
From: "Liess, Laura" 
To: 
X-OriginalArrivalTime: 10 Dec 2007 14:03:42.0370 (UTC)
	FILETIME=[78A8E820:01C83B35]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: d240764089186ffa8d0175aacaee921f
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1578520716=="
Errors-To: ecrit-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1578520716==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C83B35.78515419"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C83B35.78515419
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Henning,

There are at least two reasons for it:

1) Different from US, DT can not just charge every access customer an =
additional fee for providing the Location Info for Emergency Calling. =
The regulator will not let us to do it. We probably can charge an =
additional fee if customers "buy" the Location Info or Location Services =
from us. As we do not get the hard-/software for the whole EC and =
Location stuff for free and, on the other side, the profit margin for =
access is currently very low (at least in Germany), we need to sell the =
Location Info in some form and can not afford to just give it out for =
free.=20

2) Many of our customers just want to use their phone as they use it =
today. They don't want to deal with additional security or configuration =
issues to be able to call 112. DT can not just "push" the Location Info =
to the end device and write into the General Terms and Conditions that =
the user is responsible for its misuse. (A lot of people buy the AVM =
FritzBox DSL-Router because it has a simple switch to turn-off the WLAN =
without any software configuration.) I expect regulatory requirements in =
Germany asking the access providers to be able to do location hiding for =
112.  =20

Laura  =20

-----Urspr=FCngliche Nachricht-----
Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20
Gesendet: Freitag, 7. Dezember 2007 18:13
An: Liess, Laura
Cc: ecrit@ietf.org
Betreff: Re: AW: [Ecrit] Location Hiding -- State of the Art

Laura,

just because somebody says "we need it" doesn't make it an IETF =20
requirement. Please justify why mobile access cannot provide locations =20
to end users.

Henning

On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:

> Brian,
>
> I checked with my company and we need LH for both civic and geo for =20
> fixed and mobile access. Only DSL and civic is not an option.
>
> I would support sending the ESRP/PSAP URI to the UA, as proposed by =20
> Barbara and James some weeks ago.
>
> Laura
>
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Brian Rosen [mailto:br@brianrosen.net]
> Gesendet: Dienstag, 4. Dezember 2007 16:37
> An: 'Hannes Tschofenig'
> Cc: 'ECRIT'
> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
>
> Proposed text for framework
>
> Some access networks wish to restrict who can get a high quality =20
> location,
> possibly based on a payment arrangement.  For emergency calls, high =20
> quality
> location must be provided.  An access network can reasonably be =20
> expected to
> have a relationship with the PSAPs in its catchment area, so giving =20
> location
> to the PSAP will be straightforward
>
>
> However, an endpoint may need location
> for routing, and a proxy may need to verify that a purported =20
> emergency call
> is targeted at a bona fide PSAP.  To do so, it may take the location =20
> passed
> with the call and query LoST to confirm that the URI is genuine.  =20
> "Hiding"
> location interferes with this check.  To achieve location hiding, =20
> the LIS
> can return a coarse location which is good enough to elicit the same
> response from LoST as the actual location would.  The endpoint and =20
> the proxy
> can use this location to route and verify.  A suitable location for =20
> a geo is
> a polygon calculated by intersecting the service boundaries of all =20
> of the
> emergency services that respond to the actual location.  A suitable =20
> location
> for a civic is any civic location within the intersection of the =20
> service
> boundaries of emergency services.  In a great many cases, a country =20
> code is
> sufficient.  In others a state/province or a city name is =20
> sufficient.  Of
> course, the LIS would always return a location reference, which =20
> would return
> high quality location for a PSAP and coarse location to the endpoint =20
> or any
> proxy unknown to the LIS.
>
> Proposed text for phonebcp:
>
> A LIS who wishes to hide location returns a location reference.  When
> dereferenced by the endpoint or proxy:
> 1. For LIS's returning geo:
>    For each location served by the LIS, compute the intersection of =20
> the
>    service boundaries for all emergency services known to LoST for the
>    location. Return the resulting polygon, or any point in the =20
> polygon as
>    the value during a dereference
> 2. For LIS's returning civic:
>    Determine a civic location which is within the service boundary =20
> of all
>    emergency services known to LoST for the location.  In a great many
>    cases, this will be a country code, province/state or city. =20
> Return this
>    coarse civic location as the value during a dereference
> Note that the service boundaries returned from LoST have a TTL, the
> intersections MUST recalculated if the service boundary changes.  =20
> The LIS
> MUST return high quality location to a PSAP or ESRP.
>
> Brian
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Monday, December 03, 2007 1:38 PM
>> To: Brian Rosen
>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
>>
>> Hi Brian,
>>
>> Brian Rosen wrote:
>>> It's fine with me if there is a separate doc, but framework and =20
>>> phonebcp
>>> have to reference it.
>>>
>> Are we talking about informative or normative references?
>>> I think it can be solved with a one paragraph description of the =20
>>> problem
>> in
>>> framework and a one paragraph solution in phonebcp, but if there =20
>>> is a
>>> separate doc and a reference, I will be happy.
>>>
>> That does not make sense.
>> The solution is not one paragraph and the text in phone bcp is =20
>> normative.
>>
>> Ciao
>> Hannes
>>
>>> Brian
>>>
>>>
>>>> -----Original Message-----
>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
>>>> Sent: Monday, December 03, 2007 7:37 PM
>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
>>>>
>>>> Currently, the WG (and document editors!) should be operating under
>>>> the consensus direction that Location Hiding *not* be in PhoneBCP =20
>>>> or
>>>> Framework.  This was a clear consensus call in Chicago - and not by
>>>> default, but by most people voicing actively against having this
>>>> Hiding in either core ECRIT documents, and I haven't yet talked to
>>>> anyone here in Vancouver that thinks otherwise.
>>>>
>>>> Location Hiding is something that needs to be addressed BY ITSELF
>>>> (i.e., in its own doc) so everyone can focus on the singular topic,
>>>> and work towards not talking past each other (not like that's
>>>> happened before in ECRIT....  :-/
>>>>
>>>> Who disagrees with this?
>>>>
>>>> BTW - if someone thinks Location Hiding should be put back into
>>>> PhoneBCP or Framework, then they can attempt to gain WG consensus =20
>>>> on
>>>> that, but that's different than a direction of this inevitability =20
>>>> or
>>>> that there is not consensus on this.
>>>>
>>>>
>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
>>>>
>>>>> If people felt this was good enough so that access providers =20
>>>>> would not
>>>>> need to be required to build the infrastructure to provide =20
>>>>> location
>>>>> (because people could use this method instead of getting =20
>>>>> location from
>>>>> access providers), then location hiding would be dead. If people =20
>>>>> still
>>>>> want to place a requirement on access providers to provide =20
>>>>> location,
>>>>> then location hiding is not dead.
>>>>> Barbara
>>>>>
>>>>> -----Original Message-----
>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>>> Sent: Saturday, December 01, 2007 3:34 PM
>>>>> To: ECRIT
>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
>>>>>
>>>>> I thought that the following article would be of interest for you:
>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
>>>>>
>>>>> Here is text from
>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-
>> your
>>>>> -map.html
>>>>> "
>>>>> My Location is a new beta technology from Google that uses cell =20
>>>>> tower
>>>>> identification to provide you with approximate location =20
>>>>> information,
>> so
>>>>> it will work on phones without GPS.
>>>>> "
>>>>> Note that this stuff is not really new technology. It existed =20
>>>>> already
>>>>> for some time but the availability of GPS devices made it =20
>>>>> possible to
>>>>> setup the database in a more efficient way.
>>>>>
>>>>> Anyway, this mechanism allows you to obtain location information =20
>>>>> with
>>>>> your cell phone (using the cell id) without interacting with the
>>>>> cellular operator.
>>>>> In short: operator cannot charge for location
>>>>>
>>>>> While the location information is not really useful for first
>> responders
>>>>>
>>>>> it is still good enough for finding the closest PSAP.
>>>>>
>>>>> Is this the dead of location hiding?
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C83B35.78515419
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

AW: AW: [Ecrit] Location Hiding -- State of the Art

Henning,

There are at least two =
reasons for it:

1) =
Different from =
US, DT can not just charge =
every access customer an =
additional fee for providing =
the Location =
Info for Emergency =
Calling. =
The regulator will not let us to do =
it. We probably can charge an additional =
fee if customers "buy" the Location Info or Location Services from =
us. As we do not get the =
hard-/software for =
the =
whole EC and =
Location stuff for =
free and, on the other side, =
the profit margin for access is currently very =
low (at least in Germany), we need =
to sell the Location Info in some form and can not afford =
to just give it out for free. 

2) =
Many of our =
customers just want to use their phone as they use it =
today. They don't want to deal =
with additional security or =
configuration issues to be able to call 112. DT can not just "push" the =
Location Info to the end device and write =
into the =
General Terms and =
Conditions that the user is =
responsible for its =
misuse. (A lot of people buy the =
AVM FritzBox DSL-Router because it has =
a simple switch to turn-off the WLAN without any =
software configuration.) I expect regulatory requirements in =
Germany =
asking the access =
providers to =
be able to =
do location hiding for 112.   =

Laura   =

-----Urspr=FCngliche Nachricht-----

Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]

Gesendet: Freitag, 7. Dezember 2007 18:13

An: Liess, Laura

Cc: ecrit@ietf.org

Betreff: Re: AW: [Ecrit] Location Hiding -- State of the =
Art

Laura,

just =
because somebody says "we need it" doesn't make it an =
IETF  

requirement. Please justify why mobile access cannot provide =
locations  

to =
end users.

Henning

On =
Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:

> =
Brian,

>

> =
I checked with my company and we need LH for both civic and geo =
for  

> =
fixed and mobile access. Only DSL and civic is not an =
option.

>

> =
I would support sending the ESRP/PSAP URI to the UA, as proposed =
by  

> =
Barbara and James some weeks ago.

>

> =
Laura

>

>

>

> =
-----Urspr=FCngliche Nachricht-----

> =
Von: Brian Rosen [mailto:br@brianrosen.net]

> =
Gesendet: Dienstag, 4. Dezember 2007 16:37

> =
An: 'Hannes Tschofenig'

> =
Cc: 'ECRIT'

> =
Betreff: RE: [Ecrit] Location Hiding -- State of the =
Art

>

> =
Proposed text for framework

>

> =
Some access networks wish to restrict who can get a high quality  =

> =
location,

> =
possibly based on a payment arrangement.  For emergency calls, =
high  

> =
quality

> =
location must be provided.  An access network can reasonably =
be  

> =
expected to

> =
have a relationship with the PSAPs in its catchment area, so =
giving  

> =
location

> =
to the PSAP will be straightforward

>

>

> =
However, an endpoint may need location

> =
for routing, and a proxy may need to verify that a purported  =

> =
emergency call

> =
is targeted at a bona fide PSAP.  To do so, it may take the =
location  

> =
passed

> =
with the call and query LoST to confirm that the URI is =
genuine.   

> =
"Hiding"

> =
location interferes with this check.  To achieve location =
hiding,  

> =
the LIS

> =
can return a coarse location which is good enough to elicit the =
same

> =
response from LoST as the actual location would.  The endpoint =
and  

> =
the proxy

> =
can use this location to route and verify.  A suitable location =
for  

> =
a geo is

> =
a polygon calculated by intersecting the service boundaries of all  =

> =
of the

> =
emergency services that respond to the actual location.  A =
suitable  

> =
location

> =
for a civic is any civic location within the intersection of the  =

> =
service

> =
boundaries of emergency services.  In a great many cases, a =
country  

> =
code is

> =
sufficient.  In others a state/province or a city name is  =

> =
sufficient.  Of

> =
course, the LIS would always return a location reference, which  =

> =
would return

> =
high quality location for a PSAP and coarse location to the =
endpoint  

> =
or any

> =
proxy unknown to the LIS.

>

> =
Proposed text for phonebcp:

>

> =
A LIS who wishes to hide location returns a location reference.  =
When

> =
dereferenced by the endpoint or proxy:

> =
1. For LIS's returning geo:

>    For each location served by the LIS, compute =
the intersection of  

> =
the

>    service boundaries for all emergency =
services known to LoST for the

>    location. Return the resulting polygon, or =
any point in the  

> =
polygon as

>    the value during a =
dereference

> =
2. For LIS's returning civic:

>    Determine a civic location which is within =
the service boundary  

> =
of all

>    emergency services known to LoST for the =
location.  In a great many

>    cases, this will be a country code, =
province/state or city.  

> =
Return this

>    coarse civic location as the value during a =
dereference

> =
Note that the service boundaries returned from LoST have a TTL, =
the

> =
intersections MUST recalculated if the service boundary =
changes.   

> =
The LIS

> =
MUST return high quality location to a PSAP or ESRP.

>

> =
Brian

>

>> -----Original Message-----

>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.ne=
t]

>> Sent: Monday, December 03, 2007 1:38 PM

>> To: Brian Rosen

>> Cc: 'James M. Polk'; 'Stark, Barbara'; =
'ECRIT'

>> Subject: Re: [Ecrit] Location Hiding -- State of the =
Art

>>

>> Hi Brian,

>>

>> Brian Rosen wrote:

>>> It's fine with me if there is a separate doc, but =
framework and  

>>> phonebcp

>>> have to reference it.

>>>

>> Are we talking about informative or normative =
references?

>>> I think it can be solved with a one paragraph =
description of the  

>>> problem

>> in

>>> framework and a one paragraph solution in phonebcp, =
but if there  

>>> is a

>>> separate doc and a reference, I will be =
happy.

>>>

>> That does not make sense.

>> The solution is not one paragraph and the text in phone =
bcp is  

>> normative.

>>

>> Ciao

>> Hannes

>>

>>> Brian

>>>

>>>

>>>> -----Original Message-----

>>>> From: James M. Polk [mailto:jmpolk@cisco.com]

>>>> Sent: Monday, December 03, 2007 7:37 =
PM

>>>> To: Stark, Barbara; Hannes Tschofenig; =
ECRIT

>>>> Subject: RE: [Ecrit] Location Hiding -- State of =
the Art

>>>>

>>>> Currently, the WG (and document editors!) should =
be operating under

>>>> the consensus direction that Location Hiding *not* =
be in PhoneBCP  

>>>> or

>>>> Framework.  This was a clear consensus call =
in Chicago - and not by

>>>> default, but by most people voicing actively =
against having this

>>>> Hiding in either core ECRIT documents, and I =
haven't yet talked to

>>>> anyone here in Vancouver that thinks =
otherwise.

>>>>

>>>> Location Hiding is something that needs to be =
addressed BY ITSELF

>>>> (i.e., in its own doc) so everyone can focus on =
the singular topic,

>>>> and work towards not talking past each other (not =
like that's

>>>> happened before in ECRIT....  =
:-/

>>>>

>>>> Who disagrees with this?

>>>>

>>>> BTW - if someone thinks Location Hiding should be =
put back into

>>>> PhoneBCP or Framework, then they can attempt to =
gain WG consensus  

>>>> on

>>>> that, but that's different than a direction of =
this inevitability  

>>>> or

>>>> that there is not consensus on =
this.

>>>>

>>>>

>>>> At 07:23 AM 12/3/2007, Stark, Barbara =
wrote:

>>>>

>>>>> If people felt this was good enough so that =
access providers  

>>>>> would not

>>>>> need to be required to build the =
infrastructure to provide  

>>>>> location

>>>>> (because people could use this method instead =
of getting  

>>>>> location from

>>>>> access providers), then location hiding would =
be dead. If people  

>>>>> still

>>>>> want to place a requirement on access =
providers to provide  

>>>>> location,

>>>>> then location hiding is not =
dead.

>>>>> Barbara

>>>>>

>>>>> -----Original Message-----

>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.ne=
t]

>>>>> Sent: Saturday, December 01, 2007 3:34 =
PM

>>>>> To: ECRIT

>>>>> Subject: [Ecrit] Location Hiding -- State of =
the Art

>>>>>

>>>>> I thought that the following article would be =
of interest for you:

>>>>> http:/=
/googleblog.blogspot.com/2007/11/lost-no-found.html=

>>>>>

>>>>> Here is text from

>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-=

>> your

>>>>> -map.html

>>>>> "

>>>>> My Location is a new beta technology from =
Google that uses cell  

>>>>> tower

>>>>> identification to provide you with approximate =
location  

>>>>> information,

>> so

>>>>> it will work on phones without =
GPS.

>>>>> "

>>>>> Note that this stuff is not really new =
technology. It existed  

>>>>> already

>>>>> for some time but the availability of GPS =
devices made it  

>>>>> possible to

>>>>> setup the database in a more efficient =
way.

>>>>>

>>>>> Anyway, this mechanism allows you to obtain =
location information  

>>>>> with

>>>>> your cell phone (using the cell id) without =
interacting with the

>>>>> cellular operator.

>>>>> In short: operator cannot charge for =
location

>>>>>

>>>>> While the location information is not really =
useful for first

>> responders

>>>>>

>>>>> it is still good enough for finding the =
closest PSAP.

>>>>>

>>>>> Is this the dead of location =
hiding?

>>>>>

>>>>> Ciao

>>>>> Hannes

>>>>>

>>>>>

>>>>> =
_______________________________________________

>>>>> Ecrit mailing list

>>>>> Ecrit@ietf.org

>>>>> https://www1.ietf.o=
rg/mailman/listinfo/ecrit

>>>>>

>>>>> =
_______________________________________________

>>>>> Ecrit mailing list

>>>>> Ecrit@ietf.org

>>>>> https://www1.ietf.o=
rg/mailman/listinfo/ecrit

>>>>>

>>>> =
_______________________________________________

>>>> Ecrit mailing list

>>>> Ecrit@ietf.org

>>>> https://www1.ietf.o=
rg/mailman/listinfo/ecrit

>>>>

>

>

> =
_______________________________________________

> =
Ecrit mailing list

> =
Ecrit@ietf.org

> =
https://www1.ietf.o=
rg/mailman/listinfo/ecrit

>

> =
_______________________________________________

> =
Ecrit mailing list

> =
Ecrit@ietf.org

> =
https://www1.ietf.o=
rg/mailman/listinfo/ecrit

_______________________________________________

Ecrit =
mailing list

Ecrit@ietf.org

https://www1.ietf.o=
rg/mailman/listinfo/ecrit

------_=_NextPart_001_01C83B35.78515419--

--===============1578520716==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--===============1578520716==--

From ecrit-bounces@ietf.org Mon Dec 10 09:56:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1k3m-0006AX-N0; Mon, 10 Dec 2007 09:56:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k3k-00068J-RM
	for ecrit@ietf.org; Mon, 10 Dec 2007 09:56:40 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1k3i-0005oj-SJ
	for ecrit@ietf.org; Mon, 10 Dec 2007 09:56:40 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J1k3b-0004i9-Vp; Mon, 10 Dec 2007 08:56:32 -0600
From: "Brian Rosen" 
To: "'Dawson, Martin'" ,
	"'Henning Schulzrinne'" ,
	"'Stark, Barbara'" 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 09:56:33 -0500
Message-ID: <03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnA=
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0d6b5666eba887052ef5e87a9de0d3b8
Cc: ecrit@ietf.org, "'Liess, Laura'" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

The only emergency service in the U.S. is urn:service:sos.  There is =
only
one boundary and if it changes (which LoST tells you via the TTL of the
service boundary), you may have to find those locations affected by the
change when they request a new location URI. =20

In the countries where there are multiple services, there are only a few
(sometimes one) ESRPs.

There could be some theoretic case of lots of ESRPs and lots of =
services, in
which case there are more intersections, but the calculation is simple,
fairly quick, and the TTLs make it easy to determine when a change is =
made,
and several pretty straightforward strategies are available to minimize =
the
work on the LIS.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Saturday, December 08, 2007 6:39 PM
> To: Henning Schulzrinne; Stark, Barbara
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Hi all,
>=20
> Everything is qualified on what ultimately gets regulated. But it's
> probably time to discuss real world implications of this topic.
>=20
> I expect that, if access operators are required to provide location, =
it is
> only going to be for the purpose of emergency services. I doubt that
> regulators will even consider mandating that they provide it for all =
users
> for all purposes. There'll be no sledgehammer to force access =
providers to
> give everyone a free location service - so it won't happen until =
operators
> have their own reasons to do so.
>=20
> Since access providers can't control what client devices actually use
> location information for, they will only implement a system that =
permits a
> recognised emergency entity to retrieve the actual location value. =
They'll
> only give the end subscriber location information if that's already =
paid
> for as part of the subscription.
>=20
> The fundamental problem with the "do location hiding by providing
> location" proposal is exactly that. It fails to hide location. This is
> particularly the case in the US (which is a difficult market to =
ignore).
> The intersection of every possible service area - also called an ESN =
or
> ESZ - in the US is a quite granular area; certainly good for quite a =
lot
> of services. For a mobile access provider, in particular, a =
considerable
> amount of capital equipment is going to be invoked to provide this =
quite
> good location information.
>=20
> On the other hand, in many other countries (e.g. the UK and Australia)
> this technique is probably not problematic for the carrier, because =
they
> are just going to return the country code. That's as granular as you =
need
> to be for emergency services.
>=20
> So here's what will happen if this is the official IETF =
recommendation. It
> may get adopted but operators will limit the provided location =
information
> to just the country indicator. They'll do this in the US as well =
(they'll
> refuse to process all the LoST boundary data and take responsibility =
for
> consequent routing outcome). This means that VSPs dealing with calls
> originating in the US will need to use i2. This is because the V2
> interface in i2 does support a location reference while LoST is unable =
to
> do this. The country information will certainly be useful for =
arbitrating
> which VPC to use though - so that's good. It will mean that direct to =
PSAP
> calls won't be able to be made in the US. That's a shame. Other
> jurisdictions that only have a single PSAP route will be able to =
support
> this. OTOH, it might force the US to provide a federal level URI with
> proxies that can subsequently do the dereference and lower level =
routing -
> so maybe it's not such a shame. It won't result in access providers =
giving
> free location information until they are ready to do so however.
>=20
> Editorial and a genuine question:
>=20
> IMO, supporting the services URI extension in HELD or adding location
> reference support to LoST are both superior engineering solutions. =
They
> just aren't driven by the punitive motivations of the "hide by not =
hiding"
> proposal. Arguments that they are inferior because they require =
protocol
> changes are specious and self-fulfilling. That's why the "reference =
query"
> mechanism for LoST was "postponed" in the interest of getting LoST
> finalized. It continues to be used as a prop for this particular =
hiding
> proposal. By this line of argument, we would never add or modify =
protocols
> for anything.
>=20
> It's very difficult not to lapse into sarcasm in this area (I feel =
like
> saying it's OK not to have location hiding because Columbia University =
and
> Cisco are going to underwrite the cost of providing a 5x9s reliable
> ubiquitous location service in all public access networks out of pure
> philanthropy.... but I won't :) ).
>=20
> Insisting on providing location for all applications is like insisting
> that cellular operators let users call anyone just to ensure that they =
can
> also make emergency calls. In this hypothetical situation, refusing to
> define protocol mechanisms that permit them to distinguish between the
> scenarios would only result in there being no cellular service - or =
just
> publicly funded cellular services. It's a counter-productive attitude.
>=20
> This provides the opportunity for me to once more ask a question that
> hasn't been responded to in the past. Why is ECRIT describing a =
solution
> that has the VSP involved in the emergency call at all? Why would the =
VSP
> want to be involved in emergency calls - and why would the caller want
> them involved? It seems to be not in the interest of either party. =
There's
> already an interim architecture for the non "end-to-end IP" scenario
> called i2. In any circumstance where any of the device, the network, =
or
> emergency operator are not ECRIT-capable, then the VSP does need to be
> involved and i2 is a valid fallback.
>=20
> Cheers,
> Martin
>=20
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Saturday, 8 December 2007 8:56 AM
> To: Stark, Barbara
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Translation: You have more lobbyists than I (or the IETF), so give me.
> Thanks for clarifying that.
>=20
> Henning
>=20
> On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:
>=20
> > [The following statements are my opinion, and should not be
> > attributed to the company I work for.]
> >
> > Henning,
> > It's true that the IETF doesn't have to do something just because
> > someone wants it. It's also true that the IETF has no authority or
> > ability to force implementation of RFCs by companies who refuse to
> > implement them. You cannot shove a solution down the throats of
> > access providers that they are unwilling to buy in to. In my
> > opinion, even attempting to do so would be, well, unethical.
> >
> > So, you have a choice:
> > 1) create a solution that you like that major stakeholders are
> > unwilling to implement
> > 2) create a solution that you don't quite like, but that's better
> > than what we have today, and which major stakeholders are willing to
> > implement
> >
> > Believe it or not, major telecom companies in the US and Europe put
> > a lot of effort into lobbying regulatory bodies, to achieve
> > desirable outcomes. The IETF doesn't put in such effort. If you want
> > to make a go at pushing through a solution that stakeholders in
> > these regions are set against, and see if you can get regulatory
> > agencies to bless it, then go for it. I think the odds are stacked
> > against you, though. Especially since there are workable solutions
> > that these companies have said they would be willing to accept.
> >
> > Here is why mobile access providers "cannot" provide the best
> > available location directly to end user devices: They don't want to.
> > At this point in time, it's their network, their data, and their
> > choice.
> >
> > In free market economies, you generally have to be able to *prove*
> > (and not just say it without proof) massive benefit or massive harm
> > before you can force companies to do what they don't want to do,
> > through regulation. Again, if you think you can take on that battle
> > and win, go for it.
> >
> > I, for one, believe that not providing the "real" location value to
> > end devices would not cause such benefit or harm. If users want to
> > know what location PSAPs get on their behalf, and regulators believe
> > such a capability is needed, then we can let the phonebcp-described
> > test mechanism voice it back over the voice medium (this would only
> > work for civic), or return a JPEG map with a dot on it. This would
> > provide location in a format that's usable by a human being, but not
> > an application. Or maybe, in some countries, the regulators do
> > require access providers to give out the best possible location
> > values to end devices. But it's really improbable that you could
> > force the regulators of all countries to see things your way.
> >
> > But, this is all just my opinion.
> > Barbara
> >
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Friday, December 07, 2007 12:13 PM
> > To: Liess, Laura
> > Cc: ecrit@ietf.org
> > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Laura,
> >
> > just because somebody says "we need it" doesn't make it an IETF
> > requirement. Please justify why mobile access cannot provide =
locations
> > to end users.
> >
> > Henning
> >
> > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
> >
> >> Brian,
> >>
> >> I checked with my company and we need LH for both civic and geo for
> >> fixed and mobile access. Only DSL and civic is not an option.
> >>
> >> I would support sending the ESRP/PSAP URI to the UA, as proposed by
> >> Barbara and James some weeks ago.
> >>
> >> Laura
> >>
> >>
> >>
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: Brian Rosen [mailto:br@brianrosen.net]
> >> Gesendet: Dienstag, 4. Dezember 2007 16:37
> >> An: 'Hannes Tschofenig'
> >> Cc: 'ECRIT'
> >> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
> >>
> >> Proposed text for framework
> >>
> >> Some access networks wish to restrict who can get a high quality
> >> location,
> >> possibly based on a payment arrangement.  For emergency calls, high
> >> quality
> >> location must be provided.  An access network can reasonably be
> >> expected to
> >> have a relationship with the PSAPs in its catchment area, so giving
> >> location
> >> to the PSAP will be straightforward
> >>
> >>
> >> However, an endpoint may need location
> >> for routing, and a proxy may need to verify that a purported
> >> emergency call
> >> is targeted at a bona fide PSAP.  To do so, it may take the =
location
> >> passed
> >> with the call and query LoST to confirm that the URI is genuine.
> >> "Hiding"
> >> location interferes with this check.  To achieve location hiding,
> >> the LIS
> >> can return a coarse location which is good enough to elicit the =
same
> >> response from LoST as the actual location would.  The endpoint and
> >> the proxy
> >> can use this location to route and verify.  A suitable location for
> >> a geo is
> >> a polygon calculated by intersecting the service boundaries of all
> >> of the
> >> emergency services that respond to the actual location.  A suitable
> >> location
> >> for a civic is any civic location within the intersection of the
> >> service
> >> boundaries of emergency services.  In a great many cases, a country
> >> code is
> >> sufficient.  In others a state/province or a city name is
> >> sufficient.  Of
> >> course, the LIS would always return a location reference, which
> >> would return
> >> high quality location for a PSAP and coarse location to the =
endpoint
> >> or any
> >> proxy unknown to the LIS.
> >>
> >> Proposed text for phonebcp:
> >>
> >> A LIS who wishes to hide location returns a location reference.  =
When
> >> dereferenced by the endpoint or proxy:
> >> 1. For LIS's returning geo:
> >>   For each location served by the LIS, compute the intersection of
> >> the
> >>   service boundaries for all emergency services known to LoST for =
the
> >>   location. Return the resulting polygon, or any point in the
> >> polygon as
> >>   the value during a dereference
> >> 2. For LIS's returning civic:
> >>   Determine a civic location which is within the service boundary
> >> of all
> >>   emergency services known to LoST for the location.  In a great =
many
> >>   cases, this will be a country code, province/state or city.
> >> Return this
> >>   coarse civic location as the value during a dereference
> >> Note that the service boundaries returned from LoST have a TTL, the
> >> intersections MUST recalculated if the service boundary changes.
> >> The LIS
> >> MUST return high quality location to a PSAP or ESRP.
> >>
> >> Brian
> >>
> >>> -----Original Message-----
> >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >>> Sent: Monday, December 03, 2007 1:38 PM
> >>> To: Brian Rosen
> >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> >>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
> >>>
> >>> Hi Brian,
> >>>
> >>> Brian Rosen wrote:
> >>>> It's fine with me if there is a separate doc, but framework and
> >>>> phonebcp
> >>>> have to reference it.
> >>>>
> >>> Are we talking about informative or normative references?
> >>>> I think it can be solved with a one paragraph description of the
> >>>> problem
> >>> in
> >>>> framework and a one paragraph solution in phonebcp, but if there
> >>>> is a
> >>>> separate doc and a reference, I will be happy.
> >>>>
> >>> That does not make sense.
> >>> The solution is not one paragraph and the text in phone bcp is
> >>> normative.
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>> Brian
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> >>>>> Sent: Monday, December 03, 2007 7:37 PM
> >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
> >>>>>
> >>>>> Currently, the WG (and document editors!) should be operating
> >>>>> under
> >>>>> the consensus direction that Location Hiding *not* be in =
PhoneBCP
> >>>>> or
> >>>>> Framework.  This was a clear consensus call in Chicago - and not
> >>>>> by
> >>>>> default, but by most people voicing actively against having this
> >>>>> Hiding in either core ECRIT documents, and I haven't yet talked =
to
> >>>>> anyone here in Vancouver that thinks otherwise.
> >>>>>
> >>>>> Location Hiding is something that needs to be addressed BY =
ITSELF
> >>>>> (i.e., in its own doc) so everyone can focus on the singular
> >>>>> topic,
> >>>>> and work towards not talking past each other (not like that's
> >>>>> happened before in ECRIT....  :-/
> >>>>>
> >>>>> Who disagrees with this?
> >>>>>
> >>>>> BTW - if someone thinks Location Hiding should be put back into
> >>>>> PhoneBCP or Framework, then they can attempt to gain WG =
consensus
> >>>>> on
> >>>>> that, but that's different than a direction of this =
inevitability
> >>>>> or
> >>>>> that there is not consensus on this.
> >>>>>
> >>>>>
> >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> >>>>>
> >>>>>> If people felt this was good enough so that access providers
> >>>>>> would not
> >>>>>> need to be required to build the infrastructure to provide
> >>>>>> location
> >>>>>> (because people could use this method instead of getting
> >>>>>> location from
> >>>>>> access providers), then location hiding would be dead. If =
people
> >>>>>> still
> >>>>>> want to place a requirement on access providers to provide
> >>>>>> location,
> >>>>>> then location hiding is not dead.
> >>>>>> Barbara
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >>>>>> Sent: Saturday, December 01, 2007 3:34 PM
> >>>>>> To: ECRIT
> >>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
> >>>>>>
> >>>>>> I thought that the following article would be of interest for
> >>>>>> you:
> >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
> >>>>>>
> >>>>>> Here is text from
> >>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-
> on-
> >>> your
> >>>>>> -map.html
> >>>>>> "
> >>>>>> My Location is a new beta technology from Google that uses cell
> >>>>>> tower
> >>>>>> identification to provide you with approximate location
> >>>>>> information,
> >>> so
> >>>>>> it will work on phones without GPS.
> >>>>>> "
> >>>>>> Note that this stuff is not really new technology. It existed
> >>>>>> already
> >>>>>> for some time but the availability of GPS devices made it
> >>>>>> possible to
> >>>>>> setup the database in a more efficient way.
> >>>>>>
> >>>>>> Anyway, this mechanism allows you to obtain location =
information
> >>>>>> with
> >>>>>> your cell phone (using the cell id) without interacting with =
the
> >>>>>> cellular operator.
> >>>>>> In short: operator cannot charge for location
> >>>>>>
> >>>>>> While the location information is not really useful for first
> >>> responders
> >>>>>>
> >>>>>> it is still good enough for finding the closest PSAP.
> >>>>>>
> >>>>>> Is this the dead of location hiding?
> >>>>>>
> >>>>>> Ciao
> >>>>>> Hannes
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Ecrit mailing list
> >>>>>> Ecrit@ietf.org
> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Ecrit mailing list
> >>>>>> Ecrit@ietf.org
> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Ecrit mailing list
> >>>>> Ecrit@ietf.org
> >>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> >>>>>
> >>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ecrit
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> > *****
> >
> > 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
> >
> >
>=20
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> 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
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 10:38:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1ki9-0000m8-7z; Mon, 10 Dec 2007 10:38:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1khz-0000jK-Fp
	for ecrit@ietf.org; Mon, 10 Dec 2007 10:38:15 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1khx-0003fi-8X
	for ecrit@ietf.org; Mon, 10 Dec 2007 10:38:15 -0500
X-SEF-Processed: 5_0_0_910__2007_12_10_09_49_16
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Mon, 10 Dec 2007 09:49:16 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 09:38:12 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 09:38:08 -0600
Message-ID: 
In-Reply-To: <03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sA==
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>
From: "Winterbottom, James" 
To: "Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" ,
	"Stark, Barbara" 
X-OriginalArrivalTime: 10 Dec 2007 15:38:12.0530 (UTC)
	FILETIME=[AC56A920:01C83B42]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Brian,=0D=0A=0D=0AThe primary aim for hiding location is not to make it har=
d for emergency services, but to enable the ability to charge for value add=
ed services. Can you please explain how this solution (other than through a=
 one off charge for location) supports this requirement.=0D=0A=0D=0ACheers=0D=
=0AJames=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Brian R=
osen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, 11 December 2007 1:57=
 AM=0D=0A> To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'=0D=0A=
> Cc: ecrit@ietf.org; 'Liess, Laura'=0D=0A> Subject: RE: AW: [Ecrit] Locati=
on Hiding -- State of the Art=0D=0A>=20=0D=0A> The only emergency service i=
n the U.S. is urn:service:sos.  There is only=0D=0A> one boundary and if it=
 changes (which LoST tells you via the TTL of the=0D=0A> service boundary),=
 you may have to find those locations affected by the=0D=0A> change when th=
ey request a new location URI.=0D=0A>=20=0D=0A> In the countries where ther=
e are multiple services, there are only a few=0D=0A> (sometimes one) ESRPs.=0D=
=0A>=20=0D=0A> There could be some theoretic case of lots of ESRPs and lots=
 of services,=0D=0A> in=0D=0A> which case there are more intersections, but=
 the calculation is simple,=0D=0A> fairly quick, and the TTLs make it easy =
to determine when a change is=0D=0A> made,=0D=0A> and several pretty straig=
htforward strategies are available to minimize=0D=0A> the=0D=0A> work on th=
e LIS.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D=
=0A> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent=
: Saturday, December 08, 2007 6:39 PM=0D=0A> > To: Henning Schulzrinne; Sta=
rk, Barbara=0D=0A> > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > Subject: RE:=
 AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> >=0D=0A> > Hi all,=0D=
=0A> >=0D=0A> > Everything is qualified on what ultimately gets regulated. =
But it's=0D=0A> > probably time to discuss real world implications of this =
topic.=0D=0A> >=0D=0A> > I expect that, if access operators are required to=
 provide location, it=0D=0A> is=0D=0A> > only going to be for the purpose o=
f emergency services. I doubt that=0D=0A> > regulators will even consider m=
andating that they provide it for all=0D=0A> users=0D=0A> > for all purpose=
s. There'll be no sledgehammer to force access providers=0D=0A> to=0D=0A> >=
 give everyone a free location service - so it won't happen until=0D=0A> op=
erators=0D=0A> > have their own reasons to do so.=0D=0A> >=0D=0A> > Since a=
ccess providers can't control what client devices actually use=0D=0A> > loc=
ation information for, they will only implement a system that permits=0D=0A=
> a=0D=0A> > recognised emergency entity to retrieve the actual location va=
lue.=0D=0A> They'll=0D=0A> > only give the end subscriber location informat=
ion if that's already paid=0D=0A> > for as part of the subscription.=0D=0A>=
 >=0D=0A> > The fundamental problem with the "do location hiding by providi=
ng=0D=0A> > location" proposal is exactly that. It fails to hide location. =
This is=0D=0A> > particularly the case in the US (which is a difficult mark=
et to ignore).=0D=0A> > The intersection of every possible service area - a=
lso called an ESN or=0D=0A> > ESZ - in the US is a quite granular area; cer=
tainly good for quite a lot=0D=0A> > of services. For a mobile access provi=
der, in particular, a considerable=0D=0A> > amount of capital equipment is =
going to be invoked to provide this quite=0D=0A> > good location informatio=
n.=0D=0A> >=0D=0A> > On the other hand, in many other countries (e.g. the U=
K and Australia)=0D=0A> > this technique is probably not problematic for th=
e carrier, because they=0D=0A> > are just going to return the country code.=
 That's as granular as you=0D=0A> need=0D=0A> > to be for emergency service=
s.=0D=0A> >=0D=0A> > So here's what will happen if this is the official IET=
F recommendation.=0D=0A> It=0D=0A> > may get adopted but operators will lim=
it the provided location=0D=0A> information=0D=0A> > to just the country in=
dicator. They'll do this in the US as well=0D=0A> (they'll=0D=0A> > refuse =
to process all the LoST boundary data and take responsibility for=0D=0A> > =
consequent routing outcome). This means that VSPs dealing with calls=0D=0A>=
 > originating in the US will need to use i2. This is because the V2=0D=0A>=
 > interface in i2 does support a location reference while LoST is unable=0D=
=0A> to=0D=0A> > do this. The country information will certainly be useful =
for=0D=0A> arbitrating=0D=0A> > which VPC to use though - so that's good. I=
t will mean that direct to=0D=0A> PSAP=0D=0A> > calls won't be able to be m=
ade in the US. That's a shame. Other=0D=0A> > jurisdictions that only have =
a single PSAP route will be able to support=0D=0A> > this. OTOH, it might f=
orce the US to provide a federal level URI with=0D=0A> > proxies that can s=
ubsequently do the dereference and lower level routing=0D=0A> -=0D=0A> > so=
 maybe it's not such a shame. It won't result in access providers=0D=0A> gi=
ving=0D=0A> > free location information until they are ready to do so howev=
er.=0D=0A> >=0D=0A> > Editorial and a genuine question:=0D=0A> >=0D=0A> > I=
MO, supporting the services URI extension in HELD or adding location=0D=0A>=
 > reference support to LoST are both superior engineering solutions. They=0D=
=0A> > just aren't driven by the punitive motivations of the "hide by not=0D=
=0A> hiding"=0D=0A> > proposal. Arguments that they are inferior because th=
ey require protocol=0D=0A> > changes are specious and self-fulfilling. That=
's why the "reference=0D=0A> query"=0D=0A> > mechanism for LoST was "postpo=
ned" in the interest of getting LoST=0D=0A> > finalized. It continues to be=
 used as a prop for this particular hiding=0D=0A> > proposal. By this line =
of argument, we would never add or modify=0D=0A> protocols=0D=0A> > for any=
thing.=0D=0A> >=0D=0A> > It's very difficult not to lapse into sarcasm in t=
his area (I feel like=0D=0A> > saying it's OK not to have location hiding b=
ecause Columbia University=0D=0A> and=0D=0A> > Cisco are going to underwrit=
e the cost of providing a 5x9s reliable=0D=0A> > ubiquitous location servic=
e in all public access networks out of pure=0D=0A> > philanthropy.... but I=
 won't :) ).=0D=0A> >=0D=0A> > Insisting on providing location for all appl=
ications is like insisting=0D=0A> > that cellular operators let users call =
anyone just to ensure that they=0D=0A> can=0D=0A> > also make emergency cal=
ls. In this hypothetical situation, refusing to=0D=0A> > define protocol me=
chanisms that permit them to distinguish between the=0D=0A> > scenarios wou=
ld only result in there being no cellular service - or just=0D=0A> > public=
ly funded cellular services. It's a counter-productive attitude.=0D=0A> >=0D=
=0A> > This provides the opportunity for me to once more ask a question tha=
t=0D=0A> > hasn't been responded to in the past. Why is ECRIT describing a =
solution=0D=0A> > that has the VSP involved in the emergency call at all=3F=
 Why would the=0D=0A> VSP=0D=0A> > want to be involved in emergency calls -=
 and why would the caller want=0D=0A> > them involved=3F It seems to be not=
 in the interest of either party.=0D=0A> There's=0D=0A> > already an interi=
m architecture for the non "end-to-end IP" scenario=0D=0A> > called i2. In =
any circumstance where any of the device, the network, or=0D=0A> > emergenc=
y operator are not ECRIT-capable, then the VSP does need to be=0D=0A> > inv=
olved and i2 is a valid fallback.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=
=0A> >=0D=0A> > -----Original Message-----=0D=0A> > From: Henning Schulzrin=
ne [mailto:hgs@cs.columbia.edu]=0D=0A> > Sent: Saturday, 8 December 2007 8:=
56 AM=0D=0A> > To: Stark, Barbara=0D=0A> > Cc: ecrit@ietf.org; Liess, Laura=0D=
=0A> > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> =
>=0D=0A> > Translation: You have more lobbyists than I (or the IETF), so gi=
ve me.=0D=0A> > Thanks for clarifying that.=0D=0A> >=0D=0A> > Henning=0D=0A=
> >=0D=0A> > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:=0D=0A> >=0D=0A=
> > > [The following statements are my opinion, and should not be=0D=0A> > =
> attributed to the company I work for.]=0D=0A> > >=0D=0A> > > Henning,=0D=0A=
> > > It's true that the IETF doesn't have to do something just because=0D=0A=
> > > someone wants it. It's also true that the IETF has no authority or=0D=
=0A> > > ability to force implementation of RFCs by companies who refuse to=0D=
=0A> > > implement them. You cannot shove a solution down the throats of=0D=
=0A> > > access providers that they are unwilling to buy in to. In my=0D=0A=
> > > opinion, even attempting to do so would be, well, unethical.=0D=0A> >=
 >=0D=0A> > > So, you have a choice:=0D=0A> > > 1) create a solution that y=
ou like that major stakeholders are=0D=0A> > > unwilling to implement=0D=0A=
> > > 2) create a solution that you don't quite like, but that's better=0D=0A=
> > > than what we have today, and which major stakeholders are willing to=0D=
=0A> > > implement=0D=0A> > >=0D=0A> > > Believe it or not, major telecom c=
ompanies in the US and Europe put=0D=0A> > > a lot of effort into lobbying =
regulatory bodies, to achieve=0D=0A> > > desirable outcomes. The IETF doesn=
't put in such effort. If you want=0D=0A> > > to make a go at pushing throu=
gh a solution that stakeholders in=0D=0A> > > these regions are set against=
, and see if you can get regulatory=0D=0A> > > agencies to bless it, then g=
o for it. I think the odds are stacked=0D=0A> > > against you, though. Espe=
cially since there are workable solutions=0D=0A> > > that these companies h=
ave said they would be willing to accept.=0D=0A> > >=0D=0A> > > Here is why=
 mobile access providers "cannot" provide the best=0D=0A> > > available loc=
ation directly to end user devices: They don't want to.=0D=0A> > > At this =
point in time, it's their network, their data, and their=0D=0A> > > choice.=0D=
=0A> > >=0D=0A> > > In free market economies, you generally have to be able=
 to *prove*=0D=0A> > > (and not just say it without proof) massive benefit =
or massive harm=0D=0A> > > before you can force companies to do what they d=
on't want to do,=0D=0A> > > through regulation. Again, if you think you can=
 take on that battle=0D=0A> > > and win, go for it.=0D=0A> > >=0D=0A> > > I=
, for one, believe that not providing the "real" location value to=0D=0A> >=
 > end devices would not cause such benefit or harm. If users want to=0D=0A=
> > > know what location PSAPs get on their behalf, and regulators believe=0D=
=0A> > > such a capability is needed, then we can let the phonebcp-describe=
d=0D=0A> > > test mechanism voice it back over the voice medium (this would=
 only=0D=0A> > > work for civic), or return a JPEG map with a dot on it. Th=
is would=0D=0A> > > provide location in a format that's usable by a human b=
eing, but not=0D=0A> > > an application. Or maybe, in some countries, the r=
egulators do=0D=0A> > > require access providers to give out the best possi=
ble location=0D=0A> > > values to end devices. But it's really improbable t=
hat you could=0D=0A> > > force the regulators of all countries to see thing=
s your way.=0D=0A> > >=0D=0A> > > But, this is all just my opinion.=0D=0A> =
> > Barbara=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > Fro=
m: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > Sent: Friday=
, December 07, 2007 12:13 PM=0D=0A> > > To: Liess, Laura=0D=0A> > > Cc: ecr=
it@ietf.org=0D=0A> > > Subject: Re: AW: [Ecrit] Location Hiding -- State of=
 the Art=0D=0A> > >=0D=0A> > > Laura,=0D=0A> > >=0D=0A> > > just because so=
mebody says "we need it" doesn't make it an IETF=0D=0A> > > requirement. Pl=
ease justify why mobile access cannot provide locations=0D=0A> > > to end u=
sers.=0D=0A> > >=0D=0A> > > Henning=0D=0A> > >=0D=0A> > > On Dec 6, 2007, a=
t 10:10 PM, Liess, Laura wrote:=0D=0A> > >=0D=0A> > >> Brian,=0D=0A> > >>=0D=
=0A> > >> I checked with my company and we need LH for both civic and geo f=
or=0D=0A> > >> fixed and mobile access. Only DSL and civic is not an option=
=2E=0D=0A> > >>=0D=0A> > >> I would support sending the ESRP/PSAP URI to th=
e UA, as proposed by=0D=0A> > >> Barbara and James some weeks ago.=0D=0A> >=
 >>=0D=0A> > >> Laura=0D=0A> > >>=0D=0A> > >>=0D=0A> > >>=0D=0A> > >> -----=
Urspr=FCngliche Nachricht-----=0D=0A> > >> Von: Brian Rosen [mailto:br@bria=
nrosen.net]=0D=0A> > >> Gesendet: Dienstag, 4. Dezember 2007 16:37=0D=0A> >=
 >> An: 'Hannes Tschofenig'=0D=0A> > >> Cc: 'ECRIT'=0D=0A> > >> Betreff: RE=
: [Ecrit] Location Hiding -- State of the Art=0D=0A> > >>=0D=0A> > >> Propo=
sed text for framework=0D=0A> > >>=0D=0A> > >> Some access networks wish to=
 restrict who can get a high quality=0D=0A> > >> location,=0D=0A> > >> poss=
ibly based on a payment arrangement.  For emergency calls, high=0D=0A> > >>=
 quality=0D=0A> > >> location must be provided.  An access network can reas=
onably be=0D=0A> > >> expected to=0D=0A> > >> have a relationship with the =
PSAPs in its catchment area, so giving=0D=0A> > >> location=0D=0A> > >> to =
the PSAP will be straightforward=0D=0A> > >>=0D=0A> > >>=0D=0A> > >> Howeve=
r, an endpoint may need location=0D=0A> > >> for routing, and a proxy may n=
eed to verify that a purported=0D=0A> > >> emergency call=0D=0A> > >> is ta=
rgeted at a bona fide PSAP.  To do so, it may take the location=0D=0A> > >>=
 passed=0D=0A> > >> with the call and query LoST to confirm that the URI is=
 genuine.=0D=0A> > >> "Hiding"=0D=0A> > >> location interferes with this ch=
eck.  To achieve location hiding,=0D=0A> > >> the LIS=0D=0A> > >> can retur=
n a coarse location which is good enough to elicit the same=0D=0A> > >> res=
ponse from LoST as the actual location would.  The endpoint and=0D=0A> > >>=
 the proxy=0D=0A> > >> can use this location to route and verify.  A suitab=
le location for=0D=0A> > >> a geo is=0D=0A> > >> a polygon calculated by in=
tersecting the service boundaries of all=0D=0A> > >> of the=0D=0A> > >> eme=
rgency services that respond to the actual location.  A suitable=0D=0A> > >=
> location=0D=0A> > >> for a civic is any civic location within the interse=
ction of the=0D=0A> > >> service=0D=0A> > >> boundaries of emergency servic=
es.  In a great many cases, a country=0D=0A> > >> code is=0D=0A> > >> suffi=
cient.  In others a state/province or a city name is=0D=0A> > >> sufficient=
=2E  Of=0D=0A> > >> course, the LIS would always return a location referenc=
e, which=0D=0A> > >> would return=0D=0A> > >> high quality location for a P=
SAP and coarse location to the endpoint=0D=0A> > >> or any=0D=0A> > >> prox=
y unknown to the LIS.=0D=0A> > >>=0D=0A> > >> Proposed text for phonebcp:=0D=
=0A> > >>=0D=0A> > >> A LIS who wishes to hide location returns a location =
reference.  When=0D=0A> > >> dereferenced by the endpoint or proxy:=0D=0A> =
> >> 1. For LIS's returning geo:=0D=0A> > >>   For each location served by =
the LIS, compute the intersection of=0D=0A> > >> the=0D=0A> > >>   service =
boundaries for all emergency services known to LoST for the=0D=0A> > >>   l=
ocation. Return the resulting polygon, or any point in the=0D=0A> > >> poly=
gon as=0D=0A> > >>   the value during a dereference=0D=0A> > >> 2. For LIS'=
s returning civic:=0D=0A> > >>   Determine a civic location which is within=
 the service boundary=0D=0A> > >> of all=0D=0A> > >>   emergency services k=
nown to LoST for the location.  In a great many=0D=0A> > >>   cases, this w=
ill be a country code, province/state or city.=0D=0A> > >> Return this=0D=0A=
> > >>   coarse civic location as the value during a dereference=0D=0A> > >=
> Note that the service boundaries returned from LoST have a TTL, the=0D=0A=
> > >> intersections MUST recalculated if the service boundary changes.=0D=0A=
> > >> The LIS=0D=0A> > >> MUST return high quality location to a PSAP or E=
SRP.=0D=0A> > >>=0D=0A> > >> Brian=0D=0A> > >>=0D=0A> > >>> -----Original M=
essage-----=0D=0A> > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@=
gmx.net]=0D=0A> > >>> Sent: Monday, December 03, 2007 1:38 PM=0D=0A> > >>> =
To: Brian Rosen=0D=0A> > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'=0D=
=0A> > >>> Subject: Re: [Ecrit] Location Hiding -- State of the Art=0D=0A> =
> >>>=0D=0A> > >>> Hi Brian,=0D=0A> > >>>=0D=0A> > >>> Brian Rosen wrote:=0D=
=0A> > >>>> It's fine with me if there is a separate doc, but framework and=0D=
=0A> > >>>> phonebcp=0D=0A> > >>>> have to reference it.=0D=0A> > >>>>=0D=0A=
> > >>> Are we talking about informative or normative references=3F=0D=0A> =
> >>>> I think it can be solved with a one paragraph description of the=0D=0A=
> > >>>> problem=0D=0A> > >>> in=0D=0A> > >>>> framework and a one paragrap=
h solution in phonebcp, but if there=0D=0A> > >>>> is a=0D=0A> > >>>> separ=
ate doc and a reference, I will be happy.=0D=0A> > >>>>=0D=0A> > >>> That d=
oes not make sense.=0D=0A> > >>> The solution is not one paragraph and the =
text in phone bcp is=0D=0A> > >>> normative.=0D=0A> > >>>=0D=0A> > >>> Ciao=0D=
=0A> > >>> Hannes=0D=0A> > >>>=0D=0A> > >>>> Brian=0D=0A> > >>>>=0D=0A> > >=
>>>=0D=0A> > >>>>> -----Original Message-----=0D=0A> > >>>>> From: James M.=
 Polk [mailto:jmpolk@cisco.com]=0D=0A> > >>>>> Sent: Monday, December 03, 2=
007 7:37 PM=0D=0A> > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT=0D=0A=
> > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art=0D=0A> >=
 >>>>>=0D=0A> > >>>>> Currently, the WG (and document editors!) should be o=
perating=0D=0A> > >>>>> under=0D=0A> > >>>>> the consensus direction that L=
ocation Hiding *not* be in PhoneBCP=0D=0A> > >>>>> or=0D=0A> > >>>>> Framew=
ork.  This was a clear consensus call in Chicago - and not=0D=0A> > >>>>> b=
y=0D=0A> > >>>>> default, but by most people voicing actively against havin=
g this=0D=0A> > >>>>> Hiding in either core ECRIT documents, and I haven't =
yet talked to=0D=0A> > >>>>> anyone here in Vancouver that thinks otherwise=
=2E=0D=0A> > >>>>>=0D=0A> > >>>>> Location Hiding is something that needs t=
o be addressed BY ITSELF=0D=0A> > >>>>> (i.e., in its own doc) so everyone =
can focus on the singular=0D=0A> > >>>>> topic,=0D=0A> > >>>>> and work tow=
ards not talking past each other (not like that's=0D=0A> > >>>>> happened b=
efore in ECRIT....  :-/=0D=0A> > >>>>>=0D=0A> > >>>>> Who disagrees with th=
is=3F=0D=0A> > >>>>>=0D=0A> > >>>>> BTW - if someone thinks Location Hiding=
 should be put back into=0D=0A> > >>>>> PhoneBCP or Framework, then they ca=
n attempt to gain WG consensus=0D=0A> > >>>>> on=0D=0A> > >>>>> that, but t=
hat's different than a direction of this inevitability=0D=0A> > >>>>> or=0D=
=0A> > >>>>> that there is not consensus on this.=0D=0A> > >>>>>=0D=0A> > >=
>>>>=0D=0A> > >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:=0D=0A> > >=
>>>>=0D=0A> > >>>>>> If people felt this was good enough so that access pro=
viders=0D=0A> > >>>>>> would not=0D=0A> > >>>>>> need to be required to bui=
ld the infrastructure to provide=0D=0A> > >>>>>> location=0D=0A> > >>>>>> (=
because people could use this method instead of getting=0D=0A> > >>>>>> loc=
ation from=0D=0A> > >>>>>> access providers), then location hiding would be=
 dead. If people=0D=0A> > >>>>>> still=0D=0A> > >>>>>> want to place a requ=
irement on access providers to provide=0D=0A> > >>>>>> location,=0D=0A> > >=
>>>>> then location hiding is not dead.=0D=0A> > >>>>>> Barbara=0D=0A> > >>=
>>>>=0D=0A> > >>>>>> -----Original Message-----=0D=0A> > >>>>>> From: Hanne=
s Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > >>>>>> Sent: Satur=
day, December 01, 2007 3:34 PM=0D=0A> > >>>>>> To: ECRIT=0D=0A> > >>>>>> Su=
bject: [Ecrit] Location Hiding -- State of the Art=0D=0A> > >>>>>>=0D=0A> >=
 >>>>>> I thought that the following article would be of interest for=0D=0A=
> > >>>>>> you:=0D=0A> > >>>>>> http://googleblog.blogspot.com/2007/11/lost=
-no-found.html=0D=0A> > >>>>>>=0D=0A> > >>>>>> Here is text from=0D=0A> > >=
>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-=0D=0A=
> > on-=0D=0A> > >>> your=0D=0A> > >>>>>> -map.html=0D=0A> > >>>>>> "=0D=0A=
> > >>>>>> My Location is a new beta technology from Google that uses cell=0D=
=0A> > >>>>>> tower=0D=0A> > >>>>>> identification to provide you with appr=
oximate location=0D=0A> > >>>>>> information,=0D=0A> > >>> so=0D=0A> > >>>>=
>> it will work on phones without GPS.=0D=0A> > >>>>>> "=0D=0A> > >>>>>> No=
te that this stuff is not really new technology. It existed=0D=0A> > >>>>>>=
 already=0D=0A> > >>>>>> for some time but the availability of GPS devices =
made it=0D=0A> > >>>>>> possible to=0D=0A> > >>>>>> setup the database in a=
 more efficient way.=0D=0A> > >>>>>>=0D=0A> > >>>>>> Anyway, this mechanism=
 allows you to obtain location information=0D=0A> > >>>>>> with=0D=0A> > >>=
>>>> your cell phone (using the cell id) without interacting with the=0D=0A=
> > >>>>>> cellular operator.=0D=0A> > >>>>>> In short: operator cannot cha=
rge for location=0D=0A> > >>>>>>=0D=0A> > >>>>>> While the location informa=
tion is not really useful for first=0D=0A> > >>> responders=0D=0A> > >>>>>>=0D=
=0A> > >>>>>> it is still good enough for finding the closest PSAP.=0D=0A> =
> >>>>>>=0D=0A> > >>>>>> Is this the dead of location hiding=3F=0D=0A> > >>=
>>>>=0D=0A> > >>>>>> Ciao=0D=0A> > >>>>>> Hannes=0D=0A> > >>>>>>=0D=0A> > >=
>>>>>=0D=0A> > >>>>>> _______________________________________________=0D=0A=
> > >>>>>> Ecrit mailing list=0D=0A> > >>>>>> Ecrit@ietf.org=0D=0A> > >>>>>=
> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > >>>>>>=0D=0A> > >>>=
>>> _______________________________________________=0D=0A> > >>>>>> Ecrit m=
ailing list=0D=0A> > >>>>>> Ecrit@ietf.org=0D=0A> > >>>>>> https://www1.iet=
f.org/mailman/listinfo/ecrit=0D=0A> > >>>>>>=0D=0A> > >>>>> _______________=
________________________________=0D=0A> > >>>>> Ecrit mailing list=0D=0A> >=
 >>>>> Ecrit@ietf.org=0D=0A> > >>>>> https://www1.ietf.org/mailman/listinfo=
/ecrit=0D=0A> > >>>>>=0D=0A> > >>=0D=0A> > >>=0D=0A> > >> _________________=
______________________________=0D=0A> > >> Ecrit mailing list=0D=0A> > >> E=
crit@ietf.org=0D=0A> > >> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=
> > >>=0D=0A> > >> _______________________________________________=0D=0A> >=
 >> Ecrit mailing list=0D=0A> > >> Ecrit@ietf.org=0D=0A> > >> https://www1.=
ietf.org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> > > __________=
_____________________________________=0D=0A> > > Ecrit mailing list=0D=0A> =
> > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=
=0A> > >=0D=0A> > > *****=0D=0A> > >=0D=0A> > > The information transmitted=
 is intended only for the person or=0D=0A> > > entity to which it is addres=
sed and may contain confidential,=0D=0A> > > proprietary, and/or privileged=
 material. Any review, retransmission,=0D=0A> > > dissemination or other us=
e of, or taking of any action in reliance=0D=0A> > > upon this information =
by persons or entities other than the intended=0D=0A> > > recipient is proh=
ibited. If you received this in error, please=0D=0A> > > contact the sender=
 and delete the material from all computers. GA622=0D=0A> > >=0D=0A> > >=0D=
=0A> >=0D=0A> >=0D=0A> > _______________________________________________=0D=
=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.iet=
f.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> > ----------------------------=
--------------------------------------------=0D=0A> --=0D=0A> > -----------=
-----------=0D=0A> > This message is for the designated recipient only and =
may=0D=0A> > contain privileged, proprietary, or otherwise private informat=
ion.=0D=0A> > If you have received it in error, please notify the sender=0D=
=0A> > immediately and delete the original.  Any unauthorized use of=0D=0A>=
 > this email is prohibited.=0D=0A> > -------------------------------------=
-----------------------------------=0D=0A> --=0D=0A> > --------------------=
--=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > ______________________________=
_________________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A=
> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A>=
 _______________________________________________=0D=0A> Ecrit mailing list=0D=
=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=
=0A------------------------------------------------------------------------=
------------------------=0D=0AThis message is for the designated recipient =
only and may=0D=0Acontain privileged, proprietary, or otherwise private inf=
ormation. =20=0D=0AIf you have received it in error, please notify the send=
er=0D=0Aimmediately and delete the original.  Any unauthorized use of=0D=0A=
this email is prohibited.=0D=0A--------------------------------------------=
----------------------------------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 10:51:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1kuR-0005rl-O9; Mon, 10 Dec 2007 10:51:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kuR-0005rS-0V
	for ecrit@ietf.org; Mon, 10 Dec 2007 10:51:07 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1kuN-00045k-Nw
	for ecrit@ietf.org; Mon, 10 Dec 2007 10:51:06 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J1kuH-0000QX-14; Mon, 10 Dec 2007 09:50:57 -0600
From: "Brian Rosen" 
To: "'Winterbottom, James'" ,
	"'Dawson, Martin'" ,
	"'Henning Schulzrinne'" ,
	"'Stark, Barbara'" 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 10:50:58 -0500
Message-ID: <040b01c83b44$77094410$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQ
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5e12d21a4de46ba01a82feaa82469733
Cc: ecrit@ietf.org, "'Liess, Laura'" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

We are talking about location-by-reference.

An endpoint or VSP dereferencing this URI will get coarse location, as
described.

A PSAP or ESRP dereferencing will have credentials, and will get high
resolution data

An authorized entity (i.e. one paying for it) will have credentials and =
will
get high resolution data.

Where is the problem?

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Monday, December 10, 2007 10:38 AM
> To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Brian,
>=20
> The primary aim for hiding location is not to make it hard for =
emergency
> services, but to enable the ability to charge for value added =
services.
> Can you please explain how this solution (other than through a one off
> charge for location) supports this requirement.
>=20
> Cheers
> James
>=20
>=20
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Tuesday, 11 December 2007 1:57 AM
> > To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'
> > Cc: ecrit@ietf.org; 'Liess, Laura'
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > The only emergency service in the U.S. is urn:service:sos.  There is
> only
> > one boundary and if it changes (which LoST tells you via the TTL of =
the
> > service boundary), you may have to find those locations affected by =
the
> > change when they request a new location URI.
> >
> > In the countries where there are multiple services, there are only a =
few
> > (sometimes one) ESRPs.
> >
> > There could be some theoretic case of lots of ESRPs and lots of
> services,
> > in
> > which case there are more intersections, but the calculation is =
simple,
> > fairly quick, and the TTLs make it easy to determine when a change =
is
> > made,
> > and several pretty straightforward strategies are available to =
minimize
> > the
> > work on the LIS.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > Sent: Saturday, December 08, 2007 6:39 PM
> > > To: Henning Schulzrinne; Stark, Barbara
> > > Cc: ecrit@ietf.org; Liess, Laura
> > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > Hi all,
> > >
> > > Everything is qualified on what ultimately gets regulated. But =
it's
> > > probably time to discuss real world implications of this topic.
> > >
> > > I expect that, if access operators are required to provide =
location,
> it
> > is
> > > only going to be for the purpose of emergency services. I doubt =
that
> > > regulators will even consider mandating that they provide it for =
all
> > users
> > > for all purposes. There'll be no sledgehammer to force access
> providers
> > to
> > > give everyone a free location service - so it won't happen until
> > operators
> > > have their own reasons to do so.
> > >
> > > Since access providers can't control what client devices actually =
use
> > > location information for, they will only implement a system that
> permits
> > a
> > > recognised emergency entity to retrieve the actual location value.
> > They'll
> > > only give the end subscriber location information if that's =
already
> paid
> > > for as part of the subscription.
> > >
> > > The fundamental problem with the "do location hiding by providing
> > > location" proposal is exactly that. It fails to hide location. =
This is
> > > particularly the case in the US (which is a difficult market to
> ignore).
> > > The intersection of every possible service area - also called an =
ESN
> or
> > > ESZ - in the US is a quite granular area; certainly good for quite =
a
> lot
> > > of services. For a mobile access provider, in particular, a
> considerable
> > > amount of capital equipment is going to be invoked to provide this
> quite
> > > good location information.
> > >
> > > On the other hand, in many other countries (e.g. the UK and =
Australia)
> > > this technique is probably not problematic for the carrier, =
because
> they
> > > are just going to return the country code. That's as granular as =
you
> > need
> > > to be for emergency services.
> > >
> > > So here's what will happen if this is the official IETF
> recommendation.
> > It
> > > may get adopted but operators will limit the provided location
> > information
> > > to just the country indicator. They'll do this in the US as well
> > (they'll
> > > refuse to process all the LoST boundary data and take =
responsibility
> for
> > > consequent routing outcome). This means that VSPs dealing with =
calls
> > > originating in the US will need to use i2. This is because the V2
> > > interface in i2 does support a location reference while LoST is =
unable
> > to
> > > do this. The country information will certainly be useful for
> > arbitrating
> > > which VPC to use though - so that's good. It will mean that direct =
to
> > PSAP
> > > calls won't be able to be made in the US. That's a shame. Other
> > > jurisdictions that only have a single PSAP route will be able to
> support
> > > this. OTOH, it might force the US to provide a federal level URI =
with
> > > proxies that can subsequently do the dereference and lower level
> routing
> > -
> > > so maybe it's not such a shame. It won't result in access =
providers
> > giving
> > > free location information until they are ready to do so however.
> > >
> > > Editorial and a genuine question:
> > >
> > > IMO, supporting the services URI extension in HELD or adding =
location
> > > reference support to LoST are both superior engineering solutions.
> They
> > > just aren't driven by the punitive motivations of the "hide by not
> > hiding"
> > > proposal. Arguments that they are inferior because they require
> protocol
> > > changes are specious and self-fulfilling. That's why the =
"reference
> > query"
> > > mechanism for LoST was "postponed" in the interest of getting LoST
> > > finalized. It continues to be used as a prop for this particular
> hiding
> > > proposal. By this line of argument, we would never add or modify
> > protocols
> > > for anything.
> > >
> > > It's very difficult not to lapse into sarcasm in this area (I feel
> like
> > > saying it's OK not to have location hiding because Columbia =
University
> > and
> > > Cisco are going to underwrite the cost of providing a 5x9s =
reliable
> > > ubiquitous location service in all public access networks out of =
pure
> > > philanthropy.... but I won't :) ).
> > >
> > > Insisting on providing location for all applications is like =
insisting
> > > that cellular operators let users call anyone just to ensure that =
they
> > can
> > > also make emergency calls. In this hypothetical situation, =
refusing to
> > > define protocol mechanisms that permit them to distinguish between =
the
> > > scenarios would only result in there being no cellular service - =
or
> just
> > > publicly funded cellular services. It's a counter-productive =
attitude.
> > >
> > > This provides the opportunity for me to once more ask a question =
that
> > > hasn't been responded to in the past. Why is ECRIT describing a
> solution
> > > that has the VSP involved in the emergency call at all? Why would =
the
> > VSP
> > > want to be involved in emergency calls - and why would the caller =
want
> > > them involved? It seems to be not in the interest of either party.
> > There's
> > > already an interim architecture for the non "end-to-end IP" =
scenario
> > > called i2. In any circumstance where any of the device, the =
network,
> or
> > > emergency operator are not ECRIT-capable, then the VSP does need =
to be
> > > involved and i2 is a valid fallback.
> > >
> > > Cheers,
> > > Martin
> > >
> > > -----Original Message-----
> > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > Sent: Saturday, 8 December 2007 8:56 AM
> > > To: Stark, Barbara
> > > Cc: ecrit@ietf.org; Liess, Laura
> > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > Translation: You have more lobbyists than I (or the IETF), so give =
me.
> > > Thanks for clarifying that.
> > >
> > > Henning
> > >
> > > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:
> > >
> > > > [The following statements are my opinion, and should not be
> > > > attributed to the company I work for.]
> > > >
> > > > Henning,
> > > > It's true that the IETF doesn't have to do something just =
because
> > > > someone wants it. It's also true that the IETF has no authority =
or
> > > > ability to force implementation of RFCs by companies who refuse =
to
> > > > implement them. You cannot shove a solution down the throats of
> > > > access providers that they are unwilling to buy in to. In my
> > > > opinion, even attempting to do so would be, well, unethical.
> > > >
> > > > So, you have a choice:
> > > > 1) create a solution that you like that major stakeholders are
> > > > unwilling to implement
> > > > 2) create a solution that you don't quite like, but that's =
better
> > > > than what we have today, and which major stakeholders are =
willing to
> > > > implement
> > > >
> > > > Believe it or not, major telecom companies in the US and Europe =
put
> > > > a lot of effort into lobbying regulatory bodies, to achieve
> > > > desirable outcomes. The IETF doesn't put in such effort. If you =
want
> > > > to make a go at pushing through a solution that stakeholders in
> > > > these regions are set against, and see if you can get regulatory
> > > > agencies to bless it, then go for it. I think the odds are =
stacked
> > > > against you, though. Especially since there are workable =
solutions
> > > > that these companies have said they would be willing to accept.
> > > >
> > > > Here is why mobile access providers "cannot" provide the best
> > > > available location directly to end user devices: They don't want =
to.
> > > > At this point in time, it's their network, their data, and their
> > > > choice.
> > > >
> > > > In free market economies, you generally have to be able to =
*prove*
> > > > (and not just say it without proof) massive benefit or massive =
harm
> > > > before you can force companies to do what they don't want to do,
> > > > through regulation. Again, if you think you can take on that =
battle
> > > > and win, go for it.
> > > >
> > > > I, for one, believe that not providing the "real" location value =
to
> > > > end devices would not cause such benefit or harm. If users want =
to
> > > > know what location PSAPs get on their behalf, and regulators =
believe
> > > > such a capability is needed, then we can let the =
phonebcp-described
> > > > test mechanism voice it back over the voice medium (this would =
only
> > > > work for civic), or return a JPEG map with a dot on it. This =
would
> > > > provide location in a format that's usable by a human being, but =
not
> > > > an application. Or maybe, in some countries, the regulators do
> > > > require access providers to give out the best possible location
> > > > values to end devices. But it's really improbable that you could
> > > > force the regulators of all countries to see things your way.
> > > >
> > > > But, this is all just my opinion.
> > > > Barbara
> > > >
> > > > -----Original Message-----
> > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > Sent: Friday, December 07, 2007 12:13 PM
> > > > To: Liess, Laura
> > > > Cc: ecrit@ietf.org
> > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
> > > >
> > > > Laura,
> > > >
> > > > just because somebody says "we need it" doesn't make it an IETF
> > > > requirement. Please justify why mobile access cannot provide
> locations
> > > > to end users.
> > > >
> > > > Henning
> > > >
> > > > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
> > > >
> > > >> Brian,
> > > >>
> > > >> I checked with my company and we need LH for both civic and geo =
for
> > > >> fixed and mobile access. Only DSL and civic is not an option.
> > > >>
> > > >> I would support sending the ESRP/PSAP URI to the UA, as =
proposed by
> > > >> Barbara and James some weeks ago.
> > > >>
> > > >> Laura
> > > >>
> > > >>
> > > >>
> > > >> -----Urspr=FCngliche Nachricht-----
> > > >> Von: Brian Rosen [mailto:br@brianrosen.net]
> > > >> Gesendet: Dienstag, 4. Dezember 2007 16:37
> > > >> An: 'Hannes Tschofenig'
> > > >> Cc: 'ECRIT'
> > > >> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
> > > >>
> > > >> Proposed text for framework
> > > >>
> > > >> Some access networks wish to restrict who can get a high =
quality
> > > >> location,
> > > >> possibly based on a payment arrangement.  For emergency calls, =
high
> > > >> quality
> > > >> location must be provided.  An access network can reasonably be
> > > >> expected to
> > > >> have a relationship with the PSAPs in its catchment area, so =
giving
> > > >> location
> > > >> to the PSAP will be straightforward
> > > >>
> > > >>
> > > >> However, an endpoint may need location
> > > >> for routing, and a proxy may need to verify that a purported
> > > >> emergency call
> > > >> is targeted at a bona fide PSAP.  To do so, it may take the
> location
> > > >> passed
> > > >> with the call and query LoST to confirm that the URI is =
genuine.
> > > >> "Hiding"
> > > >> location interferes with this check.  To achieve location =
hiding,
> > > >> the LIS
> > > >> can return a coarse location which is good enough to elicit the
> same
> > > >> response from LoST as the actual location would.  The endpoint =
and
> > > >> the proxy
> > > >> can use this location to route and verify.  A suitable location =
for
> > > >> a geo is
> > > >> a polygon calculated by intersecting the service boundaries of =
all
> > > >> of the
> > > >> emergency services that respond to the actual location.  A =
suitable
> > > >> location
> > > >> for a civic is any civic location within the intersection of =
the
> > > >> service
> > > >> boundaries of emergency services.  In a great many cases, a =
country
> > > >> code is
> > > >> sufficient.  In others a state/province or a city name is
> > > >> sufficient.  Of
> > > >> course, the LIS would always return a location reference, which
> > > >> would return
> > > >> high quality location for a PSAP and coarse location to the
> endpoint
> > > >> or any
> > > >> proxy unknown to the LIS.
> > > >>
> > > >> Proposed text for phonebcp:
> > > >>
> > > >> A LIS who wishes to hide location returns a location reference.
> When
> > > >> dereferenced by the endpoint or proxy:
> > > >> 1. For LIS's returning geo:
> > > >>   For each location served by the LIS, compute the intersection =
of
> > > >> the
> > > >>   service boundaries for all emergency services known to LoST =
for
> the
> > > >>   location. Return the resulting polygon, or any point in the
> > > >> polygon as
> > > >>   the value during a dereference
> > > >> 2. For LIS's returning civic:
> > > >>   Determine a civic location which is within the service =
boundary
> > > >> of all
> > > >>   emergency services known to LoST for the location.  In a =
great
> many
> > > >>   cases, this will be a country code, province/state or city.
> > > >> Return this
> > > >>   coarse civic location as the value during a dereference
> > > >> Note that the service boundaries returned from LoST have a TTL, =
the
> > > >> intersections MUST recalculated if the service boundary =
changes.
> > > >> The LIS
> > > >> MUST return high quality location to a PSAP or ESRP.
> > > >>
> > > >> Brian
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > >>> Sent: Monday, December 03, 2007 1:38 PM
> > > >>> To: Brian Rosen
> > > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> > > >>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
> > > >>>
> > > >>> Hi Brian,
> > > >>>
> > > >>> Brian Rosen wrote:
> > > >>>> It's fine with me if there is a separate doc, but framework =
and
> > > >>>> phonebcp
> > > >>>> have to reference it.
> > > >>>>
> > > >>> Are we talking about informative or normative references?
> > > >>>> I think it can be solved with a one paragraph description of =
the
> > > >>>> problem
> > > >>> in
> > > >>>> framework and a one paragraph solution in phonebcp, but if =
there
> > > >>>> is a
> > > >>>> separate doc and a reference, I will be happy.
> > > >>>>
> > > >>> That does not make sense.
> > > >>> The solution is not one paragraph and the text in phone bcp is
> > > >>> normative.
> > > >>>
> > > >>> Ciao
> > > >>> Hannes
> > > >>>
> > > >>>> Brian
> > > >>>>
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> > > >>>>> Sent: Monday, December 03, 2007 7:37 PM
> > > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> > > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
> > > >>>>>
> > > >>>>> Currently, the WG (and document editors!) should be =
operating
> > > >>>>> under
> > > >>>>> the consensus direction that Location Hiding *not* be in
> PhoneBCP
> > > >>>>> or
> > > >>>>> Framework.  This was a clear consensus call in Chicago - and =
not
> > > >>>>> by
> > > >>>>> default, but by most people voicing actively against having =
this
> > > >>>>> Hiding in either core ECRIT documents, and I haven't yet =
talked
> to
> > > >>>>> anyone here in Vancouver that thinks otherwise.
> > > >>>>>
> > > >>>>> Location Hiding is something that needs to be addressed BY
> ITSELF
> > > >>>>> (i.e., in its own doc) so everyone can focus on the singular
> > > >>>>> topic,
> > > >>>>> and work towards not talking past each other (not like =
that's
> > > >>>>> happened before in ECRIT....  :-/
> > > >>>>>
> > > >>>>> Who disagrees with this?
> > > >>>>>
> > > >>>>> BTW - if someone thinks Location Hiding should be put back =
into
> > > >>>>> PhoneBCP or Framework, then they can attempt to gain WG
> consensus
> > > >>>>> on
> > > >>>>> that, but that's different than a direction of this
> inevitability
> > > >>>>> or
> > > >>>>> that there is not consensus on this.
> > > >>>>>
> > > >>>>>
> > > >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> > > >>>>>
> > > >>>>>> If people felt this was good enough so that access =
providers
> > > >>>>>> would not
> > > >>>>>> need to be required to build the infrastructure to provide
> > > >>>>>> location
> > > >>>>>> (because people could use this method instead of getting
> > > >>>>>> location from
> > > >>>>>> access providers), then location hiding would be dead. If
> people
> > > >>>>>> still
> > > >>>>>> want to place a requirement on access providers to provide
> > > >>>>>> location,
> > > >>>>>> then location hiding is not dead.
> > > >>>>>> Barbara
> > > >>>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > >>>>>> Sent: Saturday, December 01, 2007 3:34 PM
> > > >>>>>> To: ECRIT
> > > >>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
> > > >>>>>>
> > > >>>>>> I thought that the following article would be of interest =
for
> > > >>>>>> you:
> > > >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
> > > >>>>>>
> > > >>>>>> Here is text from
> > > >>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-blue-
> circle-
> > > on-
> > > >>> your
> > > >>>>>> -map.html
> > > >>>>>> "
> > > >>>>>> My Location is a new beta technology from Google that uses =
cell
> > > >>>>>> tower
> > > >>>>>> identification to provide you with approximate location
> > > >>>>>> information,
> > > >>> so
> > > >>>>>> it will work on phones without GPS.
> > > >>>>>> "
> > > >>>>>> Note that this stuff is not really new technology. It =
existed
> > > >>>>>> already
> > > >>>>>> for some time but the availability of GPS devices made it
> > > >>>>>> possible to
> > > >>>>>> setup the database in a more efficient way.
> > > >>>>>>
> > > >>>>>> Anyway, this mechanism allows you to obtain location
> information
> > > >>>>>> with
> > > >>>>>> your cell phone (using the cell id) without interacting =
with
> the
> > > >>>>>> cellular operator.
> > > >>>>>> In short: operator cannot charge for location
> > > >>>>>>
> > > >>>>>> While the location information is not really useful for =
first
> > > >>> responders
> > > >>>>>>
> > > >>>>>> it is still good enough for finding the closest PSAP.
> > > >>>>>>
> > > >>>>>> Is this the dead of location hiding?
> > > >>>>>>
> > > >>>>>> Ciao
> > > >>>>>> Hannes
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> Ecrit mailing list
> > > >>>>>> Ecrit@ietf.org
> > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> Ecrit mailing list
> > > >>>>>> Ecrit@ietf.org
> > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > >>>>>>
> > > >>>>> _______________________________________________
> > > >>>>> Ecrit mailing list
> > > >>>>> Ecrit@ietf.org
> > > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > >>>>>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Ecrit mailing list
> > > >> Ecrit@ietf.org
> > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > >>
> > > >> _______________________________________________
> > > >> Ecrit mailing list
> > > >> Ecrit@ietf.org
> > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > >
> > > >
> > > > _______________________________________________
> > > > Ecrit mailing list
> > > > Ecrit@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > >
> > > > *****
> > > >
> > > > 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
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > This message is for the designated recipient only and may
> > > contain privileged, proprietary, or otherwise private information.
> > > If you have received it in error, please notify the sender
> > > immediately and delete the original.  Any unauthorized use of
> > > this email is prohibited.
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > [mf2]
> > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 10:57:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1l0s-0005UV-DH; Mon, 10 Dec 2007 10:57:46 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1l0q-0005UO-LE
	for ecrit@ietf.org; Mon, 10 Dec 2007 10:57:44 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1l0o-0007cW-9j
	for ecrit@ietf.org; Mon, 10 Dec 2007 10:57:44 -0500
X-SEF-Processed: 5_0_0_910__2007_12_10_10_08_24
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, 10 Dec 2007 10:08:24 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 09:57:20 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 09:57:18 -0600
Message-ID: 
In-Reply-To: <040b01c83b44$77094410$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQAABDxoA=
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>
From: "Winterbottom, James" 
To: "Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" ,
	"Stark, Barbara" 
X-OriginalArrivalTime: 10 Dec 2007 15:57:20.0318 (UTC)
	FILETIME=[587935E0:01C83B45]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 441f623df000f14368137198649cb083
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

If I get coarse location good enough to route to my local pizza delivery fa=
cility then I have gotten my value added service for free.=0D=0A=0D=0AI res=
t my case!=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Brian=
 Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, 11 December 2007 2:=
51 AM=0D=0A> To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne'=
; 'Stark,=0D=0A> Barbara'=0D=0A> Cc: ecrit@ietf.org; 'Liess, Laura'=0D=0A> =
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A>=20=0D=0A=
> We are talking about location-by-reference.=0D=0A>=20=0D=0A> An endpoint =
or VSP dereferencing this URI will get coarse location, as=0D=0A> described=
=2E=0D=0A>=20=0D=0A> A PSAP or ESRP dereferencing will have credentials, an=
d will get high=0D=0A> resolution data=0D=0A>=20=0D=0A> An authorized entit=
y (i.e. one paying for it) will have credentials and=0D=0A> will=0D=0A> get=
 high resolution data.=0D=0A>=20=0D=0A> Where is the problem=3F=0D=0A>=20=0D=
=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From: Winterbottom, Ja=
mes [mailto:James.Winterbottom@andrew.com]=0D=0A> > Sent: Monday, December =
10, 2007 10:38 AM=0D=0A> > To: Brian Rosen; Dawson, Martin; Henning Schulzr=
inne; Stark, Barbara=0D=0A> > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > Sub=
ject: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> >=0D=0A> >=
 Brian,=0D=0A> >=0D=0A> > The primary aim for hiding location is not to mak=
e it hard for emergency=0D=0A> > services, but to enable the ability to cha=
rge for value added services.=0D=0A> > Can you please explain how this solu=
tion (other than through a one off=0D=0A> > charge for location) supports t=
his requirement.=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=
=0A> > > -----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br=
@brianrosen.net]=0D=0A> > > Sent: Tuesday, 11 December 2007 1:57 AM=0D=0A> =
> > To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'=0D=0A> > > =
Cc: ecrit@ietf.org; 'Liess, Laura'=0D=0A> > > Subject: RE: AW: [Ecrit] Loca=
tion Hiding -- State of the Art=0D=0A> > >=0D=0A> > > The only emergency se=
rvice in the U.S. is urn:service:sos.  There is=0D=0A> > only=0D=0A> > > on=
e boundary and if it changes (which LoST tells you via the TTL of=0D=0A> th=
e=0D=0A> > > service boundary), you may have to find those locations affect=
ed by=0D=0A> the=0D=0A> > > change when they request a new location URI.=0D=
=0A> > >=0D=0A> > > In the countries where there are multiple services, the=
re are only a=0D=0A> few=0D=0A> > > (sometimes one) ESRPs.=0D=0A> > >=0D=0A=
> > > There could be some theoretic case of lots of ESRPs and lots of=0D=0A=
> > services,=0D=0A> > > in=0D=0A> > > which case there are more intersecti=
ons, but the calculation is=0D=0A> simple,=0D=0A> > > fairly quick, and the=
 TTLs make it easy to determine when a change is=0D=0A> > > made,=0D=0A> > =
> and several pretty straightforward strategies are available to=0D=0A> min=
imize=0D=0A> > > the=0D=0A> > > work on the LIS.=0D=0A> > >=0D=0A> > > Bria=
n=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Daw=
son, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > Sent: Saturday, =
December 08, 2007 6:39 PM=0D=0A> > > > To: Henning Schulzrinne; Stark, Barb=
ara=0D=0A> > > > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > > > Subject: RE:=
 AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> > > >=0D=0A> > > > =
Hi all,=0D=0A> > > >=0D=0A> > > > Everything is qualified on what ultimatel=
y gets regulated. But it's=0D=0A> > > > probably time to discuss real world=
 implications of this topic.=0D=0A> > > >=0D=0A> > > > I expect that, if ac=
cess operators are required to provide location,=0D=0A> > it=0D=0A> > > is=0D=
=0A> > > > only going to be for the purpose of emergency services. I doubt =
that=0D=0A> > > > regulators will even consider mandating that they provide=
 it for all=0D=0A> > > users=0D=0A> > > > for all purposes. There'll be no =
sledgehammer to force access=0D=0A> > providers=0D=0A> > > to=0D=0A> > > > =
give everyone a free location service - so it won't happen until=0D=0A> > >=
 operators=0D=0A> > > > have their own reasons to do so.=0D=0A> > > >=0D=0A=
> > > > Since access providers can't control what client devices actually=0D=
=0A> use=0D=0A> > > > location information for, they will only implement a =
system that=0D=0A> > permits=0D=0A> > > a=0D=0A> > > > recognised emergency=
 entity to retrieve the actual location value.=0D=0A> > > They'll=0D=0A> > =
> > only give the end subscriber location information if that's already=0D=0A=
> > paid=0D=0A> > > > for as part of the subscription.=0D=0A> > > >=0D=0A> =
> > > The fundamental problem with the "do location hiding by providing=0D=0A=
> > > > location" proposal is exactly that. It fails to hide location. This=0D=
=0A> is=0D=0A> > > > particularly the case in the US (which is a difficult =
market to=0D=0A> > ignore).=0D=0A> > > > The intersection of every possible=
 service area - also called an ESN=0D=0A> > or=0D=0A> > > > ESZ - in the US=
 is a quite granular area; certainly good for quite a=0D=0A> > lot=0D=0A> >=
 > > of services. For a mobile access provider, in particular, a=0D=0A> > c=
onsiderable=0D=0A> > > > amount of capital equipment is going to be invoked=
 to provide this=0D=0A> > quite=0D=0A> > > > good location information.=0D=0A=
> > > >=0D=0A> > > > On the other hand, in many other countries (e.g. the U=
K and=0D=0A> Australia)=0D=0A> > > > this technique is probably not problem=
atic for the carrier, because=0D=0A> > they=0D=0A> > > > are just going to =
return the country code. That's as granular as you=0D=0A> > > need=0D=0A> >=
 > > to be for emergency services.=0D=0A> > > >=0D=0A> > > > So here's what=
 will happen if this is the official IETF=0D=0A> > recommendation.=0D=0A> >=
 > It=0D=0A> > > > may get adopted but operators will limit the provided lo=
cation=0D=0A> > > information=0D=0A> > > > to just the country indicator. T=
hey'll do this in the US as well=0D=0A> > > (they'll=0D=0A> > > > refuse to=
 process all the LoST boundary data and take responsibility=0D=0A> > for=0D=
=0A> > > > consequent routing outcome). This means that VSPs dealing with c=
alls=0D=0A> > > > originating in the US will need to use i2. This is becaus=
e the V2=0D=0A> > > > interface in i2 does support a location reference whi=
le LoST is=0D=0A> unable=0D=0A> > > to=0D=0A> > > > do this. The country in=
formation will certainly be useful for=0D=0A> > > arbitrating=0D=0A> > > > =
which VPC to use though - so that's good. It will mean that direct=0D=0A> t=
o=0D=0A> > > PSAP=0D=0A> > > > calls won't be able to be made in the US. Th=
at's a shame. Other=0D=0A> > > > jurisdictions that only have a single PSAP=
 route will be able to=0D=0A> > support=0D=0A> > > > this. OTOH, it might f=
orce the US to provide a federal level URI=0D=0A> with=0D=0A> > > > proxies=
 that can subsequently do the dereference and lower level=0D=0A> > routing=0D=
=0A> > > -=0D=0A> > > > so maybe it's not such a shame. It won't result in =
access providers=0D=0A> > > giving=0D=0A> > > > free location information u=
ntil they are ready to do so however.=0D=0A> > > >=0D=0A> > > > Editorial a=
nd a genuine question:=0D=0A> > > >=0D=0A> > > > IMO, supporting the servic=
es URI extension in HELD or adding=0D=0A> location=0D=0A> > > > reference s=
upport to LoST are both superior engineering solutions.=0D=0A> > They=0D=0A=
> > > > just aren't driven by the punitive motivations of the "hide by not=0D=
=0A> > > hiding"=0D=0A> > > > proposal. Arguments that they are inferior be=
cause they require=0D=0A> > protocol=0D=0A> > > > changes are specious and =
self-fulfilling. That's why the "reference=0D=0A> > > query"=0D=0A> > > > m=
echanism for LoST was "postponed" in the interest of getting LoST=0D=0A> > =
> > finalized. It continues to be used as a prop for this particular=0D=0A>=
 > hiding=0D=0A> > > > proposal. By this line of argument, we would never a=
dd or modify=0D=0A> > > protocols=0D=0A> > > > for anything.=0D=0A> > > >=0D=
=0A> > > > It's very difficult not to lapse into sarcasm in this area (I fe=
el=0D=0A> > like=0D=0A> > > > saying it's OK not to have location hiding be=
cause Columbia=0D=0A> University=0D=0A> > > and=0D=0A> > > > Cisco are goin=
g to underwrite the cost of providing a 5x9s reliable=0D=0A> > > > ubiquito=
us location service in all public access networks out of=0D=0A> pure=0D=0A>=
 > > > philanthropy.... but I won't :) ).=0D=0A> > > >=0D=0A> > > > Insisti=
ng on providing location for all applications is like=0D=0A> insisting=0D=0A=
> > > > that cellular operators let users call anyone just to ensure that=0D=
=0A> they=0D=0A> > > can=0D=0A> > > > also make emergency calls. In this hy=
pothetical situation, refusing=0D=0A> to=0D=0A> > > > define protocol mecha=
nisms that permit them to distinguish between=0D=0A> the=0D=0A> > > > scena=
rios would only result in there being no cellular service - or=0D=0A> > jus=
t=0D=0A> > > > publicly funded cellular services. It's a counter-productive=0D=
=0A> attitude.=0D=0A> > > >=0D=0A> > > > This provides the opportunity for =
me to once more ask a question=0D=0A> that=0D=0A> > > > hasn't been respond=
ed to in the past. Why is ECRIT describing a=0D=0A> > solution=0D=0A> > > >=
 that has the VSP involved in the emergency call at all=3F Why would=0D=0A>=
 the=0D=0A> > > VSP=0D=0A> > > > want to be involved in emergency calls - a=
nd why would the caller=0D=0A> want=0D=0A> > > > them involved=3F It seems =
to be not in the interest of either party.=0D=0A> > > There's=0D=0A> > > > =
already an interim architecture for the non "end-to-end IP" scenario=0D=0A>=
 > > > called i2. In any circumstance where any of the device, the network,=0D=
=0A> > or=0D=0A> > > > emergency operator are not ECRIT-capable, then the V=
SP does need to=0D=0A> be=0D=0A> > > > involved and i2 is a valid fallback.=0D=
=0A> > > >=0D=0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > >=
 > -----Original Message-----=0D=0A> > > > From: Henning Schulzrinne [mailt=
o:hgs@cs.columbia.edu]=0D=0A> > > > Sent: Saturday, 8 December 2007 8:56 AM=0D=
=0A> > > > To: Stark, Barbara=0D=0A> > > > Cc: ecrit@ietf.org; Liess, Laura=0D=
=0A> > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A=
> > > >=0D=0A> > > > Translation: You have more lobbyists than I (or the IE=
TF), so give=0D=0A> me.=0D=0A> > > > Thanks for clarifying that.=0D=0A> > >=
 >=0D=0A> > > > Henning=0D=0A> > > >=0D=0A> > > > On Dec 7, 2007, at 4:24 P=
M, Stark, Barbara wrote:=0D=0A> > > >=0D=0A> > > > > [The following stateme=
nts are my opinion, and should not be=0D=0A> > > > > attributed to the comp=
any I work for.]=0D=0A> > > > >=0D=0A> > > > > Henning,=0D=0A> > > > > It's=
 true that the IETF doesn't have to do something just because=0D=0A> > > > =
> someone wants it. It's also true that the IETF has no authority or=0D=0A>=
 > > > > ability to force implementation of RFCs by companies who refuse to=0D=
=0A> > > > > implement them. You cannot shove a solution down the throats o=
f=0D=0A> > > > > access providers that they are unwilling to buy in to. In =
my=0D=0A> > > > > opinion, even attempting to do so would be, well, unethic=
al.=0D=0A> > > > >=0D=0A> > > > > So, you have a choice:=0D=0A> > > > > 1) =
create a solution that you like that major stakeholders are=0D=0A> > > > > =
unwilling to implement=0D=0A> > > > > 2) create a solution that you don't q=
uite like, but that's better=0D=0A> > > > > than what we have today, and wh=
ich major stakeholders are willing=0D=0A> to=0D=0A> > > > > implement=0D=0A=
> > > > >=0D=0A> > > > > Believe it or not, major telecom companies in the =
US and Europe=0D=0A> put=0D=0A> > > > > a lot of effort into lobbying regul=
atory bodies, to achieve=0D=0A> > > > > desirable outcomes. The IETF doesn'=
t put in such effort. If you=0D=0A> want=0D=0A> > > > > to make a go at pus=
hing through a solution that stakeholders in=0D=0A> > > > > these regions a=
re set against, and see if you can get regulatory=0D=0A> > > > > agencies t=
o bless it, then go for it. I think the odds are stacked=0D=0A> > > > > aga=
inst you, though. Especially since there are workable solutions=0D=0A> > > =
> > that these companies have said they would be willing to accept.=0D=0A> =
> > > >=0D=0A> > > > > Here is why mobile access providers "cannot" provide=
 the best=0D=0A> > > > > available location directly to end user devices: T=
hey don't want=0D=0A> to.=0D=0A> > > > > At this point in time, it's their =
network, their data, and their=0D=0A> > > > > choice.=0D=0A> > > > >=0D=0A>=
 > > > > In free market economies, you generally have to be able to *prove*=0D=
=0A> > > > > (and not just say it without proof) massive benefit or massive=0D=
=0A> harm=0D=0A> > > > > before you can force companies to do what they don=
't want to do,=0D=0A> > > > > through regulation. Again, if you think you c=
an take on that=0D=0A> battle=0D=0A> > > > > and win, go for it.=0D=0A> > >=
 > >=0D=0A> > > > > I, for one, believe that not providing the "real" locat=
ion value=0D=0A> to=0D=0A> > > > > end devices would not cause such benefit=
 or harm. If users want to=0D=0A> > > > > know what location PSAPs get on t=
heir behalf, and regulators=0D=0A> believe=0D=0A> > > > > such a capability=
 is needed, then we can let the phonebcp-=0D=0A> described=0D=0A> > > > > t=
est mechanism voice it back over the voice medium (this would=0D=0A> only=0D=
=0A> > > > > work for civic), or return a JPEG map with a dot on it. This w=
ould=0D=0A> > > > > provide location in a format that's usable by a human b=
eing, but=0D=0A> not=0D=0A> > > > > an application. Or maybe, in some count=
ries, the regulators do=0D=0A> > > > > require access providers to give out=
 the best possible location=0D=0A> > > > > values to end devices. But it's =
really improbable that you could=0D=0A> > > > > force the regulators of all=
 countries to see things your way.=0D=0A> > > > >=0D=0A> > > > > But, this =
is all just my opinion.=0D=0A> > > > > Barbara=0D=0A> > > > >=0D=0A> > > > =
> -----Original Message-----=0D=0A> > > > > From: Henning Schulzrinne [mail=
to:hgs@cs.columbia.edu]=0D=0A> > > > > Sent: Friday, December 07, 2007 12:1=
3 PM=0D=0A> > > > > To: Liess, Laura=0D=0A> > > > > Cc: ecrit@ietf.org=0D=0A=
> > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A=
> > > > >=0D=0A> > > > > Laura,=0D=0A> > > > >=0D=0A> > > > > just because =
somebody says "we need it" doesn't make it an IETF=0D=0A> > > > > requireme=
nt. Please justify why mobile access cannot provide=0D=0A> > locations=0D=0A=
> > > > > to end users.=0D=0A> > > > >=0D=0A> > > > > Henning=0D=0A> > > > =
>=0D=0A> > > > > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:=0D=0A> > =
> > >=0D=0A> > > > >> Brian,=0D=0A> > > > >>=0D=0A> > > > >> I checked with=
 my company and we need LH for both civic and geo=0D=0A> for=0D=0A> > > > >=
> fixed and mobile access. Only DSL and civic is not an option.=0D=0A> > > =
> >>=0D=0A> > > > >> I would support sending the ESRP/PSAP URI to the UA, a=
s proposed=0D=0A> by=0D=0A> > > > >> Barbara and James some weeks ago.=0D=0A=
> > > > >>=0D=0A> > > > >> Laura=0D=0A> > > > >>=0D=0A> > > > >>=0D=0A> > >=
 > >>=0D=0A> > > > >> -----Urspr=FCngliche Nachricht-----=0D=0A> > > > >> V=
on: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > >> Gesendet: Dienst=
ag, 4. Dezember 2007 16:37=0D=0A> > > > >> An: 'Hannes Tschofenig'=0D=0A> >=
 > > >> Cc: 'ECRIT'=0D=0A> > > > >> Betreff: RE: [Ecrit] Location Hiding --=
 State of the Art=0D=0A> > > > >>=0D=0A> > > > >> Proposed text for framewo=
rk=0D=0A> > > > >>=0D=0A> > > > >> Some access networks wish to restrict wh=
o can get a high quality=0D=0A> > > > >> location,=0D=0A> > > > >> possibly=
 based on a payment arrangement.  For emergency calls,=0D=0A> high=0D=0A> >=
 > > >> quality=0D=0A> > > > >> location must be provided.  An access netwo=
rk can reasonably be=0D=0A> > > > >> expected to=0D=0A> > > > >> have a rel=
ationship with the PSAPs in its catchment area, so=0D=0A> giving=0D=0A> > >=
 > >> location=0D=0A> > > > >> to the PSAP will be straightforward=0D=0A> >=
 > > >>=0D=0A> > > > >>=0D=0A> > > > >> However, an endpoint may need locat=
ion=0D=0A> > > > >> for routing, and a proxy may need to verify that a purp=
orted=0D=0A> > > > >> emergency call=0D=0A> > > > >> is targeted at a bona =
fide PSAP.  To do so, it may take the=0D=0A> > location=0D=0A> > > > >> pas=
sed=0D=0A> > > > >> with the call and query LoST to confirm that the URI is=
 genuine.=0D=0A> > > > >> "Hiding"=0D=0A> > > > >> location interferes with=
 this check.  To achieve location hiding,=0D=0A> > > > >> the LIS=0D=0A> > =
> > >> can return a coarse location which is good enough to elicit the=0D=0A=
> > same=0D=0A> > > > >> response from LoST as the actual location would.  =
The endpoint=0D=0A> and=0D=0A> > > > >> the proxy=0D=0A> > > > >> can use t=
his location to route and verify.  A suitable location=0D=0A> for=0D=0A> > =
> > >> a geo is=0D=0A> > > > >> a polygon calculated by intersecting the se=
rvice boundaries of=0D=0A> all=0D=0A> > > > >> of the=0D=0A> > > > >> emerg=
ency services that respond to the actual location.  A=0D=0A> suitable=0D=0A=
> > > > >> location=0D=0A> > > > >> for a civic is any civic location withi=
n the intersection of the=0D=0A> > > > >> service=0D=0A> > > > >> boundarie=
s of emergency services.  In a great many cases, a=0D=0A> country=0D=0A> > =
> > >> code is=0D=0A> > > > >> sufficient.  In others a state/province or a=
 city name is=0D=0A> > > > >> sufficient.  Of=0D=0A> > > > >> course, the L=
IS would always return a location reference, which=0D=0A> > > > >> would re=
turn=0D=0A> > > > >> high quality location for a PSAP and coarse location t=
o the=0D=0A> > endpoint=0D=0A> > > > >> or any=0D=0A> > > > >> proxy unknow=
n to the LIS.=0D=0A> > > > >>=0D=0A> > > > >> Proposed text for phonebcp:=0D=
=0A> > > > >>=0D=0A> > > > >> A LIS who wishes to hide location returns a l=
ocation reference.=0D=0A> > When=0D=0A> > > > >> dereferenced by the endpoi=
nt or proxy:=0D=0A> > > > >> 1. For LIS's returning geo:=0D=0A> > > > >>   =
For each location served by the LIS, compute the intersection=0D=0A> of=0D=0A=
> > > > >> the=0D=0A> > > > >>   service boundaries for all emergency servi=
ces known to LoST for=0D=0A> > the=0D=0A> > > > >>   location. Return the r=
esulting polygon, or any point in the=0D=0A> > > > >> polygon as=0D=0A> > >=
 > >>   the value during a dereference=0D=0A> > > > >> 2. For LIS's returni=
ng civic:=0D=0A> > > > >>   Determine a civic location which is within the =
service boundary=0D=0A> > > > >> of all=0D=0A> > > > >>   emergency service=
s known to LoST for the location.  In a great=0D=0A> > many=0D=0A> > > > >>=
   cases, this will be a country code, province/state or city.=0D=0A> > > >=
 >> Return this=0D=0A> > > > >>   coarse civic location as the value during=
 a dereference=0D=0A> > > > >> Note that the service boundaries returned fr=
om LoST have a TTL,=0D=0A> the=0D=0A> > > > >> intersections MUST recalcula=
ted if the service boundary changes.=0D=0A> > > > >> The LIS=0D=0A> > > > >=
> MUST return high quality location to a PSAP or ESRP.=0D=0A> > > > >>=0D=0A=
> > > > >> Brian=0D=0A> > > > >>=0D=0A> > > > >>> -----Original Message----=
-=0D=0A> > > > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.ne=
t]=0D=0A> > > > >>> Sent: Monday, December 03, 2007 1:38 PM=0D=0A> > > > >>=
> To: Brian Rosen=0D=0A> > > > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; '=
ECRIT'=0D=0A> > > > >>> Subject: Re: [Ecrit] Location Hiding -- State of th=
e Art=0D=0A> > > > >>>=0D=0A> > > > >>> Hi Brian,=0D=0A> > > > >>>=0D=0A> >=
 > > >>> Brian Rosen wrote:=0D=0A> > > > >>>> It's fine with me if there is=
 a separate doc, but framework and=0D=0A> > > > >>>> phonebcp=0D=0A> > > > =
>>>> have to reference it.=0D=0A> > > > >>>>=0D=0A> > > > >>> Are we talkin=
g about informative or normative references=3F=0D=0A> > > > >>>> I think it=
 can be solved with a one paragraph description of=0D=0A> the=0D=0A> > > > =
>>>> problem=0D=0A> > > > >>> in=0D=0A> > > > >>>> framework and a one para=
graph solution in phonebcp, but if=0D=0A> there=0D=0A> > > > >>>> is a=0D=0A=
> > > > >>>> separate doc and a reference, I will be happy.=0D=0A> > > > >>=
>>=0D=0A> > > > >>> That does not make sense.=0D=0A> > > > >>> The solution=
 is not one paragraph and the text in phone bcp is=0D=0A> > > > >>> normati=
ve.=0D=0A> > > > >>>=0D=0A> > > > >>> Ciao=0D=0A> > > > >>> Hannes=0D=0A> >=
 > > >>>=0D=0A> > > > >>>> Brian=0D=0A> > > > >>>>=0D=0A> > > > >>>>=0D=0A>=
 > > > >>>>> -----Original Message-----=0D=0A> > > > >>>>> From: James M. P=
olk [mailto:jmpolk@cisco.com]=0D=0A> > > > >>>>> Sent: Monday, December 03,=
 2007 7:37 PM=0D=0A> > > > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECR=
IT=0D=0A> > > > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the =
Art=0D=0A> > > > >>>>>=0D=0A> > > > >>>>> Currently, the WG (and document e=
ditors!) should be operating=0D=0A> > > > >>>>> under=0D=0A> > > > >>>>> th=
e consensus direction that Location Hiding *not* be in=0D=0A> > PhoneBCP=0D=
=0A> > > > >>>>> or=0D=0A> > > > >>>>> Framework.  This was a clear consens=
us call in Chicago - and=0D=0A> not=0D=0A> > > > >>>>> by=0D=0A> > > > >>>>=
> default, but by most people voicing actively against having=0D=0A> this=0D=
=0A> > > > >>>>> Hiding in either core ECRIT documents, and I haven't yet=0D=
=0A> talked=0D=0A> > to=0D=0A> > > > >>>>> anyone here in Vancouver that th=
inks otherwise.=0D=0A> > > > >>>>>=0D=0A> > > > >>>>> Location Hiding is so=
mething that needs to be addressed BY=0D=0A> > ITSELF=0D=0A> > > > >>>>> (i=
=2Ee., in its own doc) so everyone can focus on the singular=0D=0A> > > > >=
>>>> topic,=0D=0A> > > > >>>>> and work towards not talking past each other=
 (not like that's=0D=0A> > > > >>>>> happened before in ECRIT....  :-/=0D=0A=
> > > > >>>>>=0D=0A> > > > >>>>> Who disagrees with this=3F=0D=0A> > > > >>=
>>>=0D=0A> > > > >>>>> BTW - if someone thinks Location Hiding should be pu=
t back=0D=0A> into=0D=0A> > > > >>>>> PhoneBCP or Framework, then they can =
attempt to gain WG=0D=0A> > consensus=0D=0A> > > > >>>>> on=0D=0A> > > > >>=
>>> that, but that's different than a direction of this=0D=0A> > inevitabil=
ity=0D=0A> > > > >>>>> or=0D=0A> > > > >>>>> that there is not consensus on=
 this.=0D=0A> > > > >>>>>=0D=0A> > > > >>>>>=0D=0A> > > > >>>>> At 07:23 AM=
 12/3/2007, Stark, Barbara wrote:=0D=0A> > > > >>>>>=0D=0A> > > > >>>>>> If=
 people felt this was good enough so that access providers=0D=0A> > > > >>>=
>>> would not=0D=0A> > > > >>>>>> need to be required to build the infrastr=
ucture to provide=0D=0A> > > > >>>>>> location=0D=0A> > > > >>>>>> (because=
 people could use this method instead of getting=0D=0A> > > > >>>>>> locati=
on from=0D=0A> > > > >>>>>> access providers), then location hiding would b=
e dead. If=0D=0A> > people=0D=0A> > > > >>>>>> still=0D=0A> > > > >>>>>> wa=
nt to place a requirement on access providers to provide=0D=0A> > > > >>>>>=
> location,=0D=0A> > > > >>>>>> then location hiding is not dead.=0D=0A> > =
> > >>>>>> Barbara=0D=0A> > > > >>>>>>=0D=0A> > > > >>>>>> -----Original Me=
ssage-----=0D=0A> > > > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tscho=
fenig@gmx.net]=0D=0A> > > > >>>>>> Sent: Saturday, December 01, 2007 3:34 P=
M=0D=0A> > > > >>>>>> To: ECRIT=0D=0A> > > > >>>>>> Subject: [Ecrit] Locati=
on Hiding -- State of the Art=0D=0A> > > > >>>>>>=0D=0A> > > > >>>>>> I tho=
ught that the following article would be of interest for=0D=0A> > > > >>>>>=
> you:=0D=0A> > > > >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-f=
ound.html=0D=0A> > > > >>>>>>=0D=0A> > > > >>>>>> Here is text from=0D=0A> =
> > > >>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-blue-=0D=0A=
> > circle-=0D=0A> > > > on-=0D=0A> > > > >>> your=0D=0A> > > > >>>>>> -map=
=2Ehtml=0D=0A> > > > >>>>>> "=0D=0A> > > > >>>>>> My Location is a new beta=
 technology from Google that uses=0D=0A> cell=0D=0A> > > > >>>>>> tower=0D=0A=
> > > > >>>>>> identification to provide you with approximate location=0D=0A=
> > > > >>>>>> information,=0D=0A> > > > >>> so=0D=0A> > > > >>>>>> it will=
 work on phones without GPS.=0D=0A> > > > >>>>>> "=0D=0A> > > > >>>>>> Note=
 that this stuff is not really new technology. It existed=0D=0A> > > > >>>>=
>> already=0D=0A> > > > >>>>>> for some time but the availability of GPS de=
vices made it=0D=0A> > > > >>>>>> possible to=0D=0A> > > > >>>>>> setup the=
 database in a more efficient way.=0D=0A> > > > >>>>>>=0D=0A> > > > >>>>>> =
Anyway, this mechanism allows you to obtain location=0D=0A> > information=0D=
=0A> > > > >>>>>> with=0D=0A> > > > >>>>>> your cell phone (using the cell =
id) without interacting with=0D=0A> > the=0D=0A> > > > >>>>>> cellular oper=
ator.=0D=0A> > > > >>>>>> In short: operator cannot charge for location=0D=0A=
> > > > >>>>>>=0D=0A> > > > >>>>>> While the location information is not re=
ally useful for first=0D=0A> > > > >>> responders=0D=0A> > > > >>>>>>=0D=0A=
> > > > >>>>>> it is still good enough for finding the closest PSAP.=0D=0A>=
 > > > >>>>>>=0D=0A> > > > >>>>>> Is this the dead of location hiding=3F=0D=
=0A> > > > >>>>>>=0D=0A> > > > >>>>>> Ciao=0D=0A> > > > >>>>>> Hannes=0D=0A=
> > > > >>>>>>=0D=0A> > > > >>>>>>=0D=0A> > > > >>>>>> ____________________=
___________________________=0D=0A> > > > >>>>>> Ecrit mailing list=0D=0A> >=
 > > >>>>>> Ecrit@ietf.org=0D=0A> > > > >>>>>> https://www1.ietf.org/mailma=
n/listinfo/ecrit=0D=0A> > > > >>>>>>=0D=0A> > > > >>>>>> __________________=
_____________________________=0D=0A> > > > >>>>>> Ecrit mailing list=0D=0A>=
 > > > >>>>>> Ecrit@ietf.org=0D=0A> > > > >>>>>> https://www1.ietf.org/mail=
man/listinfo/ecrit=0D=0A> > > > >>>>>>=0D=0A> > > > >>>>> _________________=
______________________________=0D=0A> > > > >>>>> Ecrit mailing list=0D=0A>=
 > > > >>>>> Ecrit@ietf.org=0D=0A> > > > >>>>> https://www1.ietf.org/mailma=
n/listinfo/ecrit=0D=0A> > > > >>>>>=0D=0A> > > > >>=0D=0A> > > > >>=0D=0A> =
> > > >> _______________________________________________=0D=0A> > > > >> Ec=
rit mailing list=0D=0A> > > > >> Ecrit@ietf.org=0D=0A> > > > >> https://www=
1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > >>=0D=0A> > > > >> _________=
______________________________________=0D=0A> > > > >> Ecrit mailing list=0D=
=0A> > > > >> Ecrit@ietf.org=0D=0A> > > > >> https://www1.ietf.org/mailman/=
listinfo/ecrit=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > > _______________=
________________________________=0D=0A> > > > > Ecrit mailing list=0D=0A> >=
 > > > Ecrit@ietf.org=0D=0A> > > > > https://www1.ietf.org/mailman/listinfo=
/ecrit=0D=0A> > > > >=0D=0A> > > > > *****=0D=0A> > > > >=0D=0A> > > > > Th=
e information transmitted is intended only for the person or=0D=0A> > > > >=
 entity to which it is addressed and may contain confidential,=0D=0A> > > >=
 > proprietary, and/or privileged material. Any review,=0D=0A> retransmissi=
on,=0D=0A> > > > > dissemination or other use of, or taking of any action i=
n reliance=0D=0A> > > > > upon this information by persons or entities othe=
r than the=0D=0A> intended=0D=0A> > > > > recipient is prohibited. If you r=
eceived this in error, please=0D=0A> > > > > contact the sender and delete =
the material from all computers.=0D=0A> GA622=0D=0A> > > > >=0D=0A> > > > >=0D=
=0A> > > >=0D=0A> > > >=0D=0A> > > > ______________________________________=
_________=0D=0A> > > > Ecrit mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A=
> > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > =
> > --------------------------------------------------------------------=0D=
=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A=
> > > > This message is for the designated recipient only and may=0D=0A> > =
> > contain privileged, proprietary, or otherwise private information.=0D=0A=
> > > > If you have received it in error, please notify the sender=0D=0A> >=
 > > immediately and delete the original.  Any unauthorized use of=0D=0A> >=
 > > this email is prohibited.=0D=0A> > > > -------------------------------=
-------------------------------------=0D=0A> --=0D=0A> > --=0D=0A> > > --=0D=
=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > =
> >=0D=0A> > > > _______________________________________________=0D=0A> > >=
 > Ecrit mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1=
=2Eietf.org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> > > _______=
________________________________________=0D=0A> > > Ecrit mailing list=0D=0A=
> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecri=
t=0D=0A> >=0D=0A> > -------------------------------------------------------=
-----------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This m=
essage is for the designated recipient only and may=0D=0A> > contain privil=
eged, proprietary, or otherwise private information.=0D=0A> > If you have r=
eceived it in error, please notify the sender=0D=0A> > immediately and dele=
te the original.  Any unauthorized use of=0D=0A> > this email is prohibited=
=2E=0D=0A> > --------------------------------------------------------------=
----------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A> =0D=
=0A=0D=0A------------------------------------------------------------------=
------------------------------=0D=0AThis message is for the designated reci=
pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva=
te information. =20=0D=0AIf you have received it in error, please notify th=
e sender=0D=0Aimmediately and delete the original.  Any unauthorized use of=0D=
=0Athis email is prohibited.=0D=0A-----------------------------------------=
-------------------------------------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 11:08:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1lAu-000474-LG; Mon, 10 Dec 2007 11:08:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lAu-00043n-7U
	for ecrit@ietf.org; Mon, 10 Dec 2007 11:08:08 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1lAr-0004aH-PE
	for ecrit@ietf.org; Mon, 10 Dec 2007 11:08:08 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J1lAl-0001qV-1s; Mon, 10 Dec 2007 10:07:59 -0600
From: "Brian Rosen" 
To: "'Winterbottom, James'" ,
	"'Dawson, Martin'" ,
	"'Henning Schulzrinne'" ,
	"'Stark, Barbara'" 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 11:08:01 -0500
Message-ID: <040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQAABDxoAAAFPxMA==
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a985ed7c9101086bea2cd7287e9f83a
Cc: ecrit@ietf.org, "'Liess, Laura'" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Yes, that is true.

If your pizza delivery service provider's service boundary matches your
ESRPs boundary, you are in luck.

In my conversations with carriers who want to do location hiding, this =
is
not seen as a problem.

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Monday, December 10, 2007 10:57 AM
> To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> If I get coarse location good enough to route to my local pizza =
delivery
> facility then I have gotten my value added service for free.
>=20
> I rest my case!
>=20
>=20
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Tuesday, 11 December 2007 2:51 AM
> > To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne'; =
'Stark,
> > Barbara'
> > Cc: ecrit@ietf.org; 'Liess, Laura'
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > We are talking about location-by-reference.
> >
> > An endpoint or VSP dereferencing this URI will get coarse location, =
as
> > described.
> >
> > A PSAP or ESRP dereferencing will have credentials, and will get =
high
> > resolution data
> >
> > An authorized entity (i.e. one paying for it) will have credentials =
and
> > will
> > get high resolution data.
> >
> > Where is the problem?
> >
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > Sent: Monday, December 10, 2007 10:38 AM
> > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, =
Barbara
> > > Cc: ecrit@ietf.org; Liess, Laura
> > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > Brian,
> > >
> > > The primary aim for hiding location is not to make it hard for
> emergency
> > > services, but to enable the ability to charge for value added
> services.
> > > Can you please explain how this solution (other than through a one =
off
> > > charge for location) supports this requirement.
> > >
> > > Cheers
> > > James
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Tuesday, 11 December 2007 1:57 AM
> > > > To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'
> > > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > >
> > > > The only emergency service in the U.S. is urn:service:sos.  =
There is
> > > only
> > > > one boundary and if it changes (which LoST tells you via the TTL =
of
> > the
> > > > service boundary), you may have to find those locations affected =
by
> > the
> > > > change when they request a new location URI.
> > > >
> > > > In the countries where there are multiple services, there are =
only a
> > few
> > > > (sometimes one) ESRPs.
> > > >
> > > > There could be some theoretic case of lots of ESRPs and lots of
> > > services,
> > > > in
> > > > which case there are more intersections, but the calculation is
> > simple,
> > > > fairly quick, and the TTLs make it easy to determine when a =
change
> is
> > > > made,
> > > > and several pretty straightforward strategies are available to
> > minimize
> > > > the
> > > > work on the LIS.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > > Sent: Saturday, December 08, 2007 6:39 PM
> > > > > To: Henning Schulzrinne; Stark, Barbara
> > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Everything is qualified on what ultimately gets regulated. But
> it's
> > > > > probably time to discuss real world implications of this =
topic.
> > > > >
> > > > > I expect that, if access operators are required to provide
> location,
> > > it
> > > > is
> > > > > only going to be for the purpose of emergency services. I =
doubt
> that
> > > > > regulators will even consider mandating that they provide it =
for
> all
> > > > users
> > > > > for all purposes. There'll be no sledgehammer to force access
> > > providers
> > > > to
> > > > > give everyone a free location service - so it won't happen =
until
> > > > operators
> > > > > have their own reasons to do so.
> > > > >
> > > > > Since access providers can't control what client devices =
actually
> > use
> > > > > location information for, they will only implement a system =
that
> > > permits
> > > > a
> > > > > recognised emergency entity to retrieve the actual location =
value.
> > > > They'll
> > > > > only give the end subscriber location information if that's
> already
> > > paid
> > > > > for as part of the subscription.
> > > > >
> > > > > The fundamental problem with the "do location hiding by =
providing
> > > > > location" proposal is exactly that. It fails to hide location.
> This
> > is
> > > > > particularly the case in the US (which is a difficult market =
to
> > > ignore).
> > > > > The intersection of every possible service area - also called =
an
> ESN
> > > or
> > > > > ESZ - in the US is a quite granular area; certainly good for =
quite
> a
> > > lot
> > > > > of services. For a mobile access provider, in particular, a
> > > considerable
> > > > > amount of capital equipment is going to be invoked to provide =
this
> > > quite
> > > > > good location information.
> > > > >
> > > > > On the other hand, in many other countries (e.g. the UK and
> > Australia)
> > > > > this technique is probably not problematic for the carrier,
> because
> > > they
> > > > > are just going to return the country code. That's as granular =
as
> you
> > > > need
> > > > > to be for emergency services.
> > > > >
> > > > > So here's what will happen if this is the official IETF
> > > recommendation.
> > > > It
> > > > > may get adopted but operators will limit the provided location
> > > > information
> > > > > to just the country indicator. They'll do this in the US as =
well
> > > > (they'll
> > > > > refuse to process all the LoST boundary data and take
> responsibility
> > > for
> > > > > consequent routing outcome). This means that VSPs dealing with
> calls
> > > > > originating in the US will need to use i2. This is because the =
V2
> > > > > interface in i2 does support a location reference while LoST =
is
> > unable
> > > > to
> > > > > do this. The country information will certainly be useful for
> > > > arbitrating
> > > > > which VPC to use though - so that's good. It will mean that =
direct
> > to
> > > > PSAP
> > > > > calls won't be able to be made in the US. That's a shame. =
Other
> > > > > jurisdictions that only have a single PSAP route will be able =
to
> > > support
> > > > > this. OTOH, it might force the US to provide a federal level =
URI
> > with
> > > > > proxies that can subsequently do the dereference and lower =
level
> > > routing
> > > > -
> > > > > so maybe it's not such a shame. It won't result in access
> providers
> > > > giving
> > > > > free location information until they are ready to do so =
however.
> > > > >
> > > > > Editorial and a genuine question:
> > > > >
> > > > > IMO, supporting the services URI extension in HELD or adding
> > location
> > > > > reference support to LoST are both superior engineering =
solutions.
> > > They
> > > > > just aren't driven by the punitive motivations of the "hide by =
not
> > > > hiding"
> > > > > proposal. Arguments that they are inferior because they =
require
> > > protocol
> > > > > changes are specious and self-fulfilling. That's why the
> "reference
> > > > query"
> > > > > mechanism for LoST was "postponed" in the interest of getting =
LoST
> > > > > finalized. It continues to be used as a prop for this =
particular
> > > hiding
> > > > > proposal. By this line of argument, we would never add or =
modify
> > > > protocols
> > > > > for anything.
> > > > >
> > > > > It's very difficult not to lapse into sarcasm in this area (I =
feel
> > > like
> > > > > saying it's OK not to have location hiding because Columbia
> > University
> > > > and
> > > > > Cisco are going to underwrite the cost of providing a 5x9s
> reliable
> > > > > ubiquitous location service in all public access networks out =
of
> > pure
> > > > > philanthropy.... but I won't :) ).
> > > > >
> > > > > Insisting on providing location for all applications is like
> > insisting
> > > > > that cellular operators let users call anyone just to ensure =
that
> > they
> > > > can
> > > > > also make emergency calls. In this hypothetical situation,
> refusing
> > to
> > > > > define protocol mechanisms that permit them to distinguish =
between
> > the
> > > > > scenarios would only result in there being no cellular service =
-
> or
> > > just
> > > > > publicly funded cellular services. It's a counter-productive
> > attitude.
> > > > >
> > > > > This provides the opportunity for me to once more ask a =
question
> > that
> > > > > hasn't been responded to in the past. Why is ECRIT describing =
a
> > > solution
> > > > > that has the VSP involved in the emergency call at all? Why =
would
> > the
> > > > VSP
> > > > > want to be involved in emergency calls - and why would the =
caller
> > want
> > > > > them involved? It seems to be not in the interest of either =
party.
> > > > There's
> > > > > already an interim architecture for the non "end-to-end IP"
> scenario
> > > > > called i2. In any circumstance where any of the device, the
> network,
> > > or
> > > > > emergency operator are not ECRIT-capable, then the VSP does =
need
> to
> > be
> > > > > involved and i2 is a valid fallback.
> > > > >
> > > > > Cheers,
> > > > > Martin
> > > > >
> > > > > -----Original Message-----
> > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > Sent: Saturday, 8 December 2007 8:56 AM
> > > > > To: Stark, Barbara
> > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
> > > > >
> > > > > Translation: You have more lobbyists than I (or the IETF), so =
give
> > me.
> > > > > Thanks for clarifying that.
> > > > >
> > > > > Henning
> > > > >
> > > > > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:
> > > > >
> > > > > > [The following statements are my opinion, and should not be
> > > > > > attributed to the company I work for.]
> > > > > >
> > > > > > Henning,
> > > > > > It's true that the IETF doesn't have to do something just
> because
> > > > > > someone wants it. It's also true that the IETF has no =
authority
> or
> > > > > > ability to force implementation of RFCs by companies who =
refuse
> to
> > > > > > implement them. You cannot shove a solution down the throats =
of
> > > > > > access providers that they are unwilling to buy in to. In my
> > > > > > opinion, even attempting to do so would be, well, unethical.
> > > > > >
> > > > > > So, you have a choice:
> > > > > > 1) create a solution that you like that major stakeholders =
are
> > > > > > unwilling to implement
> > > > > > 2) create a solution that you don't quite like, but that's
> better
> > > > > > than what we have today, and which major stakeholders are
> willing
> > to
> > > > > > implement
> > > > > >
> > > > > > Believe it or not, major telecom companies in the US and =
Europe
> > put
> > > > > > a lot of effort into lobbying regulatory bodies, to achieve
> > > > > > desirable outcomes. The IETF doesn't put in such effort. If =
you
> > want
> > > > > > to make a go at pushing through a solution that stakeholders =
in
> > > > > > these regions are set against, and see if you can get =
regulatory
> > > > > > agencies to bless it, then go for it. I think the odds are
> stacked
> > > > > > against you, though. Especially since there are workable
> solutions
> > > > > > that these companies have said they would be willing to =
accept.
> > > > > >
> > > > > > Here is why mobile access providers "cannot" provide the =
best
> > > > > > available location directly to end user devices: They don't =
want
> > to.
> > > > > > At this point in time, it's their network, their data, and =
their
> > > > > > choice.
> > > > > >
> > > > > > In free market economies, you generally have to be able to
> *prove*
> > > > > > (and not just say it without proof) massive benefit or =
massive
> > harm
> > > > > > before you can force companies to do what they don't want to =
do,
> > > > > > through regulation. Again, if you think you can take on that
> > battle
> > > > > > and win, go for it.
> > > > > >
> > > > > > I, for one, believe that not providing the "real" location =
value
> > to
> > > > > > end devices would not cause such benefit or harm. If users =
want
> to
> > > > > > know what location PSAPs get on their behalf, and regulators
> > believe
> > > > > > such a capability is needed, then we can let the phonebcp-
> > described
> > > > > > test mechanism voice it back over the voice medium (this =
would
> > only
> > > > > > work for civic), or return a JPEG map with a dot on it. This
> would
> > > > > > provide location in a format that's usable by a human being, =
but
> > not
> > > > > > an application. Or maybe, in some countries, the regulators =
do
> > > > > > require access providers to give out the best possible =
location
> > > > > > values to end devices. But it's really improbable that you =
could
> > > > > > force the regulators of all countries to see things your =
way.
> > > > > >
> > > > > > But, this is all just my opinion.
> > > > > > Barbara
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > Sent: Friday, December 07, 2007 12:13 PM
> > > > > > To: Liess, Laura
> > > > > > Cc: ecrit@ietf.org
> > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
> > > > > >
> > > > > > Laura,
> > > > > >
> > > > > > just because somebody says "we need it" doesn't make it an =
IETF
> > > > > > requirement. Please justify why mobile access cannot provide
> > > locations
> > > > > > to end users.
> > > > > >
> > > > > > Henning
> > > > > >
> > > > > > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
> > > > > >
> > > > > >> Brian,
> > > > > >>
> > > > > >> I checked with my company and we need LH for both civic and =
geo
> > for
> > > > > >> fixed and mobile access. Only DSL and civic is not an =
option.
> > > > > >>
> > > > > >> I would support sending the ESRP/PSAP URI to the UA, as
> proposed
> > by
> > > > > >> Barbara and James some weeks ago.
> > > > > >>
> > > > > >> Laura
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> -----Urspr=FCngliche Nachricht-----
> > > > > >> Von: Brian Rosen [mailto:br@brianrosen.net]
> > > > > >> Gesendet: Dienstag, 4. Dezember 2007 16:37
> > > > > >> An: 'Hannes Tschofenig'
> > > > > >> Cc: 'ECRIT'
> > > > > >> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
> > > > > >>
> > > > > >> Proposed text for framework
> > > > > >>
> > > > > >> Some access networks wish to restrict who can get a high
> quality
> > > > > >> location,
> > > > > >> possibly based on a payment arrangement.  For emergency =
calls,
> > high
> > > > > >> quality
> > > > > >> location must be provided.  An access network can =
reasonably be
> > > > > >> expected to
> > > > > >> have a relationship with the PSAPs in its catchment area, =
so
> > giving
> > > > > >> location
> > > > > >> to the PSAP will be straightforward
> > > > > >>
> > > > > >>
> > > > > >> However, an endpoint may need location
> > > > > >> for routing, and a proxy may need to verify that a =
purported
> > > > > >> emergency call
> > > > > >> is targeted at a bona fide PSAP.  To do so, it may take the
> > > location
> > > > > >> passed
> > > > > >> with the call and query LoST to confirm that the URI is
> genuine.
> > > > > >> "Hiding"
> > > > > >> location interferes with this check.  To achieve location
> hiding,
> > > > > >> the LIS
> > > > > >> can return a coarse location which is good enough to elicit =
the
> > > same
> > > > > >> response from LoST as the actual location would.  The =
endpoint
> > and
> > > > > >> the proxy
> > > > > >> can use this location to route and verify.  A suitable =
location
> > for
> > > > > >> a geo is
> > > > > >> a polygon calculated by intersecting the service boundaries =
of
> > all
> > > > > >> of the
> > > > > >> emergency services that respond to the actual location.  A
> > suitable
> > > > > >> location
> > > > > >> for a civic is any civic location within the intersection =
of
> the
> > > > > >> service
> > > > > >> boundaries of emergency services.  In a great many cases, a
> > country
> > > > > >> code is
> > > > > >> sufficient.  In others a state/province or a city name is
> > > > > >> sufficient.  Of
> > > > > >> course, the LIS would always return a location reference, =
which
> > > > > >> would return
> > > > > >> high quality location for a PSAP and coarse location to the
> > > endpoint
> > > > > >> or any
> > > > > >> proxy unknown to the LIS.
> > > > > >>
> > > > > >> Proposed text for phonebcp:
> > > > > >>
> > > > > >> A LIS who wishes to hide location returns a location =
reference.
> > > When
> > > > > >> dereferenced by the endpoint or proxy:
> > > > > >> 1. For LIS's returning geo:
> > > > > >>   For each location served by the LIS, compute the =
intersection
> > of
> > > > > >> the
> > > > > >>   service boundaries for all emergency services known to =
LoST
> for
> > > the
> > > > > >>   location. Return the resulting polygon, or any point in =
the
> > > > > >> polygon as
> > > > > >>   the value during a dereference
> > > > > >> 2. For LIS's returning civic:
> > > > > >>   Determine a civic location which is within the service
> boundary
> > > > > >> of all
> > > > > >>   emergency services known to LoST for the location.  In a
> great
> > > many
> > > > > >>   cases, this will be a country code, province/state or =
city.
> > > > > >> Return this
> > > > > >>   coarse civic location as the value during a dereference
> > > > > >> Note that the service boundaries returned from LoST have a =
TTL,
> > the
> > > > > >> intersections MUST recalculated if the service boundary
> changes.
> > > > > >> The LIS
> > > > > >> MUST return high quality location to a PSAP or ESRP.
> > > > > >>
> > > > > >> Brian
> > > > > >>
> > > > > >>> -----Original Message-----
> > > > > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > > > >>> Sent: Monday, December 03, 2007 1:38 PM
> > > > > >>> To: Brian Rosen
> > > > > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> > > > > >>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
> > > > > >>>
> > > > > >>> Hi Brian,
> > > > > >>>
> > > > > >>> Brian Rosen wrote:
> > > > > >>>> It's fine with me if there is a separate doc, but =
framework
> and
> > > > > >>>> phonebcp
> > > > > >>>> have to reference it.
> > > > > >>>>
> > > > > >>> Are we talking about informative or normative references?
> > > > > >>>> I think it can be solved with a one paragraph description =
of
> > the
> > > > > >>>> problem
> > > > > >>> in
> > > > > >>>> framework and a one paragraph solution in phonebcp, but =
if
> > there
> > > > > >>>> is a
> > > > > >>>> separate doc and a reference, I will be happy.
> > > > > >>>>
> > > > > >>> That does not make sense.
> > > > > >>> The solution is not one paragraph and the text in phone =
bcp is
> > > > > >>> normative.
> > > > > >>>
> > > > > >>> Ciao
> > > > > >>> Hannes
> > > > > >>>
> > > > > >>>> Brian
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> > > > > >>>>> Sent: Monday, December 03, 2007 7:37 PM
> > > > > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> > > > > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
> > > > > >>>>>
> > > > > >>>>> Currently, the WG (and document editors!) should be
> operating
> > > > > >>>>> under
> > > > > >>>>> the consensus direction that Location Hiding *not* be in
> > > PhoneBCP
> > > > > >>>>> or
> > > > > >>>>> Framework.  This was a clear consensus call in Chicago - =
and
> > not
> > > > > >>>>> by
> > > > > >>>>> default, but by most people voicing actively against =
having
> > this
> > > > > >>>>> Hiding in either core ECRIT documents, and I haven't yet
> > talked
> > > to
> > > > > >>>>> anyone here in Vancouver that thinks otherwise.
> > > > > >>>>>
> > > > > >>>>> Location Hiding is something that needs to be addressed =
BY
> > > ITSELF
> > > > > >>>>> (i.e., in its own doc) so everyone can focus on the =
singular
> > > > > >>>>> topic,
> > > > > >>>>> and work towards not talking past each other (not like
> that's
> > > > > >>>>> happened before in ECRIT....  :-/
> > > > > >>>>>
> > > > > >>>>> Who disagrees with this?
> > > > > >>>>>
> > > > > >>>>> BTW - if someone thinks Location Hiding should be put =
back
> > into
> > > > > >>>>> PhoneBCP or Framework, then they can attempt to gain WG
> > > consensus
> > > > > >>>>> on
> > > > > >>>>> that, but that's different than a direction of this
> > > inevitability
> > > > > >>>>> or
> > > > > >>>>> that there is not consensus on this.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> > > > > >>>>>
> > > > > >>>>>> If people felt this was good enough so that access
> providers
> > > > > >>>>>> would not
> > > > > >>>>>> need to be required to build the infrastructure to =
provide
> > > > > >>>>>> location
> > > > > >>>>>> (because people could use this method instead of =
getting
> > > > > >>>>>> location from
> > > > > >>>>>> access providers), then location hiding would be dead. =
If
> > > people
> > > > > >>>>>> still
> > > > > >>>>>> want to place a requirement on access providers to =
provide
> > > > > >>>>>> location,
> > > > > >>>>>> then location hiding is not dead.
> > > > > >>>>>> Barbara
> > > > > >>>>>>
> > > > > >>>>>> -----Original Message-----
> > > > > >>>>>> From: Hannes Tschofenig =
[mailto:Hannes.Tschofenig@gmx.net]
> > > > > >>>>>> Sent: Saturday, December 01, 2007 3:34 PM
> > > > > >>>>>> To: ECRIT
> > > > > >>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
> > > > > >>>>>>
> > > > > >>>>>> I thought that the following article would be of =
interest
> for
> > > > > >>>>>> you:
> > > > > >>>>>> =
http://googleblog.blogspot.com/2007/11/lost-no-found.html
> > > > > >>>>>>
> > > > > >>>>>> Here is text from
> > > > > >>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-
> > > circle-
> > > > > on-
> > > > > >>> your
> > > > > >>>>>> -map.html
> > > > > >>>>>> "
> > > > > >>>>>> My Location is a new beta technology from Google that =
uses
> > cell
> > > > > >>>>>> tower
> > > > > >>>>>> identification to provide you with approximate location
> > > > > >>>>>> information,
> > > > > >>> so
> > > > > >>>>>> it will work on phones without GPS.
> > > > > >>>>>> "
> > > > > >>>>>> Note that this stuff is not really new technology. It
> existed
> > > > > >>>>>> already
> > > > > >>>>>> for some time but the availability of GPS devices made =
it
> > > > > >>>>>> possible to
> > > > > >>>>>> setup the database in a more efficient way.
> > > > > >>>>>>
> > > > > >>>>>> Anyway, this mechanism allows you to obtain location
> > > information
> > > > > >>>>>> with
> > > > > >>>>>> your cell phone (using the cell id) without interacting
> with
> > > the
> > > > > >>>>>> cellular operator.
> > > > > >>>>>> In short: operator cannot charge for location
> > > > > >>>>>>
> > > > > >>>>>> While the location information is not really useful for
> first
> > > > > >>> responders
> > > > > >>>>>>
> > > > > >>>>>> it is still good enough for finding the closest PSAP.
> > > > > >>>>>>
> > > > > >>>>>> Is this the dead of location hiding?
> > > > > >>>>>>
> > > > > >>>>>> Ciao
> > > > > >>>>>> Hannes
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> _______________________________________________
> > > > > >>>>>> Ecrit mailing list
> > > > > >>>>>> Ecrit@ietf.org
> > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >>>>>>
> > > > > >>>>>> _______________________________________________
> > > > > >>>>>> Ecrit mailing list
> > > > > >>>>>> Ecrit@ietf.org
> > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >>>>>>
> > > > > >>>>> _______________________________________________
> > > > > >>>>> Ecrit mailing list
> > > > > >>>>> Ecrit@ietf.org
> > > > > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >>>>>
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Ecrit mailing list
> > > > > >> Ecrit@ietf.org
> > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Ecrit mailing list
> > > > > >> Ecrit@ietf.org
> > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Ecrit mailing list
> > > > > > Ecrit@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >
> > > > > > *****
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > Ecrit@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > > > =
------------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > ----------------------
> > > > > This message is for the designated recipient only and may
> > > > > contain privileged, proprietary, or otherwise private =
information.
> > > > > If you have received it in error, please notify the sender
> > > > > immediately and delete the original.  Any unauthorized use of
> > > > > this email is prohibited.
> > > > > =
------------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > ----------------------
> > > > > [mf2]
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > Ecrit@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > >
> > > >
> > > > _______________________________________________
> > > > Ecrit mailing list
> > > > Ecrit@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > This message is for the designated recipient only and may
> > > contain privileged, proprietary, or otherwise private information.
> > > If you have received it in error, please notify the sender
> > > immediately and delete the original.  Any unauthorized use of
> > > this email is prohibited.
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > [mf2]
> >
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 11:14:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1lHL-0003wc-3x; Mon, 10 Dec 2007 11:14:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lHJ-0003sK-S5
	for ecrit@ietf.org; Mon, 10 Dec 2007 11:14:45 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1lHH-0004jc-74
	for ecrit@ietf.org; Mon, 10 Dec 2007 11:14:45 -0500
X-SEF-Processed: 5_0_0_910__2007_12_10_10_25_44
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Mon, 10 Dec 2007 10:25:43 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 10:14:40 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 10:14:32 -0600
Message-ID: 
In-Reply-To: <040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQAABDxoAAAFPxMAAAKBBg
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>
From: "Winterbottom, James" 
To: "Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" ,
	"Stark, Barbara" 
X-OriginalArrivalTime: 10 Dec 2007 16:14:40.0122 (UTC)
	FILETIME=[C43EB5A0:01C83B47]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 6a817af60e4281a101681ecb646dffff
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Brian my point is this.=0D=0A=0D=0AA location hiding mechanism that ONLY pr=
ovides the boundary map of the ESRP is pretty much useless in that it won't=
 enable them to support the value added case period. Since the only reason =
that anyone would pay for it is so that they can support value added servic=
es I don't see how you address the requirement.=0D=0A=0D=0AFranchise bounda=
ries are unlikely to match ESRP boundaries. Further more, not all value add=
ed service may be permitted, so the Target still needs to know what service=
s for a given location provider will be permitted to obtain location inform=
ation. I think the view of providing a coarse location is driven by a parti=
cular business model you have in mind that does not seem to match the model=
 that people I have talked to have in mind.=0D=0A=0D=0ACheers=0D=0AJames=0D=
=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailt=
o:br@brianrosen.net]=0D=0A> Sent: Tuesday, 11 December 2007 3:08 AM=0D=0A> =
To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne'; 'Stark,=0D=0A=
> Barbara'=0D=0A> Cc: ecrit@ietf.org; 'Liess, Laura'=0D=0A> Subject: RE: AW=
: [Ecrit] Location Hiding -- State of the Art=0D=0A>=20=0D=0A> Yes, that is=
 true.=0D=0A>=20=0D=0A> If your pizza delivery service provider's service b=
oundary matches your=0D=0A> ESRPs boundary, you are in luck.=0D=0A>=20=0D=0A=
> In my conversations with carriers who want to do location hiding, this is=0D=
=0A> not seen as a problem.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----=
Original Message-----=0D=0A> > From: Winterbottom, James [mailto:James.Wint=
erbottom@andrew.com]=0D=0A> > Sent: Monday, December 10, 2007 10:57 AM=0D=0A=
> > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara=0D=
=0A> > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > Subject: RE: AW: [Ecrit] L=
ocation Hiding -- State of the Art=0D=0A> >=0D=0A> > If I get coarse locati=
on good enough to route to my local pizza delivery=0D=0A> > facility then I=
 have gotten my value added service for free.=0D=0A> >=0D=0A> > I rest my c=
ase!=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > Fro=
m: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Tuesday, 11 Dece=
mber 2007 2:51 AM=0D=0A> > > To: Winterbottom, James; Dawson, Martin; 'Henn=
ing Schulzrinne';=0D=0A> 'Stark,=0D=0A> > > Barbara'=0D=0A> > > Cc: ecrit@i=
etf.org; 'Liess, Laura'=0D=0A> > > Subject: RE: AW: [Ecrit] Location Hiding=
 -- State of the Art=0D=0A> > >=0D=0A> > > We are talking about location-by=
-reference.=0D=0A> > >=0D=0A> > > An endpoint or VSP dereferencing this URI=
 will get coarse location, as=0D=0A> > > described.=0D=0A> > >=0D=0A> > > A=
 PSAP or ESRP dereferencing will have credentials, and will get high=0D=0A>=
 > > resolution data=0D=0A> > >=0D=0A> > > An authorized entity (i.e. one p=
aying for it) will have credentials=0D=0A> and=0D=0A> > > will=0D=0A> > > g=
et high resolution data.=0D=0A> > >=0D=0A> > > Where is the problem=3F=0D=0A=
> > >=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From:=
 Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A> > > > Se=
nt: Monday, December 10, 2007 10:38 AM=0D=0A> > > > To: Brian Rosen; Dawson=
, Martin; Henning Schulzrinne; Stark, Barbara=0D=0A> > > > Cc: ecrit@ietf.o=
rg; Liess, Laura=0D=0A> > > > Subject: RE: AW: [Ecrit] Location Hiding -- S=
tate of the Art=0D=0A> > > >=0D=0A> > > > Brian,=0D=0A> > > >=0D=0A> > > > =
The primary aim for hiding location is not to make it hard for=0D=0A> > eme=
rgency=0D=0A> > > > services, but to enable the ability to charge for value=
 added=0D=0A> > services.=0D=0A> > > > Can you please explain how this solu=
tion (other than through a one=0D=0A> off=0D=0A> > > > charge for location)=
 supports this requirement.=0D=0A> > > >=0D=0A> > > > Cheers=0D=0A> > > > J=
ames=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > > -----Original Message-----=0D=
=0A> > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > Se=
nt: Tuesday, 11 December 2007 1:57 AM=0D=0A> > > > > To: Dawson, Martin; 'H=
enning Schulzrinne'; 'Stark, Barbara'=0D=0A> > > > > Cc: ecrit@ietf.org; 'L=
iess, Laura'=0D=0A> > > > > Subject: RE: AW: [Ecrit] Location Hiding -- Sta=
te of the Art=0D=0A> > > > >=0D=0A> > > > > The only emergency service in t=
he U.S. is urn:service:sos.  There=0D=0A> is=0D=0A> > > > only=0D=0A> > > >=
 > one boundary and if it changes (which LoST tells you via the TTL=0D=0A> =
of=0D=0A> > > the=0D=0A> > > > > service boundary), you may have to find th=
ose locations affected=0D=0A> by=0D=0A> > > the=0D=0A> > > > > change when =
they request a new location URI.=0D=0A> > > > >=0D=0A> > > > > In the count=
ries where there are multiple services, there are only=0D=0A> a=0D=0A> > > =
few=0D=0A> > > > > (sometimes one) ESRPs.=0D=0A> > > > >=0D=0A> > > > > The=
re could be some theoretic case of lots of ESRPs and lots of=0D=0A> > > > s=
ervices,=0D=0A> > > > > in=0D=0A> > > > > which case there are more interse=
ctions, but the calculation is=0D=0A> > > simple,=0D=0A> > > > > fairly qui=
ck, and the TTLs make it easy to determine when a change=0D=0A> > is=0D=0A>=
 > > > > made,=0D=0A> > > > > and several pretty straightforward strategies=
 are available to=0D=0A> > > minimize=0D=0A> > > > > the=0D=0A> > > > > wor=
k on the LIS.=0D=0A> > > > >=0D=0A> > > > > Brian=0D=0A> > > > >=0D=0A> > >=
 > > > -----Original Message-----=0D=0A> > > > > > From: Dawson, Martin [ma=
ilto:Martin.Dawson@andrew.com]=0D=0A> > > > > > Sent: Saturday, December 08=
, 2007 6:39 PM=0D=0A> > > > > > To: Henning Schulzrinne; Stark, Barbara=0D=0A=
> > > > > > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > > > > > Subject: RE: =
AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> > > > > >=0D=0A> > >=
 > > > Hi all,=0D=0A> > > > > >=0D=0A> > > > > > Everything is qualified on=
 what ultimately gets regulated. But=0D=0A> > it's=0D=0A> > > > > > probabl=
y time to discuss real world implications of this topic.=0D=0A> > > > > >=0D=
=0A> > > > > > I expect that, if access operators are required to provide=0D=
=0A> > location,=0D=0A> > > > it=0D=0A> > > > > is=0D=0A> > > > > > only go=
ing to be for the purpose of emergency services. I doubt=0D=0A> > that=0D=0A=
> > > > > > regulators will even consider mandating that they provide it fo=
r=0D=0A> > all=0D=0A> > > > > users=0D=0A> > > > > > for all purposes. Ther=
e'll be no sledgehammer to force access=0D=0A> > > > providers=0D=0A> > > >=
 > to=0D=0A> > > > > > give everyone a free location service - so it won't =
happen until=0D=0A> > > > > operators=0D=0A> > > > > > have their own reaso=
ns to do so.=0D=0A> > > > > >=0D=0A> > > > > > Since access providers can't=
 control what client devices=0D=0A> actually=0D=0A> > > use=0D=0A> > > > > =
> location information for, they will only implement a system that=0D=0A> >=
 > > permits=0D=0A> > > > > a=0D=0A> > > > > > recognised emergency entity =
to retrieve the actual location=0D=0A> value.=0D=0A> > > > > They'll=0D=0A>=
 > > > > > only give the end subscriber location information if that's=0D=0A=
> > already=0D=0A> > > > paid=0D=0A> > > > > > for as part of the subscript=
ion.=0D=0A> > > > > >=0D=0A> > > > > > The fundamental problem with the "do=
 location hiding by=0D=0A> providing=0D=0A> > > > > > location" proposal is=
 exactly that. It fails to hide location.=0D=0A> > This=0D=0A> > > is=0D=0A=
> > > > > > particularly the case in the US (which is a difficult market to=0D=
=0A> > > > ignore).=0D=0A> > > > > > The intersection of every possible ser=
vice area - also called an=0D=0A> > ESN=0D=0A> > > > or=0D=0A> > > > > > ES=
Z - in the US is a quite granular area; certainly good for=0D=0A> quite=0D=0A=
> > a=0D=0A> > > > lot=0D=0A> > > > > > of services. For a mobile access pr=
ovider, in particular, a=0D=0A> > > > considerable=0D=0A> > > > > > amount =
of capital equipment is going to be invoked to provide=0D=0A> this=0D=0A> >=
 > > quite=0D=0A> > > > > > good location information.=0D=0A> > > > > >=0D=0A=
> > > > > > On the other hand, in many other countries (e.g. the UK and=0D=0A=
> > > Australia)=0D=0A> > > > > > this technique is probably not problemati=
c for the carrier,=0D=0A> > because=0D=0A> > > > they=0D=0A> > > > > > are =
just going to return the country code. That's as granular as=0D=0A> > you=0D=
=0A> > > > > need=0D=0A> > > > > > to be for emergency services.=0D=0A> > >=
 > > >=0D=0A> > > > > > So here's what will happen if this is the official =
IETF=0D=0A> > > > recommendation.=0D=0A> > > > > It=0D=0A> > > > > > may ge=
t adopted but operators will limit the provided location=0D=0A> > > > > inf=
ormation=0D=0A> > > > > > to just the country indicator. They'll do this in=
 the US as well=0D=0A> > > > > (they'll=0D=0A> > > > > > refuse to process =
all the LoST boundary data and take=0D=0A> > responsibility=0D=0A> > > > fo=
r=0D=0A> > > > > > consequent routing outcome). This means that VSPs dealin=
g with=0D=0A> > calls=0D=0A> > > > > > originating in the US will need to u=
se i2. This is because the=0D=0A> V2=0D=0A> > > > > > interface in i2 does =
support a location reference while LoST is=0D=0A> > > unable=0D=0A> > > > >=
 to=0D=0A> > > > > > do this. The country information will certainly be use=
ful for=0D=0A> > > > > arbitrating=0D=0A> > > > > > which VPC to use though=
 - so that's good. It will mean that=0D=0A> direct=0D=0A> > > to=0D=0A> > >=
 > > PSAP=0D=0A> > > > > > calls won't be able to be made in the US. That's=
 a shame. Other=0D=0A> > > > > > jurisdictions that only have a single PSAP=
 route will be able to=0D=0A> > > > support=0D=0A> > > > > > this. OTOH, it=
 might force the US to provide a federal level URI=0D=0A> > > with=0D=0A> >=
 > > > > proxies that can subsequently do the dereference and lower level=0D=
=0A> > > > routing=0D=0A> > > > > -=0D=0A> > > > > > so maybe it's not such=
 a shame. It won't result in access=0D=0A> > providers=0D=0A> > > > > givin=
g=0D=0A> > > > > > free location information until they are ready to do so =
however.=0D=0A> > > > > >=0D=0A> > > > > > Editorial and a genuine question=
:=0D=0A> > > > > >=0D=0A> > > > > > IMO, supporting the services URI extens=
ion in HELD or adding=0D=0A> > > location=0D=0A> > > > > > reference suppor=
t to LoST are both superior engineering=0D=0A> solutions.=0D=0A> > > > They=0D=
=0A> > > > > > just aren't driven by the punitive motivations of the "hide =
by=0D=0A> not=0D=0A> > > > > hiding"=0D=0A> > > > > > proposal. Arguments t=
hat they are inferior because they require=0D=0A> > > > protocol=0D=0A> > >=
 > > > changes are specious and self-fulfilling. That's why the=0D=0A> > "r=
eference=0D=0A> > > > > query"=0D=0A> > > > > > mechanism for LoST was "pos=
tponed" in the interest of getting=0D=0A> LoST=0D=0A> > > > > > finalized. =
It continues to be used as a prop for this particular=0D=0A> > > > hiding=0D=
=0A> > > > > > proposal. By this line of argument, we would never add or mo=
dify=0D=0A> > > > > protocols=0D=0A> > > > > > for anything.=0D=0A> > > > >=
 >=0D=0A> > > > > > It's very difficult not to lapse into sarcasm in this a=
rea (I=0D=0A> feel=0D=0A> > > > like=0D=0A> > > > > > saying it's OK not to=
 have location hiding because Columbia=0D=0A> > > University=0D=0A> > > > >=
 and=0D=0A> > > > > > Cisco are going to underwrite the cost of providing a=
 5x9s=0D=0A> > reliable=0D=0A> > > > > > ubiquitous location service in all=
 public access networks out of=0D=0A> > > pure=0D=0A> > > > > > philanthrop=
y.... but I won't :) ).=0D=0A> > > > > >=0D=0A> > > > > > Insisting on prov=
iding location for all applications is like=0D=0A> > > insisting=0D=0A> > >=
 > > > that cellular operators let users call anyone just to ensure=0D=0A> =
that=0D=0A> > > they=0D=0A> > > > > can=0D=0A> > > > > > also make emergenc=
y calls. In this hypothetical situation,=0D=0A> > refusing=0D=0A> > > to=0D=
=0A> > > > > > define protocol mechanisms that permit them to distinguish=0D=
=0A> between=0D=0A> > > the=0D=0A> > > > > > scenarios would only result in=
 there being no cellular service -=0D=0A> > or=0D=0A> > > > just=0D=0A> > >=
 > > > publicly funded cellular services. It's a counter-productive=0D=0A> =
> > attitude.=0D=0A> > > > > >=0D=0A> > > > > > This provides the opportuni=
ty for me to once more ask a question=0D=0A> > > that=0D=0A> > > > > > hasn=
't been responded to in the past. Why is ECRIT describing a=0D=0A> > > > so=
lution=0D=0A> > > > > > that has the VSP involved in the emergency call at =
all=3F Why=0D=0A> would=0D=0A> > > the=0D=0A> > > > > VSP=0D=0A> > > > > > =
want to be involved in emergency calls - and why would the=0D=0A> caller=0D=
=0A> > > want=0D=0A> > > > > > them involved=3F It seems to be not in the i=
nterest of either=0D=0A> party.=0D=0A> > > > > There's=0D=0A> > > > > > alr=
eady an interim architecture for the non "end-to-end IP"=0D=0A> > scenario=0D=
=0A> > > > > > called i2. In any circumstance where any of the device, the=0D=
=0A> > network,=0D=0A> > > > or=0D=0A> > > > > > emergency operator are not=
 ECRIT-capable, then the VSP does need=0D=0A> > to=0D=0A> > > be=0D=0A> > >=
 > > > involved and i2 is a valid fallback.=0D=0A> > > > > >=0D=0A> > > > >=
 > Cheers,=0D=0A> > > > > > Martin=0D=0A> > > > > >=0D=0A> > > > > > -----O=
riginal Message-----=0D=0A> > > > > > From: Henning Schulzrinne [mailto:hgs=
@cs.columbia.edu]=0D=0A> > > > > > Sent: Saturday, 8 December 2007 8:56 AM=0D=
=0A> > > > > > To: Stark, Barbara=0D=0A> > > > > > Cc: ecrit@ietf.org; Lies=
s, Laura=0D=0A> > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State=
 of the Art=0D=0A> > > > > >=0D=0A> > > > > > Translation: You have more lo=
bbyists than I (or the IETF), so=0D=0A> give=0D=0A> > > me.=0D=0A> > > > > =
> Thanks for clarifying that.=0D=0A> > > > > >=0D=0A> > > > > > Henning=0D=0A=
> > > > > >=0D=0A> > > > > > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wro=
te:=0D=0A> > > > > >=0D=0A> > > > > > > [The following statements are my op=
inion, and should not be=0D=0A> > > > > > > attributed to the company I wor=
k for.]=0D=0A> > > > > > >=0D=0A> > > > > > > Henning,=0D=0A> > > > > > > I=
t's true that the IETF doesn't have to do something just=0D=0A> > because=0D=
=0A> > > > > > > someone wants it. It's also true that the IETF has no=0D=0A=
> authority=0D=0A> > or=0D=0A> > > > > > > ability to force implementation =
of RFCs by companies who=0D=0A> refuse=0D=0A> > to=0D=0A> > > > > > > imple=
ment them. You cannot shove a solution down the throats=0D=0A> of=0D=0A> > =
> > > > > access providers that they are unwilling to buy in to. In my=0D=0A=
> > > > > > > opinion, even attempting to do so would be, well, unethical.=0D=
=0A> > > > > > >=0D=0A> > > > > > > So, you have a choice:=0D=0A> > > > > >=
 > 1) create a solution that you like that major stakeholders are=0D=0A> > =
> > > > > unwilling to implement=0D=0A> > > > > > > 2) create a solution th=
at you don't quite like, but that's=0D=0A> > better=0D=0A> > > > > > > than=
 what we have today, and which major stakeholders are=0D=0A> > willing=0D=0A=
> > > to=0D=0A> > > > > > > implement=0D=0A> > > > > > >=0D=0A> > > > > > >=
 Believe it or not, major telecom companies in the US and=0D=0A> Europe=0D=0A=
> > > put=0D=0A> > > > > > > a lot of effort into lobbying regulatory bodie=
s, to achieve=0D=0A> > > > > > > desirable outcomes. The IETF doesn't put i=
n such effort. If=0D=0A> you=0D=0A> > > want=0D=0A> > > > > > > to make a g=
o at pushing through a solution that stakeholders=0D=0A> in=0D=0A> > > > > =
> > these regions are set against, and see if you can get=0D=0A> regulatory=0D=
=0A> > > > > > > agencies to bless it, then go for it. I think the odds are=0D=
=0A> > stacked=0D=0A> > > > > > > against you, though. Especially since the=
re are workable=0D=0A> > solutions=0D=0A> > > > > > > that these companies =
have said they would be willing to=0D=0A> accept.=0D=0A> > > > > > >=0D=0A>=
 > > > > > > Here is why mobile access providers "cannot" provide the best=0D=
=0A> > > > > > > available location directly to end user devices: They don'=
t=0D=0A> want=0D=0A> > > to.=0D=0A> > > > > > > At this point in time, it's=
 their network, their data, and=0D=0A> their=0D=0A> > > > > > > choice.=0D=0A=
> > > > > > >=0D=0A> > > > > > > In free market economies, you generally ha=
ve to be able to=0D=0A> > *prove*=0D=0A> > > > > > > (and not just say it w=
ithout proof) massive benefit or massive=0D=0A> > > harm=0D=0A> > > > > > >=
 before you can force companies to do what they don't want to=0D=0A> do,=0D=
=0A> > > > > > > through regulation. Again, if you think you can take on th=
at=0D=0A> > > battle=0D=0A> > > > > > > and win, go for it.=0D=0A> > > > > =
> >=0D=0A> > > > > > > I, for one, believe that not providing the "real" lo=
cation=0D=0A> value=0D=0A> > > to=0D=0A> > > > > > > end devices would not =
cause such benefit or harm. If users=0D=0A> want=0D=0A> > to=0D=0A> > > > >=
 > > know what location PSAPs get on their behalf, and regulators=0D=0A> > =
> believe=0D=0A> > > > > > > such a capability is needed, then we can let t=
he phonebcp-=0D=0A> > > described=0D=0A> > > > > > > test mechanism voice i=
t back over the voice medium (this would=0D=0A> > > only=0D=0A> > > > > > >=
 work for civic), or return a JPEG map with a dot on it. This=0D=0A> > woul=
d=0D=0A> > > > > > > provide location in a format that's usable by a human =
being,=0D=0A> but=0D=0A> > > not=0D=0A> > > > > > > an application. Or mayb=
e, in some countries, the regulators do=0D=0A> > > > > > > require access p=
roviders to give out the best possible=0D=0A> location=0D=0A> > > > > > > v=
alues to end devices. But it's really improbable that you=0D=0A> could=0D=0A=
> > > > > > > force the regulators of all countries to see things your way.=0D=
=0A> > > > > > >=0D=0A> > > > > > > But, this is all just my opinion.=0D=0A=
> > > > > > > Barbara=0D=0A> > > > > > >=0D=0A> > > > > > > -----Original M=
essage-----=0D=0A> > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.col=
umbia.edu]=0D=0A> > > > > > > Sent: Friday, December 07, 2007 12:13 PM=0D=0A=
> > > > > > > To: Liess, Laura=0D=0A> > > > > > > Cc: ecrit@ietf.org=0D=0A>=
 > > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art=0D=
=0A> > > > > > >=0D=0A> > > > > > > Laura,=0D=0A> > > > > > >=0D=0A> > > > =
> > > just because somebody says "we need it" doesn't make it an=0D=0A> IET=
F=0D=0A> > > > > > > requirement. Please justify why mobile access cannot p=
rovide=0D=0A> > > > locations=0D=0A> > > > > > > to end users.=0D=0A> > > >=
 > > >=0D=0A> > > > > > > Henning=0D=0A> > > > > > >=0D=0A> > > > > > > On =
Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:=0D=0A> > > > > > >=0D=0A> > >=
 > > > >> Brian,=0D=0A> > > > > > >>=0D=0A> > > > > > >> I checked with my =
company and we need LH for both civic and=0D=0A> geo=0D=0A> > > for=0D=0A> =
> > > > > >> fixed and mobile access. Only DSL and civic is not an option.=0D=
=0A> > > > > > >>=0D=0A> > > > > > >> I would support sending the ESRP/PSAP=
 URI to the UA, as=0D=0A> > proposed=0D=0A> > > by=0D=0A> > > > > > >> Barb=
ara and James some weeks ago.=0D=0A> > > > > > >>=0D=0A> > > > > > >> Laura=0D=
=0A> > > > > > >>=0D=0A> > > > > > >>=0D=0A> > > > > > >>=0D=0A> > > > > > =
>> -----Urspr=FCngliche Nachricht-----=0D=0A> > > > > > >> Von: Brian Rosen=
 [mailto:br@brianrosen.net]=0D=0A> > > > > > >> Gesendet: Dienstag, 4. Deze=
mber 2007 16:37=0D=0A> > > > > > >> An: 'Hannes Tschofenig'=0D=0A> > > > > =
> >> Cc: 'ECRIT'=0D=0A> > > > > > >> Betreff: RE: [Ecrit] Location Hiding -=
- State of the Art=0D=0A> > > > > > >>=0D=0A> > > > > > >> Proposed text fo=
r framework=0D=0A> > > > > > >>=0D=0A> > > > > > >> Some access networks wi=
sh to restrict who can get a high=0D=0A> > quality=0D=0A> > > > > > >> loca=
tion,=0D=0A> > > > > > >> possibly based on a payment arrangement.  For eme=
rgency=0D=0A> calls,=0D=0A> > > high=0D=0A> > > > > > >> quality=0D=0A> > >=
 > > > >> location must be provided.  An access network can reasonably=0D=0A=
> be=0D=0A> > > > > > >> expected to=0D=0A> > > > > > >> have a relationshi=
p with the PSAPs in its catchment area, so=0D=0A> > > giving=0D=0A> > > > >=
 > >> location=0D=0A> > > > > > >> to the PSAP will be straightforward=0D=0A=
> > > > > > >>=0D=0A> > > > > > >>=0D=0A> > > > > > >> However, an endpoint=
 may need location=0D=0A> > > > > > >> for routing, and a proxy may need to=
 verify that a purported=0D=0A> > > > > > >> emergency call=0D=0A> > > > > =
> >> is targeted at a bona fide PSAP.  To do so, it may take the=0D=0A> > >=
 > location=0D=0A> > > > > > >> passed=0D=0A> > > > > > >> with the call an=
d query LoST to confirm that the URI is=0D=0A> > genuine.=0D=0A> > > > > > =
>> "Hiding"=0D=0A> > > > > > >> location interferes with this check.  To ac=
hieve location=0D=0A> > hiding,=0D=0A> > > > > > >> the LIS=0D=0A> > > > > =
> >> can return a coarse location which is good enough to elicit=0D=0A> the=0D=
=0A> > > > same=0D=0A> > > > > > >> response from LoST as the actual locati=
on would.  The=0D=0A> endpoint=0D=0A> > > and=0D=0A> > > > > > >> the proxy=0D=
=0A> > > > > > >> can use this location to route and verify.  A suitable=0D=
=0A> location=0D=0A> > > for=0D=0A> > > > > > >> a geo is=0D=0A> > > > > > =
>> a polygon calculated by intersecting the service boundaries=0D=0A> of=0D=
=0A> > > all=0D=0A> > > > > > >> of the=0D=0A> > > > > > >> emergency servi=
ces that respond to the actual location.  A=0D=0A> > > suitable=0D=0A> > > =
> > > >> location=0D=0A> > > > > > >> for a civic is any civic location wit=
hin the intersection of=0D=0A> > the=0D=0A> > > > > > >> service=0D=0A> > >=
 > > > >> boundaries of emergency services.  In a great many cases, a=0D=0A=
> > > country=0D=0A> > > > > > >> code is=0D=0A> > > > > > >> sufficient.  =
In others a state/province or a city name is=0D=0A> > > > > > >> sufficient=
=2E  Of=0D=0A> > > > > > >> course, the LIS would always return a location =
reference,=0D=0A> which=0D=0A> > > > > > >> would return=0D=0A> > > > > > >=
> high quality location for a PSAP and coarse location to the=0D=0A> > > > =
endpoint=0D=0A> > > > > > >> or any=0D=0A> > > > > > >> proxy unknown to th=
e LIS.=0D=0A> > > > > > >>=0D=0A> > > > > > >> Proposed text for phonebcp:=0D=
=0A> > > > > > >>=0D=0A> > > > > > >> A LIS who wishes to hide location ret=
urns a location=0D=0A> reference.=0D=0A> > > > When=0D=0A> > > > > > >> der=
eferenced by the endpoint or proxy:=0D=0A> > > > > > >> 1. For LIS's return=
ing geo:=0D=0A> > > > > > >>   For each location served by the LIS, compute=
 the=0D=0A> intersection=0D=0A> > > of=0D=0A> > > > > > >> the=0D=0A> > > >=
 > > >>   service boundaries for all emergency services known to LoST=0D=0A=
> > for=0D=0A> > > > the=0D=0A> > > > > > >>   location. Return the resulti=
ng polygon, or any point in the=0D=0A> > > > > > >> polygon as=0D=0A> > > >=
 > > >>   the value during a dereference=0D=0A> > > > > > >> 2. For LIS's r=
eturning civic:=0D=0A> > > > > > >>   Determine a civic location which is w=
ithin the service=0D=0A> > boundary=0D=0A> > > > > > >> of all=0D=0A> > > >=
 > > >>   emergency services known to LoST for the location.  In a=0D=0A> >=
 great=0D=0A> > > > many=0D=0A> > > > > > >>   cases, this will be a countr=
y code, province/state or city.=0D=0A> > > > > > >> Return this=0D=0A> > > =
> > > >>   coarse civic location as the value during a dereference=0D=0A> >=
 > > > > >> Note that the service boundaries returned from LoST have a=0D=0A=
> TTL,=0D=0A> > > the=0D=0A> > > > > > >> intersections MUST recalculated i=
f the service boundary=0D=0A> > changes.=0D=0A> > > > > > >> The LIS=0D=0A>=
 > > > > > >> MUST return high quality location to a PSAP or ESRP.=0D=0A> >=
 > > > > >>=0D=0A> > > > > > >> Brian=0D=0A> > > > > > >>=0D=0A> > > > > > =
>>> -----Original Message-----=0D=0A> > > > > > >>> From: Hannes Tschofenig=
 [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > > > > > >>> Sent: Monday, Dece=
mber 03, 2007 1:38 PM=0D=0A> > > > > > >>> To: Brian Rosen=0D=0A> > > > > >=
 >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'=0D=0A> > > > > > >>> Su=
bject: Re: [Ecrit] Location Hiding -- State of the Art=0D=0A> > > > > > >>>=0D=
=0A> > > > > > >>> Hi Brian,=0D=0A> > > > > > >>>=0D=0A> > > > > > >>> Bria=
n Rosen wrote:=0D=0A> > > > > > >>>> It's fine with me if there is a separa=
te doc, but framework=0D=0A> > and=0D=0A> > > > > > >>>> phonebcp=0D=0A> > =
> > > > >>>> have to reference it.=0D=0A> > > > > > >>>>=0D=0A> > > > > > >=
>> Are we talking about informative or normative references=3F=0D=0A> > > >=
 > > >>>> I think it can be solved with a one paragraph description=0D=0A> =
of=0D=0A> > > the=0D=0A> > > > > > >>>> problem=0D=0A> > > > > > >>> in=0D=0A=
> > > > > > >>>> framework and a one paragraph solution in phonebcp, but if=0D=
=0A> > > there=0D=0A> > > > > > >>>> is a=0D=0A> > > > > > >>>> separate do=
c and a reference, I will be happy.=0D=0A> > > > > > >>>>=0D=0A> > > > > > =
>>> That does not make sense.=0D=0A> > > > > > >>> The solution is not one =
paragraph and the text in phone bcp=0D=0A> is=0D=0A> > > > > > >>> normativ=
e.=0D=0A> > > > > > >>>=0D=0A> > > > > > >>> Ciao=0D=0A> > > > > > >>> Hann=
es=0D=0A> > > > > > >>>=0D=0A> > > > > > >>>> Brian=0D=0A> > > > > > >>>>=0D=
=0A> > > > > > >>>>=0D=0A> > > > > > >>>>> -----Original Message-----=0D=0A=
> > > > > > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]=0D=0A> > > =
> > > >>>>> Sent: Monday, December 03, 2007 7:37 PM=0D=0A> > > > > > >>>>> =
To: Stark, Barbara; Hannes Tschofenig; ECRIT=0D=0A> > > > > > >>>>> Subject=
: RE: [Ecrit] Location Hiding -- State of the Art=0D=0A> > > > > > >>>>>=0D=
=0A> > > > > > >>>>> Currently, the WG (and document editors!) should be=0D=
=0A> > operating=0D=0A> > > > > > >>>>> under=0D=0A> > > > > > >>>>> the co=
nsensus direction that Location Hiding *not* be in=0D=0A> > > > PhoneBCP=0D=
=0A> > > > > > >>>>> or=0D=0A> > > > > > >>>>> Framework.  This was a clear=
 consensus call in Chicago -=0D=0A> and=0D=0A> > > not=0D=0A> > > > > > >>>=
>> by=0D=0A> > > > > > >>>>> default, but by most people voicing actively a=
gainst=0D=0A> having=0D=0A> > > this=0D=0A> > > > > > >>>>> Hiding in eithe=
r core ECRIT documents, and I haven't yet=0D=0A> > > talked=0D=0A> > > > to=0D=
=0A> > > > > > >>>>> anyone here in Vancouver that thinks otherwise.=0D=0A>=
 > > > > > >>>>>=0D=0A> > > > > > >>>>> Location Hiding is something that n=
eeds to be addressed BY=0D=0A> > > > ITSELF=0D=0A> > > > > > >>>>> (i.e., i=
n its own doc) so everyone can focus on the=0D=0A> singular=0D=0A> > > > > =
> >>>>> topic,=0D=0A> > > > > > >>>>> and work towards not talking past eac=
h other (not like=0D=0A> > that's=0D=0A> > > > > > >>>>> happened before in=
 ECRIT....  :-/=0D=0A> > > > > > >>>>>=0D=0A> > > > > > >>>>> Who disagrees=
 with this=3F=0D=0A> > > > > > >>>>>=0D=0A> > > > > > >>>>> BTW - if someon=
e thinks Location Hiding should be put back=0D=0A> > > into=0D=0A> > > > > =
> >>>>> PhoneBCP or Framework, then they can attempt to gain WG=0D=0A> > > =
> consensus=0D=0A> > > > > > >>>>> on=0D=0A> > > > > > >>>>> that, but that=
's different than a direction of this=0D=0A> > > > inevitability=0D=0A> > >=
 > > > >>>>> or=0D=0A> > > > > > >>>>> that there is not consensus on this.=0D=
=0A> > > > > > >>>>>=0D=0A> > > > > > >>>>>=0D=0A> > > > > > >>>>> At 07:23=
 AM 12/3/2007, Stark, Barbara wrote:=0D=0A> > > > > > >>>>>=0D=0A> > > > > =
> >>>>>> If people felt this was good enough so that access=0D=0A> > provid=
ers=0D=0A> > > > > > >>>>>> would not=0D=0A> > > > > > >>>>>> need to be re=
quired to build the infrastructure to=0D=0A> provide=0D=0A> > > > > > >>>>>=
> location=0D=0A> > > > > > >>>>>> (because people could use this method in=
stead of getting=0D=0A> > > > > > >>>>>> location from=0D=0A> > > > > > >>>=
>>> access providers), then location hiding would be dead. If=0D=0A> > > > =
people=0D=0A> > > > > > >>>>>> still=0D=0A> > > > > > >>>>>> want to place =
a requirement on access providers to=0D=0A> provide=0D=0A> > > > > > >>>>>>=
 location,=0D=0A> > > > > > >>>>>> then location hiding is not dead.=0D=0A>=
 > > > > > >>>>>> Barbara=0D=0A> > > > > > >>>>>>=0D=0A> > > > > > >>>>>> -=
----Original Message-----=0D=0A> > > > > > >>>>>> From: Hannes Tschofenig=0D=
=0A> [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > > > > > >>>>>> Sent: Satur=
day, December 01, 2007 3:34 PM=0D=0A> > > > > > >>>>>> To: ECRIT=0D=0A> > >=
 > > > >>>>>> Subject: [Ecrit] Location Hiding -- State of the Art=0D=0A> >=
 > > > > >>>>>>=0D=0A> > > > > > >>>>>> I thought that the following articl=
e would be of interest=0D=0A> > for=0D=0A> > > > > > >>>>>> you:=0D=0A> > >=
 > > > >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html=0D=0A=
> > > > > > >>>>>>=0D=0A> > > > > > >>>>>> Here is text from=0D=0A> > > > >=
 > >>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-=0D=0A> blue=
-=0D=0A> > > > circle-=0D=0A> > > > > > on-=0D=0A> > > > > > >>> your=0D=0A=
> > > > > > >>>>>> -map.html=0D=0A> > > > > > >>>>>> "=0D=0A> > > > > > >>>=
>>> My Location is a new beta technology from Google that=0D=0A> uses=0D=0A=
> > > cell=0D=0A> > > > > > >>>>>> tower=0D=0A> > > > > > >>>>>> identifica=
tion to provide you with approximate location=0D=0A> > > > > > >>>>>> infor=
mation,=0D=0A> > > > > > >>> so=0D=0A> > > > > > >>>>>> it will work on pho=
nes without GPS.=0D=0A> > > > > > >>>>>> "=0D=0A> > > > > > >>>>>> Note tha=
t this stuff is not really new technology. It=0D=0A> > existed=0D=0A> > > >=
 > > >>>>>> already=0D=0A> > > > > > >>>>>> for some time but the availabil=
ity of GPS devices made it=0D=0A> > > > > > >>>>>> possible to=0D=0A> > > >=
 > > >>>>>> setup the database in a more efficient way.=0D=0A> > > > > > >>=
>>>>=0D=0A> > > > > > >>>>>> Anyway, this mechanism allows you to obtain lo=
cation=0D=0A> > > > information=0D=0A> > > > > > >>>>>> with=0D=0A> > > > >=
 > >>>>>> your cell phone (using the cell id) without interacting=0D=0A> > =
with=0D=0A> > > > the=0D=0A> > > > > > >>>>>> cellular operator.=0D=0A> > >=
 > > > >>>>>> In short: operator cannot charge for location=0D=0A> > > > > =
> >>>>>>=0D=0A> > > > > > >>>>>> While the location information is not real=
ly useful for=0D=0A> > first=0D=0A> > > > > > >>> responders=0D=0A> > > > >=
 > >>>>>>=0D=0A> > > > > > >>>>>> it is still good enough for finding the c=
losest PSAP.=0D=0A> > > > > > >>>>>>=0D=0A> > > > > > >>>>>> Is this the de=
ad of location hiding=3F=0D=0A> > > > > > >>>>>>=0D=0A> > > > > > >>>>>> Ci=
ao=0D=0A> > > > > > >>>>>> Hannes=0D=0A> > > > > > >>>>>>=0D=0A> > > > > > =
>>>>>>=0D=0A> > > > > > >>>>>> ____________________________________________=
___=0D=0A> > > > > > >>>>>> Ecrit mailing list=0D=0A> > > > > > >>>>>> Ecri=
t@ietf.org=0D=0A> > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/e=
crit=0D=0A> > > > > > >>>>>>=0D=0A> > > > > > >>>>>> ______________________=
_________________________=0D=0A> > > > > > >>>>>> Ecrit mailing list=0D=0A>=
 > > > > > >>>>>> Ecrit@ietf.org=0D=0A> > > > > > >>>>>> https://www1.ietf.=
org/mailman/listinfo/ecrit=0D=0A> > > > > > >>>>>>=0D=0A> > > > > > >>>>> _=
______________________________________________=0D=0A> > > > > > >>>>> Ecrit=
 mailing list=0D=0A> > > > > > >>>>> Ecrit@ietf.org=0D=0A> > > > > > >>>>> =
https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > > > >>>>>=0D=0A> =
> > > > > >>=0D=0A> > > > > > >>=0D=0A> > > > > > >> ______________________=
_________________________=0D=0A> > > > > > >> Ecrit mailing list=0D=0A> > >=
 > > > >> Ecrit@ietf.org=0D=0A> > > > > > >> https://www1.ietf.org/mailman/=
listinfo/ecrit=0D=0A> > > > > > >>=0D=0A> > > > > > >> ____________________=
___________________________=0D=0A> > > > > > >> Ecrit mailing list=0D=0A> >=
 > > > > >> Ecrit@ietf.org=0D=0A> > > > > > >> https://www1.ietf.org/mailma=
n/listinfo/ecrit=0D=0A> > > > > > >=0D=0A> > > > > > >=0D=0A> > > > > > > _=
______________________________________________=0D=0A> > > > > > > Ecrit mai=
ling list=0D=0A> > > > > > > Ecrit@ietf.org=0D=0A> > > > > > > https://www1=
=2Eietf.org/mailman/listinfo/ecrit=0D=0A> > > > > > >=0D=0A> > > > > > > **=
***=0D=0A> > > > > > >=0D=0A> > > > > > > The information transmitted is in=
tended only for the person or=0D=0A> > > > > > > entity to which it is addr=
essed and may contain confidential,=0D=0A> > > > > > > proprietary, and/or =
privileged material. Any review,=0D=0A> > > retransmission,=0D=0A> > > > > =
> > dissemination or other use of, or taking of any action in=0D=0A> > reli=
ance=0D=0A> > > > > > > upon this information by persons or entities other =
than the=0D=0A> > > intended=0D=0A> > > > > > > recipient is prohibited. If=
 you received this in error, please=0D=0A> > > > > > > contact the sender a=
nd delete the material from all computers.=0D=0A> > > GA622=0D=0A> > > > > =
> >=0D=0A> > > > > > >=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > > _=
______________________________________________=0D=0A> > > > > > Ecrit maili=
ng list=0D=0A> > > > > > Ecrit@ietf.org=0D=0A> > > > > > https://www1.ietf.=
org/mailman/listinfo/ecrit=0D=0A> > > > > >=0D=0A> > > > > > --------------=
--------------------------------------------------=0D=0A> --=0D=0A> > --=0D=
=0A> > > --=0D=0A> > > > --=0D=0A> > > > > --=0D=0A> > > > > > ------------=
----------=0D=0A> > > > > > This message is for the designated recipient on=
ly and may=0D=0A> > > > > > contain privileged, proprietary, or otherwise p=
rivate=0D=0A> information.=0D=0A> > > > > > If you have received it in erro=
r, please notify the sender=0D=0A> > > > > > immediately and delete the ori=
ginal.  Any unauthorized use of=0D=0A> > > > > > this email is prohibited.=0D=
=0A> > > > > > ------------------------------------------------------------=
----=0D=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A> > > > --=0D=0A> > > > > --=0D=
=0A> > > > > > ----------------------=0D=0A> > > > > > [mf2]=0D=0A> > > > >=
 >=0D=0A> > > > > >=0D=0A> > > > > > ______________________________________=
_________=0D=0A> > > > > > Ecrit mailing list=0D=0A> > > > > > Ecrit@ietf.o=
rg=0D=0A> > > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > >=
 > >=0D=0A> > > > >=0D=0A> > > > > ________________________________________=
_______=0D=0A> > > > > Ecrit mailing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A=
> > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> =
> > > --------------------------------------------------------------------=0D=
=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A=
> > > > This message is for the designated recipient only and may=0D=0A> > =
> > contain privileged, proprietary, or otherwise private information.=0D=0A=
> > > > If you have received it in error, please notify the sender=0D=0A> >=
 > > immediately and delete the original.  Any unauthorized use of=0D=0A> >=
 > > this email is prohibited.=0D=0A> > > > -------------------------------=
-------------------------------------=0D=0A> --=0D=0A> > --=0D=0A> > > --=0D=
=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> > >=0D=0A> >=0D=
=0A> > --------------------------------------------------------------------=
----=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This message is for=
 the designated recipient only and may=0D=0A> > contain privileged, proprie=
tary, or otherwise private information.=0D=0A> > If you have received it in=
 error, please notify the sender=0D=0A> > immediately and delete the origin=
al.  Any unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> > --=
----------------------------------------------------------------------=0D=0A=
> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A--=
---------------------------------------------------------------------------=
-------------------=0D=0AThis message is for the designated recipient only =
and may=0D=0Acontain privileged, proprietary, or otherwise private informat=
ion. =20=0D=0AIf you have received it in error, please notify the sender=0D=
=0Aimmediately and delete the original.  Any unauthorized use of=0D=0Athis =
email is prohibited.=0D=0A-------------------------------------------------=
-----------------------------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 11:26:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1lSo-0000eV-Vv; Mon, 10 Dec 2007 11:26:38 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lSm-0000eN-Tt
	for ecrit@ietf.org; Mon, 10 Dec 2007 11:26:37 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1lSk-0008Ii-0f
	for ecrit@ietf.org; Mon, 10 Dec 2007 11:26:36 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J1lSc-0003JJ-VG; Mon, 10 Dec 2007 10:26:27 -0600
From: "Brian Rosen" 
To: "'Winterbottom, James'" ,
	"'Dawson, Martin'" ,
	"'Henning Schulzrinne'" ,
	"'Stark, Barbara'" 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 11:26:29 -0500
Message-ID: <041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQAABDxoAAAFPxMAAAKBBgAABJjLA=
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e27baca84bbcca55dd7823e3353bc895
Cc: ecrit@ietf.org, "'Liess, Laura'" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

James, we're not communicating.

Coarse location is only given to entities who the LIS doesn't want to =
give
real location.  It's good enough to route and validate emergency calls, =
and
not good for anything else.  It's not supposed to be useful for anything
else.

The LIS can give high quality location to anyone it wishes to, which =
will
work for "real" location based services.  Specifically, if it wishes =
some
entity to be able to route other services, it can give it high quality
location.   That entity can control which services get routed under =
whatever
terms the LIS is willing to give it high quality location.

No one, so far, has created a requirement that some non-authorized =
entity
has to be able to provide some form of location based service (such as
routing based on location) without having some kind of authorization or
credentials from the LIS for such purposes.  The LIS is free to give
location to anyone it wants, for any purpose, subject to the privacy
limitations in the PIDF-LO.  The LIS MUST allow any entity to route an
emergency call.

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Monday, December 10, 2007 11:15 AM
> To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Brian my point is this.
>=20
> A location hiding mechanism that ONLY provides the boundary map of the
> ESRP is pretty much useless in that it won't enable them to support =
the
> value added case period. Since the only reason that anyone would pay =
for
> it is so that they can support value added services I don't see how =
you
> address the requirement.
>=20
> Franchise boundaries are unlikely to match ESRP boundaries. Further =
more,
> not all value added service may be permitted, so the Target still =
needs to
> know what services for a given location provider will be permitted to
> obtain location information. I think the view of providing a coarse
> location is driven by a particular business model you have in mind =
that
> does not seem to match the model that people I have talked to have in
> mind.
>=20
> Cheers
> James
>=20
>=20
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Tuesday, 11 December 2007 3:08 AM
> > To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne'; =
'Stark,
> > Barbara'
> > Cc: ecrit@ietf.org; 'Liess, Laura'
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Yes, that is true.
> >
> > If your pizza delivery service provider's service boundary matches =
your
> > ESRPs boundary, you are in luck.
> >
> > In my conversations with carriers who want to do location hiding, =
this
> is
> > not seen as a problem.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > Sent: Monday, December 10, 2007 10:57 AM
> > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, =
Barbara
> > > Cc: ecrit@ietf.org; Liess, Laura
> > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > If I get coarse location good enough to route to my local pizza
> delivery
> > > facility then I have gotten my value added service for free.
> > >
> > > I rest my case!
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Tuesday, 11 December 2007 2:51 AM
> > > > To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne';
> > 'Stark,
> > > > Barbara'
> > > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > >
> > > > We are talking about location-by-reference.
> > > >
> > > > An endpoint or VSP dereferencing this URI will get coarse =
location,
> as
> > > > described.
> > > >
> > > > A PSAP or ESRP dereferencing will have credentials, and will get
> high
> > > > resolution data
> > > >
> > > > An authorized entity (i.e. one paying for it) will have =
credentials
> > and
> > > > will
> > > > get high resolution data.
> > > >
> > > > Where is the problem?
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Winterbottom, James =
[mailto:James.Winterbottom@andrew.com]
> > > > > Sent: Monday, December 10, 2007 10:38 AM
> > > > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark,
> Barbara
> > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > > >
> > > > > Brian,
> > > > >
> > > > > The primary aim for hiding location is not to make it hard for
> > > emergency
> > > > > services, but to enable the ability to charge for value added
> > > services.
> > > > > Can you please explain how this solution (other than through a =
one
> > off
> > > > > charge for location) supports this requirement.
> > > > >
> > > > > Cheers
> > > > > James
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > > > Sent: Tuesday, 11 December 2007 1:57 AM
> > > > > > To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'
> > > > > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > > > >
> > > > > > The only emergency service in the U.S. is urn:service:sos.
> There
> > is
> > > > > only
> > > > > > one boundary and if it changes (which LoST tells you via the =
TTL
> > of
> > > > the
> > > > > > service boundary), you may have to find those locations =
affected
> > by
> > > > the
> > > > > > change when they request a new location URI.
> > > > > >
> > > > > > In the countries where there are multiple services, there =
are
> only
> > a
> > > > few
> > > > > > (sometimes one) ESRPs.
> > > > > >
> > > > > > There could be some theoretic case of lots of ESRPs and lots =
of
> > > > > services,
> > > > > > in
> > > > > > which case there are more intersections, but the calculation =
is
> > > > simple,
> > > > > > fairly quick, and the TTLs make it easy to determine when a
> change
> > > is
> > > > > > made,
> > > > > > and several pretty straightforward strategies are available =
to
> > > > minimize
> > > > > > the
> > > > > > work on the LIS.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > > > > Sent: Saturday, December 08, 2007 6:39 PM
> > > > > > > To: Henning Schulzrinne; Stark, Barbara
> > > > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Everything is qualified on what ultimately gets regulated. =
But
> > > it's
> > > > > > > probably time to discuss real world implications of this
> topic.
> > > > > > >
> > > > > > > I expect that, if access operators are required to provide
> > > location,
> > > > > it
> > > > > > is
> > > > > > > only going to be for the purpose of emergency services. I
> doubt
> > > that
> > > > > > > regulators will even consider mandating that they provide =
it
> for
> > > all
> > > > > > users
> > > > > > > for all purposes. There'll be no sledgehammer to force =
access
> > > > > providers
> > > > > > to
> > > > > > > give everyone a free location service - so it won't happen
> until
> > > > > > operators
> > > > > > > have their own reasons to do so.
> > > > > > >
> > > > > > > Since access providers can't control what client devices
> > actually
> > > > use
> > > > > > > location information for, they will only implement a =
system
> that
> > > > > permits
> > > > > > a
> > > > > > > recognised emergency entity to retrieve the actual =
location
> > value.
> > > > > > They'll
> > > > > > > only give the end subscriber location information if =
that's
> > > already
> > > > > paid
> > > > > > > for as part of the subscription.
> > > > > > >
> > > > > > > The fundamental problem with the "do location hiding by
> > providing
> > > > > > > location" proposal is exactly that. It fails to hide =
location.
> > > This
> > > > is
> > > > > > > particularly the case in the US (which is a difficult =
market
> to
> > > > > ignore).
> > > > > > > The intersection of every possible service area - also =
called
> an
> > > ESN
> > > > > or
> > > > > > > ESZ - in the US is a quite granular area; certainly good =
for
> > quite
> > > a
> > > > > lot
> > > > > > > of services. For a mobile access provider, in particular, =
a
> > > > > considerable
> > > > > > > amount of capital equipment is going to be invoked to =
provide
> > this
> > > > > quite
> > > > > > > good location information.
> > > > > > >
> > > > > > > On the other hand, in many other countries (e.g. the UK =
and
> > > > Australia)
> > > > > > > this technique is probably not problematic for the =
carrier,
> > > because
> > > > > they
> > > > > > > are just going to return the country code. That's as =
granular
> as
> > > you
> > > > > > need
> > > > > > > to be for emergency services.
> > > > > > >
> > > > > > > So here's what will happen if this is the official IETF
> > > > > recommendation.
> > > > > > It
> > > > > > > may get adopted but operators will limit the provided =
location
> > > > > > information
> > > > > > > to just the country indicator. They'll do this in the US =
as
> well
> > > > > > (they'll
> > > > > > > refuse to process all the LoST boundary data and take
> > > responsibility
> > > > > for
> > > > > > > consequent routing outcome). This means that VSPs dealing =
with
> > > calls
> > > > > > > originating in the US will need to use i2. This is because =
the
> > V2
> > > > > > > interface in i2 does support a location reference while =
LoST
> is
> > > > unable
> > > > > > to
> > > > > > > do this. The country information will certainly be useful =
for
> > > > > > arbitrating
> > > > > > > which VPC to use though - so that's good. It will mean =
that
> > direct
> > > > to
> > > > > > PSAP
> > > > > > > calls won't be able to be made in the US. That's a shame.
> Other
> > > > > > > jurisdictions that only have a single PSAP route will be =
able
> to
> > > > > support
> > > > > > > this. OTOH, it might force the US to provide a federal =
level
> URI
> > > > with
> > > > > > > proxies that can subsequently do the dereference and lower
> level
> > > > > routing
> > > > > > -
> > > > > > > so maybe it's not such a shame. It won't result in access
> > > providers
> > > > > > giving
> > > > > > > free location information until they are ready to do so
> however.
> > > > > > >
> > > > > > > Editorial and a genuine question:
> > > > > > >
> > > > > > > IMO, supporting the services URI extension in HELD or =
adding
> > > > location
> > > > > > > reference support to LoST are both superior engineering
> > solutions.
> > > > > They
> > > > > > > just aren't driven by the punitive motivations of the =
"hide by
> > not
> > > > > > hiding"
> > > > > > > proposal. Arguments that they are inferior because they
> require
> > > > > protocol
> > > > > > > changes are specious and self-fulfilling. That's why the
> > > "reference
> > > > > > query"
> > > > > > > mechanism for LoST was "postponed" in the interest of =
getting
> > LoST
> > > > > > > finalized. It continues to be used as a prop for this
> particular
> > > > > hiding
> > > > > > > proposal. By this line of argument, we would never add or
> modify
> > > > > > protocols
> > > > > > > for anything.
> > > > > > >
> > > > > > > It's very difficult not to lapse into sarcasm in this area =
(I
> > feel
> > > > > like
> > > > > > > saying it's OK not to have location hiding because =
Columbia
> > > > University
> > > > > > and
> > > > > > > Cisco are going to underwrite the cost of providing a 5x9s
> > > reliable
> > > > > > > ubiquitous location service in all public access networks =
out
> of
> > > > pure
> > > > > > > philanthropy.... but I won't :) ).
> > > > > > >
> > > > > > > Insisting on providing location for all applications is =
like
> > > > insisting
> > > > > > > that cellular operators let users call anyone just to =
ensure
> > that
> > > > they
> > > > > > can
> > > > > > > also make emergency calls. In this hypothetical situation,
> > > refusing
> > > > to
> > > > > > > define protocol mechanisms that permit them to distinguish
> > between
> > > > the
> > > > > > > scenarios would only result in there being no cellular =
service
> -
> > > or
> > > > > just
> > > > > > > publicly funded cellular services. It's a =
counter-productive
> > > > attitude.
> > > > > > >
> > > > > > > This provides the opportunity for me to once more ask a
> question
> > > > that
> > > > > > > hasn't been responded to in the past. Why is ECRIT =
describing
> a
> > > > > solution
> > > > > > > that has the VSP involved in the emergency call at all? =
Why
> > would
> > > > the
> > > > > > VSP
> > > > > > > want to be involved in emergency calls - and why would the
> > caller
> > > > want
> > > > > > > them involved? It seems to be not in the interest of =
either
> > party.
> > > > > > There's
> > > > > > > already an interim architecture for the non "end-to-end =
IP"
> > > scenario
> > > > > > > called i2. In any circumstance where any of the device, =
the
> > > network,
> > > > > or
> > > > > > > emergency operator are not ECRIT-capable, then the VSP =
does
> need
> > > to
> > > > be
> > > > > > > involved and i2 is a valid fallback.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Martin
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > > Sent: Saturday, 8 December 2007 8:56 AM
> > > > > > > To: Stark, Barbara
> > > > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > >
> > > > > > > Translation: You have more lobbyists than I (or the IETF), =
so
> > give
> > > > me.
> > > > > > > Thanks for clarifying that.
> > > > > > >
> > > > > > > Henning
> > > > > > >
> > > > > > > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:
> > > > > > >
> > > > > > > > [The following statements are my opinion, and should not =
be
> > > > > > > > attributed to the company I work for.]
> > > > > > > >
> > > > > > > > Henning,
> > > > > > > > It's true that the IETF doesn't have to do something =
just
> > > because
> > > > > > > > someone wants it. It's also true that the IETF has no
> > authority
> > > or
> > > > > > > > ability to force implementation of RFCs by companies who
> > refuse
> > > to
> > > > > > > > implement them. You cannot shove a solution down the =
throats
> > of
> > > > > > > > access providers that they are unwilling to buy in to. =
In my
> > > > > > > > opinion, even attempting to do so would be, well, =
unethical.
> > > > > > > >
> > > > > > > > So, you have a choice:
> > > > > > > > 1) create a solution that you like that major =
stakeholders
> are
> > > > > > > > unwilling to implement
> > > > > > > > 2) create a solution that you don't quite like, but =
that's
> > > better
> > > > > > > > than what we have today, and which major stakeholders =
are
> > > willing
> > > > to
> > > > > > > > implement
> > > > > > > >
> > > > > > > > Believe it or not, major telecom companies in the US and
> > Europe
> > > > put
> > > > > > > > a lot of effort into lobbying regulatory bodies, to =
achieve
> > > > > > > > desirable outcomes. The IETF doesn't put in such effort. =
If
> > you
> > > > want
> > > > > > > > to make a go at pushing through a solution that =
stakeholders
> > in
> > > > > > > > these regions are set against, and see if you can get
> > regulatory
> > > > > > > > agencies to bless it, then go for it. I think the odds =
are
> > > stacked
> > > > > > > > against you, though. Especially since there are workable
> > > solutions
> > > > > > > > that these companies have said they would be willing to
> > accept.
> > > > > > > >
> > > > > > > > Here is why mobile access providers "cannot" provide the
> best
> > > > > > > > available location directly to end user devices: They =
don't
> > want
> > > > to.
> > > > > > > > At this point in time, it's their network, their data, =
and
> > their
> > > > > > > > choice.
> > > > > > > >
> > > > > > > > In free market economies, you generally have to be able =
to
> > > *prove*
> > > > > > > > (and not just say it without proof) massive benefit or
> massive
> > > > harm
> > > > > > > > before you can force companies to do what they don't =
want to
> > do,
> > > > > > > > through regulation. Again, if you think you can take on =
that
> > > > battle
> > > > > > > > and win, go for it.
> > > > > > > >
> > > > > > > > I, for one, believe that not providing the "real" =
location
> > value
> > > > to
> > > > > > > > end devices would not cause such benefit or harm. If =
users
> > want
> > > to
> > > > > > > > know what location PSAPs get on their behalf, and =
regulators
> > > > believe
> > > > > > > > such a capability is needed, then we can let the =
phonebcp-
> > > > described
> > > > > > > > test mechanism voice it back over the voice medium (this
> would
> > > > only
> > > > > > > > work for civic), or return a JPEG map with a dot on it. =
This
> > > would
> > > > > > > > provide location in a format that's usable by a human =
being,
> > but
> > > > not
> > > > > > > > an application. Or maybe, in some countries, the =
regulators
> do
> > > > > > > > require access providers to give out the best possible
> > location
> > > > > > > > values to end devices. But it's really improbable that =
you
> > could
> > > > > > > > force the regulators of all countries to see things your
> way.
> > > > > > > >
> > > > > > > > But, this is all just my opinion.
> > > > > > > > Barbara
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > > > Sent: Friday, December 07, 2007 12:13 PM
> > > > > > > > To: Liess, Laura
> > > > > > > > Cc: ecrit@ietf.org
> > > > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >
> > > > > > > > Laura,
> > > > > > > >
> > > > > > > > just because somebody says "we need it" doesn't make it =
an
> > IETF
> > > > > > > > requirement. Please justify why mobile access cannot =
provide
> > > > > locations
> > > > > > > > to end users.
> > > > > > > >
> > > > > > > > Henning
> > > > > > > >
> > > > > > > > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
> > > > > > > >
> > > > > > > >> Brian,
> > > > > > > >>
> > > > > > > >> I checked with my company and we need LH for both civic =
and
> > geo
> > > > for
> > > > > > > >> fixed and mobile access. Only DSL and civic is not an
> option.
> > > > > > > >>
> > > > > > > >> I would support sending the ESRP/PSAP URI to the UA, as
> > > proposed
> > > > by
> > > > > > > >> Barbara and James some weeks ago.
> > > > > > > >>
> > > > > > > >> Laura
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> -----Urspr=FCngliche Nachricht-----
> > > > > > > >> Von: Brian Rosen [mailto:br@brianrosen.net]
> > > > > > > >> Gesendet: Dienstag, 4. Dezember 2007 16:37
> > > > > > > >> An: 'Hannes Tschofenig'
> > > > > > > >> Cc: 'ECRIT'
> > > > > > > >> Betreff: RE: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>
> > > > > > > >> Proposed text for framework
> > > > > > > >>
> > > > > > > >> Some access networks wish to restrict who can get a =
high
> > > quality
> > > > > > > >> location,
> > > > > > > >> possibly based on a payment arrangement.  For emergency
> > calls,
> > > > high
> > > > > > > >> quality
> > > > > > > >> location must be provided.  An access network can
> reasonably
> > be
> > > > > > > >> expected to
> > > > > > > >> have a relationship with the PSAPs in its catchment =
area,
> so
> > > > giving
> > > > > > > >> location
> > > > > > > >> to the PSAP will be straightforward
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> However, an endpoint may need location
> > > > > > > >> for routing, and a proxy may need to verify that a
> purported
> > > > > > > >> emergency call
> > > > > > > >> is targeted at a bona fide PSAP.  To do so, it may take =
the
> > > > > location
> > > > > > > >> passed
> > > > > > > >> with the call and query LoST to confirm that the URI is
> > > genuine.
> > > > > > > >> "Hiding"
> > > > > > > >> location interferes with this check.  To achieve =
location
> > > hiding,
> > > > > > > >> the LIS
> > > > > > > >> can return a coarse location which is good enough to =
elicit
> > the
> > > > > same
> > > > > > > >> response from LoST as the actual location would.  The
> > endpoint
> > > > and
> > > > > > > >> the proxy
> > > > > > > >> can use this location to route and verify.  A suitable
> > location
> > > > for
> > > > > > > >> a geo is
> > > > > > > >> a polygon calculated by intersecting the service =
boundaries
> > of
> > > > all
> > > > > > > >> of the
> > > > > > > >> emergency services that respond to the actual location. =
 A
> > > > suitable
> > > > > > > >> location
> > > > > > > >> for a civic is any civic location within the =
intersection
> of
> > > the
> > > > > > > >> service
> > > > > > > >> boundaries of emergency services.  In a great many =
cases, a
> > > > country
> > > > > > > >> code is
> > > > > > > >> sufficient.  In others a state/province or a city name =
is
> > > > > > > >> sufficient.  Of
> > > > > > > >> course, the LIS would always return a location =
reference,
> > which
> > > > > > > >> would return
> > > > > > > >> high quality location for a PSAP and coarse location to =
the
> > > > > endpoint
> > > > > > > >> or any
> > > > > > > >> proxy unknown to the LIS.
> > > > > > > >>
> > > > > > > >> Proposed text for phonebcp:
> > > > > > > >>
> > > > > > > >> A LIS who wishes to hide location returns a location
> > reference.
> > > > > When
> > > > > > > >> dereferenced by the endpoint or proxy:
> > > > > > > >> 1. For LIS's returning geo:
> > > > > > > >>   For each location served by the LIS, compute the
> > intersection
> > > > of
> > > > > > > >> the
> > > > > > > >>   service boundaries for all emergency services known =
to
> LoST
> > > for
> > > > > the
> > > > > > > >>   location. Return the resulting polygon, or any point =
in
> the
> > > > > > > >> polygon as
> > > > > > > >>   the value during a dereference
> > > > > > > >> 2. For LIS's returning civic:
> > > > > > > >>   Determine a civic location which is within the =
service
> > > boundary
> > > > > > > >> of all
> > > > > > > >>   emergency services known to LoST for the location.  =
In a
> > > great
> > > > > many
> > > > > > > >>   cases, this will be a country code, province/state or
> city.
> > > > > > > >> Return this
> > > > > > > >>   coarse civic location as the value during a =
dereference
> > > > > > > >> Note that the service boundaries returned from LoST =
have a
> > TTL,
> > > > the
> > > > > > > >> intersections MUST recalculated if the service boundary
> > > changes.
> > > > > > > >> The LIS
> > > > > > > >> MUST return high quality location to a PSAP or ESRP.
> > > > > > > >>
> > > > > > > >> Brian
> > > > > > > >>
> > > > > > > >>> -----Original Message-----
> > > > > > > >>> From: Hannes Tschofenig =
[mailto:Hannes.Tschofenig@gmx.net]
> > > > > > > >>> Sent: Monday, December 03, 2007 1:38 PM
> > > > > > > >>> To: Brian Rosen
> > > > > > > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> > > > > > > >>> Subject: Re: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>>
> > > > > > > >>> Hi Brian,
> > > > > > > >>>
> > > > > > > >>> Brian Rosen wrote:
> > > > > > > >>>> It's fine with me if there is a separate doc, but
> framework
> > > and
> > > > > > > >>>> phonebcp
> > > > > > > >>>> have to reference it.
> > > > > > > >>>>
> > > > > > > >>> Are we talking about informative or normative =
references?
> > > > > > > >>>> I think it can be solved with a one paragraph =
description
> > of
> > > > the
> > > > > > > >>>> problem
> > > > > > > >>> in
> > > > > > > >>>> framework and a one paragraph solution in phonebcp, =
but
> if
> > > > there
> > > > > > > >>>> is a
> > > > > > > >>>> separate doc and a reference, I will be happy.
> > > > > > > >>>>
> > > > > > > >>> That does not make sense.
> > > > > > > >>> The solution is not one paragraph and the text in =
phone
> bcp
> > is
> > > > > > > >>> normative.
> > > > > > > >>>
> > > > > > > >>> Ciao
> > > > > > > >>> Hannes
> > > > > > > >>>
> > > > > > > >>>> Brian
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>> -----Original Message-----
> > > > > > > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> > > > > > > >>>>> Sent: Monday, December 03, 2007 7:37 PM
> > > > > > > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> > > > > > > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>>>>
> > > > > > > >>>>> Currently, the WG (and document editors!) should be
> > > operating
> > > > > > > >>>>> under
> > > > > > > >>>>> the consensus direction that Location Hiding *not* =
be in
> > > > > PhoneBCP
> > > > > > > >>>>> or
> > > > > > > >>>>> Framework.  This was a clear consensus call in =
Chicago -
> > and
> > > > not
> > > > > > > >>>>> by
> > > > > > > >>>>> default, but by most people voicing actively against
> > having
> > > > this
> > > > > > > >>>>> Hiding in either core ECRIT documents, and I haven't =
yet
> > > > talked
> > > > > to
> > > > > > > >>>>> anyone here in Vancouver that thinks otherwise.
> > > > > > > >>>>>
> > > > > > > >>>>> Location Hiding is something that needs to be =
addressed
> BY
> > > > > ITSELF
> > > > > > > >>>>> (i.e., in its own doc) so everyone can focus on the
> > singular
> > > > > > > >>>>> topic,
> > > > > > > >>>>> and work towards not talking past each other (not =
like
> > > that's
> > > > > > > >>>>> happened before in ECRIT....  :-/
> > > > > > > >>>>>
> > > > > > > >>>>> Who disagrees with this?
> > > > > > > >>>>>
> > > > > > > >>>>> BTW - if someone thinks Location Hiding should be =
put
> back
> > > > into
> > > > > > > >>>>> PhoneBCP or Framework, then they can attempt to gain =
WG
> > > > > consensus
> > > > > > > >>>>> on
> > > > > > > >>>>> that, but that's different than a direction of this
> > > > > inevitability
> > > > > > > >>>>> or
> > > > > > > >>>>> that there is not consensus on this.
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> > > > > > > >>>>>
> > > > > > > >>>>>> If people felt this was good enough so that access
> > > providers
> > > > > > > >>>>>> would not
> > > > > > > >>>>>> need to be required to build the infrastructure to
> > provide
> > > > > > > >>>>>> location
> > > > > > > >>>>>> (because people could use this method instead of
> getting
> > > > > > > >>>>>> location from
> > > > > > > >>>>>> access providers), then location hiding would be =
dead.
> If
> > > > > people
> > > > > > > >>>>>> still
> > > > > > > >>>>>> want to place a requirement on access providers to
> > provide
> > > > > > > >>>>>> location,
> > > > > > > >>>>>> then location hiding is not dead.
> > > > > > > >>>>>> Barbara
> > > > > > > >>>>>>
> > > > > > > >>>>>> -----Original Message-----
> > > > > > > >>>>>> From: Hannes Tschofenig
> > [mailto:Hannes.Tschofenig@gmx.net]
> > > > > > > >>>>>> Sent: Saturday, December 01, 2007 3:34 PM
> > > > > > > >>>>>> To: ECRIT
> > > > > > > >>>>>> Subject: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>>>>>
> > > > > > > >>>>>> I thought that the following article would be of
> interest
> > > for
> > > > > > > >>>>>> you:
> > > > > > > >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-
> found.html
> > > > > > > >>>>>>
> > > > > > > >>>>>> Here is text from
> > > > > > > >>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-
> > blue-
> > > > > circle-
> > > > > > > on-
> > > > > > > >>> your
> > > > > > > >>>>>> -map.html
> > > > > > > >>>>>> "
> > > > > > > >>>>>> My Location is a new beta technology from Google =
that
> > uses
> > > > cell
> > > > > > > >>>>>> tower
> > > > > > > >>>>>> identification to provide you with approximate =
location
> > > > > > > >>>>>> information,
> > > > > > > >>> so
> > > > > > > >>>>>> it will work on phones without GPS.
> > > > > > > >>>>>> "
> > > > > > > >>>>>> Note that this stuff is not really new technology. =
It
> > > existed
> > > > > > > >>>>>> already
> > > > > > > >>>>>> for some time but the availability of GPS devices =
made
> it
> > > > > > > >>>>>> possible to
> > > > > > > >>>>>> setup the database in a more efficient way.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Anyway, this mechanism allows you to obtain =
location
> > > > > information
> > > > > > > >>>>>> with
> > > > > > > >>>>>> your cell phone (using the cell id) without =
interacting
> > > with
> > > > > the
> > > > > > > >>>>>> cellular operator.
> > > > > > > >>>>>> In short: operator cannot charge for location
> > > > > > > >>>>>>
> > > > > > > >>>>>> While the location information is not really useful =
for
> > > first
> > > > > > > >>> responders
> > > > > > > >>>>>>
> > > > > > > >>>>>> it is still good enough for finding the closest =
PSAP.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Is this the dead of location hiding?
> > > > > > > >>>>>>
> > > > > > > >>>>>> Ciao
> > > > > > > >>>>>> Hannes
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>> _______________________________________________
> > > > > > > >>>>>> Ecrit mailing list
> > > > > > > >>>>>> Ecrit@ietf.org
> > > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>>>>>
> > > > > > > >>>>>> _______________________________________________
> > > > > > > >>>>>> Ecrit mailing list
> > > > > > > >>>>>> Ecrit@ietf.org
> > > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>>>>>
> > > > > > > >>>>> _______________________________________________
> > > > > > > >>>>> Ecrit mailing list
> > > > > > > >>>>> Ecrit@ietf.org
> > > > > > > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>>>>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> _______________________________________________
> > > > > > > >> Ecrit mailing list
> > > > > > > >> Ecrit@ietf.org
> > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>
> > > > > > > >> _______________________________________________
> > > > > > > >> Ecrit mailing list
> > > > > > > >> Ecrit@ietf.org
> > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Ecrit mailing list
> > > > > > > > Ecrit@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >
> > > > > > > > *****
> > > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Ecrit mailing list
> > > > > > > Ecrit@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > >
> > > > > > > =
--------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > ----------------------
> > > > > > > This message is for the designated recipient only and may
> > > > > > > contain privileged, proprietary, or otherwise private
> > information.
> > > > > > > If you have received it in error, please notify the sender
> > > > > > > immediately and delete the original.  Any unauthorized use =
of
> > > > > > > this email is prohibited.
> > > > > > > =
--------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > ----------------------
> > > > > > > [mf2]
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Ecrit mailing list
> > > > > > > Ecrit@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Ecrit mailing list
> > > > > > Ecrit@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > > > =
------------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > ----------------------
> > > > > This message is for the designated recipient only and may
> > > > > contain privileged, proprietary, or otherwise private =
information.
> > > > > If you have received it in error, please notify the sender
> > > > > immediately and delete the original.  Any unauthorized use of
> > > > > this email is prohibited.
> > > > > =
------------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > ----------------------
> > > > > [mf2]
> > > >
> > >
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > This message is for the designated recipient only and may
> > > contain privileged, proprietary, or otherwise private information.
> > > If you have received it in error, please notify the sender
> > > immediately and delete the original.  Any unauthorized use of
> > > this email is prohibited.
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > [mf2]
> >
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 12:53:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1mod-00053z-Nq; Mon, 10 Dec 2007 12:53:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1moc-00053r-1x
	for ecrit@ietf.org; Mon, 10 Dec 2007 12:53:14 -0500
Received: from aismt06p.bellsouth.com ([139.76.165.211])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1moZ-0002Ca-2O
	for ecrit@ietf.org; Mon, 10 Dec 2007 12:53:13 -0500
Received: from ([139.76.131.91])
	by aismt06p.bellsouth.com with ESMTP  id KP-AXPRN.35632291;
	Mon, 10 Dec 2007 12:52:45 -0500
Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by
	01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); 
	Mon, 10 Dec 2007 12:52:45 -0500
Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by
	01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); 
	Mon, 10 Dec 2007 12:52:44 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 12:52:44 -0500
Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p>
In-Reply-To: <041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQAABDxoAAAFPxMAAAKBBgAABJjLAAAoF9AA==
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
From: "Stark, Barbara" 
To: "Brian Rosen" ,
	"Winterbottom, James" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
X-OriginalArrivalTime: 10 Dec 2007 17:52:44.0739 (UTC)
	FILETIME=[77C00130:01C83B55]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 56d530dd2b9ddb285a3c7c12acee9803
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I think I understand what James is saying.

Let's say that a VSP has contracted with an access provider to be =
allowed to dereference location for its subscribers.

A device gets a location reference from the access provider, publishes =
it to the VSP's presence server; and the VSP dereferences the location.=20

The VSP would like to contract with a pizza delivery business to allow =
its subscribers to easily order pizza, from anywhere, by telling the =
device the URL associated with a pizza service, based on the device =
location.

The VSP has all the info it needs to provide this service, since it was =
able to dereference the LbyR. But there's no standard way for the VSP to =
tell the device what that pizza service URL is, for the device's =
location. And the VSP isn't allowed to tell the device what the device's =
real location value is, because that's not allowed under the agreement =
with the access provider.

Or it could be that an access provider would like to contract with =
various companies to provide routing information for specific service =
URNs. The access provider wants to provide the routing info, but not the =
location to devices. Again, there's no protocol for this.

Admittedly, this is outside the scope of ecrit. But, since LoST was made =
into a generic service URN to URI translator, it would be nice if =
somehow the LoST protocol could be used to provide devices with URIs, =
even when the device doesn't have its precise location.

I think that getting this capability would be very useful and desirable, =
but don't think it's as high a priority as getting the emergency =
services architecture worked out.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]=20
Sent: Monday, December 10, 2007 11:26 AM
To: 'Winterbottom, James'; 'Dawson, Martin'; 'Henning Schulzrinne'; =
Stark, Barbara
Cc: ecrit@ietf.org; 'Liess, Laura'
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art

James, we're not communicating.

Coarse location is only given to entities who the LIS doesn't want to =
give
real location.  It's good enough to route and validate emergency calls, =
and
not good for anything else.  It's not supposed to be useful for anything
else.

The LIS can give high quality location to anyone it wishes to, which =
will
work for "real" location based services.  Specifically, if it wishes =
some
entity to be able to route other services, it can give it high quality
location.   That entity can control which services get routed under =
whatever
terms the LIS is willing to give it high quality location.

No one, so far, has created a requirement that some non-authorized =
entity
has to be able to provide some form of location based service (such as
routing based on location) without having some kind of authorization or
credentials from the LIS for such purposes.  The LIS is free to give
location to anyone it wants, for any purpose, subject to the privacy
limitations in the PIDF-LO.  The LIS MUST allow any entity to route an
emergency call.

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Monday, December 10, 2007 11:15 AM
> To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Brian my point is this.
>=20
> A location hiding mechanism that ONLY provides the boundary map of the
> ESRP is pretty much useless in that it won't enable them to support =
the
> value added case period. Since the only reason that anyone would pay =
for
> it is so that they can support value added services I don't see how =
you
> address the requirement.
>=20
> Franchise boundaries are unlikely to match ESRP boundaries. Further =
more,
> not all value added service may be permitted, so the Target still =
needs to
> know what services for a given location provider will be permitted to
> obtain location information. I think the view of providing a coarse
> location is driven by a particular business model you have in mind =
that
> does not seem to match the model that people I have talked to have in
> mind.
>=20
> Cheers
> James
>=20
>=20
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Tuesday, 11 December 2007 3:08 AM
> > To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne'; =
'Stark,
> > Barbara'
> > Cc: ecrit@ietf.org; 'Liess, Laura'
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Yes, that is true.
> >
> > If your pizza delivery service provider's service boundary matches =
your
> > ESRPs boundary, you are in luck.
> >
> > In my conversations with carriers who want to do location hiding, =
this
> is
> > not seen as a problem.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > Sent: Monday, December 10, 2007 10:57 AM
> > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, =
Barbara
> > > Cc: ecrit@ietf.org; Liess, Laura
> > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > If I get coarse location good enough to route to my local pizza
> delivery
> > > facility then I have gotten my value added service for free.
> > >
> > > I rest my case!
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Tuesday, 11 December 2007 2:51 AM
> > > > To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne';
> > 'Stark,
> > > > Barbara'
> > > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > >
> > > > We are talking about location-by-reference.
> > > >
> > > > An endpoint or VSP dereferencing this URI will get coarse =
location,
> as
> > > > described.
> > > >
> > > > A PSAP or ESRP dereferencing will have credentials, and will get
> high
> > > > resolution data
> > > >
> > > > An authorized entity (i.e. one paying for it) will have =
credentials
> > and
> > > > will
> > > > get high resolution data.
> > > >
> > > > Where is the problem?
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Winterbottom, James =
[mailto:James.Winterbottom@andrew.com]
> > > > > Sent: Monday, December 10, 2007 10:38 AM
> > > > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark,
> Barbara
> > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > > >
> > > > > Brian,
> > > > >
> > > > > The primary aim for hiding location is not to make it hard for
> > > emergency
> > > > > services, but to enable the ability to charge for value added
> > > services.
> > > > > Can you please explain how this solution (other than through a =
one
> > off
> > > > > charge for location) supports this requirement.
> > > > >
> > > > > Cheers
> > > > > James
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > > > Sent: Tuesday, 11 December 2007 1:57 AM
> > > > > > To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'
> > > > > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > > > >
> > > > > > The only emergency service in the U.S. is urn:service:sos.
> There
> > is
> > > > > only
> > > > > > one boundary and if it changes (which LoST tells you via the =
TTL
> > of
> > > > the
> > > > > > service boundary), you may have to find those locations =
affected
> > by
> > > > the
> > > > > > change when they request a new location URI.
> > > > > >
> > > > > > In the countries where there are multiple services, there =
are
> only
> > a
> > > > few
> > > > > > (sometimes one) ESRPs.
> > > > > >
> > > > > > There could be some theoretic case of lots of ESRPs and lots =
of
> > > > > services,
> > > > > > in
> > > > > > which case there are more intersections, but the calculation =
is
> > > > simple,
> > > > > > fairly quick, and the TTLs make it easy to determine when a
> change
> > > is
> > > > > > made,
> > > > > > and several pretty straightforward strategies are available =
to
> > > > minimize
> > > > > > the
> > > > > > work on the LIS.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > > > > Sent: Saturday, December 08, 2007 6:39 PM
> > > > > > > To: Henning Schulzrinne; Stark, Barbara
> > > > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Everything is qualified on what ultimately gets regulated. =
But
> > > it's
> > > > > > > probably time to discuss real world implications of this
> topic.
> > > > > > >
> > > > > > > I expect that, if access operators are required to provide
> > > location,
> > > > > it
> > > > > > is
> > > > > > > only going to be for the purpose of emergency services. I
> doubt
> > > that
> > > > > > > regulators will even consider mandating that they provide =
it
> for
> > > all
> > > > > > users
> > > > > > > for all purposes. There'll be no sledgehammer to force =
access
> > > > > providers
> > > > > > to
> > > > > > > give everyone a free location service - so it won't happen
> until
> > > > > > operators
> > > > > > > have their own reasons to do so.
> > > > > > >
> > > > > > > Since access providers can't control what client devices
> > actually
> > > > use
> > > > > > > location information for, they will only implement a =
system
> that
> > > > > permits
> > > > > > a
> > > > > > > recognised emergency entity to retrieve the actual =
location
> > value.
> > > > > > They'll
> > > > > > > only give the end subscriber location information if =
that's
> > > already
> > > > > paid
> > > > > > > for as part of the subscription.
> > > > > > >
> > > > > > > The fundamental problem with the "do location hiding by
> > providing
> > > > > > > location" proposal is exactly that. It fails to hide =
location.
> > > This
> > > > is
> > > > > > > particularly the case in the US (which is a difficult =
market
> to
> > > > > ignore).
> > > > > > > The intersection of every possible service area - also =
called
> an
> > > ESN
> > > > > or
> > > > > > > ESZ - in the US is a quite granular area; certainly good =
for
> > quite
> > > a
> > > > > lot
> > > > > > > of services. For a mobile access provider, in particular, =
a
> > > > > considerable
> > > > > > > amount of capital equipment is going to be invoked to =
provide
> > this
> > > > > quite
> > > > > > > good location information.
> > > > > > >
> > > > > > > On the other hand, in many other countries (e.g. the UK =
and
> > > > Australia)
> > > > > > > this technique is probably not problematic for the =
carrier,
> > > because
> > > > > they
> > > > > > > are just going to return the country code. That's as =
granular
> as
> > > you
> > > > > > need
> > > > > > > to be for emergency services.
> > > > > > >
> > > > > > > So here's what will happen if this is the official IETF
> > > > > recommendation.
> > > > > > It
> > > > > > > may get adopted but operators will limit the provided =
location
> > > > > > information
> > > > > > > to just the country indicator. They'll do this in the US =
as
> well
> > > > > > (they'll
> > > > > > > refuse to process all the LoST boundary data and take
> > > responsibility
> > > > > for
> > > > > > > consequent routing outcome). This means that VSPs dealing =
with
> > > calls
> > > > > > > originating in the US will need to use i2. This is because =
the
> > V2
> > > > > > > interface in i2 does support a location reference while =
LoST
> is
> > > > unable
> > > > > > to
> > > > > > > do this. The country information will certainly be useful =
for
> > > > > > arbitrating
> > > > > > > which VPC to use though - so that's good. It will mean =
that
> > direct
> > > > to
> > > > > > PSAP
> > > > > > > calls won't be able to be made in the US. That's a shame.
> Other
> > > > > > > jurisdictions that only have a single PSAP route will be =
able
> to
> > > > > support
> > > > > > > this. OTOH, it might force the US to provide a federal =
level
> URI
> > > > with
> > > > > > > proxies that can subsequently do the dereference and lower
> level
> > > > > routing
> > > > > > -
> > > > > > > so maybe it's not such a shame. It won't result in access
> > > providers
> > > > > > giving
> > > > > > > free location information until they are ready to do so
> however.
> > > > > > >
> > > > > > > Editorial and a genuine question:
> > > > > > >
> > > > > > > IMO, supporting the services URI extension in HELD or =
adding
> > > > location
> > > > > > > reference support to LoST are both superior engineering
> > solutions.
> > > > > They
> > > > > > > just aren't driven by the punitive motivations of the =
"hide by
> > not
> > > > > > hiding"
> > > > > > > proposal. Arguments that they are inferior because they
> require
> > > > > protocol
> > > > > > > changes are specious and self-fulfilling. That's why the
> > > "reference
> > > > > > query"
> > > > > > > mechanism for LoST was "postponed" in the interest of =
getting
> > LoST
> > > > > > > finalized. It continues to be used as a prop for this
> particular
> > > > > hiding
> > > > > > > proposal. By this line of argument, we would never add or
> modify
> > > > > > protocols
> > > > > > > for anything.
> > > > > > >
> > > > > > > It's very difficult not to lapse into sarcasm in this area =
(I
> > feel
> > > > > like
> > > > > > > saying it's OK not to have location hiding because =
Columbia
> > > > University
> > > > > > and
> > > > > > > Cisco are going to underwrite the cost of providing a 5x9s
> > > reliable
> > > > > > > ubiquitous location service in all public access networks =
out
> of
> > > > pure
> > > > > > > philanthropy.... but I won't :) ).
> > > > > > >
> > > > > > > Insisting on providing location for all applications is =
like
> > > > insisting
> > > > > > > that cellular operators let users call anyone just to =
ensure
> > that
> > > > they
> > > > > > can
> > > > > > > also make emergency calls. In this hypothetical situation,
> > > refusing
> > > > to
> > > > > > > define protocol mechanisms that permit them to distinguish
> > between
> > > > the
> > > > > > > scenarios would only result in there being no cellular =
service
> -
> > > or
> > > > > just
> > > > > > > publicly funded cellular services. It's a =
counter-productive
> > > > attitude.
> > > > > > >
> > > > > > > This provides the opportunity for me to once more ask a
> question
> > > > that
> > > > > > > hasn't been responded to in the past. Why is ECRIT =
describing
> a
> > > > > solution
> > > > > > > that has the VSP involved in the emergency call at all? =
Why
> > would
> > > > the
> > > > > > VSP
> > > > > > > want to be involved in emergency calls - and why would the
> > caller
> > > > want
> > > > > > > them involved? It seems to be not in the interest of =
either
> > party.
> > > > > > There's
> > > > > > > already an interim architecture for the non "end-to-end =
IP"
> > > scenario
> > > > > > > called i2. In any circumstance where any of the device, =
the
> > > network,
> > > > > or
> > > > > > > emergency operator are not ECRIT-capable, then the VSP =
does
> need
> > > to
> > > > be
> > > > > > > involved and i2 is a valid fallback.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Martin
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > > Sent: Saturday, 8 December 2007 8:56 AM
> > > > > > > To: Stark, Barbara
> > > > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > >
> > > > > > > Translation: You have more lobbyists than I (or the IETF), =
so
> > give
> > > > me.
> > > > > > > Thanks for clarifying that.
> > > > > > >
> > > > > > > Henning
> > > > > > >
> > > > > > > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:
> > > > > > >
> > > > > > > > [The following statements are my opinion, and should not =
be
> > > > > > > > attributed to the company I work for.]
> > > > > > > >
> > > > > > > > Henning,
> > > > > > > > It's true that the IETF doesn't have to do something =
just
> > > because
> > > > > > > > someone wants it. It's also true that the IETF has no
> > authority
> > > or
> > > > > > > > ability to force implementation of RFCs by companies who
> > refuse
> > > to
> > > > > > > > implement them. You cannot shove a solution down the =
throats
> > of
> > > > > > > > access providers that they are unwilling to buy in to. =
In my
> > > > > > > > opinion, even attempting to do so would be, well, =
unethical.
> > > > > > > >
> > > > > > > > So, you have a choice:
> > > > > > > > 1) create a solution that you like that major =
stakeholders
> are
> > > > > > > > unwilling to implement
> > > > > > > > 2) create a solution that you don't quite like, but =
that's
> > > better
> > > > > > > > than what we have today, and which major stakeholders =
are
> > > willing
> > > > to
> > > > > > > > implement
> > > > > > > >
> > > > > > > > Believe it or not, major telecom companies in the US and
> > Europe
> > > > put
> > > > > > > > a lot of effort into lobbying regulatory bodies, to =
achieve
> > > > > > > > desirable outcomes. The IETF doesn't put in such effort. =
If
> > you
> > > > want
> > > > > > > > to make a go at pushing through a solution that =
stakeholders
> > in
> > > > > > > > these regions are set against, and see if you can get
> > regulatory
> > > > > > > > agencies to bless it, then go for it. I think the odds =
are
> > > stacked
> > > > > > > > against you, though. Especially since there are workable
> > > solutions
> > > > > > > > that these companies have said they would be willing to
> > accept.
> > > > > > > >
> > > > > > > > Here is why mobile access providers "cannot" provide the
> best
> > > > > > > > available location directly to end user devices: They =
don't
> > want
> > > > to.
> > > > > > > > At this point in time, it's their network, their data, =
and
> > their
> > > > > > > > choice.
> > > > > > > >
> > > > > > > > In free market economies, you generally have to be able =
to
> > > *prove*
> > > > > > > > (and not just say it without proof) massive benefit or
> massive
> > > > harm
> > > > > > > > before you can force companies to do what they don't =
want to
> > do,
> > > > > > > > through regulation. Again, if you think you can take on =
that
> > > > battle
> > > > > > > > and win, go for it.
> > > > > > > >
> > > > > > > > I, for one, believe that not providing the "real" =
location
> > value
> > > > to
> > > > > > > > end devices would not cause such benefit or harm. If =
users
> > want
> > > to
> > > > > > > > know what location PSAPs get on their behalf, and =
regulators
> > > > believe
> > > > > > > > such a capability is needed, then we can let the =
phonebcp-
> > > > described
> > > > > > > > test mechanism voice it back over the voice medium (this
> would
> > > > only
> > > > > > > > work for civic), or return a JPEG map with a dot on it. =
This
> > > would
> > > > > > > > provide location in a format that's usable by a human =
being,
> > but
> > > > not
> > > > > > > > an application. Or maybe, in some countries, the =
regulators
> do
> > > > > > > > require access providers to give out the best possible
> > location
> > > > > > > > values to end devices. But it's really improbable that =
you
> > could
> > > > > > > > force the regulators of all countries to see things your
> way.
> > > > > > > >
> > > > > > > > But, this is all just my opinion.
> > > > > > > > Barbara
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > > > Sent: Friday, December 07, 2007 12:13 PM
> > > > > > > > To: Liess, Laura
> > > > > > > > Cc: ecrit@ietf.org
> > > > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >
> > > > > > > > Laura,
> > > > > > > >
> > > > > > > > just because somebody says "we need it" doesn't make it =
an
> > IETF
> > > > > > > > requirement. Please justify why mobile access cannot =
provide
> > > > > locations
> > > > > > > > to end users.
> > > > > > > >
> > > > > > > > Henning
> > > > > > > >
> > > > > > > > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
> > > > > > > >
> > > > > > > >> Brian,
> > > > > > > >>
> > > > > > > >> I checked with my company and we need LH for both civic =
and
> > geo
> > > > for
> > > > > > > >> fixed and mobile access. Only DSL and civic is not an
> option.
> > > > > > > >>
> > > > > > > >> I would support sending the ESRP/PSAP URI to the UA, as
> > > proposed
> > > > by
> > > > > > > >> Barbara and James some weeks ago.
> > > > > > > >>
> > > > > > > >> Laura
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> -----Urspr=FCngliche Nachricht-----
> > > > > > > >> Von: Brian Rosen [mailto:br@brianrosen.net]
> > > > > > > >> Gesendet: Dienstag, 4. Dezember 2007 16:37
> > > > > > > >> An: 'Hannes Tschofenig'
> > > > > > > >> Cc: 'ECRIT'
> > > > > > > >> Betreff: RE: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>
> > > > > > > >> Proposed text for framework
> > > > > > > >>
> > > > > > > >> Some access networks wish to restrict who can get a =
high
> > > quality
> > > > > > > >> location,
> > > > > > > >> possibly based on a payment arrangement.  For emergency
> > calls,
> > > > high
> > > > > > > >> quality
> > > > > > > >> location must be provided.  An access network can
> reasonably
> > be
> > > > > > > >> expected to
> > > > > > > >> have a relationship with the PSAPs in its catchment =
area,
> so
> > > > giving
> > > > > > > >> location
> > > > > > > >> to the PSAP will be straightforward
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> However, an endpoint may need location
> > > > > > > >> for routing, and a proxy may need to verify that a
> purported
> > > > > > > >> emergency call
> > > > > > > >> is targeted at a bona fide PSAP.  To do so, it may take =
the
> > > > > location
> > > > > > > >> passed
> > > > > > > >> with the call and query LoST to confirm that the URI is
> > > genuine.
> > > > > > > >> "Hiding"
> > > > > > > >> location interferes with this check.  To achieve =
location
> > > hiding,
> > > > > > > >> the LIS
> > > > > > > >> can return a coarse location which is good enough to =
elicit
> > the
> > > > > same
> > > > > > > >> response from LoST as the actual location would.  The
> > endpoint
> > > > and
> > > > > > > >> the proxy
> > > > > > > >> can use this location to route and verify.  A suitable
> > location
> > > > for
> > > > > > > >> a geo is
> > > > > > > >> a polygon calculated by intersecting the service =
boundaries
> > of
> > > > all
> > > > > > > >> of the
> > > > > > > >> emergency services that respond to the actual location. =
 A
> > > > suitable
> > > > > > > >> location
> > > > > > > >> for a civic is any civic location within the =
intersection
> of
> > > the
> > > > > > > >> service
> > > > > > > >> boundaries of emergency services.  In a great many =
cases, a
> > > > country
> > > > > > > >> code is
> > > > > > > >> sufficient.  In others a state/province or a city name =
is
> > > > > > > >> sufficient.  Of
> > > > > > > >> course, the LIS would always return a location =
reference,
> > which
> > > > > > > >> would return
> > > > > > > >> high quality location for a PSAP and coarse location to =
the
> > > > > endpoint
> > > > > > > >> or any
> > > > > > > >> proxy unknown to the LIS.
> > > > > > > >>
> > > > > > > >> Proposed text for phonebcp:
> > > > > > > >>
> > > > > > > >> A LIS who wishes to hide location returns a location
> > reference.
> > > > > When
> > > > > > > >> dereferenced by the endpoint or proxy:
> > > > > > > >> 1. For LIS's returning geo:
> > > > > > > >>   For each location served by the LIS, compute the
> > intersection
> > > > of
> > > > > > > >> the
> > > > > > > >>   service boundaries for all emergency services known =
to
> LoST
> > > for
> > > > > the
> > > > > > > >>   location. Return the resulting polygon, or any point =
in
> the
> > > > > > > >> polygon as
> > > > > > > >>   the value during a dereference
> > > > > > > >> 2. For LIS's returning civic:
> > > > > > > >>   Determine a civic location which is within the =
service
> > > boundary
> > > > > > > >> of all
> > > > > > > >>   emergency services known to LoST for the location.  =
In a
> > > great
> > > > > many
> > > > > > > >>   cases, this will be a country code, province/state or
> city.
> > > > > > > >> Return this
> > > > > > > >>   coarse civic location as the value during a =
dereference
> > > > > > > >> Note that the service boundaries returned from LoST =
have a
> > TTL,
> > > > the
> > > > > > > >> intersections MUST recalculated if the service boundary
> > > changes.
> > > > > > > >> The LIS
> > > > > > > >> MUST return high quality location to a PSAP or ESRP.
> > > > > > > >>
> > > > > > > >> Brian
> > > > > > > >>
> > > > > > > >>> -----Original Message-----
> > > > > > > >>> From: Hannes Tschofenig =
[mailto:Hannes.Tschofenig@gmx.net]
> > > > > > > >>> Sent: Monday, December 03, 2007 1:38 PM
> > > > > > > >>> To: Brian Rosen
> > > > > > > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> > > > > > > >>> Subject: Re: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>>
> > > > > > > >>> Hi Brian,
> > > > > > > >>>
> > > > > > > >>> Brian Rosen wrote:
> > > > > > > >>>> It's fine with me if there is a separate doc, but
> framework
> > > and
> > > > > > > >>>> phonebcp
> > > > > > > >>>> have to reference it.
> > > > > > > >>>>
> > > > > > > >>> Are we talking about informative or normative =
references?
> > > > > > > >>>> I think it can be solved with a one paragraph =
description
> > of
> > > > the
> > > > > > > >>>> problem
> > > > > > > >>> in
> > > > > > > >>>> framework and a one paragraph solution in phonebcp, =
but
> if
> > > > there
> > > > > > > >>>> is a
> > > > > > > >>>> separate doc and a reference, I will be happy.
> > > > > > > >>>>
> > > > > > > >>> That does not make sense.
> > > > > > > >>> The solution is not one paragraph and the text in =
phone
> bcp
> > is
> > > > > > > >>> normative.
> > > > > > > >>>
> > > > > > > >>> Ciao
> > > > > > > >>> Hannes
> > > > > > > >>>
> > > > > > > >>>> Brian
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>> -----Original Message-----
> > > > > > > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> > > > > > > >>>>> Sent: Monday, December 03, 2007 7:37 PM
> > > > > > > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> > > > > > > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>>>>
> > > > > > > >>>>> Currently, the WG (and document editors!) should be
> > > operating
> > > > > > > >>>>> under
> > > > > > > >>>>> the consensus direction that Location Hiding *not* =
be in
> > > > > PhoneBCP
> > > > > > > >>>>> or
> > > > > > > >>>>> Framework.  This was a clear consensus call in =
Chicago -
> > and
> > > > not
> > > > > > > >>>>> by
> > > > > > > >>>>> default, but by most people voicing actively against
> > having
> > > > this
> > > > > > > >>>>> Hiding in either core ECRIT documents, and I haven't =
yet
> > > > talked
> > > > > to
> > > > > > > >>>>> anyone here in Vancouver that thinks otherwise.
> > > > > > > >>>>>
> > > > > > > >>>>> Location Hiding is something that needs to be =
addressed
> BY
> > > > > ITSELF
> > > > > > > >>>>> (i.e., in its own doc) so everyone can focus on the
> > singular
> > > > > > > >>>>> topic,
> > > > > > > >>>>> and work towards not talking past each other (not =
like
> > > that's
> > > > > > > >>>>> happened before in ECRIT....  :-/
> > > > > > > >>>>>
> > > > > > > >>>>> Who disagrees with this?
> > > > > > > >>>>>
> > > > > > > >>>>> BTW - if someone thinks Location Hiding should be =
put
> back
> > > > into
> > > > > > > >>>>> PhoneBCP or Framework, then they can attempt to gain =
WG
> > > > > consensus
> > > > > > > >>>>> on
> > > > > > > >>>>> that, but that's different than a direction of this
> > > > > inevitability
> > > > > > > >>>>> or
> > > > > > > >>>>> that there is not consensus on this.
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> > > > > > > >>>>>
> > > > > > > >>>>>> If people felt this was good enough so that access
> > > providers
> > > > > > > >>>>>> would not
> > > > > > > >>>>>> need to be required to build the infrastructure to
> > provide
> > > > > > > >>>>>> location
> > > > > > > >>>>>> (because people could use this method instead of
> getting
> > > > > > > >>>>>> location from
> > > > > > > >>>>>> access providers), then location hiding would be =
dead.
> If
> > > > > people
> > > > > > > >>>>>> still
> > > > > > > >>>>>> want to place a requirement on access providers to
> > provide
> > > > > > > >>>>>> location,
> > > > > > > >>>>>> then location hiding is not dead.
> > > > > > > >>>>>> Barbara
> > > > > > > >>>>>>
> > > > > > > >>>>>> -----Original Message-----
> > > > > > > >>>>>> From: Hannes Tschofenig
> > [mailto:Hannes.Tschofenig@gmx.net]
> > > > > > > >>>>>> Sent: Saturday, December 01, 2007 3:34 PM
> > > > > > > >>>>>> To: ECRIT
> > > > > > > >>>>>> Subject: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >>>>>>
> > > > > > > >>>>>> I thought that the following article would be of
> interest
> > > for
> > > > > > > >>>>>> you:
> > > > > > > >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-
> found.html
> > > > > > > >>>>>>
> > > > > > > >>>>>> Here is text from
> > > > > > > >>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-
> > blue-
> > > > > circle-
> > > > > > > on-
> > > > > > > >>> your
> > > > > > > >>>>>> -map.html
> > > > > > > >>>>>> "
> > > > > > > >>>>>> My Location is a new beta technology from Google =
that
> > uses
> > > > cell
> > > > > > > >>>>>> tower
> > > > > > > >>>>>> identification to provide you with approximate =
location
> > > > > > > >>>>>> information,
> > > > > > > >>> so
> > > > > > > >>>>>> it will work on phones without GPS.
> > > > > > > >>>>>> "
> > > > > > > >>>>>> Note that this stuff is not really new technology. =
It
> > > existed
> > > > > > > >>>>>> already
> > > > > > > >>>>>> for some time but the availability of GPS devices =
made
> it
> > > > > > > >>>>>> possible to
> > > > > > > >>>>>> setup the database in a more efficient way.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Anyway, this mechanism allows you to obtain =
location
> > > > > information
> > > > > > > >>>>>> with
> > > > > > > >>>>>> your cell phone (using the cell id) without =
interacting
> > > with
> > > > > the
> > > > > > > >>>>>> cellular operator.
> > > > > > > >>>>>> In short: operator cannot charge for location
> > > > > > > >>>>>>
> > > > > > > >>>>>> While the location information is not really useful =
for
> > > first
> > > > > > > >>> responders
> > > > > > > >>>>>>
> > > > > > > >>>>>> it is still good enough for finding the closest =
PSAP.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Is this the dead of location hiding?
> > > > > > > >>>>>>
> > > > > > > >>>>>> Ciao
> > > > > > > >>>>>> Hannes
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>> _______________________________________________
> > > > > > > >>>>>> Ecrit mailing list
> > > > > > > >>>>>> Ecrit@ietf.org
> > > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>>>>>
> > > > > > > >>>>>> _______________________________________________
> > > > > > > >>>>>> Ecrit mailing list
> > > > > > > >>>>>> Ecrit@ietf.org
> > > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>>>>>
> > > > > > > >>>>> _______________________________________________
> > > > > > > >>>>> Ecrit mailing list
> > > > > > > >>>>> Ecrit@ietf.org
> > > > > > > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>>>>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> _______________________________________________
> > > > > > > >> Ecrit mailing list
> > > > > > > >> Ecrit@ietf.org
> > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >>
> > > > > > > >> _______________________________________________
> > > > > > > >> Ecrit mailing list
> > > > > > > >> Ecrit@ietf.org
> > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Ecrit mailing list
> > > > > > > > Ecrit@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >
> > > > > > > > *****
> > > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Ecrit mailing list
> > > > > > > Ecrit@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > >
> > > > > > > =
--------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > ----------------------
> > > > > > > This message is for the designated recipient only and may
> > > > > > > contain privileged, proprietary, or otherwise private
> > information.
> > > > > > > If you have received it in error, please notify the sender
> > > > > > > immediately and delete the original.  Any unauthorized use =
of
> > > > > > > this email is prohibited.
> > > > > > > =
--------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > ----------------------
> > > > > > > [mf2]
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Ecrit mailing list
> > > > > > > Ecrit@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Ecrit mailing list
> > > > > > Ecrit@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > > > =
------------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > ----------------------
> > > > > This message is for the designated recipient only and may
> > > > > contain privileged, proprietary, or otherwise private =
information.
> > > > > If you have received it in error, please notify the sender
> > > > > immediately and delete the original.  Any unauthorized use of
> > > > > this email is prohibited.
> > > > > =
------------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > ----------------------
> > > > > [mf2]
> > > >
> > >
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > This message is for the designated recipient only and may
> > > contain privileged, proprietary, or otherwise private information.
> > > If you have received it in error, please notify the sender
> > > immediately and delete the original.  Any unauthorized use of
> > > this email is prohibited.
> > > =
----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > [mf2]
> >
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 13:11:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1n6U-0001vM-9N; Mon, 10 Dec 2007 13:11:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1n6T-0001vE-8Z
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:11:41 -0500
Received: from ironportdmz6.qualcomm.com ([199.106.114.251]
	helo=wolverine02.qualcomm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1n6S-0002k5-R9
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:11:41 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Cc:Content-Type;
	b=IaCBOOor8l5OJ0++gPvOC2lxCEwQDm+VtlkHamnkhJZ8fv4MuW/VjgtD
	gochinuNsL3Ke0HCWGLzCWlveGEMIgK6uiwhtVT4Ajxks3uJf9M3LFhL9
	/YmulCktP4e803Adjcv/OzpXkpfc0isorly0EWh/6+qT4kMWwOGBkXr23
	s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAAIQXUeBLjM7/2dsb2JhbAA
X-IronPort-AV: E=McAfee;i="5100,188,5182"; a="44269"
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	10 Dec 2007 10:11:39 -0800
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lBAIBcJQ019394
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Dec 2007 10:11:39 -0800
Received: from [76.126.60.89] (vpn-10-50-0-180.qualcomm.com [10.50.0.180])
	by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lBAIBZ5m012512;
	Mon, 10 Dec 2007 10:11:36 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p>
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p>
Date: Mon, 10 Dec 2007 10:11:39 -0800
To: "Stark, Barbara" , "Brian Rosen" ,
	"Winterbottom, James" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
From: Ted Hardie 
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 1.2 (+)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

>
>Admittedly, this is outside the scope of ecrit. But, since LoST was made into a generic service URN to URI translator, it would be nice if somehow the LoST protocol could be used to provide devices with URIs, even when the device doesn't have its precise location.
>
>I think that getting this capability would be very useful and desirable, but don't think it's as high a priority as getting the emergency services architecture worked out.
>Barbara

Let me strongly support the notion that getting into this before finishing the
emergency services work is not desirable.  There are several potential issues
here (the most prominent being whether re-using the service urn namespace
for services will work for non-jurisdictionally derived catchement areas).
I think it is far enough outside the realm of ECRIT that boffing the work
as a Lost extensions wg would be desirable.

In the short term, doing location hiding sufficient for emergency services
is the item under discussion.  Does anyone believe Brian's text does not
work for this point?

			regards,
				Ted

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 13:12:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1n77-0002ap-Kf; Mon, 10 Dec 2007 13:12:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1n76-0002YZ-96
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:12:20 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1n72-0007hD-Rl
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:12:20 -0500
X-SEF-Processed: 5_0_0_910__2007_12_10_12_23_17
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Mon, 10 Dec 2007 12:23:17 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 12:12:13 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 12:12:15 -0600
Message-ID: 
In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQAABDxoAAAFPxMAAAKBBgAABJjLAAAoF9AAABeBSg
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p>
From: "Winterbottom, James" 
To: "Stark, Barbara" , "Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
X-OriginalArrivalTime: 10 Dec 2007 18:12:13.0151 (UTC)
	FILETIME=[302D86F0:01C83B58]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: ba231eeb0ba293f319cac22693e776bc
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

You hit the nail on the head Barbara, and I believe that if we do this, the=
n the emergency solution falls out in the wash.=0D=0A=0D=0ACheers=0D=0AJame=
s=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Stark, Barbara [mail=
to:bs7652@att.com]=0D=0A> Sent: Tuesday, 11 December 2007 4:53 AM=0D=0A> To=
: Brian Rosen; Winterbottom, James; Dawson, Martin; Henning Schulzrinne=0D=0A=
> Cc: ecrit@ietf.org; Liess, Laura=0D=0A> Subject: RE: AW: [Ecrit] Location=
 Hiding -- State of the Art=0D=0A>=20=0D=0A> I think I understand what Jame=
s is saying.=0D=0A>=20=0D=0A> Let's say that a VSP has contracted with an a=
ccess provider to be allowed=0D=0A> to dereference location for its subscri=
bers.=0D=0A>=20=0D=0A> A device gets a location reference from the access p=
rovider, publishes it=0D=0A> to the VSP's presence server; and the VSP dere=
ferences the location.=0D=0A>=20=0D=0A> The VSP would like to contract with=
 a pizza delivery business to allow its=0D=0A> subscribers to easily order =
pizza, from anywhere, by telling the device=0D=0A> the URL associated with =
a pizza service, based on the device location.=0D=0A>=20=0D=0A> The VSP has=
 all the info it needs to provide this service, since it was=0D=0A> able to=
 dereference the LbyR. But there's no standard way for the VSP to=0D=0A> te=
ll the device what that pizza service URL is, for the device's location.=0D=
=0A> And the VSP isn't allowed to tell the device what the device's real=0D=
=0A> location value is, because that's not allowed under the agreement with=
 the=0D=0A> access provider.=0D=0A>=20=0D=0A> Or it could be that an access=
 provider would like to contract with various=0D=0A> companies to provide r=
outing information for specific service URNs. The=0D=0A> access provider wa=
nts to provide the routing info, but not the location to=0D=0A> devices. Ag=
ain, there's no protocol for this.=0D=0A>=20=0D=0A> Admittedly, this is out=
side the scope of ecrit. But, since LoST was made=0D=0A> into a generic ser=
vice URN to URI translator, it would be nice if somehow=0D=0A> the LoST pro=
tocol could be used to provide devices with URIs, even when=0D=0A> the devi=
ce doesn't have its precise location.=0D=0A>=20=0D=0A> I think that getting=
 this capability would be very useful and desirable,=0D=0A> but don't think=
 it's as high a priority as getting the emergency services=0D=0A> architect=
ure worked out.=0D=0A> Barbara=0D=0A>=20=0D=0A> -----Original Message-----=0D=
=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Monday, Dece=
mber 10, 2007 11:26 AM=0D=0A> To: 'Winterbottom, James'; 'Dawson, Martin'; =
'Henning Schulzrinne'; Stark,=0D=0A> Barbara=0D=0A> Cc: ecrit@ietf.org; 'Li=
ess, Laura'=0D=0A> Subject: RE: AW: [Ecrit] Location Hiding -- State of the=
 Art=0D=0A>=20=0D=0A> James, we're not communicating.=0D=0A>=20=0D=0A> Coar=
se location is only given to entities who the LIS doesn't want to give=0D=0A=
> real location.  It's good enough to route and validate emergency calls,=0D=
=0A> and=0D=0A> not good for anything else.  It's not supposed to be useful=
 for anything=0D=0A> else.=0D=0A>=20=0D=0A> The LIS can give high quality l=
ocation to anyone it wishes to, which will=0D=0A> work for "real" location =
based services.  Specifically, if it wishes some=0D=0A> entity to be able t=
o route other services, it can give it high quality=0D=0A> location.   That=
 entity can control which services get routed under=0D=0A> whatever=0D=0A> =
terms the LIS is willing to give it high quality location.=0D=0A>=20=0D=0A>=
 No one, so far, has created a requirement that some non-authorized entity=0D=
=0A> has to be able to provide some form of location based service (such as=0D=
=0A> routing based on location) without having some kind of authorization o=
r=0D=0A> credentials from the LIS for such purposes.  The LIS is free to gi=
ve=0D=0A> location to anyone it wants, for any purpose, subject to the priv=
acy=0D=0A> limitations in the PIDF-LO.  The LIS MUST allow any entity to ro=
ute an=0D=0A> emergency call.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > ---=
--Original Message-----=0D=0A> > From: Winterbottom, James [mailto:James.Wi=
nterbottom@andrew.com]=0D=0A> > Sent: Monday, December 10, 2007 11:15 AM=0D=
=0A> > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara=0D=
=0A> > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > Subject: RE: AW: [Ecrit] L=
ocation Hiding -- State of the Art=0D=0A> >=0D=0A> > Brian my point is this=
=2E=0D=0A> >=0D=0A> > A location hiding mechanism that ONLY provides the bo=
undary map of the=0D=0A> > ESRP is pretty much useless in that it won't ena=
ble them to support the=0D=0A> > value added case period. Since the only re=
ason that anyone would pay for=0D=0A> > it is so that they can support valu=
e added services I don't see how you=0D=0A> > address the requirement.=0D=0A=
> >=0D=0A> > Franchise boundaries are unlikely to match ESRP boundaries. Fu=
rther=0D=0A> more,=0D=0A> > not all value added service may be permitted, s=
o the Target still needs=0D=0A> to=0D=0A> > know what services for a given =
location provider will be permitted to=0D=0A> > obtain location information=
=2E I think the view of providing a coarse=0D=0A> > location is driven by a=
 particular business model you have in mind that=0D=0A> > does not seem to =
match the model that people I have talked to have in=0D=0A> > mind.=0D=0A> =
>=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> > > -----Original=
 Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A=
> > > Sent: Tuesday, 11 December 2007 3:08 AM=0D=0A> > > To: Winterbottom, =
James; Dawson, Martin; 'Henning Schulzrinne';=0D=0A> 'Stark,=0D=0A> > > Bar=
bara'=0D=0A> > > Cc: ecrit@ietf.org; 'Liess, Laura'=0D=0A> > > Subject: RE:=
 AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> > >=0D=0A> > > Yes,=
 that is true.=0D=0A> > >=0D=0A> > > If your pizza delivery service provide=
r's service boundary matches=0D=0A> your=0D=0A> > > ESRPs boundary, you are=
 in luck.=0D=0A> > >=0D=0A> > > In my conversations with carriers who want =
to do location hiding, this=0D=0A> > is=0D=0A> > > not seen as a problem.=0D=
=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original Message----=
-=0D=0A> > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.=
com]=0D=0A> > > > Sent: Monday, December 10, 2007 10:57 AM=0D=0A> > > > To:=
 Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara=0D=0A> > =
> > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > > > Subject: RE: AW: [Ecrit] =
Location Hiding -- State of the Art=0D=0A> > > >=0D=0A> > > > If I get coar=
se location good enough to route to my local pizza=0D=0A> > delivery=0D=0A>=
 > > > facility then I have gotten my value added service for free.=0D=0A> =
> > >=0D=0A> > > > I rest my case!=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > >=
 -----Original Message-----=0D=0A> > > > > From: Brian Rosen [mailto:br@bri=
anrosen.net]=0D=0A> > > > > Sent: Tuesday, 11 December 2007 2:51 AM=0D=0A> =
> > > > To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne';=0D=0A=
> > > 'Stark,=0D=0A> > > > > Barbara'=0D=0A> > > > > Cc: ecrit@ietf.org; 'L=
iess, Laura'=0D=0A> > > > > Subject: RE: AW: [Ecrit] Location Hiding -- Sta=
te of the Art=0D=0A> > > > >=0D=0A> > > > > We are talking about location-b=
y-reference.=0D=0A> > > > >=0D=0A> > > > > An endpoint or VSP dereferencing=
 this URI will get coarse=0D=0A> location,=0D=0A> > as=0D=0A> > > > > descr=
ibed.=0D=0A> > > > >=0D=0A> > > > > A PSAP or ESRP dereferencing will have =
credentials, and will get=0D=0A> > high=0D=0A> > > > > resolution data=0D=0A=
> > > > >=0D=0A> > > > > An authorized entity (i.e. one paying for it) will=
 have=0D=0A> credentials=0D=0A> > > and=0D=0A> > > > > will=0D=0A> > > > > =
get high resolution data.=0D=0A> > > > >=0D=0A> > > > > Where is the proble=
m=3F=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > > > -----Original Message--=
---=0D=0A> > > > > > From: Winterbottom, James [mailto:James.Winterbottom@a=
ndrew.com]=0D=0A> > > > > > Sent: Monday, December 10, 2007 10:38 AM=0D=0A>=
 > > > > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark,=0D=0A=
> > Barbara=0D=0A> > > > > > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > > > =
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> > >=
 > > >=0D=0A> > > > > > Brian,=0D=0A> > > > > >=0D=0A> > > > > > The primar=
y aim for hiding location is not to make it hard for=0D=0A> > > > emergency=0D=
=0A> > > > > > services, but to enable the ability to charge for value adde=
d=0D=0A> > > > services.=0D=0A> > > > > > Can you please explain how this s=
olution (other than through a=0D=0A> one=0D=0A> > > off=0D=0A> > > > > > ch=
arge for location) supports this requirement.=0D=0A> > > > > >=0D=0A> > > >=
 > > Cheers=0D=0A> > > > > > James=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A>=
 > > > > > > -----Original Message-----=0D=0A> > > > > > > From: Brian Rose=
n [mailto:br@brianrosen.net]=0D=0A> > > > > > > Sent: Tuesday, 11 December =
2007 1:57 AM=0D=0A> > > > > > > To: Dawson, Martin; 'Henning Schulzrinne'; =
'Stark, Barbara'=0D=0A> > > > > > > Cc: ecrit@ietf.org; 'Liess, Laura'=0D=0A=
> > > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=
=0A> > > > > > >=0D=0A> > > > > > > The only emergency service in the U.S. =
is urn:service:sos.=0D=0A> > There=0D=0A> > > is=0D=0A> > > > > > only=0D=0A=
> > > > > > > one boundary and if it changes (which LoST tells you via the=0D=
=0A> TTL=0D=0A> > > of=0D=0A> > > > > the=0D=0A> > > > > > > service bounda=
ry), you may have to find those locations=0D=0A> affected=0D=0A> > > by=0D=0A=
> > > > > the=0D=0A> > > > > > > change when they request a new location UR=
I.=0D=0A> > > > > > >=0D=0A> > > > > > > In the countries where there are m=
ultiple services, there are=0D=0A> > only=0D=0A> > > a=0D=0A> > > > > few=0D=
=0A> > > > > > > (sometimes one) ESRPs.=0D=0A> > > > > > >=0D=0A> > > > > >=
 > There could be some theoretic case of lots of ESRPs and lots=0D=0A> of=0D=
=0A> > > > > > services,=0D=0A> > > > > > > in=0D=0A> > > > > > > which cas=
e there are more intersections, but the calculation=0D=0A> is=0D=0A> > > > =
> simple,=0D=0A> > > > > > > fairly quick, and the TTLs make it easy to det=
ermine when a=0D=0A> > change=0D=0A> > > > is=0D=0A> > > > > > > made,=0D=0A=
> > > > > > > and several pretty straightforward strategies are available t=
o=0D=0A> > > > > minimize=0D=0A> > > > > > > the=0D=0A> > > > > > > work on=
 the LIS.=0D=0A> > > > > > >=0D=0A> > > > > > > Brian=0D=0A> > > > > > >=0D=
=0A> > > > > > > > -----Original Message-----=0D=0A> > > > > > > > From: Da=
wson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > > > > > Sent: S=
aturday, December 08, 2007 6:39 PM=0D=0A> > > > > > > > To: Henning Schulzr=
inne; Stark, Barbara=0D=0A> > > > > > > > Cc: ecrit@ietf.org; Liess, Laura=0D=
=0A> > > > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the=
 Art=0D=0A> > > > > > > >=0D=0A> > > > > > > > Hi all,=0D=0A> > > > > > > >=0D=
=0A> > > > > > > > Everything is qualified on what ultimately gets regulate=
d.=0D=0A> But=0D=0A> > > > it's=0D=0A> > > > > > > > probably time to discu=
ss real world implications of this=0D=0A> > topic.=0D=0A> > > > > > > >=0D=0A=
> > > > > > > > I expect that, if access operators are required to provide=0D=
=0A> > > > location,=0D=0A> > > > > > it=0D=0A> > > > > > > is=0D=0A> > > >=
 > > > > only going to be for the purpose of emergency services. I=0D=0A> >=
 doubt=0D=0A> > > > that=0D=0A> > > > > > > > regulators will even consider=
 mandating that they provide it=0D=0A> > for=0D=0A> > > > all=0D=0A> > > > =
> > > users=0D=0A> > > > > > > > for all purposes. There'll be no sledgeham=
mer to force=0D=0A> access=0D=0A> > > > > > providers=0D=0A> > > > > > > to=0D=
=0A> > > > > > > > give everyone a free location service - so it won't happ=
en=0D=0A> > until=0D=0A> > > > > > > operators=0D=0A> > > > > > > > have th=
eir own reasons to do so.=0D=0A> > > > > > > >=0D=0A> > > > > > > > Since a=
ccess providers can't control what client devices=0D=0A> > > actually=0D=0A=
> > > > > use=0D=0A> > > > > > > > location information for, they will only=
 implement a system=0D=0A> > that=0D=0A> > > > > > permits=0D=0A> > > > > >=
 > a=0D=0A> > > > > > > > recognised emergency entity to retrieve the actua=
l location=0D=0A> > > value.=0D=0A> > > > > > > They'll=0D=0A> > > > > > > =
> only give the end subscriber location information if that's=0D=0A> > > > =
already=0D=0A> > > > > > paid=0D=0A> > > > > > > > for as part of the subsc=
ription.=0D=0A> > > > > > > >=0D=0A> > > > > > > > The fundamental problem =
with the "do location hiding by=0D=0A> > > providing=0D=0A> > > > > > > > l=
ocation" proposal is exactly that. It fails to hide=0D=0A> location.=0D=0A>=
 > > > This=0D=0A> > > > > is=0D=0A> > > > > > > > particularly the case in=
 the US (which is a difficult market=0D=0A> > to=0D=0A> > > > > > ignore).=0D=
=0A> > > > > > > > The intersection of every possible service area - also=0D=
=0A> called=0D=0A> > an=0D=0A> > > > ESN=0D=0A> > > > > > or=0D=0A> > > > >=
 > > > ESZ - in the US is a quite granular area; certainly good for=0D=0A> =
> > quite=0D=0A> > > > a=0D=0A> > > > > > lot=0D=0A> > > > > > > > of servi=
ces. For a mobile access provider, in particular, a=0D=0A> > > > > > consid=
erable=0D=0A> > > > > > > > amount of capital equipment is going to be invo=
ked to=0D=0A> provide=0D=0A> > > this=0D=0A> > > > > > quite=0D=0A> > > > >=
 > > > good location information.=0D=0A> > > > > > > >=0D=0A> > > > > > > >=
 On the other hand, in many other countries (e.g. the UK and=0D=0A> > > > >=
 Australia)=0D=0A> > > > > > > > this technique is probably not problematic=
 for the carrier,=0D=0A> > > > because=0D=0A> > > > > > they=0D=0A> > > > >=
 > > > are just going to return the country code. That's as=0D=0A> granular=0D=
=0A> > as=0D=0A> > > > you=0D=0A> > > > > > > need=0D=0A> > > > > > > > to =
be for emergency services.=0D=0A> > > > > > > >=0D=0A> > > > > > > > So her=
e's what will happen if this is the official IETF=0D=0A> > > > > > recommen=
dation.=0D=0A> > > > > > > It=0D=0A> > > > > > > > may get adopted but oper=
ators will limit the provided=0D=0A> location=0D=0A> > > > > > > informatio=
n=0D=0A> > > > > > > > to just the country indicator. They'll do this in th=
e US as=0D=0A> > well=0D=0A> > > > > > > (they'll=0D=0A> > > > > > > > refu=
se to process all the LoST boundary data and take=0D=0A> > > > responsibili=
ty=0D=0A> > > > > > for=0D=0A> > > > > > > > consequent routing outcome). T=
his means that VSPs dealing=0D=0A> with=0D=0A> > > > calls=0D=0A> > > > > >=
 > > originating in the US will need to use i2. This is because=0D=0A> the=0D=
=0A> > > V2=0D=0A> > > > > > > > interface in i2 does support a location re=
ference while LoST=0D=0A> > is=0D=0A> > > > > unable=0D=0A> > > > > > > to=0D=
=0A> > > > > > > > do this. The country information will certainly be usefu=
l=0D=0A> for=0D=0A> > > > > > > arbitrating=0D=0A> > > > > > > > which VPC =
to use though - so that's good. It will mean that=0D=0A> > > direct=0D=0A> =
> > > > to=0D=0A> > > > > > > PSAP=0D=0A> > > > > > > > calls won't be able=
 to be made in the US. That's a shame.=0D=0A> > Other=0D=0A> > > > > > > > =
jurisdictions that only have a single PSAP route will be=0D=0A> able=0D=0A>=
 > to=0D=0A> > > > > > support=0D=0A> > > > > > > > this. OTOH, it might fo=
rce the US to provide a federal level=0D=0A> > URI=0D=0A> > > > > with=0D=0A=
> > > > > > > > proxies that can subsequently do the dereference and lower=0D=
=0A> > level=0D=0A> > > > > > routing=0D=0A> > > > > > > -=0D=0A> > > > > >=
 > > so maybe it's not such a shame. It won't result in access=0D=0A> > > >=
 providers=0D=0A> > > > > > > giving=0D=0A> > > > > > > > free location inf=
ormation until they are ready to do so=0D=0A> > however.=0D=0A> > > > > > >=
 >=0D=0A> > > > > > > > Editorial and a genuine question:=0D=0A> > > > > > =
> >=0D=0A> > > > > > > > IMO, supporting the services URI extension in HELD=
 or adding=0D=0A> > > > > location=0D=0A> > > > > > > > reference support t=
o LoST are both superior engineering=0D=0A> > > solutions.=0D=0A> > > > > >=
 They=0D=0A> > > > > > > > just aren't driven by the punitive motivations o=
f the "hide=0D=0A> by=0D=0A> > > not=0D=0A> > > > > > > hiding"=0D=0A> > > =
> > > > > proposal. Arguments that they are inferior because they=0D=0A> > =
require=0D=0A> > > > > > protocol=0D=0A> > > > > > > > changes are specious=
 and self-fulfilling. That's why the=0D=0A> > > > "reference=0D=0A> > > > >=
 > > query"=0D=0A> > > > > > > > mechanism for LoST was "postponed" in the =
interest of=0D=0A> getting=0D=0A> > > LoST=0D=0A> > > > > > > > finalized. =
It continues to be used as a prop for this=0D=0A> > particular=0D=0A> > > >=
 > > hiding=0D=0A> > > > > > > > proposal. By this line of argument, we wou=
ld never add or=0D=0A> > modify=0D=0A> > > > > > > protocols=0D=0A> > > > >=
 > > > for anything.=0D=0A> > > > > > > >=0D=0A> > > > > > > > It's very di=
fficult not to lapse into sarcasm in this area=0D=0A> (I=0D=0A> > > feel=0D=
=0A> > > > > > like=0D=0A> > > > > > > > saying it's OK not to have locatio=
n hiding because Columbia=0D=0A> > > > > University=0D=0A> > > > > > > and=0D=
=0A> > > > > > > > Cisco are going to underwrite the cost of providing a 5x=
9s=0D=0A> > > > reliable=0D=0A> > > > > > > > ubiquitous location service i=
n all public access networks=0D=0A> out=0D=0A> > of=0D=0A> > > > > pure=0D=0A=
> > > > > > > > philanthropy.... but I won't :) ).=0D=0A> > > > > > > >=0D=0A=
> > > > > > > > Insisting on providing location for all applications is lik=
e=0D=0A> > > > > insisting=0D=0A> > > > > > > > that cellular operators let=
 users call anyone just to ensure=0D=0A> > > that=0D=0A> > > > > they=0D=0A=
> > > > > > > can=0D=0A> > > > > > > > also make emergency calls. In this h=
ypothetical situation,=0D=0A> > > > refusing=0D=0A> > > > > to=0D=0A> > > >=
 > > > > define protocol mechanisms that permit them to distinguish=0D=0A> =
> > between=0D=0A> > > > > the=0D=0A> > > > > > > > scenarios would only re=
sult in there being no cellular=0D=0A> service=0D=0A> > -=0D=0A> > > > or=0D=
=0A> > > > > > just=0D=0A> > > > > > > > publicly funded cellular services.=
 It's a counter-productive=0D=0A> > > > > attitude.=0D=0A> > > > > > > >=0D=
=0A> > > > > > > > This provides the opportunity for me to once more ask a=0D=
=0A> > question=0D=0A> > > > > that=0D=0A> > > > > > > > hasn't been respon=
ded to in the past. Why is ECRIT=0D=0A> describing=0D=0A> > a=0D=0A> > > > =
> > solution=0D=0A> > > > > > > > that has the VSP involved in the emergenc=
y call at all=3F Why=0D=0A> > > would=0D=0A> > > > > the=0D=0A> > > > > > >=
 VSP=0D=0A> > > > > > > > want to be involved in emergency calls - and why =
would the=0D=0A> > > caller=0D=0A> > > > > want=0D=0A> > > > > > > > them i=
nvolved=3F It seems to be not in the interest of either=0D=0A> > > party.=0D=
=0A> > > > > > > There's=0D=0A> > > > > > > > already an interim architectu=
re for the non "end-to-end IP"=0D=0A> > > > scenario=0D=0A> > > > > > > > c=
alled i2. In any circumstance where any of the device, the=0D=0A> > > > net=
work,=0D=0A> > > > > > or=0D=0A> > > > > > > > emergency operator are not E=
CRIT-capable, then the VSP does=0D=0A> > need=0D=0A> > > > to=0D=0A> > > > =
> be=0D=0A> > > > > > > > involved and i2 is a valid fallback.=0D=0A> > > >=
 > > > >=0D=0A> > > > > > > > Cheers,=0D=0A> > > > > > > > Martin=0D=0A> > =
> > > > > >=0D=0A> > > > > > > > -----Original Message-----=0D=0A> > > > > =
> > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > > >=
 > > > Sent: Saturday, 8 December 2007 8:56 AM=0D=0A> > > > > > > > To: Sta=
rk, Barbara=0D=0A> > > > > > > > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > =
> > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art=0D=
=0A> > > > > > > >=0D=0A> > > > > > > > Translation: You have more lobbyist=
s than I (or the IETF),=0D=0A> so=0D=0A> > > give=0D=0A> > > > > me.=0D=0A>=
 > > > > > > > Thanks for clarifying that.=0D=0A> > > > > > > >=0D=0A> > > =
> > > > > Henning=0D=0A> > > > > > > >=0D=0A> > > > > > > > On Dec 7, 2007,=
 at 4:24 PM, Stark, Barbara wrote:=0D=0A> > > > > > > >=0D=0A> > > > > > > =
> > [The following statements are my opinion, and should not=0D=0A> be=0D=0A=
> > > > > > > > > attributed to the company I work for.]=0D=0A> > > > > > >=
 > >=0D=0A> > > > > > > > > Henning,=0D=0A> > > > > > > > > It's true that =
the IETF doesn't have to do something just=0D=0A> > > > because=0D=0A> > > =
> > > > > > someone wants it. It's also true that the IETF has no=0D=0A> > =
> authority=0D=0A> > > > or=0D=0A> > > > > > > > > ability to force impleme=
ntation of RFCs by companies who=0D=0A> > > refuse=0D=0A> > > > to=0D=0A> >=
 > > > > > > > implement them. You cannot shove a solution down the=0D=0A> =
throats=0D=0A> > > of=0D=0A> > > > > > > > > access providers that they are=
 unwilling to buy in to. In=0D=0A> my=0D=0A> > > > > > > > > opinion, even =
attempting to do so would be, well,=0D=0A> unethical.=0D=0A> > > > > > > > =
>=0D=0A> > > > > > > > > So, you have a choice:=0D=0A> > > > > > > > > 1) c=
reate a solution that you like that major stakeholders=0D=0A> > are=0D=0A> =
> > > > > > > > unwilling to implement=0D=0A> > > > > > > > > 2) create a s=
olution that you don't quite like, but that's=0D=0A> > > > better=0D=0A> > =
> > > > > > > than what we have today, and which major stakeholders are=0D=0A=
> > > > willing=0D=0A> > > > > to=0D=0A> > > > > > > > > implement=0D=0A> >=
 > > > > > > >=0D=0A> > > > > > > > > Believe it or not, major telecom comp=
anies in the US and=0D=0A> > > Europe=0D=0A> > > > > put=0D=0A> > > > > > >=
 > > a lot of effort into lobbying regulatory bodies, to=0D=0A> achieve=0D=0A=
> > > > > > > > > desirable outcomes. The IETF doesn't put in such effort.=0D=
=0A> If=0D=0A> > > you=0D=0A> > > > > want=0D=0A> > > > > > > > > to make a=
 go at pushing through a solution that=0D=0A> stakeholders=0D=0A> > > in=0D=
=0A> > > > > > > > > these regions are set against, and see if you can get=0D=
=0A> > > regulatory=0D=0A> > > > > > > > > agencies to bless it, then go fo=
r it. I think the odds are=0D=0A> > > > stacked=0D=0A> > > > > > > > > agai=
nst you, though. Especially since there are workable=0D=0A> > > > solutions=0D=
=0A> > > > > > > > > that these companies have said they would be willing t=
o=0D=0A> > > accept.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > Here is =
why mobile access providers "cannot" provide the=0D=0A> > best=0D=0A> > > >=
 > > > > > available location directly to end user devices: They=0D=0A> don=
't=0D=0A> > > want=0D=0A> > > > > to.=0D=0A> > > > > > > > > At this point =
in time, it's their network, their data, and=0D=0A> > > their=0D=0A> > > > =
> > > > > choice.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > In free mar=
ket economies, you generally have to be able to=0D=0A> > > > *prove*=0D=0A>=
 > > > > > > > > (and not just say it without proof) massive benefit or=0D=0A=
> > massive=0D=0A> > > > > harm=0D=0A> > > > > > > > > before you can force=
 companies to do what they don't want=0D=0A> to=0D=0A> > > do,=0D=0A> > > >=
 > > > > > through regulation. Again, if you think you can take on=0D=0A> t=
hat=0D=0A> > > > > battle=0D=0A> > > > > > > > > and win, go for it.=0D=0A>=
 > > > > > > > >=0D=0A> > > > > > > > > I, for one, believe that not provid=
ing the "real" location=0D=0A> > > value=0D=0A> > > > > to=0D=0A> > > > > >=
 > > > end devices would not cause such benefit or harm. If users=0D=0A> > =
> want=0D=0A> > > > to=0D=0A> > > > > > > > > know what location PSAPs get =
on their behalf, and=0D=0A> regulators=0D=0A> > > > > believe=0D=0A> > > > =
> > > > > such a capability is needed, then we can let the phonebcp-=0D=0A>=
 > > > > described=0D=0A> > > > > > > > > test mechanism voice it back over=
 the voice medium (this=0D=0A> > would=0D=0A> > > > > only=0D=0A> > > > > >=
 > > > work for civic), or return a JPEG map with a dot on it.=0D=0A> This=0D=
=0A> > > > would=0D=0A> > > > > > > > > provide location in a format that's=
 usable by a human=0D=0A> being,=0D=0A> > > but=0D=0A> > > > > not=0D=0A> >=
 > > > > > > > an application. Or maybe, in some countries, the=0D=0A> regu=
lators=0D=0A> > do=0D=0A> > > > > > > > > require access providers to give =
out the best possible=0D=0A> > > location=0D=0A> > > > > > > > > values to =
end devices. But it's really improbable that you=0D=0A> > > could=0D=0A> > =
> > > > > > > force the regulators of all countries to see things your=0D=0A=
> > way.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > But, this is all jus=
t my opinion.=0D=0A> > > > > > > > > Barbara=0D=0A> > > > > > > > >=0D=0A> =
> > > > > > > > -----Original Message-----=0D=0A> > > > > > > > > From: Hen=
ning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > > > > > > > Sent: =
Friday, December 07, 2007 12:13 PM=0D=0A> > > > > > > > > To: Liess, Laura=0D=
=0A> > > > > > > > > Cc: ecrit@ietf.org=0D=0A> > > > > > > > > Subject: Re:=
 AW: [Ecrit] Location Hiding -- State of the=0D=0A> Art=0D=0A> > > > > > > =
> >=0D=0A> > > > > > > > > Laura,=0D=0A> > > > > > > > >=0D=0A> > > > > > >=
 > > just because somebody says "we need it" doesn't make it an=0D=0A> > > =
IETF=0D=0A> > > > > > > > > requirement. Please justify why mobile access c=
annot=0D=0A> provide=0D=0A> > > > > > locations=0D=0A> > > > > > > > > to e=
nd users.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > Henning=0D=0A> > > =
> > > > > >=0D=0A> > > > > > > > > On Dec 6, 2007, at 10:10 PM, Liess, Laur=
a wrote:=0D=0A> > > > > > > > >=0D=0A> > > > > > > > >> Brian,=0D=0A> > > >=
 > > > > >>=0D=0A> > > > > > > > >> I checked with my company and we need L=
H for both civic=0D=0A> and=0D=0A> > > geo=0D=0A> > > > > for=0D=0A> > > > =
> > > > >> fixed and mobile access. Only DSL and civic is not an=0D=0A> > o=
ption.=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >> I would support send=
ing the ESRP/PSAP URI to the UA, as=0D=0A> > > > proposed=0D=0A> > > > > by=0D=
=0A> > > > > > > > >> Barbara and James some weeks ago.=0D=0A> > > > > > > =
> >>=0D=0A> > > > > > > > >> Laura=0D=0A> > > > > > > > >>=0D=0A> > > > > >=
 > > >>=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >> -----Urspr=FCnglich=
e Nachricht-----=0D=0A> > > > > > > > >> Von: Brian Rosen [mailto:br@brianr=
osen.net]=0D=0A> > > > > > > > >> Gesendet: Dienstag, 4. Dezember 2007 16:3=
7=0D=0A> > > > > > > > >> An: 'Hannes Tschofenig'=0D=0A> > > > > > > > >> C=
c: 'ECRIT'=0D=0A> > > > > > > > >> Betreff: RE: [Ecrit] Location Hiding -- =
State of the Art=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >> Proposed t=
ext for framework=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >> Some acce=
ss networks wish to restrict who can get a high=0D=0A> > > > quality=0D=0A>=
 > > > > > > > >> location,=0D=0A> > > > > > > > >> possibly based on a pay=
ment arrangement.  For emergency=0D=0A> > > calls,=0D=0A> > > > > high=0D=0A=
> > > > > > > > >> quality=0D=0A> > > > > > > > >> location must be provide=
d.  An access network can=0D=0A> > reasonably=0D=0A> > > be=0D=0A> > > > > =
> > > >> expected to=0D=0A> > > > > > > > >> have a relationship with the P=
SAPs in its catchment area,=0D=0A> > so=0D=0A> > > > > giving=0D=0A> > > > =
> > > > >> location=0D=0A> > > > > > > > >> to the PSAP will be straightfor=
ward=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >=
> However, an endpoint may need location=0D=0A> > > > > > > > >> for routin=
g, and a proxy may need to verify that a=0D=0A> > purported=0D=0A> > > > > =
> > > >> emergency call=0D=0A> > > > > > > > >> is targeted at a bona fide =
PSAP.  To do so, it may take=0D=0A> the=0D=0A> > > > > > location=0D=0A> > =
> > > > > > >> passed=0D=0A> > > > > > > > >> with the call and query LoST =
to confirm that the URI is=0D=0A> > > > genuine.=0D=0A> > > > > > > > >> "H=
iding"=0D=0A> > > > > > > > >> location interferes with this check.  To ach=
ieve location=0D=0A> > > > hiding,=0D=0A> > > > > > > > >> the LIS=0D=0A> >=
 > > > > > > >> can return a coarse location which is good enough to=0D=0A>=
 elicit=0D=0A> > > the=0D=0A> > > > > > same=0D=0A> > > > > > > > >> respon=
se from LoST as the actual location would.  The=0D=0A> > > endpoint=0D=0A> =
> > > > and=0D=0A> > > > > > > > >> the proxy=0D=0A> > > > > > > > >> can u=
se this location to route and verify.  A suitable=0D=0A> > > location=0D=0A=
> > > > > for=0D=0A> > > > > > > > >> a geo is=0D=0A> > > > > > > > >> a po=
lygon calculated by intersecting the service=0D=0A> boundaries=0D=0A> > > o=
f=0D=0A> > > > > all=0D=0A> > > > > > > > >> of the=0D=0A> > > > > > > > >>=
 emergency services that respond to the actual location.=0D=0A> A=0D=0A> > =
> > > suitable=0D=0A> > > > > > > > >> location=0D=0A> > > > > > > > >> for=
 a civic is any civic location within the intersection=0D=0A> > of=0D=0A> >=
 > > the=0D=0A> > > > > > > > >> service=0D=0A> > > > > > > > >> boundaries=
 of emergency services.  In a great many cases,=0D=0A> a=0D=0A> > > > > cou=
ntry=0D=0A> > > > > > > > >> code is=0D=0A> > > > > > > > >> sufficient.  I=
n others a state/province or a city name is=0D=0A> > > > > > > > >> suffici=
ent.  Of=0D=0A> > > > > > > > >> course, the LIS would always return a loca=
tion reference,=0D=0A> > > which=0D=0A> > > > > > > > >> would return=0D=0A=
> > > > > > > > >> high quality location for a PSAP and coarse location to=0D=
=0A> the=0D=0A> > > > > > endpoint=0D=0A> > > > > > > > >> or any=0D=0A> > =
> > > > > > >> proxy unknown to the LIS.=0D=0A> > > > > > > > >>=0D=0A> > >=
 > > > > > >> Proposed text for phonebcp:=0D=0A> > > > > > > > >>=0D=0A> > =
> > > > > > >> A LIS who wishes to hide location returns a location=0D=0A> =
> > reference.=0D=0A> > > > > > When=0D=0A> > > > > > > > >> dereferenced b=
y the endpoint or proxy:=0D=0A> > > > > > > > >> 1. For LIS's returning geo=
:=0D=0A> > > > > > > > >>   For each location served by the LIS, compute th=
e=0D=0A> > > intersection=0D=0A> > > > > of=0D=0A> > > > > > > > >> the=0D=0A=
> > > > > > > > >>   service boundaries for all emergency services known to=0D=
=0A> > LoST=0D=0A> > > > for=0D=0A> > > > > > the=0D=0A> > > > > > > > >>  =
 location. Return the resulting polygon, or any point in=0D=0A> > the=0D=0A=
> > > > > > > > >> polygon as=0D=0A> > > > > > > > >>   the value during a =
dereference=0D=0A> > > > > > > > >> 2. For LIS's returning civic:=0D=0A> > =
> > > > > > >>   Determine a civic location which is within the service=0D=0A=
> > > > boundary=0D=0A> > > > > > > > >> of all=0D=0A> > > > > > > > >>   e=
mergency services known to LoST for the location.  In=0D=0A> a=0D=0A> > > >=
 great=0D=0A> > > > > > many=0D=0A> > > > > > > > >>   cases, this will be =
a country code, province/state or=0D=0A> > city.=0D=0A> > > > > > > > >> Re=
turn this=0D=0A> > > > > > > > >>   coarse civic location as the value duri=
ng a dereference=0D=0A> > > > > > > > >> Note that the service boundaries r=
eturned from LoST have=0D=0A> a=0D=0A> > > TTL,=0D=0A> > > > > the=0D=0A> >=
 > > > > > > >> intersections MUST recalculated if the service boundary=0D=0A=
> > > > changes.=0D=0A> > > > > > > > >> The LIS=0D=0A> > > > > > > > >> MU=
ST return high quality location to a PSAP or ESRP.=0D=0A> > > > > > > > >>=0D=
=0A> > > > > > > > >> Brian=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >>=
> -----Original Message-----=0D=0A> > > > > > > > >>> From: Hannes Tschofen=
ig=0D=0A> [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > > > > > > > >>> Sent:=
 Monday, December 03, 2007 1:38 PM=0D=0A> > > > > > > > >>> To: Brian Rosen=0D=
=0A> > > > > > > > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'=0D=0A=
> > > > > > > > >>> Subject: Re: [Ecrit] Location Hiding -- State of the Ar=
t=0D=0A> > > > > > > > >>>=0D=0A> > > > > > > > >>> Hi Brian,=0D=0A> > > > =
> > > > >>>=0D=0A> > > > > > > > >>> Brian Rosen wrote:=0D=0A> > > > > > > =
> >>>> It's fine with me if there is a separate doc, but=0D=0A> > framework=0D=
=0A> > > > and=0D=0A> > > > > > > > >>>> phonebcp=0D=0A> > > > > > > > >>>>=
 have to reference it.=0D=0A> > > > > > > > >>>>=0D=0A> > > > > > > > >>> A=
re we talking about informative or normative=0D=0A> references=3F=0D=0A> > =
> > > > > > >>>> I think it can be solved with a one paragraph=0D=0A> descr=
iption=0D=0A> > > of=0D=0A> > > > > the=0D=0A> > > > > > > > >>>> problem=0D=
=0A> > > > > > > > >>> in=0D=0A> > > > > > > > >>>> framework and a one par=
agraph solution in phonebcp, but=0D=0A> > if=0D=0A> > > > > there=0D=0A> > =
> > > > > > >>>> is a=0D=0A> > > > > > > > >>>> separate doc and a referenc=
e, I will be happy.=0D=0A> > > > > > > > >>>>=0D=0A> > > > > > > > >>> That=
 does not make sense.=0D=0A> > > > > > > > >>> The solution is not one para=
graph and the text in phone=0D=0A> > bcp=0D=0A> > > is=0D=0A> > > > > > > >=
 >>> normative.=0D=0A> > > > > > > > >>>=0D=0A> > > > > > > > >>> Ciao=0D=0A=
> > > > > > > > >>> Hannes=0D=0A> > > > > > > > >>>=0D=0A> > > > > > > > >>=
>> Brian=0D=0A> > > > > > > > >>>>=0D=0A> > > > > > > > >>>>=0D=0A> > > > >=
 > > > >>>>> -----Original Message-----=0D=0A> > > > > > > > >>>>> From: Ja=
mes M. Polk [mailto:jmpolk@cisco.com]=0D=0A> > > > > > > > >>>>> Sent: Mond=
ay, December 03, 2007 7:37 PM=0D=0A> > > > > > > > >>>>> To: Stark, Barbara=
; Hannes Tschofenig; ECRIT=0D=0A> > > > > > > > >>>>> Subject: RE: [Ecrit] =
Location Hiding -- State of the=0D=0A> Art=0D=0A> > > > > > > > >>>>>=0D=0A=
> > > > > > > > >>>>> Currently, the WG (and document editors!) should be=0D=
=0A> > > > operating=0D=0A> > > > > > > > >>>>> under=0D=0A> > > > > > > > =
>>>>> the consensus direction that Location Hiding *not* be=0D=0A> in=0D=0A=
> > > > > > PhoneBCP=0D=0A> > > > > > > > >>>>> or=0D=0A> > > > > > > > >>>=
>> Framework.  This was a clear consensus call in Chicago=0D=0A> -=0D=0A> >=
 > and=0D=0A> > > > > not=0D=0A> > > > > > > > >>>>> by=0D=0A> > > > > > > =
> >>>>> default, but by most people voicing actively against=0D=0A> > > hav=
ing=0D=0A> > > > > this=0D=0A> > > > > > > > >>>>> Hiding in either core EC=
RIT documents, and I haven't=0D=0A> yet=0D=0A> > > > > talked=0D=0A> > > > =
> > to=0D=0A> > > > > > > > >>>>> anyone here in Vancouver that thinks othe=
rwise.=0D=0A> > > > > > > > >>>>>=0D=0A> > > > > > > > >>>>> Location Hidin=
g is something that needs to be=0D=0A> addressed=0D=0A> > BY=0D=0A> > > > >=
 > ITSELF=0D=0A> > > > > > > > >>>>> (i.e., in its own doc) so everyone can=
 focus on the=0D=0A> > > singular=0D=0A> > > > > > > > >>>>> topic,=0D=0A> =
> > > > > > > >>>>> and work towards not talking past each other (not like=0D=
=0A> > > > that's=0D=0A> > > > > > > > >>>>> happened before in ECRIT....  =
:-/=0D=0A> > > > > > > > >>>>>=0D=0A> > > > > > > > >>>>> Who disagrees wit=
h this=3F=0D=0A> > > > > > > > >>>>>=0D=0A> > > > > > > > >>>>> BTW - if so=
meone thinks Location Hiding should be put=0D=0A> > back=0D=0A> > > > > int=
o=0D=0A> > > > > > > > >>>>> PhoneBCP or Framework, then they can attempt t=
o gain=0D=0A> WG=0D=0A> > > > > > consensus=0D=0A> > > > > > > > >>>>> on=0D=
=0A> > > > > > > > >>>>> that, but that's different than a direction of thi=
s=0D=0A> > > > > > inevitability=0D=0A> > > > > > > > >>>>> or=0D=0A> > > >=
 > > > > >>>>> that there is not consensus on this.=0D=0A> > > > > > > > >>=
>>>=0D=0A> > > > > > > > >>>>>=0D=0A> > > > > > > > >>>>> At 07:23 AM 12/3/=
2007, Stark, Barbara wrote:=0D=0A> > > > > > > > >>>>>=0D=0A> > > > > > > >=
 >>>>>> If people felt this was good enough so that access=0D=0A> > > > pro=
viders=0D=0A> > > > > > > > >>>>>> would not=0D=0A> > > > > > > > >>>>>> ne=
ed to be required to build the infrastructure to=0D=0A> > > provide=0D=0A> =
> > > > > > > >>>>>> location=0D=0A> > > > > > > > >>>>>> (because people c=
ould use this method instead of=0D=0A> > getting=0D=0A> > > > > > > > >>>>>=
> location from=0D=0A> > > > > > > > >>>>>> access providers), then locatio=
n hiding would be=0D=0A> dead.=0D=0A> > If=0D=0A> > > > > > people=0D=0A> >=
 > > > > > > >>>>>> still=0D=0A> > > > > > > > >>>>>> want to place a requi=
rement on access providers to=0D=0A> > > provide=0D=0A> > > > > > > > >>>>>=
> location,=0D=0A> > > > > > > > >>>>>> then location hiding is not dead.=0D=
=0A> > > > > > > > >>>>>> Barbara=0D=0A> > > > > > > > >>>>>>=0D=0A> > > > =
> > > > >>>>>> -----Original Message-----=0D=0A> > > > > > > > >>>>>> From:=
 Hannes Tschofenig=0D=0A> > > [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > >=
 > > > > > >>>>>> Sent: Saturday, December 01, 2007 3:34 PM=0D=0A> > > > > =
> > > >>>>>> To: ECRIT=0D=0A> > > > > > > > >>>>>> Subject: [Ecrit] Locatio=
n Hiding -- State of the Art=0D=0A> > > > > > > > >>>>>>=0D=0A> > > > > > >=
 > >>>>>> I thought that the following article would be of=0D=0A> > interes=
t=0D=0A> > > > for=0D=0A> > > > > > > > >>>>>> you:=0D=0A> > > > > > > > >>=
>>>> http://googleblog.blogspot.com/2007/11/lost-no-=0D=0A> > found.html=0D=
=0A> > > > > > > > >>>>>>=0D=0A> > > > > > > > >>>>>> Here is text from=0D=0A=
> > > > > > > > >>>>>> http://googlemobile.blogspot.com/2007/11/new-magical=
-=0D=0A> > > blue-=0D=0A> > > > > > circle-=0D=0A> > > > > > > > on-=0D=0A>=
 > > > > > > > >>> your=0D=0A> > > > > > > > >>>>>> -map.html=0D=0A> > > > =
> > > > >>>>>> "=0D=0A> > > > > > > > >>>>>> My Location is a new beta tech=
nology from Google that=0D=0A> > > uses=0D=0A> > > > > cell=0D=0A> > > > > =
> > > >>>>>> tower=0D=0A> > > > > > > > >>>>>> identification to provide yo=
u with approximate=0D=0A> location=0D=0A> > > > > > > > >>>>>> information,=0D=
=0A> > > > > > > > >>> so=0D=0A> > > > > > > > >>>>>> it will work on phone=
s without GPS.=0D=0A> > > > > > > > >>>>>> "=0D=0A> > > > > > > > >>>>>> No=
te that this stuff is not really new technology. It=0D=0A> > > > existed=0D=
=0A> > > > > > > > >>>>>> already=0D=0A> > > > > > > > >>>>>> for some time=
 but the availability of GPS devices=0D=0A> made=0D=0A> > it=0D=0A> > > > >=
 > > > >>>>>> possible to=0D=0A> > > > > > > > >>>>>> setup the database in=
 a more efficient way.=0D=0A> > > > > > > > >>>>>>=0D=0A> > > > > > > > >>>=
>>> Anyway, this mechanism allows you to obtain location=0D=0A> > > > > > i=
nformation=0D=0A> > > > > > > > >>>>>> with=0D=0A> > > > > > > > >>>>>> you=
r cell phone (using the cell id) without=0D=0A> interacting=0D=0A> > > > wi=
th=0D=0A> > > > > > the=0D=0A> > > > > > > > >>>>>> cellular operator.=0D=0A=
> > > > > > > > >>>>>> In short: operator cannot charge for location=0D=0A>=
 > > > > > > > >>>>>>=0D=0A> > > > > > > > >>>>>> While the location inform=
ation is not really useful=0D=0A> for=0D=0A> > > > first=0D=0A> > > > > > >=
 > >>> responders=0D=0A> > > > > > > > >>>>>>=0D=0A> > > > > > > > >>>>>> i=
t is still good enough for finding the closest PSAP.=0D=0A> > > > > > > > >=
>>>>>=0D=0A> > > > > > > > >>>>>> Is this the dead of location hiding=3F=0D=
=0A> > > > > > > > >>>>>>=0D=0A> > > > > > > > >>>>>> Ciao=0D=0A> > > > > >=
 > > >>>>>> Hannes=0D=0A> > > > > > > > >>>>>>=0D=0A> > > > > > > > >>>>>>=0D=
=0A> > > > > > > > >>>>>> _______________________________________________=0D=
=0A> > > > > > > > >>>>>> Ecrit mailing list=0D=0A> > > > > > > > >>>>>> Ec=
rit@ietf.org=0D=0A> > > > > > > > >>>>>> https://www1.ietf.org/mailman/list=
info/ecrit=0D=0A> > > > > > > > >>>>>>=0D=0A> > > > > > > > >>>>>> ________=
_______________________________________=0D=0A> > > > > > > > >>>>>> Ecrit m=
ailing list=0D=0A> > > > > > > > >>>>>> Ecrit@ietf.org=0D=0A> > > > > > > >=
 >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > > > > > >=
>>>>>=0D=0A> > > > > > > > >>>>> __________________________________________=
_____=0D=0A> > > > > > > > >>>>> Ecrit mailing list=0D=0A> > > > > > > > >>=
>>> Ecrit@ietf.org=0D=0A> > > > > > > > >>>>> https://www1.ietf.org/mailman=
/listinfo/ecrit=0D=0A> > > > > > > > >>>>>=0D=0A> > > > > > > > >>=0D=0A> >=
 > > > > > > >>=0D=0A> > > > > > > > >> ___________________________________=
____________=0D=0A> > > > > > > > >> Ecrit mailing list=0D=0A> > > > > > > =
> >> Ecrit@ietf.org=0D=0A> > > > > > > > >> https://www1.ietf.org/mailman/l=
istinfo/ecrit=0D=0A> > > > > > > > >>=0D=0A> > > > > > > > >> _____________=
__________________________________=0D=0A> > > > > > > > >> Ecrit mailing li=
st=0D=0A> > > > > > > > >> Ecrit@ietf.org=0D=0A> > > > > > > > >> https://w=
ww1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > > > > > >=0D=0A> > > > > >=
 > > >=0D=0A> > > > > > > > > _____________________________________________=
__=0D=0A> > > > > > > > > Ecrit mailing list=0D=0A> > > > > > > > > Ecrit@i=
etf.org=0D=0A> > > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=
=0A> > > > > > > > >=0D=0A> > > > > > > > > *****=0D=0A> > > > > > > > >=0D=
=0A> > > > > > > > > The information transmitted is intended only for the=0D=
=0A> person=0D=0A> > or=0D=0A> > > > > > > > > entity to which it is addres=
sed and may contain=0D=0A> > confidential,=0D=0A> > > > > > > > > proprieta=
ry, and/or privileged material. Any review,=0D=0A> > > > > retransmission,=0D=
=0A> > > > > > > > > dissemination or other use of, or taking of any action=
 in=0D=0A> > > > reliance=0D=0A> > > > > > > > > upon this information by p=
ersons or entities other than=0D=0A> the=0D=0A> > > > > intended=0D=0A> > >=
 > > > > > > recipient is prohibited. If you received this in error,=0D=0A>=
 > please=0D=0A> > > > > > > > > contact the sender and delete the material=
 from all=0D=0A> > computers.=0D=0A> > > > > GA622=0D=0A> > > > > > > > >=0D=
=0A> > > > > > > > >=0D=0A> > > > > > > >=0D=0A> > > > > > > >=0D=0A> > > >=
 > > > > _______________________________________________=0D=0A> > > > > > >=
 > Ecrit mailing list=0D=0A> > > > > > > > Ecrit@ietf.org=0D=0A> > > > > > =
> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > > > > >=0D=0A=
> > > > > > > > -----------------------------------------------------------=
-=0D=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A> > > > --=0D=0A> > > > > --=0D=0A=
> > > > > > --=0D=0A> > > > > > > --=0D=0A> > > > > > > > -----------------=
-----=0D=0A> > > > > > > > This message is for the designated recipient onl=
y and may=0D=0A> > > > > > > > contain privileged, proprietary, or otherwis=
e private=0D=0A> > > information.=0D=0A> > > > > > > > If you have received=
 it in error, please notify the sender=0D=0A> > > > > > > > immediately and=
 delete the original.  Any unauthorized use=0D=0A> of=0D=0A> > > > > > > > =
this email is prohibited.=0D=0A> > > > > > > > ----------------------------=
--------------------------------=0D=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A>=
 > > > --=0D=0A> > > > > --=0D=0A> > > > > > --=0D=0A> > > > > > > --=0D=0A=
> > > > > > > > ----------------------=0D=0A> > > > > > > > [mf2]=0D=0A> > =
> > > > > >=0D=0A> > > > > > > >=0D=0A> > > > > > > > _____________________=
__________________________=0D=0A> > > > > > > > Ecrit mailing list=0D=0A> >=
 > > > > > > Ecrit@ietf.org=0D=0A> > > > > > > > https://www1.ietf.org/mail=
man/listinfo/ecrit=0D=0A> > > > > > >=0D=0A> > > > > > >=0D=0A> > > > > > >=
 _______________________________________________=0D=0A> > > > > > > Ecrit m=
ailing list=0D=0A> > > > > > > Ecrit@ietf.org=0D=0A> > > > > > > https://ww=
w1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > > >=0D=0A> > > > > > ------=
----------------------------------------------------------=0D=0A> --=0D=0A>=
 > --=0D=0A> > > --=0D=0A> > > > --=0D=0A> > > > > --=0D=0A> > > > > > ----=
------------------=0D=0A> > > > > > This message is for the designated reci=
pient only and may=0D=0A> > > > > > contain privileged, proprietary, or oth=
erwise private=0D=0A> information.=0D=0A> > > > > > If you have received it=
 in error, please notify the sender=0D=0A> > > > > > immediately and delete=
 the original.  Any unauthorized use of=0D=0A> > > > > > this email is proh=
ibited.=0D=0A> > > > > > --------------------------------------------------=
--------------=0D=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A> > > > --=0D=0A> >=
 > > > --=0D=0A> > > > > > ----------------------=0D=0A> > > > > > [mf2]=0D=
=0A> > > > >=0D=0A> > > >=0D=0A> > > > ------------------------------------=
--------------------------------=0D=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A>=
 > > > ----------------------=0D=0A> > > > This message is for the designat=
ed recipient only and may=0D=0A> > > > contain privileged, proprietary, or =
otherwise private information.=0D=0A> > > > If you have received it in erro=
r, please notify the sender=0D=0A> > > > immediately and delete the origina=
l.  Any unauthorized use of=0D=0A> > > > this email is prohibited.=0D=0A> >=
 > > --------------------------------------------------------------------=0D=
=0A> --=0D=0A> > --=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A=
> > > > [mf2]=0D=0A> > >=0D=0A> >=0D=0A> > --------------------------------=
----------------------------------------=0D=0A> --=0D=0A> > ---------------=
-------=0D=0A> > This message is for the designated recipient only and may=0D=
=0A> > contain privileged, proprietary, or otherwise private information.=0D=
=0A> > If you have received it in error, please notify the sender=0D=0A> > =
immediately and delete the original.  Any unauthorized use of=0D=0A> > this=
 email is prohibited.=0D=0A> > --------------------------------------------=
----------------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A=
> > [mf2]=0D=0A>=20=0D=0A=0D=0A--------------------------------------------=
----------------------------------------------------=0D=0AThis message is f=
or the designated recipient only and may=0D=0Acontain privileged, proprieta=
ry, or otherwise private information. =20=0D=0AIf you have received it in e=
rror, please notify the sender=0D=0Aimmediately and delete the original.  A=
ny unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------------=
---------------------------------------------------------------------------=
-----=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 13:31:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1nPi-0004Jj-6w; Mon, 10 Dec 2007 13:31:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nPh-0004Jd-CD
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:31:33 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1nPg-0008Fz-Ve
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:31:33 -0500
X-SEF-Processed: 5_0_0_910__2007_12_10_12_42_36
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, 10 Dec 2007 12:42:36 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 12:31:32 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 12:31:37 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7WB2Q0+TYzJyFSh2eWU2o7COTYwAAmu5Q
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p> 
From: "Winterbottom, James" 
To: "Ted Hardie" , "Stark, Barbara" ,
	"Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
X-OriginalArrivalTime: 10 Dec 2007 18:31:32.0659 (UTC)
	FILETIME=[E34C6830:01C83B5A]
X-Spam-Score: 3.1 (+++)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Ted,=0D=0A=0D=0AMy concern here is that we need one solution for location h=
iding. The=0D=0Aproposal that has been tabled in the current ECRIT document=
 is a=0D=0Asolution that does not work for the main requirement of location=
 hiding,=0D=0Awhich is the enablement of value added services. The solution=
 that I=0D=0Ahave proposed works for both, the only issue that has been fla=
gged with=0D=0Ait is a billing issue at the VSP concerning emergency calls,=
 this I=0D=0Abelieve can be worked out later.=0D=0A=0D=0ASo in short answer=
, I am very unhappy with any solution that requires=0D=0Athe LIS to do serv=
ice boundary mappings on-platform.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=
=0A> -----Original Message-----=0D=0A> From: Ted Hardie [mailto:hardie@qual=
comm.com]=0D=0A> Sent: Tuesday, 11 December 2007 5:12 AM=0D=0A> To: Stark, =
Barbara; Brian Rosen; Winterbottom, James; Dawson, Martin;=0D=0A> Henning S=
chulzrinne=0D=0A> Cc: ecrit@ietf.org; Liess, Laura=0D=0A> Subject: RE: AW: =
[Ecrit] Location Hiding -- State of the Art=0D=0A>=20=0D=0A> >=0D=0A> >Admi=
ttedly, this is outside the scope of ecrit. But, since LoST was=0D=0Amade=0D=
=0A> into a generic service URN to URI translator, it would be nice if=0D=0A=
somehow=0D=0A> the LoST protocol could be used to provide devices with URIs=
, even=0D=0Awhen=0D=0A> the device doesn't have its precise location.=0D=0A=
> >=0D=0A> >I think that getting this capability would be very useful and=0D=
=0Adesirable,=0D=0A> but don't think it's as high a priority as getting the=
 emergency=0D=0Aservices=0D=0A> architecture worked out.=0D=0A> >Barbara=0D=
=0A>=20=0D=0A> Let me strongly support the notion that getting into this be=
fore=0D=0Afinishing=0D=0A> the=0D=0A> emergency services work is not desira=
ble.  There are several potential=0D=0A> issues=0D=0A> here (the most promi=
nent being whether re-using the service urn=0D=0Anamespace=0D=0A> for servi=
ces will work for non-jurisdictionally derived catchement=0D=0Aareas).=0D=0A=
> I think it is far enough outside the realm of ECRIT that boffing the=0D=0A=
work=0D=0A> as a Lost extensions wg would be desirable.=0D=0A>=20=0D=0A> In=
 the short term, doing location hiding sufficient for emergency=0D=0Aservic=
es=0D=0A> is the item under discussion.  Does anyone believe Brian's text d=
oes=0D=0Anot=0D=0A> work for this point=3F=0D=0A>=20=0D=0A> =09=09=09regard=
s,=0D=0A> =09=09=09=09Ted=0D=0A=0D=0A--------------------------------------=
----------------------------------------------------------=0D=0AThis messag=
e is for the designated recipient only and may=0D=0Acontain privileged, pro=
prietary, or otherwise private information. =20=0D=0AIf you have received i=
t in error, please notify the sender=0D=0Aimmediately and delete the origin=
al.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------=
---------------------------------------------------------------------------=
-----------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 13:38:16 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1nWB-0003dt-U3; Mon, 10 Dec 2007 13:38:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nWA-0003dk-BM
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:38:14 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1nW7-0003Ve-25
	for ecrit@ietf.org; Mon, 10 Dec 2007 13:38:14 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J1nVy-0004QI-Q0; Mon, 10 Dec 2007 12:38:03 -0600
From: "Brian Rosen" 
To: "'Stark, Barbara'" ,
	"'Winterbottom, James'" ,
	"'Dawson, Martin'" ,
	"'Henning Schulzrinne'" 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p>
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 13:38:06 -0500
Message-ID: <044a01c83b5b$d0270520$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crexc41p>
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAAZp/sAAAagkQAABDxoAAAFPxMAAAKBBgAABJjLAAAoF9AAABSQGA
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3eec21359cc773323f0aab45cb0596af
Cc: ecrit@ietf.org, "'Liess, Laura'" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

You mean that the VSP wants to route a call to =
urn:service:pizza.pizza-hut?

He gives that urn to his customer.  His customer doesn't directly use =
LoST
(he can't use the emergency LoST server, and in any event, the LoST =
server
known to the access provider isn't going to necessarily get him to the =
VSP).

So the URN is sent in Request URI along with the location reference.  =
The
VSP fields it, dereferences it, routes it, and sends the call onward.
Pizza-Hut may have to be authorized separately to get a dispatch =
location.

Brian

> -----Original Message-----
> From: Stark, Barbara [mailto:bs7652@att.com]
> Sent: Monday, December 10, 2007 12:53 PM
> To: Brian Rosen; Winterbottom, James; Dawson, Martin; Henning =
Schulzrinne
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> I think I understand what James is saying.
>=20
> Let's say that a VSP has contracted with an access provider to be =
allowed
> to dereference location for its subscribers.
>=20
> A device gets a location reference from the access provider, publishes =
it
> to the VSP's presence server; and the VSP dereferences the location.
>=20
> The VSP would like to contract with a pizza delivery business to allow =
its
> subscribers to easily order pizza, from anywhere, by telling the =
device
> the URL associated with a pizza service, based on the device location.
>=20
> The VSP has all the info it needs to provide this service, since it =
was
> able to dereference the LbyR. But there's no standard way for the VSP =
to
> tell the device what that pizza service URL is, for the device's =
location.
> And the VSP isn't allowed to tell the device what the device's real
> location value is, because that's not allowed under the agreement with =
the
> access provider.
>=20
> Or it could be that an access provider would like to contract with =
various
> companies to provide routing information for specific service URNs. =
The
> access provider wants to provide the routing info, but not the =
location to
> devices. Again, there's no protocol for this.
>=20
> Admittedly, this is outside the scope of ecrit. But, since LoST was =
made
> into a generic service URN to URI translator, it would be nice if =
somehow
> the LoST protocol could be used to provide devices with URIs, even =
when
> the device doesn't have its precise location.
>=20
> I think that getting this capability would be very useful and =
desirable,
> but don't think it's as high a priority as getting the emergency =
services
> architecture worked out.
> Barbara
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Monday, December 10, 2007 11:26 AM
> To: 'Winterbottom, James'; 'Dawson, Martin'; 'Henning Schulzrinne'; =
Stark,
> Barbara
> Cc: ecrit@ietf.org; 'Liess, Laura'
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> James, we're not communicating.
>=20
> Coarse location is only given to entities who the LIS doesn't want to =
give
> real location.  It's good enough to route and validate emergency =
calls,
> and
> not good for anything else.  It's not supposed to be useful for =
anything
> else.
>=20
> The LIS can give high quality location to anyone it wishes to, which =
will
> work for "real" location based services.  Specifically, if it wishes =
some
> entity to be able to route other services, it can give it high quality
> location.   That entity can control which services get routed under
> whatever
> terms the LIS is willing to give it high quality location.
>=20
> No one, so far, has created a requirement that some non-authorized =
entity
> has to be able to provide some form of location based service (such as
> routing based on location) without having some kind of authorization =
or
> credentials from the LIS for such purposes.  The LIS is free to give
> location to anyone it wants, for any purpose, subject to the privacy
> limitations in the PIDF-LO.  The LIS MUST allow any entity to route an
> emergency call.
>=20
> Brian
>=20
> > -----Original Message-----
> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > Sent: Monday, December 10, 2007 11:15 AM
> > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara
> > Cc: ecrit@ietf.org; Liess, Laura
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Brian my point is this.
> >
> > A location hiding mechanism that ONLY provides the boundary map of =
the
> > ESRP is pretty much useless in that it won't enable them to support =
the
> > value added case period. Since the only reason that anyone would pay =
for
> > it is so that they can support value added services I don't see how =
you
> > address the requirement.
> >
> > Franchise boundaries are unlikely to match ESRP boundaries. Further
> more,
> > not all value added service may be permitted, so the Target still =
needs
> to
> > know what services for a given location provider will be permitted =
to
> > obtain location information. I think the view of providing a coarse
> > location is driven by a particular business model you have in mind =
that
> > does not seem to match the model that people I have talked to have =
in
> > mind.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Tuesday, 11 December 2007 3:08 AM
> > > To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne';
> 'Stark,
> > > Barbara'
> > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > Yes, that is true.
> > >
> > > If your pizza delivery service provider's service boundary matches
> your
> > > ESRPs boundary, you are in luck.
> > >
> > > In my conversations with carriers who want to do location hiding, =
this
> > is
> > > not seen as a problem.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > > Sent: Monday, December 10, 2007 10:57 AM
> > > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, =
Barbara
> > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > >
> > > > If I get coarse location good enough to route to my local pizza
> > delivery
> > > > facility then I have gotten my value added service for free.
> > > >
> > > > I rest my case!
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > > Sent: Tuesday, 11 December 2007 2:51 AM
> > > > > To: Winterbottom, James; Dawson, Martin; 'Henning =
Schulzrinne';
> > > 'Stark,
> > > > > Barbara'
> > > > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > > >
> > > > > We are talking about location-by-reference.
> > > > >
> > > > > An endpoint or VSP dereferencing this URI will get coarse
> location,
> > as
> > > > > described.
> > > > >
> > > > > A PSAP or ESRP dereferencing will have credentials, and will =
get
> > high
> > > > > resolution data
> > > > >
> > > > > An authorized entity (i.e. one paying for it) will have
> credentials
> > > and
> > > > > will
> > > > > get high resolution data.
> > > > >
> > > > > Where is the problem?
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Winterbottom, James =
[mailto:James.Winterbottom@andrew.com]
> > > > > > Sent: Monday, December 10, 2007 10:38 AM
> > > > > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark,
> > Barbara
> > > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > > > > >
> > > > > > Brian,
> > > > > >
> > > > > > The primary aim for hiding location is not to make it hard =
for
> > > > emergency
> > > > > > services, but to enable the ability to charge for value =
added
> > > > services.
> > > > > > Can you please explain how this solution (other than through =
a
> one
> > > off
> > > > > > charge for location) supports this requirement.
> > > > > >
> > > > > > Cheers
> > > > > > James
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > > > > Sent: Tuesday, 11 December 2007 1:57 AM
> > > > > > > To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, =
Barbara'
> > > > > > > Cc: ecrit@ietf.org; 'Liess, Laura'
> > > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > >
> > > > > > > The only emergency service in the U.S. is urn:service:sos.
> > There
> > > is
> > > > > > only
> > > > > > > one boundary and if it changes (which LoST tells you via =
the
> TTL
> > > of
> > > > > the
> > > > > > > service boundary), you may have to find those locations
> affected
> > > by
> > > > > the
> > > > > > > change when they request a new location URI.
> > > > > > >
> > > > > > > In the countries where there are multiple services, there =
are
> > only
> > > a
> > > > > few
> > > > > > > (sometimes one) ESRPs.
> > > > > > >
> > > > > > > There could be some theoretic case of lots of ESRPs and =
lots
> of
> > > > > > services,
> > > > > > > in
> > > > > > > which case there are more intersections, but the =
calculation
> is
> > > > > simple,
> > > > > > > fairly quick, and the TTLs make it easy to determine when =
a
> > change
> > > > is
> > > > > > > made,
> > > > > > > and several pretty straightforward strategies are =
available to
> > > > > minimize
> > > > > > > the
> > > > > > > work on the LIS.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > > > > > Sent: Saturday, December 08, 2007 6:39 PM
> > > > > > > > To: Henning Schulzrinne; Stark, Barbara
> > > > > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > > > > Subject: RE: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > Everything is qualified on what ultimately gets =
regulated.
> But
> > > > it's
> > > > > > > > probably time to discuss real world implications of this
> > topic.
> > > > > > > >
> > > > > > > > I expect that, if access operators are required to =
provide
> > > > location,
> > > > > > it
> > > > > > > is
> > > > > > > > only going to be for the purpose of emergency services. =
I
> > doubt
> > > > that
> > > > > > > > regulators will even consider mandating that they =
provide it
> > for
> > > > all
> > > > > > > users
> > > > > > > > for all purposes. There'll be no sledgehammer to force
> access
> > > > > > providers
> > > > > > > to
> > > > > > > > give everyone a free location service - so it won't =
happen
> > until
> > > > > > > operators
> > > > > > > > have their own reasons to do so.
> > > > > > > >
> > > > > > > > Since access providers can't control what client devices
> > > actually
> > > > > use
> > > > > > > > location information for, they will only implement a =
system
> > that
> > > > > > permits
> > > > > > > a
> > > > > > > > recognised emergency entity to retrieve the actual =
location
> > > value.
> > > > > > > They'll
> > > > > > > > only give the end subscriber location information if =
that's
> > > > already
> > > > > > paid
> > > > > > > > for as part of the subscription.
> > > > > > > >
> > > > > > > > The fundamental problem with the "do location hiding by
> > > providing
> > > > > > > > location" proposal is exactly that. It fails to hide
> location.
> > > > This
> > > > > is
> > > > > > > > particularly the case in the US (which is a difficult =
market
> > to
> > > > > > ignore).
> > > > > > > > The intersection of every possible service area - also
> called
> > an
> > > > ESN
> > > > > > or
> > > > > > > > ESZ - in the US is a quite granular area; certainly good =
for
> > > quite
> > > > a
> > > > > > lot
> > > > > > > > of services. For a mobile access provider, in =
particular, a
> > > > > > considerable
> > > > > > > > amount of capital equipment is going to be invoked to
> provide
> > > this
> > > > > > quite
> > > > > > > > good location information.
> > > > > > > >
> > > > > > > > On the other hand, in many other countries (e.g. the UK =
and
> > > > > Australia)
> > > > > > > > this technique is probably not problematic for the =
carrier,
> > > > because
> > > > > > they
> > > > > > > > are just going to return the country code. That's as
> granular
> > as
> > > > you
> > > > > > > need
> > > > > > > > to be for emergency services.
> > > > > > > >
> > > > > > > > So here's what will happen if this is the official IETF
> > > > > > recommendation.
> > > > > > > It
> > > > > > > > may get adopted but operators will limit the provided
> location
> > > > > > > information
> > > > > > > > to just the country indicator. They'll do this in the US =
as
> > well
> > > > > > > (they'll
> > > > > > > > refuse to process all the LoST boundary data and take
> > > > responsibility
> > > > > > for
> > > > > > > > consequent routing outcome). This means that VSPs =
dealing
> with
> > > > calls
> > > > > > > > originating in the US will need to use i2. This is =
because
> the
> > > V2
> > > > > > > > interface in i2 does support a location reference while =
LoST
> > is
> > > > > unable
> > > > > > > to
> > > > > > > > do this. The country information will certainly be =
useful
> for
> > > > > > > arbitrating
> > > > > > > > which VPC to use though - so that's good. It will mean =
that
> > > direct
> > > > > to
> > > > > > > PSAP
> > > > > > > > calls won't be able to be made in the US. That's a =
shame.
> > Other
> > > > > > > > jurisdictions that only have a single PSAP route will be
> able
> > to
> > > > > > support
> > > > > > > > this. OTOH, it might force the US to provide a federal =
level
> > URI
> > > > > with
> > > > > > > > proxies that can subsequently do the dereference and =
lower
> > level
> > > > > > routing
> > > > > > > -
> > > > > > > > so maybe it's not such a shame. It won't result in =
access
> > > > providers
> > > > > > > giving
> > > > > > > > free location information until they are ready to do so
> > however.
> > > > > > > >
> > > > > > > > Editorial and a genuine question:
> > > > > > > >
> > > > > > > > IMO, supporting the services URI extension in HELD or =
adding
> > > > > location
> > > > > > > > reference support to LoST are both superior engineering
> > > solutions.
> > > > > > They
> > > > > > > > just aren't driven by the punitive motivations of the =
"hide
> by
> > > not
> > > > > > > hiding"
> > > > > > > > proposal. Arguments that they are inferior because they
> > require
> > > > > > protocol
> > > > > > > > changes are specious and self-fulfilling. That's why the
> > > > "reference
> > > > > > > query"
> > > > > > > > mechanism for LoST was "postponed" in the interest of
> getting
> > > LoST
> > > > > > > > finalized. It continues to be used as a prop for this
> > particular
> > > > > > hiding
> > > > > > > > proposal. By this line of argument, we would never add =
or
> > modify
> > > > > > > protocols
> > > > > > > > for anything.
> > > > > > > >
> > > > > > > > It's very difficult not to lapse into sarcasm in this =
area
> (I
> > > feel
> > > > > > like
> > > > > > > > saying it's OK not to have location hiding because =
Columbia
> > > > > University
> > > > > > > and
> > > > > > > > Cisco are going to underwrite the cost of providing a =
5x9s
> > > > reliable
> > > > > > > > ubiquitous location service in all public access =
networks
> out
> > of
> > > > > pure
> > > > > > > > philanthropy.... but I won't :) ).
> > > > > > > >
> > > > > > > > Insisting on providing location for all applications is =
like
> > > > > insisting
> > > > > > > > that cellular operators let users call anyone just to =
ensure
> > > that
> > > > > they
> > > > > > > can
> > > > > > > > also make emergency calls. In this hypothetical =
situation,
> > > > refusing
> > > > > to
> > > > > > > > define protocol mechanisms that permit them to =
distinguish
> > > between
> > > > > the
> > > > > > > > scenarios would only result in there being no cellular
> service
> > -
> > > > or
> > > > > > just
> > > > > > > > publicly funded cellular services. It's a =
counter-productive
> > > > > attitude.
> > > > > > > >
> > > > > > > > This provides the opportunity for me to once more ask a
> > question
> > > > > that
> > > > > > > > hasn't been responded to in the past. Why is ECRIT
> describing
> > a
> > > > > > solution
> > > > > > > > that has the VSP involved in the emergency call at all? =
Why
> > > would
> > > > > the
> > > > > > > VSP
> > > > > > > > want to be involved in emergency calls - and why would =
the
> > > caller
> > > > > want
> > > > > > > > them involved? It seems to be not in the interest of =
either
> > > party.
> > > > > > > There's
> > > > > > > > already an interim architecture for the non "end-to-end =
IP"
> > > > scenario
> > > > > > > > called i2. In any circumstance where any of the device, =
the
> > > > network,
> > > > > > or
> > > > > > > > emergency operator are not ECRIT-capable, then the VSP =
does
> > need
> > > > to
> > > > > be
> > > > > > > > involved and i2 is a valid fallback.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Martin
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > > > Sent: Saturday, 8 December 2007 8:56 AM
> > > > > > > > To: Stark, Barbara
> > > > > > > > Cc: ecrit@ietf.org; Liess, Laura
> > > > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > >
> > > > > > > > Translation: You have more lobbyists than I (or the =
IETF),
> so
> > > give
> > > > > me.
> > > > > > > > Thanks for clarifying that.
> > > > > > > >
> > > > > > > > Henning
> > > > > > > >
> > > > > > > > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:
> > > > > > > >
> > > > > > > > > [The following statements are my opinion, and should =
not
> be
> > > > > > > > > attributed to the company I work for.]
> > > > > > > > >
> > > > > > > > > Henning,
> > > > > > > > > It's true that the IETF doesn't have to do something =
just
> > > > because
> > > > > > > > > someone wants it. It's also true that the IETF has no
> > > authority
> > > > or
> > > > > > > > > ability to force implementation of RFCs by companies =
who
> > > refuse
> > > > to
> > > > > > > > > implement them. You cannot shove a solution down the
> throats
> > > of
> > > > > > > > > access providers that they are unwilling to buy in to. =
In
> my
> > > > > > > > > opinion, even attempting to do so would be, well,
> unethical.
> > > > > > > > >
> > > > > > > > > So, you have a choice:
> > > > > > > > > 1) create a solution that you like that major =
stakeholders
> > are
> > > > > > > > > unwilling to implement
> > > > > > > > > 2) create a solution that you don't quite like, but =
that's
> > > > better
> > > > > > > > > than what we have today, and which major stakeholders =
are
> > > > willing
> > > > > to
> > > > > > > > > implement
> > > > > > > > >
> > > > > > > > > Believe it or not, major telecom companies in the US =
and
> > > Europe
> > > > > put
> > > > > > > > > a lot of effort into lobbying regulatory bodies, to
> achieve
> > > > > > > > > desirable outcomes. The IETF doesn't put in such =
effort.
> If
> > > you
> > > > > want
> > > > > > > > > to make a go at pushing through a solution that
> stakeholders
> > > in
> > > > > > > > > these regions are set against, and see if you can get
> > > regulatory
> > > > > > > > > agencies to bless it, then go for it. I think the odds =
are
> > > > stacked
> > > > > > > > > against you, though. Especially since there are =
workable
> > > > solutions
> > > > > > > > > that these companies have said they would be willing =
to
> > > accept.
> > > > > > > > >
> > > > > > > > > Here is why mobile access providers "cannot" provide =
the
> > best
> > > > > > > > > available location directly to end user devices: They
> don't
> > > want
> > > > > to.
> > > > > > > > > At this point in time, it's their network, their data, =
and
> > > their
> > > > > > > > > choice.
> > > > > > > > >
> > > > > > > > > In free market economies, you generally have to be =
able to
> > > > *prove*
> > > > > > > > > (and not just say it without proof) massive benefit or
> > massive
> > > > > harm
> > > > > > > > > before you can force companies to do what they don't =
want
> to
> > > do,
> > > > > > > > > through regulation. Again, if you think you can take =
on
> that
> > > > > battle
> > > > > > > > > and win, go for it.
> > > > > > > > >
> > > > > > > > > I, for one, believe that not providing the "real" =
location
> > > value
> > > > > to
> > > > > > > > > end devices would not cause such benefit or harm. If =
users
> > > want
> > > > to
> > > > > > > > > know what location PSAPs get on their behalf, and
> regulators
> > > > > believe
> > > > > > > > > such a capability is needed, then we can let the =
phonebcp-
> > > > > described
> > > > > > > > > test mechanism voice it back over the voice medium =
(this
> > would
> > > > > only
> > > > > > > > > work for civic), or return a JPEG map with a dot on =
it.
> This
> > > > would
> > > > > > > > > provide location in a format that's usable by a human
> being,
> > > but
> > > > > not
> > > > > > > > > an application. Or maybe, in some countries, the
> regulators
> > do
> > > > > > > > > require access providers to give out the best possible
> > > location
> > > > > > > > > values to end devices. But it's really improbable that =
you
> > > could
> > > > > > > > > force the regulators of all countries to see things =
your
> > way.
> > > > > > > > >
> > > > > > > > > But, this is all just my opinion.
> > > > > > > > > Barbara
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > > > > > > Sent: Friday, December 07, 2007 12:13 PM
> > > > > > > > > To: Liess, Laura
> > > > > > > > > Cc: ecrit@ietf.org
> > > > > > > > > Subject: Re: AW: [Ecrit] Location Hiding -- State of =
the
> Art
> > > > > > > > >
> > > > > > > > > Laura,
> > > > > > > > >
> > > > > > > > > just because somebody says "we need it" doesn't make =
it an
> > > IETF
> > > > > > > > > requirement. Please justify why mobile access cannot
> provide
> > > > > > locations
> > > > > > > > > to end users.
> > > > > > > > >
> > > > > > > > > Henning
> > > > > > > > >
> > > > > > > > > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
> > > > > > > > >
> > > > > > > > >> Brian,
> > > > > > > > >>
> > > > > > > > >> I checked with my company and we need LH for both =
civic
> and
> > > geo
> > > > > for
> > > > > > > > >> fixed and mobile access. Only DSL and civic is not an
> > option.
> > > > > > > > >>
> > > > > > > > >> I would support sending the ESRP/PSAP URI to the UA, =
as
> > > > proposed
> > > > > by
> > > > > > > > >> Barbara and James some weeks ago.
> > > > > > > > >>
> > > > > > > > >> Laura
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> -----Urspr=FCngliche Nachricht-----
> > > > > > > > >> Von: Brian Rosen [mailto:br@brianrosen.net]
> > > > > > > > >> Gesendet: Dienstag, 4. Dezember 2007 16:37
> > > > > > > > >> An: 'Hannes Tschofenig'
> > > > > > > > >> Cc: 'ECRIT'
> > > > > > > > >> Betreff: RE: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > > >>
> > > > > > > > >> Proposed text for framework
> > > > > > > > >>
> > > > > > > > >> Some access networks wish to restrict who can get a =
high
> > > > quality
> > > > > > > > >> location,
> > > > > > > > >> possibly based on a payment arrangement.  For =
emergency
> > > calls,
> > > > > high
> > > > > > > > >> quality
> > > > > > > > >> location must be provided.  An access network can
> > reasonably
> > > be
> > > > > > > > >> expected to
> > > > > > > > >> have a relationship with the PSAPs in its catchment =
area,
> > so
> > > > > giving
> > > > > > > > >> location
> > > > > > > > >> to the PSAP will be straightforward
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> However, an endpoint may need location
> > > > > > > > >> for routing, and a proxy may need to verify that a
> > purported
> > > > > > > > >> emergency call
> > > > > > > > >> is targeted at a bona fide PSAP.  To do so, it may =
take
> the
> > > > > > location
> > > > > > > > >> passed
> > > > > > > > >> with the call and query LoST to confirm that the URI =
is
> > > > genuine.
> > > > > > > > >> "Hiding"
> > > > > > > > >> location interferes with this check.  To achieve =
location
> > > > hiding,
> > > > > > > > >> the LIS
> > > > > > > > >> can return a coarse location which is good enough to
> elicit
> > > the
> > > > > > same
> > > > > > > > >> response from LoST as the actual location would.  The
> > > endpoint
> > > > > and
> > > > > > > > >> the proxy
> > > > > > > > >> can use this location to route and verify.  A =
suitable
> > > location
> > > > > for
> > > > > > > > >> a geo is
> > > > > > > > >> a polygon calculated by intersecting the service
> boundaries
> > > of
> > > > > all
> > > > > > > > >> of the
> > > > > > > > >> emergency services that respond to the actual =
location.
> A
> > > > > suitable
> > > > > > > > >> location
> > > > > > > > >> for a civic is any civic location within the =
intersection
> > of
> > > > the
> > > > > > > > >> service
> > > > > > > > >> boundaries of emergency services.  In a great many =
cases,
> a
> > > > > country
> > > > > > > > >> code is
> > > > > > > > >> sufficient.  In others a state/province or a city =
name is
> > > > > > > > >> sufficient.  Of
> > > > > > > > >> course, the LIS would always return a location =
reference,
> > > which
> > > > > > > > >> would return
> > > > > > > > >> high quality location for a PSAP and coarse location =
to
> the
> > > > > > endpoint
> > > > > > > > >> or any
> > > > > > > > >> proxy unknown to the LIS.
> > > > > > > > >>
> > > > > > > > >> Proposed text for phonebcp:
> > > > > > > > >>
> > > > > > > > >> A LIS who wishes to hide location returns a location
> > > reference.
> > > > > > When
> > > > > > > > >> dereferenced by the endpoint or proxy:
> > > > > > > > >> 1. For LIS's returning geo:
> > > > > > > > >>   For each location served by the LIS, compute the
> > > intersection
> > > > > of
> > > > > > > > >> the
> > > > > > > > >>   service boundaries for all emergency services known =
to
> > LoST
> > > > for
> > > > > > the
> > > > > > > > >>   location. Return the resulting polygon, or any =
point in
> > the
> > > > > > > > >> polygon as
> > > > > > > > >>   the value during a dereference
> > > > > > > > >> 2. For LIS's returning civic:
> > > > > > > > >>   Determine a civic location which is within the =
service
> > > > boundary
> > > > > > > > >> of all
> > > > > > > > >>   emergency services known to LoST for the location.  =
In
> a
> > > > great
> > > > > > many
> > > > > > > > >>   cases, this will be a country code, province/state =
or
> > city.
> > > > > > > > >> Return this
> > > > > > > > >>   coarse civic location as the value during a =
dereference
> > > > > > > > >> Note that the service boundaries returned from LoST =
have
> a
> > > TTL,
> > > > > the
> > > > > > > > >> intersections MUST recalculated if the service =
boundary
> > > > changes.
> > > > > > > > >> The LIS
> > > > > > > > >> MUST return high quality location to a PSAP or ESRP.
> > > > > > > > >>
> > > > > > > > >> Brian
> > > > > > > > >>
> > > > > > > > >>> -----Original Message-----
> > > > > > > > >>> From: Hannes Tschofenig
> [mailto:Hannes.Tschofenig@gmx.net]
> > > > > > > > >>> Sent: Monday, December 03, 2007 1:38 PM
> > > > > > > > >>> To: Brian Rosen
> > > > > > > > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> > > > > > > > >>> Subject: Re: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > > >>>
> > > > > > > > >>> Hi Brian,
> > > > > > > > >>>
> > > > > > > > >>> Brian Rosen wrote:
> > > > > > > > >>>> It's fine with me if there is a separate doc, but
> > framework
> > > > and
> > > > > > > > >>>> phonebcp
> > > > > > > > >>>> have to reference it.
> > > > > > > > >>>>
> > > > > > > > >>> Are we talking about informative or normative
> references?
> > > > > > > > >>>> I think it can be solved with a one paragraph
> description
> > > of
> > > > > the
> > > > > > > > >>>> problem
> > > > > > > > >>> in
> > > > > > > > >>>> framework and a one paragraph solution in phonebcp, =
but
> > if
> > > > > there
> > > > > > > > >>>> is a
> > > > > > > > >>>> separate doc and a reference, I will be happy.
> > > > > > > > >>>>
> > > > > > > > >>> That does not make sense.
> > > > > > > > >>> The solution is not one paragraph and the text in =
phone
> > bcp
> > > is
> > > > > > > > >>> normative.
> > > > > > > > >>>
> > > > > > > > >>> Ciao
> > > > > > > > >>> Hannes
> > > > > > > > >>>
> > > > > > > > >>>> Brian
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>> -----Original Message-----
> > > > > > > > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> > > > > > > > >>>>> Sent: Monday, December 03, 2007 7:37 PM
> > > > > > > > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> > > > > > > > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of =
the
> Art
> > > > > > > > >>>>>
> > > > > > > > >>>>> Currently, the WG (and document editors!) should =
be
> > > > operating
> > > > > > > > >>>>> under
> > > > > > > > >>>>> the consensus direction that Location Hiding *not* =
be
> in
> > > > > > PhoneBCP
> > > > > > > > >>>>> or
> > > > > > > > >>>>> Framework.  This was a clear consensus call in =
Chicago
> -
> > > and
> > > > > not
> > > > > > > > >>>>> by
> > > > > > > > >>>>> default, but by most people voicing actively =
against
> > > having
> > > > > this
> > > > > > > > >>>>> Hiding in either core ECRIT documents, and I =
haven't
> yet
> > > > > talked
> > > > > > to
> > > > > > > > >>>>> anyone here in Vancouver that thinks otherwise.
> > > > > > > > >>>>>
> > > > > > > > >>>>> Location Hiding is something that needs to be
> addressed
> > BY
> > > > > > ITSELF
> > > > > > > > >>>>> (i.e., in its own doc) so everyone can focus on =
the
> > > singular
> > > > > > > > >>>>> topic,
> > > > > > > > >>>>> and work towards not talking past each other (not =
like
> > > > that's
> > > > > > > > >>>>> happened before in ECRIT....  :-/
> > > > > > > > >>>>>
> > > > > > > > >>>>> Who disagrees with this?
> > > > > > > > >>>>>
> > > > > > > > >>>>> BTW - if someone thinks Location Hiding should be =
put
> > back
> > > > > into
> > > > > > > > >>>>> PhoneBCP or Framework, then they can attempt to =
gain
> WG
> > > > > > consensus
> > > > > > > > >>>>> on
> > > > > > > > >>>>> that, but that's different than a direction of =
this
> > > > > > inevitability
> > > > > > > > >>>>> or
> > > > > > > > >>>>> that there is not consensus on this.
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> > > > > > > > >>>>>
> > > > > > > > >>>>>> If people felt this was good enough so that =
access
> > > > providers
> > > > > > > > >>>>>> would not
> > > > > > > > >>>>>> need to be required to build the infrastructure =
to
> > > provide
> > > > > > > > >>>>>> location
> > > > > > > > >>>>>> (because people could use this method instead of
> > getting
> > > > > > > > >>>>>> location from
> > > > > > > > >>>>>> access providers), then location hiding would be
> dead.
> > If
> > > > > > people
> > > > > > > > >>>>>> still
> > > > > > > > >>>>>> want to place a requirement on access providers =
to
> > > provide
> > > > > > > > >>>>>> location,
> > > > > > > > >>>>>> then location hiding is not dead.
> > > > > > > > >>>>>> Barbara
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> -----Original Message-----
> > > > > > > > >>>>>> From: Hannes Tschofenig
> > > [mailto:Hannes.Tschofenig@gmx.net]
> > > > > > > > >>>>>> Sent: Saturday, December 01, 2007 3:34 PM
> > > > > > > > >>>>>> To: ECRIT
> > > > > > > > >>>>>> Subject: [Ecrit] Location Hiding -- State of the =
Art
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> I thought that the following article would be of
> > interest
> > > > for
> > > > > > > > >>>>>> you:
> > > > > > > > >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-
> > found.html
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Here is text from
> > > > > > > > >>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-
> > > blue-
> > > > > > circle-
> > > > > > > > on-
> > > > > > > > >>> your
> > > > > > > > >>>>>> -map.html
> > > > > > > > >>>>>> "
> > > > > > > > >>>>>> My Location is a new beta technology from Google =
that
> > > uses
> > > > > cell
> > > > > > > > >>>>>> tower
> > > > > > > > >>>>>> identification to provide you with approximate
> location
> > > > > > > > >>>>>> information,
> > > > > > > > >>> so
> > > > > > > > >>>>>> it will work on phones without GPS.
> > > > > > > > >>>>>> "
> > > > > > > > >>>>>> Note that this stuff is not really new =
technology. It
> > > > existed
> > > > > > > > >>>>>> already
> > > > > > > > >>>>>> for some time but the availability of GPS devices
> made
> > it
> > > > > > > > >>>>>> possible to
> > > > > > > > >>>>>> setup the database in a more efficient way.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Anyway, this mechanism allows you to obtain =
location
> > > > > > information
> > > > > > > > >>>>>> with
> > > > > > > > >>>>>> your cell phone (using the cell id) without
> interacting
> > > > with
> > > > > > the
> > > > > > > > >>>>>> cellular operator.
> > > > > > > > >>>>>> In short: operator cannot charge for location
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> While the location information is not really =
useful
> for
> > > > first
> > > > > > > > >>> responders
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> it is still good enough for finding the closest =
PSAP.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Is this the dead of location hiding?
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Ciao
> > > > > > > > >>>>>> Hannes
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> _______________________________________________
> > > > > > > > >>>>>> Ecrit mailing list
> > > > > > > > >>>>>> Ecrit@ietf.org
> > > > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> _______________________________________________
> > > > > > > > >>>>>> Ecrit mailing list
> > > > > > > > >>>>>> Ecrit@ietf.org
> > > > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > > >>>>>>
> > > > > > > > >>>>> _______________________________________________
> > > > > > > > >>>>> Ecrit mailing list
> > > > > > > > >>>>> Ecrit@ietf.org
> > > > > > > > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > > >>>>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> _______________________________________________
> > > > > > > > >> Ecrit mailing list
> > > > > > > > >> Ecrit@ietf.org
> > > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > > >>
> > > > > > > > >> _______________________________________________
> > > > > > > > >> Ecrit mailing list
> > > > > > > > >> Ecrit@ietf.org
> > > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Ecrit mailing list
> > > > > > > > > Ecrit@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > > >
> > > > > > > > > *****
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Ecrit mailing list
> > > > > > > > Ecrit@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > >
> > > > > > > > =
------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > --
> > > > > > > > ----------------------
> > > > > > > > This message is for the designated recipient only and =
may
> > > > > > > > contain privileged, proprietary, or otherwise private
> > > information.
> > > > > > > > If you have received it in error, please notify the =
sender
> > > > > > > > immediately and delete the original.  Any unauthorized =
use
> of
> > > > > > > > this email is prohibited.
> > > > > > > > =
------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > --
> > > > > > > > ----------------------
> > > > > > > > [mf2]
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Ecrit mailing list
> > > > > > > > Ecrit@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Ecrit mailing list
> > > > > > > Ecrit@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >
> > > > > > =
----------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > ----------------------
> > > > > > This message is for the designated recipient only and may
> > > > > > contain privileged, proprietary, or otherwise private
> information.
> > > > > > If you have received it in error, please notify the sender
> > > > > > immediately and delete the original.  Any unauthorized use =
of
> > > > > > this email is prohibited.
> > > > > > =
----------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > ----------------------
> > > > > > [mf2]
> > > > >
> > > >
> > > > =
--------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > This message is for the designated recipient only and may
> > > > contain privileged, proprietary, or otherwise private =
information.
> > > > If you have received it in error, please notify the sender
> > > > immediately and delete the original.  Any unauthorized use of
> > > > this email is prohibited.
> > > > =
--------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > [mf2]
> > >
> >
> > =
------------------------------------------------------------------------
> --
> > ----------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> > =
------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 14:05:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1nwq-0005ZZ-QR; Mon, 10 Dec 2007 14:05:48 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nwq-0005ZU-3g
	for ecrit@ietf.org; Mon, 10 Dec 2007 14:05:48 -0500
Received: from ironportdmz5.qualcomm.com ([199.106.114.254]
	helo=wolverine01.qualcomm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1nwp-0004Fj-8W
	for ecrit@ietf.org; Mon, 10 Dec 2007 14:05:47 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Cc:Content-Type;
	b=ut6uqUiOv9e5FjJq+2ANR5NL4VjYLmkZ5GNrhXosDcmKBfTUBTxf5qSb
	rsFWVBxuhT0B5ghlz/M+BxK/lLhjqbH4xBvewBJj15xf1JfMrtCkg/r+G
	xbSts12uf9X+6LSGoTgXoGSvYN4MJehnaeCeKeC48tBOw9EAVR+o0cXE/
	U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAIYcXUeBLjM7/2dsb2JhbAA
X-IronPort-AV: E=McAfee;i="5100,188,5182"; a="50063"
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	10 Dec 2007 11:05:45 -0800
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lBAJ5iEH027617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Dec 2007 11:05:45 -0800
Received: from [76.126.60.89] (vpn-10-50-0-180.qualcomm.com [10.50.0.180])
	by neophyte.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lBAJ5e4f012008; Mon, 10 Dec 2007 11:05:43 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! c41p> 

Date: Mon, 10 Dec 2007 11:05:44 -0800
To: "Winterbottom, James" ,
	"Stark, Barbara" , "Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
From: Ted Hardie 
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 1.2 (+)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 12:31 PM -0600 12/10/07, Winterbottom, James wrote:
>Ted,
>
>My concern here is that we need one solution for location hiding

I really don't think you do need that.  It may be handy, but the billing
problem is really quiet different.  In case one, you want something
that can be handed back to a phone with no per-dip charge.  I've
already mentioned some ways of dealing with that at a billing level,
and I'm trying to suggest that if those don't work going to Brian's
method does.  The location delivered will not be sufficient for
anything other than discovering the right PSAP.

For non-emergency cases, you are dealing instead with the
case where you have a concern that selling someone location
for purpose X gets them location for purpose Y.  That's both
a different problem and it falls into an area where there are
enough other problems that it is, honestly, probably the least
of your worries.  It's also way out of the charter of this group.

>So in short answer, I am very unhappy with any solution that requires
>the LIS to do service boundary mappings on-platform.
>

Some warm cocoa may help with your unhappiness.  But I'm not too
happy when people raise issues and then reject solutions which
require them to spend effort; especially when their proposals are
fundamentally more fragile for delivery of critical services.

			regards,
				Ted

>Cheers
>James
>
>
>> -----Original Message-----
>> From: Ted Hardie [mailto:hardie@qualcomm.com]
>> Sent: Tuesday, 11 December 2007 5:12 AM
>> To: Stark, Barbara; Brian Rosen; Winterbottom, James; Dawson, Martin;
>> Henning Schulzrinne
>> Cc: ecrit@ietf.org; Liess, Laura
>> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>>
>> >
>> >Admittedly, this is outside the scope of ecrit. But, since LoST was
>made
>> into a generic service URN to URI translator, it would be nice if
>somehow
>> the LoST protocol could be used to provide devices with URIs, even
>when
>> the device doesn't have its precise location.
>> >
>> >I think that getting this capability would be very useful and
>desirable,
>> but don't think it's as high a priority as getting the emergency
>services
>> architecture worked out.
>> >Barbara
>>
>> Let me strongly support the notion that getting into this before
>finishing
>> the
>> emergency services work is not desirable.  There are several potential
>> issues
>> here (the most prominent being whether re-using the service urn
>namespace
>> for services will work for non-jurisdictionally derived catchement
>areas).
>> I think it is far enough outside the realm of ECRIT that boffing the
>work
>> as a Lost extensions wg would be desirable.
>>
>> In the short term, doing location hiding sufficient for emergency
>services
>> is the item under discussion.  Does anyone believe Brian's text does
>not
>> work for this point?
>>
>>			regards,
>>				Ted
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information. 
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 14:26:03 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1oGQ-0003JZ-Rd; Mon, 10 Dec 2007 14:26:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oGQ-0003JU-Ei
	for ecrit@ietf.org; Mon, 10 Dec 2007 14:26:02 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1oGQ-0005MV-1T
	for ecrit@ietf.org; Mon, 10 Dec 2007 14:26:02 -0500
X-SEF-Processed: 5_0_0_910__2007_12_10_13_37_03
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, 10 Dec 2007 13:37:03 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 13:25:59 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 13:25:52 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7X6wxS1Yo4fROQFqj0RBug8SQBwAAlHGQ
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! c41p> <
	p0 6240605c3 8330f2cd7e@[76.126.60.89]>

From: "Winterbottom, James" 
To: "Ted Hardie" , "Stark, Barbara" ,
	"Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
X-OriginalArrivalTime: 10 Dec 2007 19:25:59.0368 (UTC)
	FILETIME=[7E68A480:01C83B62]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Ted inline.=0D=0A=0D=0A>=20=0D=0A> I really don't think you do need that.  =
It may be handy, but the=0D=0Abilling=0D=0A> problem is really quiet differ=
ent.  In case one, you want something=0D=0A> that can be handed back to a p=
hone with no per-dip charge.  I've=0D=0A> already mentioned some ways of de=
aling with that at a billing level,=0D=0A> and I'm trying to suggest that i=
f those don't work going to Brian's=0D=0A> method does.  The location deliv=
ered will not be sufficient for=0D=0A> anything other than discovering the =
right PSAP.=0D=0A>=20=0D=0A=0D=0AIf the device is simply given a PSAP URI, =
a service URN, and a location=0D=0AURI, what more does it need=3F=0D=0A=0D=0A=
> For non-emergency cases, you are dealing instead with the=0D=0A> case whe=
re you have a concern that selling someone location=0D=0A> for purpose X ge=
ts them location for purpose Y.  That's both=0D=0A> a different problem and=
 it falls into an area where there are=0D=0A> enough other problems that it=
 is, honestly, probably the least=0D=0A> of your worries.  It's also way ou=
t of the charter of this group.=0D=0A>=0D=0A=0D=0AI would argue that locati=
on hiding is not in the charter of this WG at=0D=0Aall. How to route to a P=
SAP is the current charter, so if the end-point=0D=0Ais given all it needs =
to route to the PSAP then we are done aren't we=3F=0D=0A=0D=0A=20=0D=0A> >S=
o in short answer, I am very unhappy with any solution that requires=0D=0A>=
 >the LIS to do service boundary mappings on-platform.=0D=0A> >=0D=0A>=20=0D=
=0A> Some warm cocoa may help with your unhappiness.  But I'm not too=0D=0A=
> happy when people raise issues and then reject solutions which=0D=0A> req=
uire them to spend effort; especially when their proposals are=0D=0A> funda=
mentally more fragile for delivery of critical services.=0D=0A>=20=0D=0AUmm=
, how is providing the end point with where it needs to go more=0D=0Afragil=
e than giving it a bodgey location=3F=0D=0A=0D=0A=0D=0ACheers=0D=0AJames=0D=
=0A------------------------------------------------------------------------=
------------------------=0D=0AThis message is for the designated recipient =
only and may=0D=0Acontain privileged, proprietary, or otherwise private inf=
ormation. =20=0D=0AIf you have received it in error, please notify the send=
er=0D=0Aimmediately and delete the original.  Any unauthorized use of=0D=0A=
this email is prohibited.=0D=0A--------------------------------------------=
----------------------------------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 16:37:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1qK6-0007qt-Em; Mon, 10 Dec 2007 16:37:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qK5-0007pn-6M
	for ecrit@ietf.org; Mon, 10 Dec 2007 16:37:57 -0500
Received: from ironportdmz6.qualcomm.com ([199.106.114.251]
	helo=wolverine02.qualcomm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1qK3-0004uV-3Y
	for ecrit@ietf.org; Mon, 10 Dec 2007 16:37:57 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Cc:Content-Type;
	b=JZJPYuKbqUU+AKKqMLTuaoe1WQbqcrT/04fFTqPszeLPRUlN5wQLUVjS
	e2oY1Zg1ucSZLHXdMXsq+yucxN6ORxWvAQ+rCOXr5YyDIBOjJoYJ1vcPl
	CFbVlqdc7Ulfc1/mp19Qxp+65rAhq9M2zoGwtKJywxjhPwp/dOvr3jb/j
	U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAEpAXUeBLjM6/2dsb2JhbAA
X-IronPort-AV: E=McAfee;i="5100,188,5182"; a="50394"
Received: from numenor.qualcomm.com ([129.46.51.58])
	by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	10 Dec 2007 13:37:54 -0800
Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com
	[129.46.61.151])
	by numenor.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lBALbqOO027604
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Dec 2007 13:37:53 -0800
Received: from [76.126.60.89] (vpn-10-50-0-180.qualcomm.com [10.50.0.180])
	by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lBALbo2O012533; Mon, 10 Dec 2007 13:37:51 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> <	p0 6240605c3
	8330f2cd7e@[76.126.60.89]>

Date: Mon, 10 Dec 2007 13:37:53 -0800
To: "Winterbottom, James" ,
	"Stark, Barbara" , "Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
From: Ted Hardie 
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
>If the device is simply given a PSAP URI, a service URN, and a location
>URI, what more does it need?

As several people have pointed out, it needs/could use the ability to sanity
check the location.  You've argued it doesn't need that as much as
the operators need to be paid for location infrastructure deployed,
which set up the whole apples to oranges discussion that has been
going so far.

Past that, you're introducing a mechanism that combines two services
(receiving a location and associating that location with a psap URI).  If you gave
that data to a device which has a different LoST server configured, what
do you expect to happen?  Is it going to pass that location URI to its
own LoST server to confirm it gets the same PSAP URI?  The current
system allows a user/device to request service boundaries and to
make reasonable choices about when to refresh URI mappings.  How
are you replicating that functionality?  The service boundaries are,
after all, pretty much at the level of Brian's proposal.  

> > For non-emergency cases, you are dealing instead with the
>> case where you have a concern that selling someone location
>> for purpose X gets them location for purpose Y.  That's both
>> a different problem and it falls into an area where there are
>> enough other problems that it is, honestly, probably the least
>> of your worries.  It's also way out of the charter of this group.
>>
>
>I would argue that location hiding is not in the charter of this WG at
>all. How to route to a PSAP is the current charter, so if the end-point
>is given all it needs to route to the PSAP then we are done aren't we?
>

I agree that location hiding is not in the charter of this working group.
You've been among those saying it had to be considered.  What you're
proposing goes in a different design direction to the one the
working group has had so far and it goes against some base principles
of location in GeoPRIV contexts as well (see:  the user controls access to
his/her location)

If what you were providing were as robust as the other methods being
offered we might be done, despite the design difference.  But there is
no consensus that this is the case.  At least Henning and I feel it is more
fragile.  I believe there are others as well.

>Umm, how is providing the end point with where it needs to go more
>fragile than giving it a bodgey location?
>

It can check the location it is provided.  You can be working off a bodgey
location, and it would never know.

Really, try the cocoa.  It's quite nice.
				Ted

>
>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]
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 18:01:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1rd6-0001ff-Kp; Mon, 10 Dec 2007 18:01:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1rd5-0001ZP-A3
	for ecrit@ietf.org; Mon, 10 Dec 2007 18:01:39 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1rd2-0006yN-3t
	for ecrit@ietf.org; Mon, 10 Dec 2007 18:01:39 -0500
X-SEF-Processed: 5_0_0_910__2007_12_10_17_12_35
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Mon, 10 Dec 2007 17:12:35 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 17:01:31 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Mon, 10 Dec 2007 17:01:29 -0600
Message-ID: 
In-Reply-To: <03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAEOl44A==
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>
From: "Dawson, Martin" 
To: "Brian Rosen" ,
	"Henning Schulzrinne" ,
	"Stark, Barbara" 
X-OriginalArrivalTime: 10 Dec 2007 23:01:31.0439 (UTC)
	FILETIME=[9A8613F0:01C83B80]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Sorry to rewind the thread - somebody said something about "ordering drinks=
" at the beginning of the conversation (HG2G).=0D=0A=0D=0A> The only emerge=
ncy service in the U.S. is urn:service:sos.=0D=0A=0D=0ACan you elaborate on=
 this=3F Explicitly, then, what boundary would the LIS provide for a call o=
riginating in a typical US ESZ=3F It sounds like you're saying it just need=
s to provide "the US"=3F What do you mean by this boundary "changing" in th=
is context=3F How does the boundary of the US change=3F=0D=0A=0D=0AWhen was=
 this decided - and which agency, ESP, or authority has taken responsibilit=
y for administering the single national URN and routing boundary=3F It's go=
od news, but I hadn't heard it had occured.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=
=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brian=
rosen.net]=20=0D=0ASent: Tuesday, 11 December 2007 1:57 AM=0D=0ATo: Dawson,=
 Martin; 'Henning Schulzrinne'; 'Stark, Barbara'=0D=0ACc: ecrit@ietf.org; '=
Liess, Laura'=0D=0ASubject: RE: AW: [Ecrit] Location Hiding -- State of the=
 Art=0D=0A=0D=0AThe only emergency service in the U.S. is urn:service:sos. =
 There is only=0D=0Aone boundary and if it changes (which LoST tells you vi=
a the TTL of the=0D=0Aservice boundary), you may have to find those locatio=
ns affected by the=0D=0Achange when they request a new location URI. =20=0D=
=0A=0D=0AIn the countries where there are multiple services, there are only=
 a few=0D=0A(sometimes one) ESRPs.=0D=0A=0D=0AThere could be some theoretic=
 case of lots of ESRPs and lots of services, in=0D=0Awhich case there are m=
ore intersections, but the calculation is simple,=0D=0Afairly quick, and th=
e TTLs make it easy to determine when a change is made,=0D=0Aand several pr=
etty straightforward strategies are available to minimize the=0D=0Awork on =
the LIS.=0D=0A=0D=0ABrian=0D=0A=0D=0A> -----Original Message-----=0D=0A> Fr=
om: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: Saturday,=
 December 08, 2007 6:39 PM=0D=0A> To: Henning Schulzrinne; Stark, Barbara=0D=
=0A> Cc: ecrit@ietf.org; Liess, Laura=0D=0A> Subject: RE: AW: [Ecrit] Locat=
ion Hiding -- State of the Art=0D=0A>=20=0D=0A> Hi all,=0D=0A>=20=0D=0A> Ev=
erything is qualified on what ultimately gets regulated. But it's=0D=0A> pr=
obably time to discuss real world implications of this topic.=0D=0A>=20=0D=0A=
> I expect that, if access operators are required to provide location, it i=
s=0D=0A> only going to be for the purpose of emergency services. I doubt th=
at=0D=0A> regulators will even consider mandating that they provide it for =
all users=0D=0A> for all purposes. There'll be no sledgehammer to force acc=
ess providers to=0D=0A> give everyone a free location service - so it won't=
 happen until operators=0D=0A> have their own reasons to do so.=0D=0A>=20=0D=
=0A> Since access providers can't control what client devices actually use=0D=
=0A> location information for, they will only implement a system that permi=
ts a=0D=0A> recognised emergency entity to retrieve the actual location val=
ue. They'll=0D=0A> only give the end subscriber location information if tha=
t's already paid=0D=0A> for as part of the subscription.=0D=0A>=20=0D=0A> T=
he fundamental problem with the "do location hiding by providing=0D=0A> loc=
ation" proposal is exactly that. It fails to hide location. This is=0D=0A> =
particularly the case in the US (which is a difficult market to ignore).=0D=
=0A> The intersection of every possible service area - also called an ESN o=
r=0D=0A> ESZ - in the US is a quite granular area; certainly good for quite=
 a lot=0D=0A> of services. For a mobile access provider, in particular, a c=
onsiderable=0D=0A> amount of capital equipment is going to be invoked to pr=
ovide this quite=0D=0A> good location information.=0D=0A>=20=0D=0A> On the =
other hand, in many other countries (e.g. the UK and Australia)=0D=0A> this=
 technique is probably not problematic for the carrier, because they=0D=0A>=
 are just going to return the country code. That's as granular as you need=0D=
=0A> to be for emergency services.=0D=0A>=20=0D=0A> So here's what will hap=
pen if this is the official IETF recommendation. It=0D=0A> may get adopted =
but operators will limit the provided location information=0D=0A> to just t=
he country indicator. They'll do this in the US as well (they'll=0D=0A> ref=
use to process all the LoST boundary data and take responsibility for=0D=0A=
> consequent routing outcome). This means that VSPs dealing with calls=0D=0A=
> originating in the US will need to use i2. This is because the V2=0D=0A> =
interface in i2 does support a location reference while LoST is unable to=0D=
=0A> do this. The country information will certainly be useful for arbitrat=
ing=0D=0A> which VPC to use though - so that's good. It will mean that dire=
ct to PSAP=0D=0A> calls won't be able to be made in the US. That's a shame.=
 Other=0D=0A> jurisdictions that only have a single PSAP route will be able=
 to support=0D=0A> this. OTOH, it might force the US to provide a federal l=
evel URI with=0D=0A> proxies that can subsequently do the dereference and l=
ower level routing -=0D=0A> so maybe it's not such a shame. It won't result=
 in access providers giving=0D=0A> free location information until they are=
 ready to do so however.=0D=0A>=20=0D=0A> Editorial and a genuine question:=0D=
=0A>=20=0D=0A> IMO, supporting the services URI extension in HELD or adding=
 location=0D=0A> reference support to LoST are both superior engineering so=
lutions. They=0D=0A> just aren't driven by the punitive motivations of the =
"hide by not hiding"=0D=0A> proposal. Arguments that they are inferior beca=
use they require protocol=0D=0A> changes are specious and self-fulfilling. =
That's why the "reference query"=0D=0A> mechanism for LoST was "postponed" =
in the interest of getting LoST=0D=0A> finalized. It continues to be used a=
s a prop for this particular hiding=0D=0A> proposal. By this line of argume=
nt, we would never add or modify protocols=0D=0A> for anything.=0D=0A>=20=0D=
=0A> It's very difficult not to lapse into sarcasm in this area (I feel lik=
e=0D=0A> saying it's OK not to have location hiding because Columbia Univer=
sity and=0D=0A> Cisco are going to underwrite the cost of providing a 5x9s =
reliable=0D=0A> ubiquitous location service in all public access networks o=
ut of pure=0D=0A> philanthropy.... but I won't :) ).=0D=0A>=20=0D=0A> Insis=
ting on providing location for all applications is like insisting=0D=0A> th=
at cellular operators let users call anyone just to ensure that they can=0D=
=0A> also make emergency calls. In this hypothetical situation, refusing to=0D=
=0A> define protocol mechanisms that permit them to distinguish between the=0D=
=0A> scenarios would only result in there being no cellular service - or ju=
st=0D=0A> publicly funded cellular services. It's a counter-productive atti=
tude.=0D=0A>=20=0D=0A> This provides the opportunity for me to once more as=
k a question that=0D=0A> hasn't been responded to in the past. Why is ECRIT=
 describing a solution=0D=0A> that has the VSP involved in the emergency ca=
ll at all=3F Why would the VSP=0D=0A> want to be involved in emergency call=
s - and why would the caller want=0D=0A> them involved=3F It seems to be no=
t in the interest of either party. There's=0D=0A> already an interim archit=
ecture for the non "end-to-end IP" scenario=0D=0A> called i2. In any circum=
stance where any of the device, the network, or=0D=0A> emergency operator a=
re not ECRIT-capable, then the VSP does need to be=0D=0A> involved and i2 i=
s a valid fallback.=0D=0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A>=
 -----Original Message-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs=
=2Ecolumbia.edu]=0D=0A> Sent: Saturday, 8 December 2007 8:56 AM=0D=0A> To: =
Stark, Barbara=0D=0A> Cc: ecrit@ietf.org; Liess, Laura=0D=0A> Subject: Re: =
AW: [Ecrit] Location Hiding -- State of the Art=0D=0A>=20=0D=0A> Translatio=
n: You have more lobbyists than I (or the IETF), so give me.=0D=0A> Thanks =
for clarifying that.=0D=0A>=20=0D=0A> Henning=0D=0A>=20=0D=0A> On Dec 7, 20=
07, at 4:24 PM, Stark, Barbara wrote:=0D=0A>=20=0D=0A> > [The following sta=
tements are my opinion, and should not be=0D=0A> > attributed to the compan=
y I work for.]=0D=0A> >=0D=0A> > Henning,=0D=0A> > It's true that the IETF =
doesn't have to do something just because=0D=0A> > someone wants it. It's a=
lso true that the IETF has no authority or=0D=0A> > ability to force implem=
entation of RFCs by companies who refuse to=0D=0A> > implement them. You ca=
nnot shove a solution down the throats of=0D=0A> > access providers that th=
ey are unwilling to buy in to. In my=0D=0A> > opinion, even attempting to d=
o so would be, well, unethical.=0D=0A> >=0D=0A> > So, you have a choice:=0D=
=0A> > 1) create a solution that you like that major stakeholders are=0D=0A=
> > unwilling to implement=0D=0A> > 2) create a solution that you don't qui=
te like, but that's better=0D=0A> > than what we have today, and which majo=
r stakeholders are willing to=0D=0A> > implement=0D=0A> >=0D=0A> > Believe =
it or not, major telecom companies in the US and Europe put=0D=0A> > a lot =
of effort into lobbying regulatory bodies, to achieve=0D=0A> > desirable ou=
tcomes. The IETF doesn't put in such effort. If you want=0D=0A> > to make a=
 go at pushing through a solution that stakeholders in=0D=0A> > these regio=
ns are set against, and see if you can get regulatory=0D=0A> > agencies to =
bless it, then go for it. I think the odds are stacked=0D=0A> > against you=
, though. Especially since there are workable solutions=0D=0A> > that these=
 companies have said they would be willing to accept.=0D=0A> >=0D=0A> > Her=
e is why mobile access providers "cannot" provide the best=0D=0A> > availab=
le location directly to end user devices: They don't want to.=0D=0A> > At t=
his point in time, it's their network, their data, and their=0D=0A> > choic=
e.=0D=0A> >=0D=0A> > In free market economies, you generally have to be abl=
e to *prove*=0D=0A> > (and not just say it without proof) massive benefit o=
r massive harm=0D=0A> > before you can force companies to do what they don'=
t want to do,=0D=0A> > through regulation. Again, if you think you can take=
 on that battle=0D=0A> > and win, go for it.=0D=0A> >=0D=0A> > I, for one, =
believe that not providing the "real" location value to=0D=0A> > end device=
s would not cause such benefit or harm. If users want to=0D=0A> > know what=
 location PSAPs get on their behalf, and regulators believe=0D=0A> > such a=
 capability is needed, then we can let the phonebcp-described=0D=0A> > test=
 mechanism voice it back over the voice medium (this would only=0D=0A> > wo=
rk for civic), or return a JPEG map with a dot on it. This would=0D=0A> > p=
rovide location in a format that's usable by a human being, but not=0D=0A> =
> an application. Or maybe, in some countries, the regulators do=0D=0A> > r=
equire access providers to give out the best possible location=0D=0A> > val=
ues to end devices. But it's really improbable that you could=0D=0A> > forc=
e the regulators of all countries to see things your way.=0D=0A> >=0D=0A> >=
 But, this is all just my opinion.=0D=0A> > Barbara=0D=0A> >=0D=0A> > -----=
Original Message-----=0D=0A> > From: Henning Schulzrinne [mailto:hgs@cs.col=
umbia.edu]=0D=0A> > Sent: Friday, December 07, 2007 12:13 PM=0D=0A> > To: L=
iess, Laura=0D=0A> > Cc: ecrit@ietf.org=0D=0A> > Subject: Re: AW: [Ecrit] L=
ocation Hiding -- State of the Art=0D=0A> >=0D=0A> > Laura,=0D=0A> >=0D=0A>=
 > just because somebody says "we need it" doesn't make it an IETF=0D=0A> >=
 requirement. Please justify why mobile access cannot provide locations=0D=0A=
> > to end users.=0D=0A> >=0D=0A> > Henning=0D=0A> >=0D=0A> > On Dec 6, 200=
7, at 10:10 PM, Liess, Laura wrote:=0D=0A> >=0D=0A> >> Brian,=0D=0A> >>=0D=0A=
> >> I checked with my company and we need LH for both civic and geo for=0D=
=0A> >> fixed and mobile access. Only DSL and civic is not an option.=0D=0A=
> >>=0D=0A> >> I would support sending the ESRP/PSAP URI to the UA, as prop=
osed by=0D=0A> >> Barbara and James some weeks ago.=0D=0A> >>=0D=0A> >> Lau=
ra=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >> -----Urspr=FCngliche Nachricht--=
---=0D=0A> >> Von: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> >> Gesende=
t: Dienstag, 4. Dezember 2007 16:37=0D=0A> >> An: 'Hannes Tschofenig'=0D=0A=
> >> Cc: 'ECRIT'=0D=0A> >> Betreff: RE: [Ecrit] Location Hiding -- State of=
 the Art=0D=0A> >>=0D=0A> >> Proposed text for framework=0D=0A> >>=0D=0A> >=
> Some access networks wish to restrict who can get a high quality=0D=0A> >=
> location,=0D=0A> >> possibly based on a payment arrangement.  For emergen=
cy calls, high=0D=0A> >> quality=0D=0A> >> location must be provided.  An a=
ccess network can reasonably be=0D=0A> >> expected to=0D=0A> >> have a rela=
tionship with the PSAPs in its catchment area, so giving=0D=0A> >> location=0D=
=0A> >> to the PSAP will be straightforward=0D=0A> >>=0D=0A> >>=0D=0A> >> H=
owever, an endpoint may need location=0D=0A> >> for routing, and a proxy ma=
y need to verify that a purported=0D=0A> >> emergency call=0D=0A> >> is tar=
geted at a bona fide PSAP.  To do so, it may take the location=0D=0A> >> pa=
ssed=0D=0A> >> with the call and query LoST to confirm that the URI is genu=
ine.=0D=0A> >> "Hiding"=0D=0A> >> location interferes with this check.  To =
achieve location hiding,=0D=0A> >> the LIS=0D=0A> >> can return a coarse lo=
cation which is good enough to elicit the same=0D=0A> >> response from LoST=
 as the actual location would.  The endpoint and=0D=0A> >> the proxy=0D=0A>=
 >> can use this location to route and verify.  A suitable location for=0D=0A=
> >> a geo is=0D=0A> >> a polygon calculated by intersecting the service bo=
undaries of all=0D=0A> >> of the=0D=0A> >> emergency services that respond =
to the actual location.  A suitable=0D=0A> >> location=0D=0A> >> for a civi=
c is any civic location within the intersection of the=0D=0A> >> service=0D=
=0A> >> boundaries of emergency services.  In a great many cases, a country=0D=
=0A> >> code is=0D=0A> >> sufficient.  In others a state/province or a city=
 name is=0D=0A> >> sufficient.  Of=0D=0A> >> course, the LIS would always r=
eturn a location reference, which=0D=0A> >> would return=0D=0A> >> high qua=
lity location for a PSAP and coarse location to the endpoint=0D=0A> >> or a=
ny=0D=0A> >> proxy unknown to the LIS.=0D=0A> >>=0D=0A> >> Proposed text fo=
r phonebcp:=0D=0A> >>=0D=0A> >> A LIS who wishes to hide location returns a=
 location reference.  When=0D=0A> >> dereferenced by the endpoint or proxy:=0D=
=0A> >> 1. For LIS's returning geo:=0D=0A> >>   For each location served by=
 the LIS, compute the intersection of=0D=0A> >> the=0D=0A> >>   service bou=
ndaries for all emergency services known to LoST for the=0D=0A> >>   locati=
on. Return the resulting polygon, or any point in the=0D=0A> >> polygon as=0D=
=0A> >>   the value during a dereference=0D=0A> >> 2. For LIS's returning c=
ivic:=0D=0A> >>   Determine a civic location which is within the service bo=
undary=0D=0A> >> of all=0D=0A> >>   emergency services known to LoST for th=
e location.  In a great many=0D=0A> >>   cases, this will be a country code=
, province/state or city.=0D=0A> >> Return this=0D=0A> >>   coarse civic lo=
cation as the value during a dereference=0D=0A> >> Note that the service bo=
undaries returned from LoST have a TTL, the=0D=0A> >> intersections MUST re=
calculated if the service boundary changes.=0D=0A> >> The LIS=0D=0A> >> MUS=
T return high quality location to a PSAP or ESRP.=0D=0A> >>=0D=0A> >> Brian=0D=
=0A> >>=0D=0A> >>> -----Original Message-----=0D=0A> >>> From: Hannes Tscho=
fenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >>> Sent: Monday, December =
03, 2007 1:38 PM=0D=0A> >>> To: Brian Rosen=0D=0A> >>> Cc: 'James M. Polk';=
 'Stark, Barbara'; 'ECRIT'=0D=0A> >>> Subject: Re: [Ecrit] Location Hiding =
-- State of the Art=0D=0A> >>>=0D=0A> >>> Hi Brian,=0D=0A> >>>=0D=0A> >>> B=
rian Rosen wrote:=0D=0A> >>>> It's fine with me if there is a separate doc,=
 but framework and=0D=0A> >>>> phonebcp=0D=0A> >>>> have to reference it.=0D=
=0A> >>>>=0D=0A> >>> Are we talking about informative or normative referenc=
es=3F=0D=0A> >>>> I think it can be solved with a one paragraph description=
 of the=0D=0A> >>>> problem=0D=0A> >>> in=0D=0A> >>>> framework and a one p=
aragraph solution in phonebcp, but if there=0D=0A> >>>> is a=0D=0A> >>>> se=
parate doc and a reference, I will be happy.=0D=0A> >>>>=0D=0A> >>> That do=
es not make sense.=0D=0A> >>> The solution is not one paragraph and the tex=
t in phone bcp is=0D=0A> >>> normative.=0D=0A> >>>=0D=0A> >>> Ciao=0D=0A> >=
>> Hannes=0D=0A> >>>=0D=0A> >>>> Brian=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>>>=
 -----Original Message-----=0D=0A> >>>>> From: James M. Polk [mailto:jmpolk=
@cisco.com]=0D=0A> >>>>> Sent: Monday, December 03, 2007 7:37 PM=0D=0A> >>>=
>> To: Stark, Barbara; Hannes Tschofenig; ECRIT=0D=0A> >>>>> Subject: RE: [=
Ecrit] Location Hiding -- State of the Art=0D=0A> >>>>>=0D=0A> >>>>> Curren=
tly, the WG (and document editors!) should be operating=0D=0A> >>>>> under=0D=
=0A> >>>>> the consensus direction that Location Hiding *not* be in PhoneBC=
P=0D=0A> >>>>> or=0D=0A> >>>>> Framework.  This was a clear consensus call =
in Chicago - and not=0D=0A> >>>>> by=0D=0A> >>>>> default, but by most peop=
le voicing actively against having this=0D=0A> >>>>> Hiding in either core =
ECRIT documents, and I haven't yet talked to=0D=0A> >>>>> anyone here in Va=
ncouver that thinks otherwise.=0D=0A> >>>>>=0D=0A> >>>>> Location Hiding is=
 something that needs to be addressed BY ITSELF=0D=0A> >>>>> (i.e., in its =
own doc) so everyone can focus on the singular=0D=0A> >>>>> topic,=0D=0A> >=
>>>> and work towards not talking past each other (not like that's=0D=0A> >=
>>>> happened before in ECRIT....  :-/=0D=0A> >>>>>=0D=0A> >>>>> Who disagr=
ees with this=3F=0D=0A> >>>>>=0D=0A> >>>>> BTW - if someone thinks Location=
 Hiding should be put back into=0D=0A> >>>>> PhoneBCP or Framework, then th=
ey can attempt to gain WG consensus=0D=0A> >>>>> on=0D=0A> >>>>> that, but =
that's different than a direction of this inevitability=0D=0A> >>>>> or=0D=0A=
> >>>>> that there is not consensus on this.=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A=
> >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:=0D=0A> >>>>>=0D=0A> >>=
>>>> If people felt this was good enough so that access providers=0D=0A> >>=
>>>> would not=0D=0A> >>>>>> need to be required to build the infrastructur=
e to provide=0D=0A> >>>>>> location=0D=0A> >>>>>> (because people could use=
 this method instead of getting=0D=0A> >>>>>> location from=0D=0A> >>>>>> a=
ccess providers), then location hiding would be dead. If people=0D=0A> >>>>=
>> still=0D=0A> >>>>>> want to place a requirement on access providers to p=
rovide=0D=0A> >>>>>> location,=0D=0A> >>>>>> then location hiding is not de=
ad.=0D=0A> >>>>>> Barbara=0D=0A> >>>>>>=0D=0A> >>>>>> -----Original Message=
-----=0D=0A> >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.n=
et]=0D=0A> >>>>>> Sent: Saturday, December 01, 2007 3:34 PM=0D=0A> >>>>>> T=
o: ECRIT=0D=0A> >>>>>> Subject: [Ecrit] Location Hiding -- State of the Art=0D=
=0A> >>>>>>=0D=0A> >>>>>> I thought that the following article would be of =
interest for=0D=0A> >>>>>> you:=0D=0A> >>>>>> http://googleblog.blogspot.co=
m/2007/11/lost-no-found.html=0D=0A> >>>>>>=0D=0A> >>>>>> Here is text from=0D=
=0A> >>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-blue-circl=
e-=0D=0A> on-=0D=0A> >>> your=0D=0A> >>>>>> -map.html=0D=0A> >>>>>> "=0D=0A=
> >>>>>> My Location is a new beta technology from Google that uses cell=0D=
=0A> >>>>>> tower=0D=0A> >>>>>> identification to provide you with approxim=
ate location=0D=0A> >>>>>> information,=0D=0A> >>> so=0D=0A> >>>>>> it will=
 work on phones without GPS.=0D=0A> >>>>>> "=0D=0A> >>>>>> Note that this s=
tuff is not really new technology. It existed=0D=0A> >>>>>> already=0D=0A> =
>>>>>> for some time but the availability of GPS devices made it=0D=0A> >>>=
>>> possible to=0D=0A> >>>>>> setup the database in a more efficient way.=0D=
=0A> >>>>>>=0D=0A> >>>>>> Anyway, this mechanism allows you to obtain locat=
ion information=0D=0A> >>>>>> with=0D=0A> >>>>>> your cell phone (using the=
 cell id) without interacting with the=0D=0A> >>>>>> cellular operator.=0D=0A=
> >>>>>> In short: operator cannot charge for location=0D=0A> >>>>>>=0D=0A>=
 >>>>>> While the location information is not really useful for first=0D=0A=
> >>> responders=0D=0A> >>>>>>=0D=0A> >>>>>> it is still good enough for fi=
nding the closest PSAP.=0D=0A> >>>>>>=0D=0A> >>>>>> Is this the dead of loc=
ation hiding=3F=0D=0A> >>>>>>=0D=0A> >>>>>> Ciao=0D=0A> >>>>>> Hannes=0D=0A=
> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>> ______________________________________=
_________=0D=0A> >>>>>> Ecrit mailing list=0D=0A> >>>>>> Ecrit@ietf.org=0D=0A=
> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >>>>>>=0D=0A> =
>>>>>> _______________________________________________=0D=0A> >>>>>> Ecrit =
mailing list=0D=0A> >>>>>> Ecrit@ietf.org=0D=0A> >>>>>> https://www1.ietf.o=
rg/mailman/listinfo/ecrit=0D=0A> >>>>>>=0D=0A> >>>>> ______________________=
_________________________=0D=0A> >>>>> Ecrit mailing list=0D=0A> >>>>> Ecri=
t@ietf.org=0D=0A> >>>>> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=
 >>>>>=0D=0A> >>=0D=0A> >>=0D=0A> >> ______________________________________=
_________=0D=0A> >> Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> h=
ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >>=0D=0A> >> ___________=
____________________________________=0D=0A> >> Ecrit mailing list=0D=0A> >>=
 Ecrit@ietf.org=0D=0A> >> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=
> >=0D=0A> >=0D=0A> > _______________________________________________=0D=0A=
> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.o=
rg/mailman/listinfo/ecrit=0D=0A> >=0D=0A> > *****=0D=0A> >=0D=0A> > The inf=
ormation transmitted is intended only for the person or=0D=0A> > entity to =
which it is addressed and may contain confidential,=0D=0A> > proprietary, a=
nd/or privileged material. Any review, retransmission,=0D=0A> > disseminati=
on or other use of, or taking of any action in reliance=0D=0A> > upon this =
information by persons or entities other than the intended=0D=0A> > recipie=
nt is prohibited. If you received this in error, please=0D=0A> > contact th=
e sender and delete the material from all computers. GA622=0D=0A> >=0D=0A> =
>=0D=0A>=20=0D=0A>=20=0D=0A> ______________________________________________=
_=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.=
org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A> -------------------------------=
-------------------------------------------=0D=0A> ----------------------=0D=
=0A> This message is for the designated recipient only and may=0D=0A> conta=
in privileged, proprietary, or otherwise private information.=0D=0A> If you=
 have received it in error, please notify the sender=0D=0A> immediately and=
 delete the original.  Any unauthorized use of=0D=0A> this email is prohibi=
ted.=0D=0A> ---------------------------------------------------------------=
-----------=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A>=20=0D=0A>=20=0D=
=0A> _______________________________________________=0D=0A> Ecrit mailing l=
ist=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecr=
it=0D=0A=0D=0A=0D=0A_______________________________________________=0D=0AEc=
rit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/lis=
tinfo/ecrit=0D=0A=0D=0A----------------------------------------------------=
--------------------------------------------=0D=0AThis message is for the d=
esignated recipient only and may=0D=0Acontain privileged, proprietary, or o=
therwise private information. =20=0D=0AIf you have received it in error, pl=
ease notify the sender=0D=0Aimmediately and delete the original.  Any unaut=
horized use of=0D=0Athis email is prohibited.=0D=0A------------------------=
------------------------------------------------------------------------=0D=
=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 10 19:02:28 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1sZu-0008Bg-IF; Mon, 10 Dec 2007 19:02:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1sZs-0008Am-KU
	for ecrit@ietf.org; Mon, 10 Dec 2007 19:02:24 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1sZs-0003w2-45
	for ecrit@ietf.org; Mon, 10 Dec 2007 19:02:24 -0500
Received: (qmail invoked by alias); 11 Dec 2007 00:02:22 -0000
Received: from p549867C5.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.103.197]
	by mail.gmx.net (mp005) with SMTP; 11 Dec 2007 01:02:22 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18N3MlzRQMNUP4wziwemxnCa5ZQivLgPfoxvoY6sC
	/DO3at/JUuSQ5g
Message-ID: <475DD38E.5060207@gmx.net>
Date: Tue, 11 Dec 2007 01:02:22 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: ECRIT 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Subject: [Ecrit] Meeting Minutes
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Roger compiled the meeting minutes.
Here they are:
http://www3.ietf.org/proceedings/07dec/minutes/ecrit.txt

Comments?

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 08:52:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J25XX-0006gQ-C6; Tue, 11 Dec 2007 08:52:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J25XW-0006g8-7z
	for ecrit@ietf.org; Tue, 11 Dec 2007 08:52:50 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J25XT-0000PK-VU
	for ecrit@ietf.org; Tue, 11 Dec 2007 08:52:50 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J25XK-0004GA-UQ; Tue, 11 Dec 2007 07:52:39 -0600
From: "Brian Rosen" 
To: "'Dawson, Martin'" ,
	"'Henning Schulzrinne'" ,
	"'Stark, Barbara'" 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc41p><069a01c83617$a66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$96348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 08:52:39 -0500
Message-ID: <058301c83bfd$1a6dfe80$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: 
Thread-Index: Acg5G/dvD2upzxVjROq9pzRTtoHnpwA0CLcgAFP5mnAAEOl44AAe6HtQ
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: aafd3813f49c1dfb11e9623a3ab5d812
Cc: ecrit@ietf.org, "'Liess, Laura'" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Speaking only about the U.S.:
There is one emergency service (urn:service:sos).  That=92s the only =
URN, and
thus for any location, you only need one service boundary; the one that
urn:service:sos returns for a given location.

There will be on the order of 50 ESRPs, roughly state level.  There may =
be
some areas that are smaller than a state, there may be some areas =
covering
more than a state.  That means a LoST server covering the entire U.S. =
would
have roughly 50 service boundaries that don't overlap.  We see a local =
9-1-1
authority (which is most often at roughly county level) will provide =
LoST
services in its service area.  All the locations in that service area =
would
point to the state level ESRP for an endpoint, access network or VSP =
query.

In those areas, it would be sufficient to return, for example, the state
name as the civic address.  Even where the actual service boundary =
doesn't
cover the state precisely, returning the state level will get the =
correct
route.

That won't work everywhere.  For example, it's pretty likely that New =
York
City would run its own ESRP.  In that case, returning the city name (and
state) would be needed.

There clearly WILL be exceptions to this; I'm just describing how NENA
believes the provisioning of ESRPs will be done.  It's likely, for =
example,
that as we start deploying, it's somewhat more complex.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Monday, December 10, 2007 6:01 PM
> To: Brian Rosen; Henning Schulzrinne; Stark, Barbara
> Cc: ecrit@ietf.org; Liess, Laura
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Sorry to rewind the thread - somebody said something about "ordering
> drinks" at the beginning of the conversation (HG2G).
>=20
> > The only emergency service in the U.S. is urn:service:sos.
>=20
> Can you elaborate on this? Explicitly, then, what boundary would the =
LIS
> provide for a call originating in a typical US ESZ? It sounds like =
you're
> saying it just needs to provide "the US"? What do you mean by this
> boundary "changing" in this context? How does the boundary of the US
> change?
>=20
> When was this decided - and which agency, ESP, or authority has taken
> responsibility for administering the single national URN and routing
> boundary? It's good news, but I hadn't heard it had occured.
>=20
> Cheers,
> Martin
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Tuesday, 11 December 2007 1:57 AM
> To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'
> Cc: ecrit@ietf.org; 'Liess, Laura'
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> The only emergency service in the U.S. is urn:service:sos.  There is =
only
> one boundary and if it changes (which LoST tells you via the TTL of =
the
> service boundary), you may have to find those locations affected by =
the
> change when they request a new location URI.
>=20
> In the countries where there are multiple services, there are only a =
few
> (sometimes one) ESRPs.
>=20
> There could be some theoretic case of lots of ESRPs and lots of =
services,
> in
> which case there are more intersections, but the calculation is =
simple,
> fairly quick, and the TTLs make it easy to determine when a change is
> made,
> and several pretty straightforward strategies are available to =
minimize
> the
> work on the LIS.
>=20
> Brian
>=20
> > -----Original Message-----
> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > Sent: Saturday, December 08, 2007 6:39 PM
> > To: Henning Schulzrinne; Stark, Barbara
> > Cc: ecrit@ietf.org; Liess, Laura
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Hi all,
> >
> > Everything is qualified on what ultimately gets regulated. But it's
> > probably time to discuss real world implications of this topic.
> >
> > I expect that, if access operators are required to provide location, =
it
> is
> > only going to be for the purpose of emergency services. I doubt that
> > regulators will even consider mandating that they provide it for all
> users
> > for all purposes. There'll be no sledgehammer to force access =
providers
> to
> > give everyone a free location service - so it won't happen until
> operators
> > have their own reasons to do so.
> >
> > Since access providers can't control what client devices actually =
use
> > location information for, they will only implement a system that =
permits
> a
> > recognised emergency entity to retrieve the actual location value.
> They'll
> > only give the end subscriber location information if that's already =
paid
> > for as part of the subscription.
> >
> > The fundamental problem with the "do location hiding by providing
> > location" proposal is exactly that. It fails to hide location. This =
is
> > particularly the case in the US (which is a difficult market to =
ignore).
> > The intersection of every possible service area - also called an ESN =
or
> > ESZ - in the US is a quite granular area; certainly good for quite a =
lot
> > of services. For a mobile access provider, in particular, a =
considerable
> > amount of capital equipment is going to be invoked to provide this =
quite
> > good location information.
> >
> > On the other hand, in many other countries (e.g. the UK and =
Australia)
> > this technique is probably not problematic for the carrier, because =
they
> > are just going to return the country code. That's as granular as you
> need
> > to be for emergency services.
> >
> > So here's what will happen if this is the official IETF =
recommendation.
> It
> > may get adopted but operators will limit the provided location
> information
> > to just the country indicator. They'll do this in the US as well
> (they'll
> > refuse to process all the LoST boundary data and take responsibility =
for
> > consequent routing outcome). This means that VSPs dealing with calls
> > originating in the US will need to use i2. This is because the V2
> > interface in i2 does support a location reference while LoST is =
unable
> to
> > do this. The country information will certainly be useful for
> arbitrating
> > which VPC to use though - so that's good. It will mean that direct =
to
> PSAP
> > calls won't be able to be made in the US. That's a shame. Other
> > jurisdictions that only have a single PSAP route will be able to =
support
> > this. OTOH, it might force the US to provide a federal level URI =
with
> > proxies that can subsequently do the dereference and lower level =
routing
> -
> > so maybe it's not such a shame. It won't result in access providers
> giving
> > free location information until they are ready to do so however.
> >
> > Editorial and a genuine question:
> >
> > IMO, supporting the services URI extension in HELD or adding =
location
> > reference support to LoST are both superior engineering solutions. =
They
> > just aren't driven by the punitive motivations of the "hide by not
> hiding"
> > proposal. Arguments that they are inferior because they require =
protocol
> > changes are specious and self-fulfilling. That's why the "reference
> query"
> > mechanism for LoST was "postponed" in the interest of getting LoST
> > finalized. It continues to be used as a prop for this particular =
hiding
> > proposal. By this line of argument, we would never add or modify
> protocols
> > for anything.
> >
> > It's very difficult not to lapse into sarcasm in this area (I feel =
like
> > saying it's OK not to have location hiding because Columbia =
University
> and
> > Cisco are going to underwrite the cost of providing a 5x9s reliable
> > ubiquitous location service in all public access networks out of =
pure
> > philanthropy.... but I won't :) ).
> >
> > Insisting on providing location for all applications is like =
insisting
> > that cellular operators let users call anyone just to ensure that =
they
> can
> > also make emergency calls. In this hypothetical situation, refusing =
to
> > define protocol mechanisms that permit them to distinguish between =
the
> > scenarios would only result in there being no cellular service - or =
just
> > publicly funded cellular services. It's a counter-productive =
attitude.
> >
> > This provides the opportunity for me to once more ask a question =
that
> > hasn't been responded to in the past. Why is ECRIT describing a =
solution
> > that has the VSP involved in the emergency call at all? Why would =
the
> VSP
> > want to be involved in emergency calls - and why would the caller =
want
> > them involved? It seems to be not in the interest of either party.
> There's
> > already an interim architecture for the non "end-to-end IP" scenario
> > called i2. In any circumstance where any of the device, the network, =
or
> > emergency operator are not ECRIT-capable, then the VSP does need to =
be
> > involved and i2 is a valid fallback.
> >
> > Cheers,
> > Martin
> >
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Saturday, 8 December 2007 8:56 AM
> > To: Stark, Barbara
> > Cc: ecrit@ietf.org; Liess, Laura
> > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Translation: You have more lobbyists than I (or the IETF), so give =
me.
> > Thanks for clarifying that.
> >
> > Henning
> >
> > On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:
> >
> > > [The following statements are my opinion, and should not be
> > > attributed to the company I work for.]
> > >
> > > Henning,
> > > It's true that the IETF doesn't have to do something just because
> > > someone wants it. It's also true that the IETF has no authority or
> > > ability to force implementation of RFCs by companies who refuse to
> > > implement them. You cannot shove a solution down the throats of
> > > access providers that they are unwilling to buy in to. In my
> > > opinion, even attempting to do so would be, well, unethical.
> > >
> > > So, you have a choice:
> > > 1) create a solution that you like that major stakeholders are
> > > unwilling to implement
> > > 2) create a solution that you don't quite like, but that's better
> > > than what we have today, and which major stakeholders are willing =
to
> > > implement
> > >
> > > Believe it or not, major telecom companies in the US and Europe =
put
> > > a lot of effort into lobbying regulatory bodies, to achieve
> > > desirable outcomes. The IETF doesn't put in such effort. If you =
want
> > > to make a go at pushing through a solution that stakeholders in
> > > these regions are set against, and see if you can get regulatory
> > > agencies to bless it, then go for it. I think the odds are stacked
> > > against you, though. Especially since there are workable solutions
> > > that these companies have said they would be willing to accept.
> > >
> > > Here is why mobile access providers "cannot" provide the best
> > > available location directly to end user devices: They don't want =
to.
> > > At this point in time, it's their network, their data, and their
> > > choice.
> > >
> > > In free market economies, you generally have to be able to *prove*
> > > (and not just say it without proof) massive benefit or massive =
harm
> > > before you can force companies to do what they don't want to do,
> > > through regulation. Again, if you think you can take on that =
battle
> > > and win, go for it.
> > >
> > > I, for one, believe that not providing the "real" location value =
to
> > > end devices would not cause such benefit or harm. If users want to
> > > know what location PSAPs get on their behalf, and regulators =
believe
> > > such a capability is needed, then we can let the =
phonebcp-described
> > > test mechanism voice it back over the voice medium (this would =
only
> > > work for civic), or return a JPEG map with a dot on it. This would
> > > provide location in a format that's usable by a human being, but =
not
> > > an application. Or maybe, in some countries, the regulators do
> > > require access providers to give out the best possible location
> > > values to end devices. But it's really improbable that you could
> > > force the regulators of all countries to see things your way.
> > >
> > > But, this is all just my opinion.
> > > Barbara
> > >
> > > -----Original Message-----
> > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > Sent: Friday, December 07, 2007 12:13 PM
> > > To: Liess, Laura
> > > Cc: ecrit@ietf.org
> > > Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > Laura,
> > >
> > > just because somebody says "we need it" doesn't make it an IETF
> > > requirement. Please justify why mobile access cannot provide =
locations
> > > to end users.
> > >
> > > Henning
> > >
> > > On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:
> > >
> > >> Brian,
> > >>
> > >> I checked with my company and we need LH for both civic and geo =
for
> > >> fixed and mobile access. Only DSL and civic is not an option.
> > >>
> > >> I would support sending the ESRP/PSAP URI to the UA, as proposed =
by
> > >> Barbara and James some weeks ago.
> > >>
> > >> Laura
> > >>
> > >>
> > >>
> > >> -----Urspr=FCngliche Nachricht-----
> > >> Von: Brian Rosen [mailto:br@brianrosen.net]
> > >> Gesendet: Dienstag, 4. Dezember 2007 16:37
> > >> An: 'Hannes Tschofenig'
> > >> Cc: 'ECRIT'
> > >> Betreff: RE: [Ecrit] Location Hiding -- State of the Art
> > >>
> > >> Proposed text for framework
> > >>
> > >> Some access networks wish to restrict who can get a high quality
> > >> location,
> > >> possibly based on a payment arrangement.  For emergency calls, =
high
> > >> quality
> > >> location must be provided.  An access network can reasonably be
> > >> expected to
> > >> have a relationship with the PSAPs in its catchment area, so =
giving
> > >> location
> > >> to the PSAP will be straightforward
> > >>
> > >>
> > >> However, an endpoint may need location
> > >> for routing, and a proxy may need to verify that a purported
> > >> emergency call
> > >> is targeted at a bona fide PSAP.  To do so, it may take the =
location
> > >> passed
> > >> with the call and query LoST to confirm that the URI is genuine.
> > >> "Hiding"
> > >> location interferes with this check.  To achieve location hiding,
> > >> the LIS
> > >> can return a coarse location which is good enough to elicit the =
same
> > >> response from LoST as the actual location would.  The endpoint =
and
> > >> the proxy
> > >> can use this location to route and verify.  A suitable location =
for
> > >> a geo is
> > >> a polygon calculated by intersecting the service boundaries of =
all
> > >> of the
> > >> emergency services that respond to the actual location.  A =
suitable
> > >> location
> > >> for a civic is any civic location within the intersection of the
> > >> service
> > >> boundaries of emergency services.  In a great many cases, a =
country
> > >> code is
> > >> sufficient.  In others a state/province or a city name is
> > >> sufficient.  Of
> > >> course, the LIS would always return a location reference, which
> > >> would return
> > >> high quality location for a PSAP and coarse location to the =
endpoint
> > >> or any
> > >> proxy unknown to the LIS.
> > >>
> > >> Proposed text for phonebcp:
> > >>
> > >> A LIS who wishes to hide location returns a location reference.  =
When
> > >> dereferenced by the endpoint or proxy:
> > >> 1. For LIS's returning geo:
> > >>   For each location served by the LIS, compute the intersection =
of
> > >> the
> > >>   service boundaries for all emergency services known to LoST for =
the
> > >>   location. Return the resulting polygon, or any point in the
> > >> polygon as
> > >>   the value during a dereference
> > >> 2. For LIS's returning civic:
> > >>   Determine a civic location which is within the service boundary
> > >> of all
> > >>   emergency services known to LoST for the location.  In a great =
many
> > >>   cases, this will be a country code, province/state or city.
> > >> Return this
> > >>   coarse civic location as the value during a dereference
> > >> Note that the service boundaries returned from LoST have a TTL, =
the
> > >> intersections MUST recalculated if the service boundary changes.
> > >> The LIS
> > >> MUST return high quality location to a PSAP or ESRP.
> > >>
> > >> Brian
> > >>
> > >>> -----Original Message-----
> > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > >>> Sent: Monday, December 03, 2007 1:38 PM
> > >>> To: Brian Rosen
> > >>> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> > >>> Subject: Re: [Ecrit] Location Hiding -- State of the Art
> > >>>
> > >>> Hi Brian,
> > >>>
> > >>> Brian Rosen wrote:
> > >>>> It's fine with me if there is a separate doc, but framework and
> > >>>> phonebcp
> > >>>> have to reference it.
> > >>>>
> > >>> Are we talking about informative or normative references?
> > >>>> I think it can be solved with a one paragraph description of =
the
> > >>>> problem
> > >>> in
> > >>>> framework and a one paragraph solution in phonebcp, but if =
there
> > >>>> is a
> > >>>> separate doc and a reference, I will be happy.
> > >>>>
> > >>> That does not make sense.
> > >>> The solution is not one paragraph and the text in phone bcp is
> > >>> normative.
> > >>>
> > >>> Ciao
> > >>> Hannes
> > >>>
> > >>>> Brian
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
> > >>>>> Sent: Monday, December 03, 2007 7:37 PM
> > >>>>> To: Stark, Barbara; Hannes Tschofenig; ECRIT
> > >>>>> Subject: RE: [Ecrit] Location Hiding -- State of the Art
> > >>>>>
> > >>>>> Currently, the WG (and document editors!) should be operating
> > >>>>> under
> > >>>>> the consensus direction that Location Hiding *not* be in =
PhoneBCP
> > >>>>> or
> > >>>>> Framework.  This was a clear consensus call in Chicago - and =
not
> > >>>>> by
> > >>>>> default, but by most people voicing actively against having =
this
> > >>>>> Hiding in either core ECRIT documents, and I haven't yet =
talked to
> > >>>>> anyone here in Vancouver that thinks otherwise.
> > >>>>>
> > >>>>> Location Hiding is something that needs to be addressed BY =
ITSELF
> > >>>>> (i.e., in its own doc) so everyone can focus on the singular
> > >>>>> topic,
> > >>>>> and work towards not talking past each other (not like that's
> > >>>>> happened before in ECRIT....  :-/
> > >>>>>
> > >>>>> Who disagrees with this?
> > >>>>>
> > >>>>> BTW - if someone thinks Location Hiding should be put back =
into
> > >>>>> PhoneBCP or Framework, then they can attempt to gain WG =
consensus
> > >>>>> on
> > >>>>> that, but that's different than a direction of this =
inevitability
> > >>>>> or
> > >>>>> that there is not consensus on this.
> > >>>>>
> > >>>>>
> > >>>>> At 07:23 AM 12/3/2007, Stark, Barbara wrote:
> > >>>>>
> > >>>>>> If people felt this was good enough so that access providers
> > >>>>>> would not
> > >>>>>> need to be required to build the infrastructure to provide
> > >>>>>> location
> > >>>>>> (because people could use this method instead of getting
> > >>>>>> location from
> > >>>>>> access providers), then location hiding would be dead. If =
people
> > >>>>>> still
> > >>>>>> want to place a requirement on access providers to provide
> > >>>>>> location,
> > >>>>>> then location hiding is not dead.
> > >>>>>> Barbara
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > >>>>>> Sent: Saturday, December 01, 2007 3:34 PM
> > >>>>>> To: ECRIT
> > >>>>>> Subject: [Ecrit] Location Hiding -- State of the Art
> > >>>>>>
> > >>>>>> I thought that the following article would be of interest for
> > >>>>>> you:
> > >>>>>> http://googleblog.blogspot.com/2007/11/lost-no-found.html
> > >>>>>>
> > >>>>>> Here is text from
> > >>>>>> =
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-
> > on-
> > >>> your
> > >>>>>> -map.html
> > >>>>>> "
> > >>>>>> My Location is a new beta technology from Google that uses =
cell
> > >>>>>> tower
> > >>>>>> identification to provide you with approximate location
> > >>>>>> information,
> > >>> so
> > >>>>>> it will work on phones without GPS.
> > >>>>>> "
> > >>>>>> Note that this stuff is not really new technology. It existed
> > >>>>>> already
> > >>>>>> for some time but the availability of GPS devices made it
> > >>>>>> possible to
> > >>>>>> setup the database in a more efficient way.
> > >>>>>>
> > >>>>>> Anyway, this mechanism allows you to obtain location =
information
> > >>>>>> with
> > >>>>>> your cell phone (using the cell id) without interacting with =
the
> > >>>>>> cellular operator.
> > >>>>>> In short: operator cannot charge for location
> > >>>>>>
> > >>>>>> While the location information is not really useful for first
> > >>> responders
> > >>>>>>
> > >>>>>> it is still good enough for finding the closest PSAP.
> > >>>>>>
> > >>>>>> Is this the dead of location hiding?
> > >>>>>>
> > >>>>>> Ciao
> > >>>>>> Hannes
> > >>>>>>
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> Ecrit mailing list
> > >>>>>> Ecrit@ietf.org
> > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> Ecrit mailing list
> > >>>>>> Ecrit@ietf.org
> > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > >>>>>>
> > >>>>> _______________________________________________
> > >>>>> Ecrit mailing list
> > >>>>> Ecrit@ietf.org
> > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit
> > >>>>>
> > >>
> > >>
> > >> _______________________________________________
> > >> Ecrit mailing list
> > >> Ecrit@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > >>
> > >> _______________________________________________
> > >> Ecrit mailing list
> > >> Ecrit@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > > *****
> > >
> > > 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
> > >
> > >
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> > =
------------------------------------------------------------------------
> --
> > ----------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> > =
------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
>=20
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 09:37:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J26F3-0000KQ-LM; Tue, 11 Dec 2007 09:37:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J26F1-0000KH-Se
	for ecrit@ietf.org; Tue, 11 Dec 2007 09:37:47 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J26F1-0007CX-8A
	for ecrit@ietf.org; Tue, 11 Dec 2007 09:37:47 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_08_48_49
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Tue, 11 Dec 2007 08:48:49 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 08:37:44 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 08:37:41 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7dO6UT0d1bhYIRUmCEKjmhdMDSwAiutkg
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> <	p0 624060
	5c3 8330f2cd7e@[76.126.60.89]>

From: "Winterbottom, James" 
To: "Ted Hardie" , "Stark, Barbara" ,
	"Brian Rosen" ,
	"Dawson, Martin" ,
	"Henning Schulzrinne" 
X-OriginalArrivalTime: 11 Dec 2007 14:37:44.0587 (UTC)
	FILETIME=[64543DB0:01C83C03]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: ecrit@ietf.org, "Liess, Laura" 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Hi Ted,=0D=0A=0D=0AI think you mischaracterize my position, which is that I=
 don't want to=0D=0Ado location hiding, but if some people, namely those th=
at need to deploy=0D=0Alocation in access network, say that we need it, the=
n I want it done=0D=0Aproperly and not with a half-baked solution that does=
n't really serve=0D=0Aanyone.=0D=0A=0D=0ATo that end, if we insist upon com=
pleting the framework and phone BCP=0D=0Adocuments quickly, the documents n=
eed to say that this issue, along with=0D=0Aunauthenticated access are work=
 in progress and not propose ANY=0D=0Asolution.=0D=0A=0D=0ACheers=0D=0AJame=
s=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Ted Hard=
ie [mailto:hardie@qualcomm.com]=0D=0A> Sent: Tuesday, 11 December 2007 8:38=
 AM=0D=0A> To: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Ma=
rtin;=0D=0A> Henning Schulzrinne=0D=0A> Cc: ecrit@ietf.org; Liess, Laura=0D=
=0A> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> =0D=
=0A> At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:=0D=0A> >If the d=
evice is simply given a PSAP URI, a service URN, and a=0D=0Alocation=0D=0A>=
 >URI, what more does it need=3F=0D=0A>=20=0D=0A> As several people have po=
inted out, it needs/could use the ability to=0D=0A> sanity=0D=0A> check the=
 location.  You've argued it doesn't need that as much as=0D=0A> the operat=
ors need to be paid for location infrastructure deployed,=0D=0A> which set =
up the whole apples to oranges discussion that has been=0D=0A> going so far=
=2E=0D=0A>=20=0D=0A> Past that, you're introducing a mechanism that combine=
s two services=0D=0A> (receiving a location and associating that location w=
ith a psap URI).=0D=0AIf=0D=0A> you gave=0D=0A> that data to a device which=
 has a different LoST server configured,=0D=0Awhat=0D=0A> do you expect to =
happen=3F  Is it going to pass that location URI to its=0D=0A> own LoST ser=
ver to confirm it gets the same PSAP URI=3F  The current=0D=0A> system allo=
ws a user/device to request service boundaries and to=0D=0A> make reasonabl=
e choices about when to refresh URI mappings.  How=0D=0A> are you replicati=
ng that functionality=3F  The service boundaries are,=0D=0A> after all, pre=
tty much at the level of Brian's proposal.=0D=0A>=20=0D=0A> > > For non-eme=
rgency cases, you are dealing instead with the=0D=0A> >> case where you hav=
e a concern that selling someone location=0D=0A> >> for purpose X gets them=
 location for purpose Y.  That's both=0D=0A> >> a different problem and it =
falls into an area where there are=0D=0A> >> enough other problems that it =
is, honestly, probably the least=0D=0A> >> of your worries.  It's also way =
out of the charter of this group.=0D=0A> >>=0D=0A> >=0D=0A> >I would argue =
that location hiding is not in the charter of this WG=0D=0Aat=0D=0A> >all. =
How to route to a PSAP is the current charter, so if the=0D=0Aend-point=0D=0A=
> >is given all it needs to route to the PSAP then we are done aren't=0D=0A=
we=3F=0D=0A> >=0D=0A>=20=0D=0A> I agree that location hiding is not in the =
charter of this working=0D=0Agroup.=0D=0A> You've been among those saying i=
t had to be considered.  What you're=0D=0A> proposing goes in a different d=
esign direction to the one the=0D=0A> working group has had so far and it g=
oes against some base principles=0D=0A> of location in GeoPRIV contexts as =
well (see:  the user controls=0D=0Aaccess to=0D=0A> his/her location)=0D=0A=
>=20=0D=0A> If what you were providing were as robust as the other methods =
being=0D=0A> offered we might be done, despite the design difference.  But =
there is=0D=0A> no consensus that this is the case.  At least Henning and I=
 feel it is=0D=0A> more=0D=0A> fragile.  I believe there are others as well=
=2E=0D=0A>=20=0D=0A> >Umm, how is providing the end point with where it nee=
ds to go more=0D=0A> >fragile than giving it a bodgey location=3F=0D=0A> >=0D=
=0A>=20=0D=0A> It can check the location it is provided.  You can be workin=
g off a=0D=0Abodgey=0D=0A> location, and it would never know.=0D=0A>=20=0D=0A=
> Really, try the cocoa.  It's quite nice.=0D=0A> =09=09=09=09Ted=0D=0A> =0D=
=0A>=20=0D=0A>=20=0D=0A> >=0D=0A> >Cheers=0D=0A> >James=0D=0A>=0D=0A>------=
-----------------------------------------------------------------=0D=0A--=0D=
=0A> -----------------------=0D=0A> >This message is for the designated rec=
ipient only and may=0D=0A> >contain privileged, proprietary, or otherwise p=
rivate information.=0D=0A> >If you have received it in error, please notify=
 the sender=0D=0A> >immediately and delete the original.  Any unauthorized =
use of=0D=0A> >this email is prohibited.=0D=0A>=0D=0A>---------------------=
--------------------------------------------------=0D=0A--=0D=0A> ---------=
--------------=0D=0A> >[mf2]=0D=0A> >=0D=0A>=20=0D=0A=0D=0A----------------=
---------------------------------------------------------------------------=
-----=0D=0AThis message is for the designated recipient only and may=0D=0Ac=
ontain privileged, proprietary, or otherwise private information. =20=0D=0A=
If you have received it in error, please notify the sender=0D=0Aimmediately=
 and delete the original.  Any unauthorized use of=0D=0Athis email is prohi=
bited.=0D=0A---------------------------------------------------------------=
---------------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 15:58:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2CB7-0000ox-Ee; Tue, 11 Dec 2007 15:58:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CB6-0000os-Ki
	for ecrit@ietf.org; Tue, 11 Dec 2007 15:58:08 -0500
Received: from tcmail31.telekom.de ([217.6.95.238])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2CB4-0001l4-9b
	for ecrit@ietf.org; Tue, 11 Dec 2007 15:58:08 -0500
Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP;
	Tue, 11 Dec 2007 21:58:04 +0100
Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by
	s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); 
	Tue, 11 Dec 2007 21:58:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 21:58:01 +0100
Message-Id: <182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdw
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> 
	<	p0 6240605 c3 8330f2cd7e@[76.126.60.89]>

From: "Liess, Laura" 
To: , , ,
	, 
X-OriginalArrivalTime: 11 Dec 2007 20:58:04.0064 (UTC)
	FILETIME=[85CC1A00:01C83C38]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I see two advantages with James URI proposal:

1) It's simple. People (also product managers) understand it within 2 =
minutes and like it exactly for this reason. The chance to get it =
implemented soon is probably quite high.=20

2) The ISP provider is responsible for most EC functionality. The VSP is =
just "transport". (Marc pointed out this aspect to me last week.) =
Probably the regulators would like this because they can control the =
ISPs better than the VSPs. =20
The chance for this solution to work, at lest at the beginning, is =
probably higher than if 3 different providers (the ISP, the VSP and the =
LOST provider), with eventually conflicting economical interests, have =
to cooperate to provide the EC functionality.=20

What if we have both options, coarse location and ESRP/PSAP URI? Does =
this mean too high implementation effort for clients?=20
=20
Laura

-----Urspr=FCngliche Nachricht-----
Von: Ted Hardie [mailto:hardie@qualcomm.com]=20
Gesendet: Montag, 10. Dezember 2007 22:38
An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin; =
Henning Schulzrinne
Cc: ecrit@ietf.org; Liess, Laura
Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art

At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
>If the device is simply given a PSAP URI, a service URN, and a location
>URI, what more does it need?

As several people have pointed out, it needs/could use the ability to =
sanity
check the location.  You've argued it doesn't need that as much as
the operators need to be paid for location infrastructure deployed,
which set up the whole apples to oranges discussion that has been
going so far.

Past that, you're introducing a mechanism that combines two services
(receiving a location and associating that location with a psap URI).  =
If you gave
that data to a device which has a different LoST server configured, what
do you expect to happen?  Is it going to pass that location URI to its
own LoST server to confirm it gets the same PSAP URI?  The current
system allows a user/device to request service boundaries and to
make reasonable choices about when to refresh URI mappings.  How
are you replicating that functionality?  The service boundaries are,
after all, pretty much at the level of Brian's proposal. =20

> > For non-emergency cases, you are dealing instead with the
>> case where you have a concern that selling someone location
>> for purpose X gets them location for purpose Y.  That's both
>> a different problem and it falls into an area where there are
>> enough other problems that it is, honestly, probably the least
>> of your worries.  It's also way out of the charter of this group.
>>
>
>I would argue that location hiding is not in the charter of this WG at
>all. How to route to a PSAP is the current charter, so if the end-point
>is given all it needs to route to the PSAP then we are done aren't we?
>

I agree that location hiding is not in the charter of this working =
group.
You've been among those saying it had to be considered.  What you're
proposing goes in a different design direction to the one the
working group has had so far and it goes against some base principles
of location in GeoPRIV contexts as well (see:  the user controls access =
to
his/her location)

If what you were providing were as robust as the other methods being
offered we might be done, despite the design difference.  But there is
no consensus that this is the case.  At least Henning and I feel it is =
more
fragile.  I believe there are others as well.

>Umm, how is providing the end point with where it needs to go more
>fragile than giving it a bodgey location?
>

It can check the location it is provided.  You can be working off a =
bodgey
location, and it would never know.
=09
Really, try the cocoa.  It's quite nice.
				Ted

>
>Cheers
>James
>------------------------------------------------------------------------=
------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.=20
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------=
------------------------
>[mf2]
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 16:21:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2CXP-0008D6-8R; Tue, 11 Dec 2007 16:21:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CXN-0008Cw-HS
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:21:09 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2CXM-0000mV-Mg
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:21:09 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2CXG-00051x-2E; Tue, 11 Dec 2007 15:21:02 -0600
From: "Brian Rosen" 
To: "'Liess, Laura'" , ,
	, ,

References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> <	p0
	6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 16:21:02 -0500
Message-ID: <066801c83c3b$bd820150$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
Thread-Index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiA=
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Yeah, my problem with this is that every client has to implement two
mechanisms.  They need to implement the LCP then dereference then LoST
lookup AND they have to implement the HELD+LoST mechanism.=20

I think this mechanism requires the reverse LoST lookup for VSPs, so =
more
work for LoST servers.  I think James wants to ignore that problem
(something about letting VSPs charge for emergency calls and working it =
out
later).

BTW, the HELD return would have to supply ALL of the service URNs,
dialstrings, and boundaries that the LoST server knows about.  I'm not =
quite
sure how the HELD server figures that out.  If there are commercial =
services
using LoST, all of them would have to be returned.  I think the VSP =
wants to
get into the "Location Based Routing" act (they do route calls after =
all,
and ISPs don't).  I'm not sure how it would do so with this proposal. =20

If the device is mobile, what happens?  The way we specified it so far, =
the
endpoint would subscribe to a location update service and get location
updates.  It would have the service boundary from LoST, and it would =
requery
if it moved beyond the service boundary.  That works, and makes sense to =
me.
I'm not sure what James proposes.

If we're going to go beyond the basic location hiding idea, using what I
proposed, which takes no standards changes and puts the burden on the =
LIS
who is hiding location, then I think Richard's idea of allowing LoST to
dereference is a better one.  I don't like that idea; we've talked about =
why
it's not a great idea in the past, but it's better than James'.

Brian=20

> -----Original Message-----
> From: Liess, Laura [mailto:Laura.Liess@t-systems.com]
> Sent: Tuesday, December 11, 2007 3:58 PM
> To: hardie@qualcomm.com; James.Winterbottom@andrew.com; =
bs7652@att.com;
> br@brianrosen.net; Martin.Dawson@andrew.com
> Cc: ecrit@ietf.org
> Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
>=20
>=20
> I see two advantages with James URI proposal:
>=20
> 1) It's simple. People (also product managers) understand it within 2
> minutes and like it exactly for this reason. The chance to get it
> implemented soon is probably quite high.
>=20
> 2) The ISP provider is responsible for most EC functionality. The VSP =
is
> just "transport". (Marc pointed out this aspect to me last week.) =
Probably
> the regulators would like this because they can control the ISPs =
better
> than the VSPs.
> The chance for this solution to work, at lest at the beginning, is
> probably higher than if 3 different providers (the ISP, the VSP and =
the
> LOST provider), with eventually conflicting economical interests, have =
to
> cooperate to provide the EC functionality.
>=20
> What if we have both options, coarse location and ESRP/PSAP URI? Does =
this
> mean too high implementation effort for clients?
>=20
> Laura
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Ted Hardie [mailto:hardie@qualcomm.com]
> Gesendet: Montag, 10. Dezember 2007 22:38
> An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin;
> Henning Schulzrinne
> Cc: ecrit@ietf.org; Liess, Laura
> Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
> >If the device is simply given a PSAP URI, a service URN, and a =
location
> >URI, what more does it need?
>=20
> As several people have pointed out, it needs/could use the ability to
> sanity
> check the location.  You've argued it doesn't need that as much as
> the operators need to be paid for location infrastructure deployed,
> which set up the whole apples to oranges discussion that has been
> going so far.
>=20
> Past that, you're introducing a mechanism that combines two services
> (receiving a location and associating that location with a psap URI).  =
If
> you gave
> that data to a device which has a different LoST server configured, =
what
> do you expect to happen?  Is it going to pass that location URI to its
> own LoST server to confirm it gets the same PSAP URI?  The current
> system allows a user/device to request service boundaries and to
> make reasonable choices about when to refresh URI mappings.  How
> are you replicating that functionality?  The service boundaries are,
> after all, pretty much at the level of Brian's proposal.
>=20
> > > For non-emergency cases, you are dealing instead with the
> >> case where you have a concern that selling someone location
> >> for purpose X gets them location for purpose Y.  That's both
> >> a different problem and it falls into an area where there are
> >> enough other problems that it is, honestly, probably the least
> >> of your worries.  It's also way out of the charter of this group.
> >>
> >
> >I would argue that location hiding is not in the charter of this WG =
at
> >all. How to route to a PSAP is the current charter, so if the =
end-point
> >is given all it needs to route to the PSAP then we are done aren't =
we?
> >
>=20
> I agree that location hiding is not in the charter of this working =
group.
> You've been among those saying it had to be considered.  What you're
> proposing goes in a different design direction to the one the
> working group has had so far and it goes against some base principles
> of location in GeoPRIV contexts as well (see:  the user controls =
access to
> his/her location)
>=20
> If what you were providing were as robust as the other methods being
> offered we might be done, despite the design difference.  But there is
> no consensus that this is the case.  At least Henning and I feel it is
> more
> fragile.  I believe there are others as well.
>=20
> >Umm, how is providing the end point with where it needs to go more
> >fragile than giving it a bodgey location?
> >
>=20
> It can check the location it is provided.  You can be working off a =
bodgey
> location, and it would never know.
>=20
> Really, try the cocoa.  It's quite nice.
> 				Ted
>=20
>=20
>=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]
> >

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 16:37:42 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2CnN-0007EK-D2; Tue, 11 Dec 2007 16:37:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CnL-0007C9-9Z
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:37:39 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2CnJ-0002kX-Ve
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:37:39 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 11 Dec 2007 16:37:37 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBBLbbv2001107
	for ; Tue, 11 Dec 2007 16:37:37 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBBLbOZS013277
	for ; Tue, 11 Dec 2007 21:37:37 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); 
	Tue, 11 Dec 2007 16:37:34 -0500
Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Dec 2007 16:37:34 -0500
From: "Marc Linsner" 
To: "'ECRIT'" 
Date: Tue, 11 Dec 2007 16:37:33 -0500
Message-ID: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg8Pgj2dqflZy3VTZ6b9wS7hhXpQA==
X-OriginalArrivalTime: 11 Dec 2007 21:37:34.0609 (UTC)
	FILETIME=[0AC09010:01C83C3E]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=533; t=1197409057; x=1198273057;
	c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mlinsner@cisco.com;
	z=From:=20=22Marc=20Linsner=22=20
	|Subject:=20Forward=20Progress |Sender:=20
	|To:=20=22'ECRIT'=22=20;
	bh=xGB8wGq4CgDEPrHCglDQFO9rFP4owLfMviu0apS6DFg=;
	b=dQQXON4i+t+I2LMpf0irYYXMiQWv6dvEnH9wEnRAwxwc4QobV3yZJKowu+
	YepZ6A3m+vc8mY7PVbMD6ZqD5iKGgkaZBbmWhc4E4VVaoy/RWqzOTw3DRsyV
	jDgRvTW+s1;
Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: [Ecrit] Forward Progress
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

It appears that forward progress with regards to 'Location Hiding' and
'Unauthenticated Access' is going to take some time.  In an effort to
complete current milestones, what are opinions about adding the text below
to phonebcp/framework?

"This document provides guidance for generic network configurations.  It is
recognized that unique issues may exist in some network deployments.  The
IETF will continue to investigate these unique situations and provide
further guidance, if warranted, in future documents."

-Marc-

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 16:40:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Cpl-0002PW-2K; Tue, 11 Dec 2007 16:40:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Cpj-0002PF-TN
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:40:07 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Cpg-0002nm-83
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:40:07 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_15_50_59
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, 11 Dec 2007 15:50:59 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 15:39:54 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ecrit] Forward Progress
Date: Tue, 11 Dec 2007 15:39:52 -0600
Message-ID: 
In-Reply-To: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Forward Progress
Thread-Index: Acg8Pgj2dqflZy3VTZ6b9wS7hhXpQAAAEywg
References: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
From: "Winterbottom, James" 
To: "Marc Linsner" ,
	"ECRIT" 
X-OriginalArrivalTime: 11 Dec 2007 21:39:54.0124 (UTC)
	FILETIME=[5DE8DCC0:01C83C3E]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I am fine with that Marc.=0D=0A=0D=0A> -----Original Message-----=0D=0A> Fr=
om: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A> Sent: Wednesday, 12 Dec=
ember 2007 8:38 AM=0D=0A> To: 'ECRIT'=0D=0A> Subject: [Ecrit] Forward Progr=
ess=0D=0A>=20=0D=0A> It appears that forward progress with regards to 'Loca=
tion Hiding' and=0D=0A> 'Unauthenticated Access' is going to take some time=
=2E  In an effort to=0D=0A> complete current milestones, what are opinions =
about adding the text=0D=0Abelow=0D=0A> to phonebcp/framework=3F=0D=0A>=20=0D=
=0A> "This document provides guidance for generic network configurations.=0D=
=0AIt=0D=0A> is=0D=0A> recognized that unique issues may exist in some netw=
ork deployments.=0D=0AThe=0D=0A> IETF will continue to investigate these un=
ique situations and provide=0D=0A> further guidance, if warranted, in futur=
e documents."=0D=0A>=20=0D=0A> -Marc-=0D=0A>=20=0D=0A> ____________________=
___________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=
=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------------=
---------------------------------------------------------------------------=
-------=0D=0AThis message is for the designated recipient only and may=0D=0A=
contain privileged, proprietary, or otherwise private information. =20=0D=0A=
If you have received it in error, please notify the sender=0D=0Aimmediately=
 and delete the original.  Any unauthorized use of=0D=0Athis email is prohi=
bited.=0D=0A---------------------------------------------------------------=
---------------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 16:43:04 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2CsZ-0006gg-86; Tue, 11 Dec 2007 16:43:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CsY-0006gZ-62
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:43:02 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2CsV-0002sa-Tq
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:43:02 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_15_54_02
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Tue, 11 Dec 2007 15:54:02 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 15:42:57 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 15:42:55 -0600
Message-ID: 
In-Reply-To: <066801c83c3b$bd820150$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiAAAViIIA==
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> 
	<	p0 6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>
From: "Winterbottom, James" 
To: "Brian Rosen" ,
	"Liess, Laura" , ,
	, "Dawson, Martin" 
X-OriginalArrivalTime: 11 Dec 2007 21:42:57.0219 (UTC)
	FILETIME=[CB0AF130:01C83C3E]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I will reply to this in more detail later Brian, when my brain is a little =
less fried.=0D=0A=0D=0AThe basis of my proposal is that the Location provid=
er knows what services etc that it will grant access to. There is no way fo=
r the VSP to know this unless they are also the access provider. So while t=
he VSPs may want to get into the location dependent routing game, I think t=
hat this is actually a very good value-add that access providers will have =
dominance over for some time.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> ---=
--Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=
=0A> Sent: Wednesday, 12 December 2007 8:21 AM=0D=0A> To: 'Liess, Laura'; h=
ardie@qualcomm.com; Winterbottom, James;=0D=0A> bs7652@att.com; Dawson, Mar=
tin=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: AW: [Ecrit] Location Hidi=
ng -- State of the Art=0D=0A>=20=0D=0A> Yeah, my problem with this is that =
every client has to implement two=0D=0A> mechanisms.  They need to implemen=
t the LCP then dereference then LoST=0D=0A> lookup AND they have to impleme=
nt the HELD+LoST mechanism.=0D=0A>=20=0D=0A> I think this mechanism require=
s the reverse LoST lookup for VSPs, so more=0D=0A> work for LoST servers.  =
I think James wants to ignore that problem=0D=0A> (something about letting =
VSPs charge for emergency calls and working it=0D=0A> out=0D=0A> later).=0D=
=0A>=20=0D=0A> BTW, the HELD return would have to supply ALL of the service=
 URNs,=0D=0A> dialstrings, and boundaries that the LoST server knows about.=
  I'm not=0D=0A> quite=0D=0A> sure how the HELD server figures that out.  I=
f there are commercial=0D=0A> services=0D=0A> using LoST, all of them would=
 have to be returned.  I think the VSP wants=0D=0A> to=0D=0A> get into the =
"Location Based Routing" act (they do route calls after all,=0D=0A> and ISP=
s don't).  I'm not sure how it would do so with this proposal.=0D=0A>=20=0D=
=0A> If the device is mobile, what happens=3F  The way we specified it so f=
ar,=0D=0A> the=0D=0A> endpoint would subscribe to a location update service=
 and get location=0D=0A> updates.  It would have the service boundary from =
LoST, and it would=0D=0A> requery=0D=0A> if it moved beyond the service bou=
ndary.  That works, and makes sense to=0D=0A> me.=0D=0A> I'm not sure what =
James proposes.=0D=0A>=20=0D=0A> If we're going to go beyond the basic loca=
tion hiding idea, using what I=0D=0A> proposed, which takes no standards ch=
anges and puts the burden on the LIS=0D=0A> who is hiding location, then I =
think Richard's idea of allowing LoST to=0D=0A> dereference is a better one=
=2E  I don't like that idea; we've talked about=0D=0A> why=0D=0A> it's not =
a great idea in the past, but it's better than James'.=0D=0A>=20=0D=0A> Bri=
an=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From: Liess, Laur=
a [mailto:Laura.Liess@t-systems.com]=0D=0A> > Sent: Tuesday, December 11, 2=
007 3:58 PM=0D=0A> > To: hardie@qualcomm.com; James.Winterbottom@andrew.com=
; bs7652@att.com;=0D=0A> > br@brianrosen.net; Martin.Dawson@andrew.com=0D=0A=
> > Cc: ecrit@ietf.org=0D=0A> > Subject: AW: AW: [Ecrit] Location Hiding --=
 State of the Art=0D=0A> >=0D=0A> >=0D=0A> > I see two advantages with Jame=
s URI proposal:=0D=0A> >=0D=0A> > 1) It's simple. People (also product mana=
gers) understand it within 2=0D=0A> > minutes and like it exactly for this =
reason. The chance to get it=0D=0A> > implemented soon is probably quite hi=
gh.=0D=0A> >=0D=0A> > 2) The ISP provider is responsible for most EC functi=
onality. The VSP is=0D=0A> > just "transport". (Marc pointed out this aspec=
t to me last week.)=0D=0A> Probably=0D=0A> > the regulators would like this=
 because they can control the ISPs better=0D=0A> > than the VSPs.=0D=0A> > =
The chance for this solution to work, at lest at the beginning, is=0D=0A> >=
 probably higher than if 3 different providers (the ISP, the VSP and the=0D=
=0A> > LOST provider), with eventually conflicting economical interests, ha=
ve=0D=0A> to=0D=0A> > cooperate to provide the EC functionality.=0D=0A> >=0D=
=0A> > What if we have both options, coarse location and ESRP/PSAP URI=3F D=
oes=0D=0A> this=0D=0A> > mean too high implementation effort for clients=3F=0D=
=0A> >=0D=0A> > Laura=0D=0A> >=0D=0A> > -----Urspr=FCngliche Nachricht-----=0D=
=0A> > Von: Ted Hardie [mailto:hardie@qualcomm.com]=0D=0A> > Gesendet: Mont=
ag, 10. Dezember 2007 22:38=0D=0A> > An: Winterbottom, James; Stark, Barbar=
a; Brian Rosen; Dawson, Martin;=0D=0A> > Henning Schulzrinne=0D=0A> > Cc: e=
crit@ietf.org; Liess, Laura=0D=0A> > Betreff: RE: AW: [Ecrit] Location Hidi=
ng -- State of the Art=0D=0A> >=0D=0A> > At 1:25 PM -0600 12/10/07, Winterb=
ottom, James wrote:=0D=0A> > >If the device is simply given a PSAP URI, a s=
ervice URN, and a location=0D=0A> > >URI, what more does it need=3F=0D=0A> =
>=0D=0A> > As several people have pointed out, it needs/could use the abili=
ty to=0D=0A> > sanity=0D=0A> > check the location.  You've argued it doesn'=
t need that as much as=0D=0A> > the operators need to be paid for location =
infrastructure deployed,=0D=0A> > which set up the whole apples to oranges =
discussion that has been=0D=0A> > going so far.=0D=0A> >=0D=0A> > Past that=
, you're introducing a mechanism that combines two services=0D=0A> > (recei=
ving a location and associating that location with a psap URI).=0D=0A> If=0D=
=0A> > you gave=0D=0A> > that data to a device which has a different LoST s=
erver configured, what=0D=0A> > do you expect to happen=3F  Is it going to =
pass that location URI to its=0D=0A> > own LoST server to confirm it gets t=
he same PSAP URI=3F  The current=0D=0A> > system allows a user/device to re=
quest service boundaries and to=0D=0A> > make reasonable choices about when=
 to refresh URI mappings.  How=0D=0A> > are you replicating that functional=
ity=3F  The service boundaries are,=0D=0A> > after all, pretty much at the =
level of Brian's proposal.=0D=0A> >=0D=0A> > > > For non-emergency cases, y=
ou are dealing instead with the=0D=0A> > >> case where you have a concern t=
hat selling someone location=0D=0A> > >> for purpose X gets them location f=
or purpose Y.  That's both=0D=0A> > >> a different problem and it falls int=
o an area where there are=0D=0A> > >> enough other problems that it is, hon=
estly, probably the least=0D=0A> > >> of your worries.  It's also way out o=
f the charter of this group.=0D=0A> > >>=0D=0A> > >=0D=0A> > >I would argue=
 that location hiding is not in the charter of this WG at=0D=0A> > >all. Ho=
w to route to a PSAP is the current charter, so if the end-point=0D=0A> > >=
is given all it needs to route to the PSAP then we are done aren't we=3F=0D=
=0A> > >=0D=0A> >=0D=0A> > I agree that location hiding is not in the chart=
er of this working=0D=0A> group.=0D=0A> > You've been among those saying it=
 had to be considered.  What you're=0D=0A> > proposing goes in a different =
design direction to the one the=0D=0A> > working group has had so far and i=
t goes against some base principles=0D=0A> > of location in GeoPRIV context=
s as well (see:  the user controls access=0D=0A> to=0D=0A> > his/her locati=
on)=0D=0A> >=0D=0A> > If what you were providing were as robust as the othe=
r methods being=0D=0A> > offered we might be done, despite the design diffe=
rence.  But there is=0D=0A> > no consensus that this is the case.  At least=
 Henning and I feel it is=0D=0A> > more=0D=0A> > fragile.  I believe there =
are others as well.=0D=0A> >=0D=0A> > >Umm, how is providing the end point =
with where it needs to go more=0D=0A> > >fragile than giving it a bodgey lo=
cation=3F=0D=0A> > >=0D=0A> >=0D=0A> > It can check the location it is prov=
ided.  You can be working off a=0D=0A> bodgey=0D=0A> > location, and it wou=
ld never know.=0D=0A> >=0D=0A> > Really, try the cocoa.  It's quite nice.=0D=
=0A> > =09=09=09=09Ted=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > >=0D=0A> > >Chee=
rs=0D=0A> > >James=0D=0A> > >----------------------------------------------=
-------------------------=0D=0A> --=0D=0A> > -----------------------=0D=0A>=
 > >This message is for the designated recipient only and may=0D=0A> > >con=
tain privileged, proprietary, or otherwise private information.=0D=0A> > >I=
f you have received it in error, please notify the sender=0D=0A> > >immedia=
tely and delete the original.  Any unauthorized use of=0D=0A> > >this email=
 is prohibited.=0D=0A> > >-------------------------------------------------=
----------------------=0D=0A> --=0D=0A> > -----------------------=0D=0A> > =
>[mf2]=0D=0A> > >=0D=0A>=20=0D=0A=0D=0A------------------------------------=
------------------------------------------------------------=0D=0AThis mess=
age is for the designated recipient only and may=0D=0Acontain privileged, p=
roprietary, or otherwise private information. =20=0D=0AIf you have received=
 it in error, please notify the sender=0D=0Aimmediately and delete the orig=
inal.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------=
---------------------------------------------------------------------------=
-------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 16:55:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2D4Q-0003Ft-06; Tue, 11 Dec 2007 16:55:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2D4P-0003FX-3L
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:55:17 -0500
Received: from ironportdmz5.qualcomm.com ([199.106.114.254]
	helo=wolverine01.qualcomm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2D4N-0001bJ-Jl
	for ecrit@ietf.org; Tue, 11 Dec 2007 16:55:16 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Cc:Content-Type:
	Content-Transfer-Encoding;
	b=fmDrHd3Ps7U8YzBOHtXwOcV1sHfaubOXXkt3sPCpfCQ/FNbl+oNAvnD/
	pydidDR9VQumhbMOVmu81wpIf0F5g5/Am5yyObPnB/81uhIAHpx40PPf0
	ufKxrjIje3eW2hwfgTVCUfmUN+D6rbL5DKElzPXLeRE+ajBtsxvM7LwNt
	8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAAKWXkeBLjM7/2dsb2JhbAA
X-IronPort-AV: E=McAfee;i="5100,188,5183"; a="77439"
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	11 Dec 2007 13:55:14 -0800
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lBBLtDWM030041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Dec 2007 13:55:13 -0800
Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27])
	by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lBBLtBVK009235; Tue, 11 Dec 2007 13:55:12 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex!! ! c41p> <	p0 6240605
	c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

Date: Tue, 11 Dec 2007 13:55:16 -0800
To: "Winterbottom, James" ,
	"Brian Rosen" ,
	"Liess, Laura" , ,
	"Dawson, Martin" 
From: Ted Hardie 
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 3:42 PM -0600 12/11/07, Winterbottom, James wrote:
>I will reply to this in more detail later Brian, when my brain is a little less fried.
>
>The basis of my proposal is that the Location provider knows what services etc that it will grant access to.

Huh?  This sounds like you mean an access provider/doubling as a location provider,
might block access to specific emergency services.  That can't be what you mean,
so maybe you mean to specific non-emergency services.  Since these will
often be expressed in the form of fairly typical URIs (like SIP URIs, XMPP URIs,
etc.), you're either implying that blocking access to location blocks all access
to those services (it doesn't) or that they will otherwise block it unless they've
sold you your location (which they theoretically could do with deep packet
inspection, but seem likely to pull out of quickly if they tried).

>There is no way for the VSP to know this unless they are also the access provider. So while the VSPs may want to get into the location dependent routing game, I think that this is actually a very good value-add that access providers will have dominance over for some time.
>

As stated, this doesn't make sense, at least to me.  A VSP with access to location
can provide exactly the same location-based-routing as the originator of that location.
If it cannot, some other manipulation of the packet flow must be present to prevent
it.
					Ted

>Cheers
>James
>
>> -----Original Message-----
>> From: Brian Rosen [mailto:br@brianrosen.net]
>> Sent: Wednesday, 12 December 2007 8:21 AM
>> To: 'Liess, Laura'; hardie@qualcomm.com; Winterbottom, James;
>> bs7652@att.com; Dawson, Martin
>> Cc: ecrit@ietf.org
>> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>>
>> Yeah, my problem with this is that every client has to implement two
>> mechanisms.  They need to implement the LCP then dereference then LoST
>> lookup AND they have to implement the HELD+LoST mechanism.
>>
>> I think this mechanism requires the reverse LoST lookup for VSPs, so more
>> work for LoST servers.  I think James wants to ignore that problem
>> (something about letting VSPs charge for emergency calls and working it
>> out
>> later).
>>
>> BTW, the HELD return would have to supply ALL of the service URNs,
>> dialstrings, and boundaries that the LoST server knows about.  I'm not
>> quite
>> sure how the HELD server figures that out.  If there are commercial
>> services
>> using LoST, all of them would have to be returned.  I think the VSP wants
>> to
>> get into the "Location Based Routing" act (they do route calls after all,
>> and ISPs don't).  I'm not sure how it would do so with this proposal.
>>
>> If the device is mobile, what happens?  The way we specified it so far,
>> the
>> endpoint would subscribe to a location update service and get location
>> updates.  It would have the service boundary from LoST, and it would
>> requery
>> if it moved beyond the service boundary.  That works, and makes sense to
>> me.
>> I'm not sure what James proposes.
>>
>> If we're going to go beyond the basic location hiding idea, using what I
>> proposed, which takes no standards changes and puts the burden on the LIS
>> who is hiding location, then I think Richard's idea of allowing LoST to
>> dereference is a better one.  I don't like that idea; we've talked about
>> why
>> it's not a great idea in the past, but it's better than James'.
>>
>> Brian
>>
>> > -----Original Message-----
>> > From: Liess, Laura [mailto:Laura.Liess@t-systems.com]
>> > Sent: Tuesday, December 11, 2007 3:58 PM
>> > To: hardie@qualcomm.com; James.Winterbottom@andrew.com; bs7652@att.com;
>> > br@brianrosen.net; Martin.Dawson@andrew.com
>> > Cc: ecrit@ietf.org
>> > Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
>> >
>> >
>> > I see two advantages with James URI proposal:
> > >
>> > 1) It's simple. People (also product managers) understand it within 2
>> > minutes and like it exactly for this reason. The chance to get it
>> > implemented soon is probably quite high.
>> >
>> > 2) The ISP provider is responsible for most EC functionality. The VSP is
>> > just "transport". (Marc pointed out this aspect to me last week.)
>> Probably
>> > the regulators would like this because they can control the ISPs better
>> > than the VSPs.
>> > The chance for this solution to work, at lest at the beginning, is
>> > probably higher than if 3 different providers (the ISP, the VSP and the
>> > LOST provider), with eventually conflicting economical interests, have
>> to
>> > cooperate to provide the EC functionality.
>> >
>> > What if we have both options, coarse location and ESRP/PSAP URI? Does
>> this
>> > mean too high implementation effort for clients?
>> >
>> > Laura
>> >
>> > -----Urspr�ngliche Nachricht-----
>> > Von: Ted Hardie [mailto:hardie@qualcomm.com]
>> > Gesendet: Montag, 10. Dezember 2007 22:38
>> > An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin;
>> > Henning Schulzrinne
>> > Cc: ecrit@ietf.org; Liess, Laura
>> > Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art
>> >
>> > At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
>> > >If the device is simply given a PSAP URI, a service URN, and a location
>> > >URI, what more does it need?
>> >
>> > As several people have pointed out, it needs/could use the ability to
>> > sanity
>> > check the location.  You've argued it doesn't need that as much as
>> > the operators need to be paid for location infrastructure deployed,
>> > which set up the whole apples to oranges discussion that has been
>> > going so far.
>> >
>> > Past that, you're introducing a mechanism that combines two services
>> > (receiving a location and associating that location with a psap URI).
>> If
>> > you gave
>> > that data to a device which has a different LoST server configured, what
>> > do you expect to happen?  Is it going to pass that location URI to its
>> > own LoST server to confirm it gets the same PSAP URI?  The current
>> > system allows a user/device to request service boundaries and to
>> > make reasonable choices about when to refresh URI mappings.  How
>> > are you replicating that functionality?  The service boundaries are,
>> > after all, pretty much at the level of Brian's proposal.
>> >
>> > > > For non-emergency cases, you are dealing instead with the
>> > >> case where you have a concern that selling someone location
>> > >> for purpose X gets them location for purpose Y.  That's both
>> > >> a different problem and it falls into an area where there are
>> > >> enough other problems that it is, honestly, probably the least
>> > >> of your worries.  It's also way out of the charter of this group.
>> > >>
>> > >
>> > >I would argue that location hiding is not in the charter of this WG at
>> > >all. How to route to a PSAP is the current charter, so if the end-point
>> > >is given all it needs to route to the PSAP then we are done aren't we?
>> > >
>> >
>> > I agree that location hiding is not in the charter of this working
>> group.
>> > You've been among those saying it had to be considered.  What you're
>> > proposing goes in a different design direction to the one the
>> > working group has had so far and it goes against some base principles
>> > of location in GeoPRIV contexts as well (see:  the user controls access
>> to
>> > his/her location)
>> >
>> > If what you were providing were as robust as the other methods being
>> > offered we might be done, despite the design difference.  But there is
>> > no consensus that this is the case.  At least Henning and I feel it is
>> > more
>> > fragile.  I believe there are others as well.
>> >
>> > >Umm, how is providing the end point with where it needs to go more
>> > >fragile than giving it a bodgey location?
>> > >
>> >
>> > It can check the location it is provided.  You can be working off a
>> bodgey
>> > location, and it would never know.
>> >
>> > Really, try the cocoa.  It's quite nice.
>> >				Ted
>> >
>> >
>> >
>> > >
>> > >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]
>> > >
>>
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information. 
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 17:10:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2DJ5-0001wn-S2; Tue, 11 Dec 2007 17:10:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DJ4-0001dl-3q
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:10:26 -0500
Received: from tcmail31.telekom.de ([217.6.95.238])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2DJ3-0001vv-KG
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:10:26 -0500
Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP;
	Tue, 11 Dec 2007 23:10:24 +0100
Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by
	S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); 
	Tue, 11 Dec 2007 23:10:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Ecrit] Forward Progress
Date: Tue, 11 Dec 2007 23:10:18 +0100
Message-Id: <182C63BFBAF131428EA0C16F7FD2191B0355ABD8@S4DE8PSAAGM.mitte.t-com.de>
In-Reply-To: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Forward Progress
Thread-Index: Acg8Pgj2dqflZy3VTZ6b9wS7hhXpQAABFjzQ
References: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
From: "Liess, Laura" 
To: ,

X-OriginalArrivalTime: 11 Dec 2007 22:10:24.0306 (UTC)
	FILETIME=[A0C87920:01C83C42]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Marc,

I am fine if there is some small hint about LH.=20

"It is recognized that unique issues, as hiding the precise location, =
may exist in some network deployments."  I think this doesn't harm =
anybody. Maybe you have better wording for it...=20

Laura  =20

-----Urspr=FCngliche Nachricht-----
Von: Marc Linsner [mailto:mlinsner@cisco.com]=20
Gesendet: Dienstag, 11. Dezember 2007 22:38
An: 'ECRIT'
Betreff: [Ecrit] Forward Progress

It appears that forward progress with regards to 'Location Hiding' and
'Unauthenticated Access' is going to take some time.  In an effort to
complete current milestones, what are opinions about adding the text =
below
to phonebcp/framework?

"This document provides guidance for generic network configurations.  It =
is
recognized that unique issues may exist in some network deployments.  =
The
IETF will continue to investigate these unique situations and provide
further guidance, if warranted, in future documents."

-Marc-

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 17:16:08 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2DOa-0000YA-4A; Tue, 11 Dec 2007 17:16:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DOZ-0000Y3-F9
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:16:07 -0500
Received: from aismt07p.bellsouth.com ([139.76.165.213])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2DOY-0003a1-UL
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:16:07 -0500
Received: from ([139.76.131.87])
	by aismt07p.bellsouth.com with ESMTP  id KP-AXPTB.190599196;
	Tue, 11 Dec 2007 17:15:38 -0500
Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by
	01GAF5142010623.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Tue, 11 Dec 2007 17:15:38 -0500
Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by
	01NC27689010625.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Tue, 11 Dec 2007 17:15:37 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ecrit] Forward Progress
Date: Tue, 11 Dec 2007 17:15:37 -0500
Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06ABBAB7@crexc41p>
In-Reply-To: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Forward Progress
thread-index: Acg8Pgj2dqflZy3VTZ6b9wS7hhXpQAABGZJg
References: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
From: "Stark, Barbara" 
To: "Marc Linsner" ,"ECRIT" 
X-OriginalArrivalTime: 11 Dec 2007 22:15:37.0759 (UTC)
	FILETIME=[5B9D9AF0:01C83C43]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I'm fine with moving forward with your recommended text.=20
Barbara

-----Original Message-----
From: Marc Linsner [mailto:mlinsner@cisco.com]=20
Sent: Tuesday, December 11, 2007 4:38 PM
To: 'ECRIT'
Subject: [Ecrit] Forward Progress

It appears that forward progress with regards to 'Location Hiding' and
'Unauthenticated Access' is going to take some time.  In an effort to
complete current milestones, what are opinions about adding the text
below
to phonebcp/framework?

"This document provides guidance for generic network configurations.  It
is
recognized that unique issues may exist in some network deployments.
The
IETF will continue to investigate these unique situations and provide
further guidance, if warranted, in future documents."

-Marc-

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

*****

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

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 17:16:53 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2DPJ-0000zj-Ml; Tue, 11 Dec 2007 17:16:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DPI-0000zd-Cg
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:16:52 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2DPH-000253-UJ
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:16:52 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_16_27_54
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Tue, 11 Dec 2007 16:27:54 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 16:16:49 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 16:16:47 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg8QIP3nVhOpVQNT5W5TfhXIE4TMAAAbcGw
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex!! ! c41 p> 	<	p0 624
	0605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

From: "Winterbottom, James" 
To: "Ted Hardie" , "Brian Rosen" ,
	"Liess, Laura" , ,
	"Dawson, Martin" 
X-OriginalArrivalTime: 11 Dec 2007 22:16:49.0286 (UTC)
	FILETIME=[863FC260:01C83C43]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Hi ted,=0D=0A=0D=0AComments inline.=0D=0A=0D=0AGiven some of your response =
I think we are talking past each other.=0D=0A=0D=0A> >=0D=0A> >The basis of=
 my proposal is that the Location provider knows what=0D=0A> services etc t=
hat it will grant access to.=0D=0A>=20=0D=0A> Huh=3F  This sounds like you =
mean an access provider/doubling as a=0D=0Alocation=0D=0A> provider,=0D=0A>=
 might block access to specific emergency services.  That can't be what=0D=0A=
you=0D=0A> mean,=0D=0A> so maybe you mean to specific non-emergency service=
s.  Since these=0D=0Awill=0D=0A> often be expressed in the form of fairly t=
ypical URIs (like SIP URIs,=0D=0AXMPP=0D=0A> URIs,=0D=0A> etc.), you're eit=
her implying that blocking access to location blocks=0D=0Aall=0D=0A> access=0D=
=0A> to those services (it doesn't) or that they will otherwise block it=0D=
=0Aunless=0D=0A> they've=0D=0A> sold you your location (which they theoreti=
cally could do with deep=0D=0Apacket=0D=0A> inspection, but seem likely to =
pull out of quickly if they tried).=0D=0A>=20=0D=0A=0D=0A[AJW] Perhaps I sh=
ould have been consistent in my terminology, I used=0D=0Aaccess and locatio=
n provider inter-changeably. I see location always=0D=0Abeing provided to e=
mergency service providers.=0D=0A=0D=0AOn the other front, a location provi=
der can form trust relationships=0D=0Awith service vendors, for example the=
 local pizza parlor, or the AAA, or=0D=0Awhatever. This would require the r=
ecipient of a location URI to=0D=0Aauthenticate with the LIS prior to locat=
ion being handed out. This=0D=0Aallows the location provider to gain revenu=
e, either per dip, or by a=0D=0Amonthly fee. I am not sure why you are talk=
ing about deep packet=0D=0Ainspection in this model.=20=0D=0A=0D=0A>=20=0D=0A=
>=20=0D=0A> >There is no way for the VSP to know this unless they are also =
the=0D=0Aaccess=0D=0A> provider. So while the VSPs may want to get into the=
 location=0D=0Adependent=0D=0A> routing game, I think that this is actually=
 a very good value-add that=0D=0A> access providers will have dominance ove=
r for some time.=0D=0A> >=0D=0A>=20=0D=0A> As stated, this doesn't make sen=
se, at least to me.  A VSP with access=0D=0Ato=0D=0A> location=0D=0A> can p=
rovide exactly the same location-based-routing as the originator=0D=0Aof=0D=
=0A> that location.=0D=0A> If it cannot, some other manipulation of the pac=
ket flow must be=0D=0Apresent=0D=0A> to prevent=0D=0A> it.=0D=0A> =09=09=09=
=09=09Ted=0D=0A>=0D=0A=0D=0A[AJW] If all you give the end point is the serv=
ice URN (+ dial string),=0D=0Aa destination URI and a location URI, where t=
he latter requires=0D=0Aauthentication to dereference, how does the VSP get=
 location=3F=0D=0A=0D=0A=0D=0A=20=0D=0A>=20=0D=0A=0D=0A--------------------=
---------------------------------------------------------------------------=
-=0D=0AThis message is for the designated recipient only and may=0D=0Aconta=
in privileged, proprietary, or otherwise private information. =20=0D=0AIf y=
ou have received it in error, please notify the sender=0D=0Aimmediately and=
 delete the original.  Any unauthorized use of=0D=0Athis email is prohibite=
d.=0D=0A-------------------------------------------------------------------=
-----------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 17:23:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2DVG-0005id-Jy; Tue, 11 Dec 2007 17:23:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DVF-0005gk-PI
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:23:01 -0500
Received: from aismt06p.bellsouth.com ([139.76.165.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2DVB-0003nC-AZ
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:23:00 -0500
Received: from ([139.76.131.79])
	by aismt06p.bellsouth.com with ESMTP  id KP-AXPRN.35771398;
	Tue, 11 Dec 2007 17:22:32 -0500
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by
	01GAF5142010621.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Tue, 11 Dec 2007 17:22:31 -0500
Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by
	01NC27689010626.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Tue, 11 Dec 2007 17:22:31 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 11 Dec 2007 17:22:30 -0500
Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06ABBAC1@crexc41p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Phonebcp and LoST responses
thread-index: Acg8RFG8SQGDOVYzQxq9bzRXv1aTnQ==
From: "Stark, Barbara" 
To: "ECRIT" 
X-OriginalArrivalTime: 11 Dec 2007 22:22:31.0941 (UTC)
	FILETIME=[527CC350:01C83C44]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Ecrit] Phonebcp and LoST responses
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

In phonebcp section 8, it says that if a device can't get a LoST
response, it must use its cached value. I'm wondering if we could add
another statement, that if it has no cached value and no LoST response,
it must leave off the route header and just send the Service URN in the
Request URI (or whatever the correct description is)? I think that would
be consistent with the use of LoST only being a should, in the first
place, and the role of the "SP" in phonebcp as being responsible for
being able to handle this situation.
Barbara

*****

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

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 17:24:13 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2DWP-0000Ln-4W; Tue, 11 Dec 2007 17:24:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DWN-0000Kc-8u
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:24:11 -0500
Received: from mx12.bbn.com ([128.33.0.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2DWM-0003v7-LV
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:24:11 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx12.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1J2DWM-0003nP-3v; Tue, 11 Dec 2007 17:24:10 -0500
Received: from dhcp33-081-074.bbn.com ([128.33.81.74] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1J2DWM-0004M8-5P; Tue, 11 Dec 2007 17:24:10 -0500
Message-ID: <475F0E09.2010307@bbn.com>
Date: Tue, 11 Dec 2007 17:24:09 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Ted Hardie , ECRIT 
Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art
References: <4751C54C.4040704@gmx.net><03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>		<040b01c83b44$77094410$640fa8c0@cis.neustar.com>		<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>		<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex!!
	! c41p> <	p0 6240605	c3
	8330f2cd7e@[76.126.60.89]>					<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>	

In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Maybe I can clarify...

>> The basis of my proposal is that the Location provider knows what services etc that it will grant access to.

I believe James is referring here to non-emergency location-based 
services.  If you try to invoke these location-based services using a 
location URI that the service can't dereference (because he hasn't 
paid), the request will fail.  James's point is that location provider 
is the only entity that knows which providers of location-based services 
it has agreements with.  The user can find out by trying and failing, 
but the provider giving him a "whitelist" is a short-cut.

As I said to James in Vancouver, though, this is just an optimization 
for the case when an access-controlled LbyR is used to obtain 
value-added services, namely ALL of the location hiding solutions.  It's 
not a differentiator for one solution over another.

--Richard

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 17:33:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Dfi-0001pf-CL; Tue, 11 Dec 2007 17:33:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Dfg-0001pa-KC
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:33:48 -0500
Received: from ironportdmz5.qualcomm.com ([199.106.114.254]
	helo=wolverine01.qualcomm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Dfe-0004Ho-8p
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:33:48 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-Anti-Spam-Filtered:
	X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
	Received:Received:Mime-Version:Message-Id:In-Reply-To:
	References:Date:To:From:Subject:Cc:Content-Type;
	b=DPAEJ75toaQSEBVnj/QbA9hanTTixgw9agyexQJuRyiDzFnUjUD9ynj3
	C6EYkRmGPuGfAvmidOh4EPg8CIVREuJaknngnw+E3HcFolxKUdX+Agggy
	CLO6G/3YMKvjTlGlO2ywEYMAyHQPsBNxSH+C1ljzWB94Djd7JOv6xuu9X
	k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAPCeXkeBLjM7/2dsb2JhbACROw
X-IronPort-AV: E=McAfee;i="5100,188,5183"; a="78454"
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	11 Dec 2007 14:33:45 -0800
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lBBMXinB002892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Dec 2007 14:33:44 -0800
Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27])
	by neophyte.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lBBMXgHB018727; Tue, 11 Dec 2007 14:33:43 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! !! ! c41	p> <	p0 624
	0605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

Date: Tue, 11 Dec 2007 14:33:47 -0800
To: "Winterbottom, James" ,
	"Brian Rosen" ,
	"Liess, Laura" , ,
	"Dawson, Martin" 
From: Ted Hardie 
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 4:16 PM -0600 12/11/07, Winterbottom, James wrote:
>Hi ted,
>
>Comments inline.
>
>Given some of your response I think we are talking past each other.

>[AJW] Perhaps I should have been consistent in my terminology, I used
>access and location provider inter-changeably. I see location always
>being provided to emergency service providers.
>

Yes, this was a source of confusion.

>On the other front, a location provider can form trust relationships
>with service vendors, for example the local pizza parlor, or the AAA, or
>whatever. This would require the recipient of a location URI to
>authenticate with the LIS prior to location being handed out.

In this model, the location provider chooses not to provide location
to the end users  at all, since they could then hand it out as they please,
but to sell it only to those with whom it has business relationships.  That's not really
a location hiding problem; it's entirely a business one.   It's difficult
to get the end user to support this with subscription revenue, so
the relationships have to be broad enough that selling them pays
for the infrastructure.  This really is well outside the problem space
of this working group, though, and I don't see much use in going down
into this rathole here.

The point I was making before is that eliminating access to the location
doesn't eliminate access to the service; I can still call Pizza Igloo even
if you will provide a location URI dereference only to Pizza Leanto.
You're not doing anything to stop access to Pizza Leanto's service,
which was what your initial formulation sounded like.

> > As stated, this doesn't make sense, at least to me.  A VSP with access
>to
>> location
>> can provide exactly the same location-based-routing as the originator
>of
>> that location.
>> If it cannot, some other manipulation of the packet flow must be
>present
>> to prevent
>> it.
>>					Ted
>>
>
>[AJW] If all you give the end point is the service URN (+ dial string),
>a destination URI and a location URI, where the latter requires
>authentication to dereference, how does the VSP get location?

The point I was making is that there is no necessary coupling here;
if the  VSP gets location (say, from a form entry by a customer with
a static line), they can do  the same location-based routing
that an access network can.   The access network's knowledge of
that location does not give it any advantages over *any other entity
which has the location*, unless it is willing to couple its knowledge
of location with deep-packet based inspection (think of the parental
controls done via proxy in some family-oriented networks).

I'm increasingly skeptical of the value of protocol changes here.
Going down this road now seems to involve requiring trust relationships
between every ESRP/PSAP and the location-providing access networks.
We've talked about this in the past, and that just doesn't scale to
the enterprise, so there is no way this mechanism can become truly
general.  The truly general mechanism is always going to be to pass
the location through the one common relationship (with the end user),
so we'd be stuck with two systems that everyone would have to
implement.  That's all kinds of bad.

My personal opinion, of course,
				Ted

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 17:50:59 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2DwJ-0008I6-Bz; Tue, 11 Dec 2007 17:50:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DwI-0008I0-78
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:50:58 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2DwH-000388-H8
	for ecrit@ietf.org; Tue, 11 Dec 2007 17:50:58 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_17_02_02
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Tue, 11 Dec 2007 17:02:02 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 16:50:57 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 16:50:44 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg8ReS9SNeRWdXRTkCQrGmuIDhHEAAAM9fg
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! !! ! c 41	p> 	<	p0 
	624 0605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

From: "Winterbottom, James" 
To: "Ted Hardie" , "Brian Rosen" ,
	"Liess, Laura" , ,
	"Dawson, Martin" 
X-OriginalArrivalTime: 11 Dec 2007 22:50:57.0131 (UTC)
	FILETIME=[4ADC1BB0:01C83C48]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Hi Ted,=0D=0A=0D=0A=0D=0A> >[AJW] Perhaps I should have been consistent in =
my terminology, I used=0D=0A> >access and location provider inter-changeabl=
y. I see location always=0D=0A> >being provided to emergency service provid=
ers.=0D=0A> >=0D=0A>=20=0D=0A> Yes, this was a source of confusion.=0D=0A=0D=
=0A[AJW] I am glad that this cleared up, I shall try to be more consistent=0D=
=0Ain my terminology from now on.=0D=0A=0D=0A>=20=0D=0A> >On the other fron=
t, a location provider can form trust relationships=0D=0A> >with service ve=
ndors, for example the local pizza parlor, or the AAA,=0D=0Aor=0D=0A> >what=
ever. This would require the recipient of a location URI to=0D=0A> >authent=
icate with the LIS prior to location being handed out.=0D=0A>=20=0D=0A> In =
this model, the location provider chooses not to provide location=0D=0A> to=
 the end users  at all, since they could then hand it out as they=0D=0A> pl=
ease,=0D=0A> but to sell it only to those with whom it has business relatio=
nships.=0D=0A> That's not really=0D=0A> a location hiding problem; it's ent=
irely a business one.   It's=0D=0Adifficult=0D=0A> to get the end user to s=
upport this with subscription revenue, so=0D=0A> the relationships have to =
be broad enough that selling them pays=0D=0A> for the infrastructure.  This=
 really is well outside the problem space=0D=0A> of this working group, tho=
ugh, and I don't see much use in going down=0D=0A> into this rathole here.=0D=
=0A>=20=0D=0A=0D=0A[AJW] Actually I think that this is crux of the reason w=
hy location=0D=0Ahiding is important, ECRIT merely highlights that hiding l=
ocation has=0D=0Aother implications.=0D=0A=0D=0A> The point I was making be=
fore is that eliminating access to the=0D=0Alocation=0D=0A> doesn't elimina=
te access to the service; I can still call Pizza Igloo=0D=0Aeven=0D=0A> if =
you will provide a location URI dereference only to Pizza Leanto.=0D=0A> Yo=
u're not doing anything to stop access to Pizza Leanto's service,=0D=0A> wh=
ich was what your initial formulation sounded like.=0D=0A>=0D=0A=0D=0A[AJW]=
 What you say is true, and where location dependent routing is not=0D=0Areq=
uired, either because you have the address of the local franchise, or=0D=0A=
because you are only local anyway, then there isn't a problem. If Pizza=0D=0A=
Leanto has a central office in San Francisco though, and you are calling=0D=
=0Afrom Washington DC, then things may not go where you expect them to.=0D=0A=0D=
=0A> >=0D=0A> >[AJW] If all you give the end point is the service URN (+ di=
al=0D=0Astring),=0D=0A> >a destination URI and a location URI, where the la=
tter requires=0D=0A> >authentication to dereference, how does the VSP get l=
ocation=3F=0D=0A>=20=0D=0A> The point I was making is that there is no nece=
ssary coupling here;=0D=0A> if the  VSP gets location (say, from a form ent=
ry by a customer with=0D=0A> a static line), they can do  the same location=
-based routing=0D=0A> that an access network can.=0D=0A=0D=0A[AJW] This is =
true, but it requires the user to do something, where they=0D=0Adon't have =
to do anything if the location provider provides them with=0D=0Aeverything =
they need. I would wager that for many people if Domino's is=0D=0Ain the pr=
eferred service list and Pizza hut isn't, then they will just=0D=0Acall Dom=
ino's rather than entering their location through a form so that=0D=0Athey =
can route to the local Pizza Hut.=0D=0A=0D=0A=0D=0A   The access network's =
knowledge of=0D=0A> that location does not give it any advantages over *any=
 other entity=0D=0A> which has the location*, unless it is willing to coupl=
e its knowledge=0D=0A> of location with deep-packet based inspection (think=
 of the parental=0D=0A> controls done via proxy in some family-oriented net=
works).=0D=0A>=0D=0A=0D=0A[AJW] This is absolutely true. The difference tha=
t the location provider=0D=0Ahas is that it is potentially easier for them =
to obtain and do things=0D=0Awith the location, and as I hinted before most=
 users of these types of=0D=0Aservices will go with the easiest option.=0D=0A=
=20=0D=0A> I'm increasingly skeptical of the value of protocol changes here=
=2E=0D=0A> Going down this road now seems to involve requiring trust=0D=0Ar=
elationships=0D=0A> between every ESRP/PSAP and the location-providing acce=
ss networks.=0D=0A> We've talked about this in the past, and that just does=
n't scale to=0D=0A> the enterprise, so there is no way this mechanism can b=
ecome truly=0D=0A> general.  The truly general mechanism is always going to=
 be to pass=0D=0A> the location through the one common relationship (with t=
he end user),=0D=0A> so we'd be stuck with two systems that everyone would =
have to=0D=0A> implement.  That's all kinds of bad.=0D=0A>=20=0D=0A> My per=
sonal opinion, of course,=0D=0A>=20=0D=0A=0D=0A[AJW] I am not sure the prob=
lem is so large, or that the bad is so bad.=0D=0AI do agree however that no=
t trying to hide location at all would be the=0D=0Abest solution.=0D=0A=0D=0A=
Cheers=0D=0AJames=0D=0A=09=09=09=09=0D=0A=0D=0A----------------------------=
--------------------------------------------------------------------=0D=0AT=
his message is for the designated recipient only and may=0D=0Acontain privi=
leged, proprietary, or otherwise private information. =20=0D=0AIf you have =
received it in error, please notify the sender=0D=0Aimmediately and delete =
the original.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A=
---------------------------------------------------------------------------=
---------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 18:37:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Efd-0006fM-3e; Tue, 11 Dec 2007 18:37:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Efc-0006eA-6h
	for ecrit@ietf.org; Tue, 11 Dec 2007 18:37:48 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Efb-0004YB-GM
	for ecrit@ietf.org; Tue, 11 Dec 2007 18:37:48 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_17_48_48
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, 11 Dec 2007 17:48:48 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 17:37:42 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 17:37:43 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg8ReTFYO7bkhXqSgKupLz1DLbVWAABwoSA
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! !! ! c 41	p> 	<	p0 
	624 0605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

From: "Dawson, Martin" 
To: "Ted Hardie" ,
	"Winterbottom, James" ,
	"Brian Rosen" ,
	"Liess, Laura" , 
X-OriginalArrivalTime: 11 Dec 2007 23:37:42.0642 (UTC)
	FILETIME=[D3131D20:01C83C4E]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Hi Ted,=0D=0A=0D=0A> so we'd be stuck with two systems that everyone would =
have to=0D=0A> implement.  That's all kinds of bad.=0D=0A=0D=0AThey are two=
 different models for location based service - there's also=0D=0Aa third ty=
pe of location query based on user-identity and made to a=0D=0Apresence ser=
vice. Location queries to a LIS are largely anonymous.=0D=0A=0D=0AIn keepin=
g with the "nothing new under the sun" principle, these models=0D=0Aalready=
 have a precedent.=0D=0A=0D=0A3GPP defines three categories of location req=
uest:=0D=0A=0D=0AMO-LR - "mobile originated location request". The device r=
equests=0D=0Alocation from the access network and obtains it for its own pu=
rpose.=0D=0A=0D=0ANI-LR - "network initiated location request". The network=
 queries the=0D=0Alocation server for some network based application (emerg=
ency calling be=0D=0Athe classic case).=0D=0A=0D=0AMT-LR - "mobile terminat=
ed location request". Some application external=0D=0Ato the network request=
 the location of the device based on the=0D=0Asubscriber identity (phone nu=
mber).=0D=0A=0D=0AA device-initiated LbyV request is really the MO-LR case.=
 LbyR is=0D=0Adifferent primarily because of the more fundamental access-se=
rvice split=0D=0Athat occurs in the Internet but, for the types of services=
 being=0D=0Adiscussed, it's very like the NI-LR in some cases and the MT-LR=
 in=0D=0Aothers. A query for location to a presence service is the MT-LR ca=
se.=0D=0A=0D=0AAs opposed to being "all kinds of bad", I'd posit that these=
 models will=0D=0Ainevitably emerge and, in fact, they live together quite =
comfortably.=0D=0AWhile ever we have protocol specifications that don't sup=
port all these=0D=0Amodels there will be somebody who is experiencing frust=
ration and=0D=0Adiscontent with the specifications.=0D=0A=0D=0ACheers,=0D=0A=
Martin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Ted Hardie [mailto:=
hardie@qualcomm.com]=20=0D=0ASent: Wednesday, 12 December 2007 9:34 AM=0D=0A=
To: Winterbottom, James; Brian Rosen; Liess, Laura; bs7652@att.com;=0D=0ADa=
wson, Martin=0D=0ACc: ecrit@ietf.org=0D=0ASubject: RE: AW: [Ecrit] Location=
 Hiding -- State of the Art=0D=0A=0D=0AAt 4:16 PM -0600 12/11/07, Winterbot=
tom, James wrote:=0D=0A>Hi ted,=0D=0A>=0D=0A>Comments inline.=0D=0A>=0D=0A>=
Given some of your response I think we are talking past each other.=0D=0A=0D=0A=0D=0A=0D=0A>[AJW] Perhaps I should have been consistent in my te=
rminology, I used=0D=0A>access and location provider inter-changeably. I se=
e location always=0D=0A>being provided to emergency service providers.=0D=0A=
>=0D=0A=0D=0AYes, this was a source of confusion.=0D=0A=0D=0A>On the other =
front, a location provider can form trust relationships=0D=0A>with service =
vendors, for example the local pizza parlor, or the AAA,=0D=0Aor=0D=0A>what=
ever. This would require the recipient of a location URI to=0D=0A>authentic=
ate with the LIS prior to location being handed out.=0D=0A=0D=0AIn this mod=
el, the location provider chooses not to provide location=0D=0Ato the end u=
sers  at all, since they could then hand it out as they=0D=0Aplease,=0D=0Ab=
ut to sell it only to those with whom it has business relationships.=0D=0AT=
hat's not really=0D=0Aa location hiding problem; it's entirely a business o=
ne.   It's=0D=0Adifficult=0D=0Ato get the end user to support this with sub=
scription revenue, so=0D=0Athe relationships have to be broad enough that s=
elling them pays=0D=0Afor the infrastructure.  This really is well outside =
the problem space=0D=0Aof this working group, though, and I don't see much =
use in going down=0D=0Ainto this rathole here.=0D=0A=0D=0AThe point I was m=
aking before is that eliminating access to the location=0D=0Adoesn't elimin=
ate access to the service; I can still call Pizza Igloo=0D=0Aeven=0D=0Aif y=
ou will provide a location URI dereference only to Pizza Leanto.=0D=0AYou'r=
e not doing anything to stop access to Pizza Leanto's service,=0D=0Awhich w=
as what your initial formulation sounded like.=0D=0A=0D=0A=0D=0A> > As stat=
ed, this doesn't make sense, at least to me.  A VSP with=0D=0Aaccess=0D=0A>=
to=0D=0A>> location=0D=0A>> can provide exactly the same location-based-rou=
ting as the originator=0D=0A>of=0D=0A>> that location.=0D=0A>> If it cannot=
, some other manipulation of the packet flow must be=0D=0A>present=0D=0A>> =
to prevent=0D=0A>> it.=0D=0A>>=09=09=09=09=09Ted=0D=0A>>=0D=0A>=0D=0A>[AJW]=
 If all you give the end point is the service URN (+ dial string),=0D=0A>a =
destination URI and a location URI, where the latter requires=0D=0A>authent=
ication to dereference, how does the VSP get location=3F=0D=0A=0D=0AThe poi=
nt I was making is that there is no necessary coupling here;=0D=0Aif the  V=
SP gets location (say, from a form entry by a customer with=0D=0Aa static l=
ine), they can do  the same location-based routing=0D=0Athat an access netw=
ork can.   The access network's knowledge of=0D=0Athat location does not gi=
ve it any advantages over *any other entity=0D=0Awhich has the location*, u=
nless it is willing to couple its knowledge=0D=0Aof location with deep-pack=
et based inspection (think of the parental=0D=0Acontrols done via proxy in =
some family-oriented networks).=0D=0A=0D=0AI'm increasingly skeptical of th=
e value of protocol changes here.=0D=0AGoing down this road now seems to in=
volve requiring trust relationships=0D=0Abetween every ESRP/PSAP and the lo=
cation-providing access networks.=0D=0AWe've talked about this in the past,=
 and that just doesn't scale to=0D=0Athe enterprise, so there is no way thi=
s mechanism can become truly=0D=0Ageneral.  The truly general mechanism is =
always going to be to pass=0D=0Athe location through the one common relatio=
nship (with the end user),=0D=0Aso we'd be stuck with two systems that ever=
yone would have to=0D=0Aimplement.  That's all kinds of bad.=0D=0A=0D=0AMy =
personal opinion, of course,=0D=0A=09=09=09=09Ted=0D=0A=0D=0A--------------=
---------------------------------------------------------------------------=
-------=0D=0AThis message is for the designated recipient only and may=0D=0A=
contain privileged, proprietary, or otherwise private information. =20=0D=0A=
If you have received it in error, please notify the sender=0D=0Aimmediately=
 and delete the original.  Any unauthorized use of=0D=0Athis email is prohi=
bited.=0D=0A---------------------------------------------------------------=
---------------------------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 18:53:43 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Ev0-0006FH-Ed; Tue, 11 Dec 2007 18:53:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Euz-0006FA-7h
	for ecrit@ietf.org; Tue, 11 Dec 2007 18:53:41 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Euy-0006HP-Od
	for ecrit@ietf.org; Tue, 11 Dec 2007 18:53:41 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2Eut-00019w-ND; Tue, 11 Dec 2007 17:53:35 -0600
From: "Brian Rosen" 
To: "'Marc Linsner'" ,
	"'ECRIT'" 
References: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
Subject: RE: [Ecrit] Forward Progress
Date: Tue, 11 Dec 2007 18:53:37 -0500
Message-ID: <005701c83c51$0df2c290$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg8Pgj2dqflZy3VTZ6b9wS7hhXpQAAEeajw
In-Reply-To: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

There is some belief that we can deploy location hiding without
specification.  My proposal only involves what the LIS does, for example.  I
fear unspecified things will be implemented badly, which is why I wanted
text in -phonebcp.  If that's not possible, then we'll have to live without
it.

I'd prefer to see if we can get a rough consensus on the proposal on the
table.  We're not going to get a unanimous consensus.

With respect to unauthenticated access, I do think we need mechanism,
because it's not possible for a VSP to know what to do.  The access network
can just obey its own local regulations, so no problem there, but a VSP on
the Internet doesn't know what to do; it's location dependent.

I think we need a solution.  I don't think it's hard, since the only thing a
VSP can do is pass or not pass the call through.  What I think we need is a
flag from LoST that says whether unauthenticated calling is required in the
location specified.  It might be able to be a single bit, but perhaps an
enumerated type makes more sense for possible future variations in what the
VSP has to do.

Endpoints can try regardless.  PSAPs take calls they get, generally.  It's
really the VSP that is in the dark.

Brian

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Tuesday, December 11, 2007 4:38 PM
> To: 'ECRIT'
> Subject: [Ecrit] Forward Progress
> 
> It appears that forward progress with regards to 'Location Hiding' and
> 'Unauthenticated Access' is going to take some time.  In an effort to
> complete current milestones, what are opinions about adding the text below
> to phonebcp/framework?
> 
> "This document provides guidance for generic network configurations.  It
> is
> recognized that unique issues may exist in some network deployments.  The
> IETF will continue to investigate these unique situations and provide
> further guidance, if warranted, in future documents."
> 
> -Marc-
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 18:58:00 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Ez9-00027f-Dn; Tue, 11 Dec 2007 18:57:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ez7-00027Q-HP
	for ecrit@ietf.org; Tue, 11 Dec 2007 18:57:57 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Ez6-0004yb-GB
	for ecrit@ietf.org; Tue, 11 Dec 2007 18:57:57 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2Ez0-0001RW-Pp; Tue, 11 Dec 2007 17:57:51 -0600
From: "Brian Rosen" 
To: "'Winterbottom, James'" ,
	"'Liess, Laura'" , ,
	, "'Dawson, Martin'" 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> <	p0
	6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 18:57:52 -0500
Message-ID: <005801c83c51$a60dd100$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiAAAViIIAAEpTsw
In-Reply-To: 
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Access providers don=92t route calls, so it's impossible for them to =
provide a
call routing service (unless of course the VSP and the ASP are the same
entity).  The LIS controls access always.  It can authorize a VSP to get
location and provide location based routing, and it can do so for any =
set of
services it wishes to.  It could even provide the LoST server for such
services. =20

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Tuesday, December 11, 2007 4:43 PM
> To: Brian Rosen; Liess, Laura; hardie@qualcomm.com; bs7652@att.com;
> Dawson, Martin
> Cc: ecrit@ietf.org
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> I will reply to this in more detail later Brian, when my brain is a =
little
> less fried.
>=20
> The basis of my proposal is that the Location provider knows what =
services
> etc that it will grant access to. There is no way for the VSP to know =
this
> unless they are also the access provider. So while the VSPs may want =
to
> get into the location dependent routing game, I think that this is
> actually a very good value-add that access providers will have =
dominance
> over for some time.
>=20
> Cheers
> James
>=20
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Wednesday, 12 December 2007 8:21 AM
> > To: 'Liess, Laura'; hardie@qualcomm.com; Winterbottom, James;
> > bs7652@att.com; Dawson, Martin
> > Cc: ecrit@ietf.org
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Yeah, my problem with this is that every client has to implement two
> > mechanisms.  They need to implement the LCP then dereference then =
LoST
> > lookup AND they have to implement the HELD+LoST mechanism.
> >
> > I think this mechanism requires the reverse LoST lookup for VSPs, so
> more
> > work for LoST servers.  I think James wants to ignore that problem
> > (something about letting VSPs charge for emergency calls and working =
it
> > out
> > later).
> >
> > BTW, the HELD return would have to supply ALL of the service URNs,
> > dialstrings, and boundaries that the LoST server knows about.  I'm =
not
> > quite
> > sure how the HELD server figures that out.  If there are commercial
> > services
> > using LoST, all of them would have to be returned.  I think the VSP
> wants
> > to
> > get into the "Location Based Routing" act (they do route calls after
> all,
> > and ISPs don't).  I'm not sure how it would do so with this =
proposal.
> >
> > If the device is mobile, what happens?  The way we specified it so =
far,
> > the
> > endpoint would subscribe to a location update service and get =
location
> > updates.  It would have the service boundary from LoST, and it would
> > requery
> > if it moved beyond the service boundary.  That works, and makes =
sense to
> > me.
> > I'm not sure what James proposes.
> >
> > If we're going to go beyond the basic location hiding idea, using =
what I
> > proposed, which takes no standards changes and puts the burden on =
the
> LIS
> > who is hiding location, then I think Richard's idea of allowing LoST =
to
> > dereference is a better one.  I don't like that idea; we've talked =
about
> > why
> > it's not a great idea in the past, but it's better than James'.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com]
> > > Sent: Tuesday, December 11, 2007 3:58 PM
> > > To: hardie@qualcomm.com; James.Winterbottom@andrew.com;
> bs7652@att.com;
> > > br@brianrosen.net; Martin.Dawson@andrew.com
> > > Cc: ecrit@ietf.org
> > > Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > >
> > > I see two advantages with James URI proposal:
> > >
> > > 1) It's simple. People (also product managers) understand it =
within 2
> > > minutes and like it exactly for this reason. The chance to get it
> > > implemented soon is probably quite high.
> > >
> > > 2) The ISP provider is responsible for most EC functionality. The =
VSP
> is
> > > just "transport". (Marc pointed out this aspect to me last week.)
> > Probably
> > > the regulators would like this because they can control the ISPs
> better
> > > than the VSPs.
> > > The chance for this solution to work, at lest at the beginning, is
> > > probably higher than if 3 different providers (the ISP, the VSP =
and
> the
> > > LOST provider), with eventually conflicting economical interests, =
have
> > to
> > > cooperate to provide the EC functionality.
> > >
> > > What if we have both options, coarse location and ESRP/PSAP URI? =
Does
> > this
> > > mean too high implementation effort for clients?
> > >
> > > Laura
> > >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: Ted Hardie [mailto:hardie@qualcomm.com]
> > > Gesendet: Montag, 10. Dezember 2007 22:38
> > > An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, =
Martin;
> > > Henning Schulzrinne
> > > Cc: ecrit@ietf.org; Liess, Laura
> > > Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
> > > >If the device is simply given a PSAP URI, a service URN, and a
> location
> > > >URI, what more does it need?
> > >
> > > As several people have pointed out, it needs/could use the ability =
to
> > > sanity
> > > check the location.  You've argued it doesn't need that as much as
> > > the operators need to be paid for location infrastructure =
deployed,
> > > which set up the whole apples to oranges discussion that has been
> > > going so far.
> > >
> > > Past that, you're introducing a mechanism that combines two =
services
> > > (receiving a location and associating that location with a psap =
URI).
> > If
> > > you gave
> > > that data to a device which has a different LoST server =
configured,
> what
> > > do you expect to happen?  Is it going to pass that location URI to =
its
> > > own LoST server to confirm it gets the same PSAP URI?  The current
> > > system allows a user/device to request service boundaries and to
> > > make reasonable choices about when to refresh URI mappings.  How
> > > are you replicating that functionality?  The service boundaries =
are,
> > > after all, pretty much at the level of Brian's proposal.
> > >
> > > > > For non-emergency cases, you are dealing instead with the
> > > >> case where you have a concern that selling someone location
> > > >> for purpose X gets them location for purpose Y.  That's both
> > > >> a different problem and it falls into an area where there are
> > > >> enough other problems that it is, honestly, probably the least
> > > >> of your worries.  It's also way out of the charter of this =
group.
> > > >>
> > > >
> > > >I would argue that location hiding is not in the charter of this =
WG
> at
> > > >all. How to route to a PSAP is the current charter, so if the =
end-
> point
> > > >is given all it needs to route to the PSAP then we are done =
aren't
> we?
> > > >
> > >
> > > I agree that location hiding is not in the charter of this working
> > group.
> > > You've been among those saying it had to be considered.  What =
you're
> > > proposing goes in a different design direction to the one the
> > > working group has had so far and it goes against some base =
principles
> > > of location in GeoPRIV contexts as well (see:  the user controls
> access
> > to
> > > his/her location)
> > >
> > > If what you were providing were as robust as the other methods =
being
> > > offered we might be done, despite the design difference.  But =
there is
> > > no consensus that this is the case.  At least Henning and I feel =
it is
> > > more
> > > fragile.  I believe there are others as well.
> > >
> > > >Umm, how is providing the end point with where it needs to go =
more
> > > >fragile than giving it a bodgey location?
> > > >
> > >
> > > It can check the location it is provided.  You can be working off =
a
> > bodgey
> > > location, and it would never know.
> > >
> > > Really, try the cocoa.  It's quite nice.
> > > 				Ted
> > >
> > >
> > >
> > > >
> > > >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
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 19:15:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2FFd-0002Vh-5y; Tue, 11 Dec 2007 19:15:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2FFb-0002MZ-5M
	for ecrit@ietf.org; Tue, 11 Dec 2007 19:14:59 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2FFa-0006hR-R9
	for ecrit@ietf.org; Tue, 11 Dec 2007 19:14:59 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2FFV-0002eZ-Nn; Tue, 11 Dec 2007 18:14:53 -0600
From: "Brian Rosen" 
To: "'Stark, Barbara'" ,
	"'ECRIT'" 
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABBAC1@crexc41p>
Subject: RE: [Ecrit] Phonebcp and LoST responses
Date: Tue, 11 Dec 2007 19:14:55 -0500
Message-ID: <005f01c83c54$07ba04d0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg8RFG8SQGDOVYzQxq9bzRXv1aTnQAD5lSQ
In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06ABBAC1@crexc41p>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Yeah, probably needed.  Things can go wrong, and no LoST server could be
found, for example.

Brian

> -----Original Message-----
> From: Stark, Barbara [mailto:bs7652@att.com]
> Sent: Tuesday, December 11, 2007 5:23 PM
> To: ECRIT
> Subject: [Ecrit] Phonebcp and LoST responses
> 
> 
> In phonebcp section 8, it says that if a device can't get a LoST
> response, it must use its cached value. I'm wondering if we could add
> another statement, that if it has no cached value and no LoST response,
> it must leave off the route header and just send the Service URN in the
> Request URI (or whatever the correct description is)? I think that would
> be consistent with the use of LoST only being a should, in the first
> place, and the role of the "SP" in phonebcp as being responsible for
> being able to handle this situation.
> Barbara
> 
> *****
> 
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA621
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 20:03:35 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2G0a-0002gI-FG; Tue, 11 Dec 2007 20:03:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2G0Y-0002aK-VU
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:03:30 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2G0W-00082t-JU
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:03:30 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_19_14_33
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, 11 Dec 2007 19:14:33 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 19:03:28 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 19:03:25 -0600
Message-ID: 
In-Reply-To: <066801c83c3b$bd820150$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiAABk7wYA==
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> 
	<	p0 6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>
From: "Dawson, Martin" 
To: "Brian Rosen" ,
	"Liess, Laura" , ,
	"Winterbottom, James" , 
X-OriginalArrivalTime: 12 Dec 2007 01:03:28.0077 (UTC)
	FILETIME=[CDFE2FD0:01C83C5A]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I like Leisa's suggestion and she just beat me to the proposal. My question=
 as to why it's a good idea to involve VSPs at all still hasn't really been=
 answered. My *opinion* is that the VSP should only be involved if the call=
ing device can't call directly to the PSAP. This would lead to the followin=
g logic for a device (assuming the LIS response would contain any one or mo=
re of coarse location, location-URI, PSAP-URI):=0D=0A=0D=0A1. Request locat=
ion=0D=0A2. PSAP URI provided with loc-URI and device is ECRIT-capable=3F=0D=
=0A=092 a. Route call to PSAP with Loc-URI and preferred callback details=0D=
=0A=092.b. End=0D=0A3. PSAP URI not provided and device is ECRIT-capable=3F=0D=
=0A=093.a. Do LoST procedure to obtain PSAP URI using coarse location=0D=0A=
=093.b. Successful LoST lookup=3F=0D=0A=09=093.b.i Route call to PSAP with =
preferred callback details=0D=0A=09=093.b.ii End=0D=0A4. Either device is n=
ot ECRIT-capable or the local jurisdiction or access network are not ECRIT-=
capable (e.g. No LoST service or no successful lookup)=0D=0A5. Send coarse =
location and location reference to VSP=0D=0A4. VSP invokes proxy emergency =
support using i2 or other solution=0D=0A5. End=0D=0A=0D=0AThe definition of=
 "ECRIT-capable" in the above is my own - and it means "permitting emergenc=
y services to be located and called with just an Internet connection". In o=
ther words, anything that happens once the call is sent to a VSP can be out=
 of scope for ECRIT. I figure that's probably contentious but I think it's =
a more pure position - given there are already interim architectures that u=
tilize VSPs.=0D=0A=0D=0AThis supports jurisdictions that aren't ECRIT-capab=
le - i.e. the LIS won't provide a PSAP URI or there is no LoST service or m=
apping for that location.=0D=0A=0D=0AIt supports devices that aren't ECRIT-=
capable - i.e. they only know how to ask for location and initiate calls th=
rough the VSP.=0D=0A=0D=0AIn my *opinion* the VSP should not be involved un=
less there is a reason the call can't be made directly to the PSAP. I don't=
 accept the "authenticated" argument (if that's what it's about). You can't=
 guarantee somebody has a VSP or, indeed, that the VSP's authentication mea=
ns anything to the PSAP. If authentication is important at all, it's only g=
oing to be the authentication that occurs at the access. Signed location, I=
 believe, is actually more important than access authentication in any case=
=2E It would bring ECRIT up to par with emergency calls made from public pa=
y phones.=0D=0A=0D=0AMy suggestion is that we pool resources to make an ope=
n-source reference implementation of an ECRIT emergency client that embodie=
s the above procedure. Brian says below that he doesn't want devices to imp=
lement two mechanisms. I agree it's not ideal in the long term but it's imp=
ossible not to recognise this situation in the interim. A reference client =
implementation would mitigate this issue.=0D=0A=0D=0ABearing in mind that a=
 given device may have no VSP client or multiple VSP clients, I believe it =
would be preferable to have a relatively independent and standard emergency=
 client implementation that independent open-source and commercial VoIP cli=
ent implementers could integrate.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A=
-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net=
]=20=0D=0ASent: Wednesday, 12 December 2007 8:21 AM=0D=0ATo: 'Liess, Laura'=
; hardie@qualcomm.com; Winterbottom, James; bs7652@att.com; Dawson, Martin=0D=
=0ACc: ecrit@ietf.org=0D=0ASubject: RE: AW: [Ecrit] Location Hiding -- Stat=
e of the Art=0D=0A=0D=0AYeah, my problem with this is that every client has=
 to implement two=0D=0Amechanisms.  They need to implement the LCP then der=
eference then LoST=0D=0Alookup AND they have to implement the HELD+LoST mec=
hanism.=20=0D=0A=0D=0AI think this mechanism requires the reverse LoST look=
up for VSPs, so more=0D=0Awork for LoST servers.  I think James wants to ig=
nore that problem=0D=0A(something about letting VSPs charge for emergency c=
alls and working it out=0D=0Alater).=0D=0A=0D=0ABTW, the HELD return would =
have to supply ALL of the service URNs,=0D=0Adialstrings, and boundaries th=
at the LoST server knows about.  I'm not quite=0D=0Asure how the HELD serve=
r figures that out.  If there are commercial services=0D=0Ausing LoST, all =
of them would have to be returned.  I think the VSP wants to=0D=0Aget into =
the "Location Based Routing" act (they do route calls after all,=0D=0Aand I=
SPs don't).  I'm not sure how it would do so with this proposal. =20=0D=0A=0D=
=0AIf the device is mobile, what happens=3F  The way we specified it so far=
, the=0D=0Aendpoint would subscribe to a location update service and get lo=
cation=0D=0Aupdates.  It would have the service boundary from LoST, and it =
would requery=0D=0Aif it moved beyond the service boundary.  That works, an=
d makes sense to me.=0D=0AI'm not sure what James proposes.=0D=0A=0D=0AIf w=
e're going to go beyond the basic location hiding idea, using what I=0D=0Ap=
roposed, which takes no standards changes and puts the burden on the LIS=0D=
=0Awho is hiding location, then I think Richard's idea of allowing LoST to=0D=
=0Adereference is a better one.  I don't like that idea; we've talked about=
 why=0D=0Ait's not a great idea in the past, but it's better than James'.=0D=
=0A=0D=0ABrian=20=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Lies=
s, Laura [mailto:Laura.Liess@t-systems.com]=0D=0A> Sent: Tuesday, December =
11, 2007 3:58 PM=0D=0A> To: hardie@qualcomm.com; James.Winterbottom@andrew.=
com; bs7652@att.com;=0D=0A> br@brianrosen.net; Martin.Dawson@andrew.com=0D=0A=
> Cc: ecrit@ietf.org=0D=0A> Subject: AW: AW: [Ecrit] Location Hiding -- Sta=
te of the Art=0D=0A>=20=0D=0A>=20=0D=0A> I see two advantages with James UR=
I proposal:=0D=0A>=20=0D=0A> 1) It's simple. People (also product managers)=
 understand it within 2=0D=0A> minutes and like it exactly for this reason.=
 The chance to get it=0D=0A> implemented soon is probably quite high.=0D=0A=
>=20=0D=0A> 2) The ISP provider is responsible for most EC functionality. T=
he VSP is=0D=0A> just "transport". (Marc pointed out this aspect to me last=
 week.) Probably=0D=0A> the regulators would like this because they can con=
trol the ISPs better=0D=0A> than the VSPs.=0D=0A> The chance for this solut=
ion to work, at lest at the beginning, is=0D=0A> probably higher than if 3 =
different providers (the ISP, the VSP and the=0D=0A> LOST provider), with e=
ventually conflicting economical interests, have to=0D=0A> cooperate to pro=
vide the EC functionality.=0D=0A>=20=0D=0A> What if we have both options, c=
oarse location and ESRP/PSAP URI=3F Does this=0D=0A> mean too high implemen=
tation effort for clients=3F=0D=0A>=20=0D=0A> Laura=0D=0A>=20=0D=0A> -----U=
rspr=FCngliche Nachricht-----=0D=0A> Von: Ted Hardie [mailto:hardie@qualcom=
m.com]=0D=0A> Gesendet: Montag, 10. Dezember 2007 22:38=0D=0A> An: Winterbo=
ttom, James; Stark, Barbara; Brian Rosen; Dawson, Martin;=0D=0A> Henning Sc=
hulzrinne=0D=0A> Cc: ecrit@ietf.org; Liess, Laura=0D=0A> Betreff: RE: AW: [=
Ecrit] Location Hiding -- State of the Art=0D=0A>=20=0D=0A> At 1:25 PM -060=
0 12/10/07, Winterbottom, James wrote:=0D=0A> >If the device is simply give=
n a PSAP URI, a service URN, and a location=0D=0A> >URI, what more does it =
need=3F=0D=0A>=20=0D=0A> As several people have pointed out, it needs/could=
 use the ability to=0D=0A> sanity=0D=0A> check the location.  You've argued=
 it doesn't need that as much as=0D=0A> the operators need to be paid for l=
ocation infrastructure deployed,=0D=0A> which set up the whole apples to or=
anges discussion that has been=0D=0A> going so far.=0D=0A>=20=0D=0A> Past t=
hat, you're introducing a mechanism that combines two services=0D=0A> (rece=
iving a location and associating that location with a psap URI).  If=0D=0A>=
 you gave=0D=0A> that data to a device which has a different LoST server co=
nfigured, what=0D=0A> do you expect to happen=3F  Is it going to pass that =
location URI to its=0D=0A> own LoST server to confirm it gets the same PSAP=
 URI=3F  The current=0D=0A> system allows a user/device to request service =
boundaries and to=0D=0A> make reasonable choices about when to refresh URI =
mappings.  How=0D=0A> are you replicating that functionality=3F  The servic=
e boundaries are,=0D=0A> after all, pretty much at the level of Brian's pro=
posal.=0D=0A>=20=0D=0A> > > For non-emergency cases, you are dealing instea=
d with the=0D=0A> >> case where you have a concern that selling someone loc=
ation=0D=0A> >> for purpose X gets them location for purpose Y.  That's bot=
h=0D=0A> >> a different problem and it falls into an area where there are=0D=
=0A> >> enough other problems that it is, honestly, probably the least=0D=0A=
> >> of your worries.  It's also way out of the charter of this group.=0D=0A=
> >>=0D=0A> >=0D=0A> >I would argue that location hiding is not in the char=
ter of this WG at=0D=0A> >all. How to route to a PSAP is the current charte=
r, so if the end-point=0D=0A> >is given all it needs to route to the PSAP t=
hen we are done aren't we=3F=0D=0A> >=0D=0A>=20=0D=0A> I agree that locatio=
n hiding is not in the charter of this working group.=0D=0A> You've been am=
ong those saying it had to be considered.  What you're=0D=0A> proposing goe=
s in a different design direction to the one the=0D=0A> working group has h=
ad so far and it goes against some base principles=0D=0A> of location in Ge=
oPRIV contexts as well (see:  the user controls access to=0D=0A> his/her lo=
cation)=0D=0A>=20=0D=0A> If what you were providing were as robust as the o=
ther methods being=0D=0A> offered we might be done, despite the design diff=
erence.  But there is=0D=0A> no consensus that this is the case.  At least =
Henning and I feel it is=0D=0A> more=0D=0A> fragile.  I believe there are o=
thers as well.=0D=0A>=20=0D=0A> >Umm, how is providing the end point with w=
here it needs to go more=0D=0A> >fragile than giving it a bodgey location=3F=0D=
=0A> >=0D=0A>=20=0D=0A> It can check the location it is provided.  You can =
be working off a bodgey=0D=0A> location, and it would never know.=0D=0A> =0D=
=0A> Really, try the cocoa.  It's quite nice.=0D=0A> =09=09=09=09Ted=0D=0A>=
=20=0D=0A>=20=0D=0A>=20=0D=0A> >=0D=0A> >Cheers=0D=0A> >James=0D=0A> >-----=
--------------------------------------------------------------------=0D=0A>=
 -----------------------=0D=0A> >This message is for the designated recipie=
nt only and may=0D=0A> >contain privileged, proprietary, or otherwise priva=
te information.=0D=0A> >If you have received it in error, please notify the=
 sender=0D=0A> >immediately and delete the original.  Any unauthorized use =
of=0D=0A> >this email is prohibited.=0D=0A> >------------------------------=
-------------------------------------------=0D=0A> -----------------------=0D=
=0A> >[mf2]=0D=0A> >=0D=0A=0D=0A=0D=0A-------------------------------------=
-----------------------------------------------------------=0D=0AThis messa=
ge is for the designated recipient only and may=0D=0Acontain privileged, pr=
oprietary, or otherwise private information. =20=0D=0AIf you have received =
it in error, please notify the sender=0D=0Aimmediately and delete the origi=
nal.  Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A---------=
---------------------------------------------------------------------------=
------------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 20:35:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2GVm-0003rZ-Q0; Tue, 11 Dec 2007 20:35:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2GVm-0003r0-44
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:35:46 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2GVk-0000Tg-SB
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:35:46 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2GVe-0007Ng-Mw; Tue, 11 Dec 2007 19:35:39 -0600
From: "Brian Rosen" 
To: "'Dawson, Martin'" ,
	"'Liess, Laura'" , ,
	"'Winterbottom, James'" , 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> <	p0
	6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 20:35:40 -0500
Message-ID: <007b01c83c5f$4feab280$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiAABk7wYAAC4V0A
In-Reply-To: 
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Although we need to permit emergency calls that don't come from a =
carrier,
we really don't want to encourage them.  Carriers provide quite a few =
things
that PSAPs want, not the least of which is someone to call for help when
things go wrong.  Consider, for example, call-backs.  Given NATs, you =
can't
call a bare device back; you can't get a signaling message to it.  You =
need
an incoming proxy that is reachable.  Further, many devices won't accept
calls from arbitrary callers; calls come from their incoming proxy.
You also don't get P-A-I or Identity.  You don't get additional =
information
about the call (subscriber name and address for example).  You don't get
most forms of default routing.  So, please, let's not bypass carriers =
for
emergency calls.

We've been around the notion that access networks provide emergency =
proxies.
That doesn't work either.  Similar problems, plus the problem that while =
a
PSAP can restrict calls to be SIP based (and maybe one or two others), =
lots
of services actually use proprietary protocols, or extensions, between =
the
device and the service provider.  The access network can't deal with =
that.

I don't think it helps to try to redefine the basics here.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Tuesday, December 11, 2007 8:03 PM
> To: Brian Rosen; Liess, Laura; hardie@qualcomm.com; Winterbottom, =
James;
> bs7652@att.com
> Cc: ecrit@ietf.org
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> I like Leisa's suggestion and she just beat me to the proposal. My
> question as to why it's a good idea to involve VSPs at all still =
hasn't
> really been answered. My *opinion* is that the VSP should only be =
involved
> if the calling device can't call directly to the PSAP. This would lead =
to
> the following logic for a device (assuming the LIS response would =
contain
> any one or more of coarse location, location-URI, PSAP-URI):
>=20
> 1. Request location
> 2. PSAP URI provided with loc-URI and device is ECRIT-capable?
> 	2 a. Route call to PSAP with Loc-URI and preferred callback details
> 	2.b. End
> 3. PSAP URI not provided and device is ECRIT-capable?
> 	3.a. Do LoST procedure to obtain PSAP URI using coarse location
> 	3.b. Successful LoST lookup?
> 		3.b.i Route call to PSAP with preferred callback details
> 		3.b.ii End
> 4. Either device is not ECRIT-capable or the local jurisdiction or =
access
> network are not ECRIT-capable (e.g. No LoST service or no successful
> lookup)
> 5. Send coarse location and location reference to VSP
> 4. VSP invokes proxy emergency support using i2 or other solution
> 5. End
>=20
> The definition of "ECRIT-capable" in the above is my own - and it =
means
> "permitting emergency services to be located and called with just an
> Internet connection". In other words, anything that happens once the =
call
> is sent to a VSP can be out of scope for ECRIT. I figure that's =
probably
> contentious but I think it's a more pure position - given there are
> already interim architectures that utilize VSPs.
>=20
> This supports jurisdictions that aren't ECRIT-capable - i.e. the LIS =
won't
> provide a PSAP URI or there is no LoST service or mapping for that
> location.
>=20
> It supports devices that aren't ECRIT-capable - i.e. they only know =
how to
> ask for location and initiate calls through the VSP.
>=20
> In my *opinion* the VSP should not be involved unless there is a =
reason
> the call can't be made directly to the PSAP. I don't accept the
> "authenticated" argument (if that's what it's about). You can't =
guarantee
> somebody has a VSP or, indeed, that the VSP's authentication means
> anything to the PSAP. If authentication is important at all, it's only
> going to be the authentication that occurs at the access. Signed =
location,
> I believe, is actually more important than access authentication in =
any
> case. It would bring ECRIT up to par with emergency calls made from =
public
> pay phones.
>=20
> My suggestion is that we pool resources to make an open-source =
reference
> implementation of an ECRIT emergency client that embodies the above
> procedure. Brian says below that he doesn't want devices to implement =
two
> mechanisms. I agree it's not ideal in the long term but it's =
impossible
> not to recognise this situation in the interim. A reference client
> implementation would mitigate this issue.
>=20
> Bearing in mind that a given device may have no VSP client or multiple =
VSP
> clients, I believe it would be preferable to have a relatively =
independent
> and standard emergency client implementation that independent =
open-source
> and commercial VoIP client implementers could integrate.
>=20
> Cheers,
> Martin
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, 12 December 2007 8:21 AM
> To: 'Liess, Laura'; hardie@qualcomm.com; Winterbottom, James;
> bs7652@att.com; Dawson, Martin
> Cc: ecrit@ietf.org
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Yeah, my problem with this is that every client has to implement two
> mechanisms.  They need to implement the LCP then dereference then LoST
> lookup AND they have to implement the HELD+LoST mechanism.
>=20
> I think this mechanism requires the reverse LoST lookup for VSPs, so =
more
> work for LoST servers.  I think James wants to ignore that problem
> (something about letting VSPs charge for emergency calls and working =
it
> out
> later).
>=20
> BTW, the HELD return would have to supply ALL of the service URNs,
> dialstrings, and boundaries that the LoST server knows about.  I'm not
> quite
> sure how the HELD server figures that out.  If there are commercial
> services
> using LoST, all of them would have to be returned.  I think the VSP =
wants
> to
> get into the "Location Based Routing" act (they do route calls after =
all,
> and ISPs don't).  I'm not sure how it would do so with this proposal.
>=20
> If the device is mobile, what happens?  The way we specified it so =
far,
> the
> endpoint would subscribe to a location update service and get location
> updates.  It would have the service boundary from LoST, and it would
> requery
> if it moved beyond the service boundary.  That works, and makes sense =
to
> me.
> I'm not sure what James proposes.
>=20
> If we're going to go beyond the basic location hiding idea, using what =
I
> proposed, which takes no standards changes and puts the burden on the =
LIS
> who is hiding location, then I think Richard's idea of allowing LoST =
to
> dereference is a better one.  I don't like that idea; we've talked =
about
> why
> it's not a great idea in the past, but it's better than James'.
>=20
> Brian
>=20
> > -----Original Message-----
> > From: Liess, Laura [mailto:Laura.Liess@t-systems.com]
> > Sent: Tuesday, December 11, 2007 3:58 PM
> > To: hardie@qualcomm.com; James.Winterbottom@andrew.com; =
bs7652@att.com;
> > br@brianrosen.net; Martin.Dawson@andrew.com
> > Cc: ecrit@ietf.org
> > Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
> >
> >
> > I see two advantages with James URI proposal:
> >
> > 1) It's simple. People (also product managers) understand it within =
2
> > minutes and like it exactly for this reason. The chance to get it
> > implemented soon is probably quite high.
> >
> > 2) The ISP provider is responsible for most EC functionality. The =
VSP is
> > just "transport". (Marc pointed out this aspect to me last week.)
> Probably
> > the regulators would like this because they can control the ISPs =
better
> > than the VSPs.
> > The chance for this solution to work, at lest at the beginning, is
> > probably higher than if 3 different providers (the ISP, the VSP and =
the
> > LOST provider), with eventually conflicting economical interests, =
have
> to
> > cooperate to provide the EC functionality.
> >
> > What if we have both options, coarse location and ESRP/PSAP URI? =
Does
> this
> > mean too high implementation effort for clients?
> >
> > Laura
> >
> > -----Urspr=FCngliche Nachricht-----
> > Von: Ted Hardie [mailto:hardie@qualcomm.com]
> > Gesendet: Montag, 10. Dezember 2007 22:38
> > An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, =
Martin;
> > Henning Schulzrinne
> > Cc: ecrit@ietf.org; Liess, Laura
> > Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
> > >If the device is simply given a PSAP URI, a service URN, and a =
location
> > >URI, what more does it need?
> >
> > As several people have pointed out, it needs/could use the ability =
to
> > sanity
> > check the location.  You've argued it doesn't need that as much as
> > the operators need to be paid for location infrastructure deployed,
> > which set up the whole apples to oranges discussion that has been
> > going so far.
> >
> > Past that, you're introducing a mechanism that combines two services
> > (receiving a location and associating that location with a psap =
URI).
> If
> > you gave
> > that data to a device which has a different LoST server configured, =
what
> > do you expect to happen?  Is it going to pass that location URI to =
its
> > own LoST server to confirm it gets the same PSAP URI?  The current
> > system allows a user/device to request service boundaries and to
> > make reasonable choices about when to refresh URI mappings.  How
> > are you replicating that functionality?  The service boundaries are,
> > after all, pretty much at the level of Brian's proposal.
> >
> > > > For non-emergency cases, you are dealing instead with the
> > >> case where you have a concern that selling someone location
> > >> for purpose X gets them location for purpose Y.  That's both
> > >> a different problem and it falls into an area where there are
> > >> enough other problems that it is, honestly, probably the least
> > >> of your worries.  It's also way out of the charter of this group.
> > >>
> > >
> > >I would argue that location hiding is not in the charter of this WG =
at
> > >all. How to route to a PSAP is the current charter, so if the =
end-point
> > >is given all it needs to route to the PSAP then we are done aren't =
we?
> > >
> >
> > I agree that location hiding is not in the charter of this working
> group.
> > You've been among those saying it had to be considered.  What you're
> > proposing goes in a different design direction to the one the
> > working group has had so far and it goes against some base =
principles
> > of location in GeoPRIV contexts as well (see:  the user controls =
access
> to
> > his/her location)
> >
> > If what you were providing were as robust as the other methods being
> > offered we might be done, despite the design difference.  But there =
is
> > no consensus that this is the case.  At least Henning and I feel it =
is
> > more
> > fragile.  I believe there are others as well.
> >
> > >Umm, how is providing the end point with where it needs to go more
> > >fragile than giving it a bodgey location?
> > >
> >
> > It can check the location it is provided.  You can be working off a
> bodgey
> > location, and it would never know.
> >
> > Really, try the cocoa.  It's quite nice.
> > 				Ted
> >
> >
> >
> > >
> > >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
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 20:47:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2GhN-0002FG-EC; Tue, 11 Dec 2007 20:47:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2GhM-00026R-0w
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:47:44 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2GhK-0000kj-KB
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:47:44 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_19_58_47
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, 11 Dec 2007 19:58:47 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 19:47:41 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 19:47:39 -0600
Message-ID: 
In-Reply-To: <007b01c83c5f$4feab280$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiAABk7wYAAC4V0AAABtAtA=
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> 
	<	p0 6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

	<007b01c83c5f$4feab280$640fa8c0@cis.neustar.com>
From: "Dawson, Martin" 
To: "Brian Rosen" ,
	"Liess, Laura" , ,
	"Winterbottom, James" , 
X-OriginalArrivalTime: 12 Dec 2007 01:47:41.0862 (UTC)
	FILETIME=[FBC5A460:01C83C60]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I'm going to assume you mean "VoIP provider" by carrier.=0D=0A=0D=0AYet we =
are defining a system that allows emergency calls to be made without them. =
We can't have our cake and eat it too. The guarantee of this sort of relati=
onship with a "voice carrier" was thrown out the window at the outset.=0D=0A=0D=
=0AIt's not the same as the PSTN days. The voice service provider, by defin=
ition, was part of the local jurisdiction. It simply doesn't apply for VoIP=
=2E The value of this "carrier" proposition has been diluted out of existen=
ce.=0D=0A=0D=0AIn addition, there's a new "carrier" - the access provider. =
Unlike VSPs, this particular carrier does maintain the same characteristic =
of being part of the local jurisdiction by definition. It would be more fru=
itful to concentrate on getting "authentication" information from them. Sim=
ilarly, I think the callback issue could be more robustly addressed by focu=
ssing on the transient device-PSAP relationship than the very brittle assum=
ptions that are made about VSPs. Has any creativity been applied to this at=
 all=3F I don't believe it does need a proxy in the access network.=0D=0A=0D=
=0AI've asked about these basics a number of times and generally have not b=
een answered.=0D=0A=0D=0AThe incredible number of complications that have a=
risen out of VSP use cases has certainly been enough for me to conclude tha=
t a serious rethink is required.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A=0D=
=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brian=
rosen.net]=20=0D=0ASent: Wednesday, 12 December 2007 12:36 PM=0D=0ATo: Daws=
on, Martin; 'Liess, Laura'; hardie@qualcomm.com; Winterbottom, James; bs765=
2@att.com=0D=0ACc: ecrit@ietf.org=0D=0ASubject: RE: AW: [Ecrit] Location Hi=
ding -- State of the Art=0D=0A=0D=0AAlthough we need to permit emergency ca=
lls that don't come from a carrier,=0D=0Awe really don't want to encourage =
them.  Carriers provide quite a few things=0D=0Athat PSAPs want, not the le=
ast of which is someone to call for help when=0D=0Athings go wrong.  Consid=
er, for example, call-backs.  Given NATs, you can't=0D=0Acall a bare device=
 back; you can't get a signaling message to it.  You need=0D=0Aan incoming =
proxy that is reachable.  Further, many devices won't accept=0D=0Acalls fro=
m arbitrary callers; calls come from their incoming proxy.=0D=0AYou also do=
n't get P-A-I or Identity.  You don't get additional information=0D=0Aabout=
 the call (subscriber name and address for example).  You don't get=0D=0Amo=
st forms of default routing.  So, please, let's not bypass carriers for=0D=0A=
emergency calls.=0D=0A=0D=0AWe've been around the notion that access networ=
ks provide emergency proxies.=0D=0AThat doesn't work either.  Similar probl=
ems, plus the problem that while a=0D=0APSAP can restrict calls to be SIP b=
ased (and maybe one or two others), lots=0D=0Aof services actually use prop=
rietary protocols, or extensions, between the=0D=0Adevice and the service p=
rovider.  The access network can't deal with that.=0D=0A=0D=0AI don't think=
 it helps to try to redefine the basics here.=0D=0A=0D=0ABrian=0D=0A=0D=0A=0D=
=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson, Martin [mailto:M=
artin.Dawson@andrew.com]=0D=0A> Sent: Tuesday, December 11, 2007 8:03 PM=0D=
=0A> To: Brian Rosen; Liess, Laura; hardie@qualcomm.com; Winterbottom, Jame=
s;=0D=0A> bs7652@att.com=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: AW: =
[Ecrit] Location Hiding -- State of the Art=0D=0A>=20=0D=0A> I like Leisa's=
 suggestion and she just beat me to the proposal. My=0D=0A> question as to =
why it's a good idea to involve VSPs at all still hasn't=0D=0A> really been=
 answered. My *opinion* is that the VSP should only be involved=0D=0A> if t=
he calling device can't call directly to the PSAP. This would lead to=0D=0A=
> the following logic for a device (assuming the LIS response would contain=0D=
=0A> any one or more of coarse location, location-URI, PSAP-URI):=0D=0A> =0D=
=0A> 1. Request location=0D=0A> 2. PSAP URI provided with loc-URI and devic=
e is ECRIT-capable=3F=0D=0A> =092 a. Route call to PSAP with Loc-URI and pr=
eferred callback details=0D=0A> =092.b. End=0D=0A> 3. PSAP URI not provided=
 and device is ECRIT-capable=3F=0D=0A> =093.a. Do LoST procedure to obtain =
PSAP URI using coarse location=0D=0A> =093.b. Successful LoST lookup=3F=0D=0A=
> =09=093.b.i Route call to PSAP with preferred callback details=0D=0A> =09=
=093.b.ii End=0D=0A> 4. Either device is not ECRIT-capable or the local jur=
isdiction or access=0D=0A> network are not ECRIT-capable (e.g. No LoST serv=
ice or no successful=0D=0A> lookup)=0D=0A> 5. Send coarse location and loca=
tion reference to VSP=0D=0A> 4. VSP invokes proxy emergency support using i=
2 or other solution=0D=0A> 5. End=0D=0A>=20=0D=0A> The definition of "ECRIT=
-capable" in the above is my own - and it means=0D=0A> "permitting emergenc=
y services to be located and called with just an=0D=0A> Internet connection=
". In other words, anything that happens once the call=0D=0A> is sent to a =
VSP can be out of scope for ECRIT. I figure that's probably=0D=0A> contenti=
ous but I think it's a more pure position - given there are=0D=0A> already =
interim architectures that utilize VSPs.=0D=0A>=20=0D=0A> This supports jur=
isdictions that aren't ECRIT-capable - i.e. the LIS won't=0D=0A> provide a =
PSAP URI or there is no LoST service or mapping for that=0D=0A> location.=0D=
=0A>=20=0D=0A> It supports devices that aren't ECRIT-capable - i.e. they on=
ly know how to=0D=0A> ask for location and initiate calls through the VSP.=0D=
=0A>=20=0D=0A> In my *opinion* the VSP should not be involved unless there =
is a reason=0D=0A> the call can't be made directly to the PSAP. I don't acc=
ept the=0D=0A> "authenticated" argument (if that's what it's about). You ca=
n't guarantee=0D=0A> somebody has a VSP or, indeed, that the VSP's authenti=
cation means=0D=0A> anything to the PSAP. If authentication is important at=
 all, it's only=0D=0A> going to be the authentication that occurs at the ac=
cess. Signed location,=0D=0A> I believe, is actually more important than ac=
cess authentication in any=0D=0A> case. It would bring ECRIT up to par with=
 emergency calls made from public=0D=0A> pay phones.=0D=0A>=20=0D=0A> My su=
ggestion is that we pool resources to make an open-source reference=0D=0A> =
implementation of an ECRIT emergency client that embodies the above=0D=0A> =
procedure. Brian says below that he doesn't want devices to implement two=0D=
=0A> mechanisms. I agree it's not ideal in the long term but it's impossibl=
e=0D=0A> not to recognise this situation in the interim. A reference client=0D=
=0A> implementation would mitigate this issue.=0D=0A>=20=0D=0A> Bearing in =
mind that a given device may have no VSP client or multiple VSP=0D=0A> clie=
nts, I believe it would be preferable to have a relatively independent=0D=0A=
> and standard emergency client implementation that independent open-source=0D=
=0A> and commercial VoIP client implementers could integrate.=0D=0A>=20=0D=0A=
> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> =
From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Wednesday, 12 Dec=
ember 2007 8:21 AM=0D=0A> To: 'Liess, Laura'; hardie@qualcomm.com; Winterbo=
ttom, James;=0D=0A> bs7652@att.com; Dawson, Martin=0D=0A> Cc: ecrit@ietf.or=
g=0D=0A> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A=
>=20=0D=0A> Yeah, my problem with this is that every client has to implemen=
t two=0D=0A> mechanisms.  They need to implement the LCP then dereference t=
hen LoST=0D=0A> lookup AND they have to implement the HELD+LoST mechanism.=0D=
=0A>=20=0D=0A> I think this mechanism requires the reverse LoST lookup for =
VSPs, so more=0D=0A> work for LoST servers.  I think James wants to ignore =
that problem=0D=0A> (something about letting VSPs charge for emergency call=
s and working it=0D=0A> out=0D=0A> later).=0D=0A>=20=0D=0A> BTW, the HELD r=
eturn would have to supply ALL of the service URNs,=0D=0A> dialstrings, and=
 boundaries that the LoST server knows about.  I'm not=0D=0A> quite=0D=0A> =
sure how the HELD server figures that out.  If there are commercial=0D=0A> =
services=0D=0A> using LoST, all of them would have to be returned.  I think=
 the VSP wants=0D=0A> to=0D=0A> get into the "Location Based Routing" act (=
they do route calls after all,=0D=0A> and ISPs don't).  I'm not sure how it=
 would do so with this proposal.=0D=0A>=20=0D=0A> If the device is mobile, =
what happens=3F  The way we specified it so far,=0D=0A> the=0D=0A> endpoint=
 would subscribe to a location update service and get location=0D=0A> updat=
es.  It would have the service boundary from LoST, and it would=0D=0A> requ=
ery=0D=0A> if it moved beyond the service boundary.  That works, and makes =
sense to=0D=0A> me.=0D=0A> I'm not sure what James proposes.=0D=0A>=20=0D=0A=
> If we're going to go beyond the basic location hiding idea, using what I=0D=
=0A> proposed, which takes no standards changes and puts the burden on the =
LIS=0D=0A> who is hiding location, then I think Richard's idea of allowing =
LoST to=0D=0A> dereference is a better one.  I don't like that idea; we've =
talked about=0D=0A> why=0D=0A> it's not a great idea in the past, but it's =
better than James'.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original=
 Message-----=0D=0A> > From: Liess, Laura [mailto:Laura.Liess@t-systems.com=
]=0D=0A> > Sent: Tuesday, December 11, 2007 3:58 PM=0D=0A> > To: hardie@qua=
lcomm.com; James.Winterbottom@andrew.com; bs7652@att.com;=0D=0A> > br@brian=
rosen.net; Martin.Dawson@andrew.com=0D=0A> > Cc: ecrit@ietf.org=0D=0A> > Su=
bject: AW: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> >=0D=0A> =
>=0D=0A> > I see two advantages with James URI proposal:=0D=0A> >=0D=0A> > =
1) It's simple. People (also product managers) understand it within 2=0D=0A=
> > minutes and like it exactly for this reason. The chance to get it=0D=0A=
> > implemented soon is probably quite high.=0D=0A> >=0D=0A> > 2) The ISP p=
rovider is responsible for most EC functionality. The VSP is=0D=0A> > just =
"transport". (Marc pointed out this aspect to me last week.)=0D=0A> Probabl=
y=0D=0A> > the regulators would like this because they can control the ISPs=
 better=0D=0A> > than the VSPs.=0D=0A> > The chance for this solution to wo=
rk, at lest at the beginning, is=0D=0A> > probably higher than if 3 differe=
nt providers (the ISP, the VSP and the=0D=0A> > LOST provider), with eventu=
ally conflicting economical interests, have=0D=0A> to=0D=0A> > cooperate to=
 provide the EC functionality.=0D=0A> >=0D=0A> > What if we have both optio=
ns, coarse location and ESRP/PSAP URI=3F Does=0D=0A> this=0D=0A> > mean too=
 high implementation effort for clients=3F=0D=0A> >=0D=0A> > Laura=0D=0A> >=0D=
=0A> > -----Urspr=FCngliche Nachricht-----=0D=0A> > Von: Ted Hardie [mailto=
:hardie@qualcomm.com]=0D=0A> > Gesendet: Montag, 10. Dezember 2007 22:38=0D=
=0A> > An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin=
;=0D=0A> > Henning Schulzrinne=0D=0A> > Cc: ecrit@ietf.org; Liess, Laura=0D=
=0A> > Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> =
>=0D=0A> > At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:=0D=0A> > >=
If the device is simply given a PSAP URI, a service URN, and a location=0D=0A=
> > >URI, what more does it need=3F=0D=0A> >=0D=0A> > As several people hav=
e pointed out, it needs/could use the ability to=0D=0A> > sanity=0D=0A> > c=
heck the location.  You've argued it doesn't need that as much as=0D=0A> > =
the operators need to be paid for location infrastructure deployed,=0D=0A> =
> which set up the whole apples to oranges discussion that has been=0D=0A> =
> going so far.=0D=0A> >=0D=0A> > Past that, you're introducing a mechanism=
 that combines two services=0D=0A> > (receiving a location and associating =
that location with a psap URI).=0D=0A> If=0D=0A> > you gave=0D=0A> > that d=
ata to a device which has a different LoST server configured, what=0D=0A> >=
 do you expect to happen=3F  Is it going to pass that location URI to its=0D=
=0A> > own LoST server to confirm it gets the same PSAP URI=3F  The current=0D=
=0A> > system allows a user/device to request service boundaries and to=0D=0A=
> > make reasonable choices about when to refresh URI mappings.  How=0D=0A>=
 > are you replicating that functionality=3F  The service boundaries are,=0D=
=0A> > after all, pretty much at the level of Brian's proposal.=0D=0A> >=0D=
=0A> > > > For non-emergency cases, you are dealing instead with the=0D=0A>=
 > >> case where you have a concern that selling someone location=0D=0A> > =
>> for purpose X gets them location for purpose Y.  That's both=0D=0A> > >>=
 a different problem and it falls into an area where there are=0D=0A> > >> =
enough other problems that it is, honestly, probably the least=0D=0A> > >> =
of your worries.  It's also way out of the charter of this group.=0D=0A> > =
>>=0D=0A> > >=0D=0A> > >I would argue that location hiding is not in the ch=
arter of this WG at=0D=0A> > >all. How to route to a PSAP is the current ch=
arter, so if the end-point=0D=0A> > >is given all it needs to route to the =
PSAP then we are done aren't we=3F=0D=0A> > >=0D=0A> >=0D=0A> > I agree tha=
t location hiding is not in the charter of this working=0D=0A> group.=0D=0A=
> > You've been among those saying it had to be considered.  What you're=0D=
=0A> > proposing goes in a different design direction to the one the=0D=0A>=
 > working group has had so far and it goes against some base principles=0D=
=0A> > of location in GeoPRIV contexts as well (see:  the user controls acc=
ess=0D=0A> to=0D=0A> > his/her location)=0D=0A> >=0D=0A> > If what you were=
 providing were as robust as the other methods being=0D=0A> > offered we mi=
ght be done, despite the design difference.  But there is=0D=0A> > no conse=
nsus that this is the case.  At least Henning and I feel it is=0D=0A> > mor=
e=0D=0A> > fragile.  I believe there are others as well.=0D=0A> >=0D=0A> > =
>Umm, how is providing the end point with where it needs to go more=0D=0A> =
> >fragile than giving it a bodgey location=3F=0D=0A> > >=0D=0A> >=0D=0A> >=
 It can check the location it is provided.  You can be working off a=0D=0A>=
 bodgey=0D=0A> > location, and it would never know.=0D=0A> >=0D=0A> > Reall=
y, try the cocoa.  It's quite nice.=0D=0A> > =09=09=09=09Ted=0D=0A> >=0D=0A=
> >=0D=0A> >=0D=0A> > >=0D=0A> > >Cheers=0D=0A> > >James=0D=0A> > >--------=
---------------------------------------------------------------=0D=0A> --=0D=
=0A> > -----------------------=0D=0A> > >This message is for the designated=
 recipient only and may=0D=0A> > >contain privileged, proprietary, or other=
wise private information.=0D=0A> > >If you have received it in error, pleas=
e notify the sender=0D=0A> > >immediately and delete the original.  Any una=
uthorized use of=0D=0A> > >this email is prohibited.=0D=0A> > >------------=
-----------------------------------------------------------=0D=0A> --=0D=0A=
> > -----------------------=0D=0A> > >[mf2]=0D=0A> > >=0D=0A>=20=0D=0A>=20=0D=
=0A> ----------------------------------------------------------------------=
----=0D=0A> ----------------------=0D=0A> This message is for the designate=
d recipient only and may=0D=0A> contain privileged, proprietary, or otherwi=
se private information.=0D=0A> If you have received it in error, please not=
ify the sender=0D=0A> immediately and delete the original.  Any unauthorize=
d use of=0D=0A> this email is prohibited.=0D=0A> --------------------------=
------------------------------------------------=0D=0A> -------------------=
---=0D=0A> [mf2]=0D=0A=0D=0A=0D=0A-----------------------------------------=
-------------------------------------------------------=0D=0AThis message i=
s for the designated recipient only and may=0D=0Acontain privileged, propri=
etary, or otherwise private information. =20=0D=0AIf you have received it i=
n error, please notify the sender=0D=0Aimmediately and delete the original.=
  Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------=
---------------------------------------------------------------------------=
--------=0D=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 20:55:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Gp8-00008j-Sn; Tue, 11 Dec 2007 20:55:46 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Gp8-00008Y-2j
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:55:46 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Gp6-00085b-GZ
	for ecrit@ietf.org; Tue, 11 Dec 2007 20:55:45 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2Goz-0000HN-PU; Tue, 11 Dec 2007 19:55:38 -0600
From: "Brian Rosen" 
To: "'Dawson, Martin'" ,
	"'Liess, Laura'" , ,
	"'Winterbottom, James'" , 
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> <	p0
	6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

	<007b01c83c5f$4feab280$640fa8c0@cis.neustar.com>

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 20:55:39 -0500
Message-ID: <008c01c83c62$1abee9c0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiAABk7wYAAC4V0AAABtAtAAAH4NgA==
In-Reply-To: 
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I don't agree.  Probably 99.999% of emergency calls will come through =
some
form of carrier, be they VoIP carrier, mobile carrier or legacy wireline
carrier, IM service provider, video service provider, ....
That's what the PSAPs want.  Generally, that's what the regulators want.
It has to be possible to place a call without a carrier.  That is the
reality of the Internet.  However, we can, and should let the major
responsibility for handling emergency calls rest with the service =
provider
who provides session establishment services for the user.  That's the
carrier, and not the access network, which generally is a bit pipe, and
which we have to deal with solely because they are in the best position =
to
supply location.  I have no desire to burden access networks with any =
more
responsibility.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Tuesday, December 11, 2007 8:48 PM
> To: Brian Rosen; Liess, Laura; hardie@qualcomm.com; Winterbottom, =
James;
> bs7652@att.com
> Cc: ecrit@ietf.org
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> I'm going to assume you mean "VoIP provider" by carrier.
>=20
> Yet we are defining a system that allows emergency calls to be made
> without them. We can't have our cake and eat it too. The guarantee of =
this
> sort of relationship with a "voice carrier" was thrown out the window =
at
> the outset.
>=20
> It's not the same as the PSTN days. The voice service provider, by
> definition, was part of the local jurisdiction. It simply doesn't =
apply
> for VoIP. The value of this "carrier" proposition has been diluted out =
of
> existence.
>=20
> In addition, there's a new "carrier" - the access provider. Unlike =
VSPs,
> this particular carrier does maintain the same characteristic of being
> part of the local jurisdiction by definition. It would be more =
fruitful to
> concentrate on getting "authentication" information from them. =
Similarly,
> I think the callback issue could be more robustly addressed by =
focussing
> on the transient device-PSAP relationship than the very brittle
> assumptions that are made about VSPs. Has any creativity been applied =
to
> this at all? I don't believe it does need a proxy in the access =
network.
>=20
> I've asked about these basics a number of times and generally have not
> been answered.
>=20
> The incredible number of complications that have arisen out of VSP use
> cases has certainly been enough for me to conclude that a serious =
rethink
> is required.
>=20
> Cheers,
> Martin
>=20
>=20
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, 12 December 2007 12:36 PM
> To: Dawson, Martin; 'Liess, Laura'; hardie@qualcomm.com; Winterbottom,
> James; bs7652@att.com
> Cc: ecrit@ietf.org
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
>=20
> Although we need to permit emergency calls that don't come from a =
carrier,
> we really don't want to encourage them.  Carriers provide quite a few
> things
> that PSAPs want, not the least of which is someone to call for help =
when
> things go wrong.  Consider, for example, call-backs.  Given NATs, you
> can't
> call a bare device back; you can't get a signaling message to it.  You
> need
> an incoming proxy that is reachable.  Further, many devices won't =
accept
> calls from arbitrary callers; calls come from their incoming proxy.
> You also don't get P-A-I or Identity.  You don't get additional
> information
> about the call (subscriber name and address for example).  You don't =
get
> most forms of default routing.  So, please, let's not bypass carriers =
for
> emergency calls.
>=20
> We've been around the notion that access networks provide emergency
> proxies.
> That doesn't work either.  Similar problems, plus the problem that =
while a
> PSAP can restrict calls to be SIP based (and maybe one or two others),
> lots
> of services actually use proprietary protocols, or extensions, between =
the
> device and the service provider.  The access network can't deal with =
that.
>=20
> I don't think it helps to try to redefine the basics here.
>=20
> Brian
>=20
>=20
>=20
> > -----Original Message-----
> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > Sent: Tuesday, December 11, 2007 8:03 PM
> > To: Brian Rosen; Liess, Laura; hardie@qualcomm.com; Winterbottom, =
James;
> > bs7652@att.com
> > Cc: ecrit@ietf.org
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > I like Leisa's suggestion and she just beat me to the proposal. My
> > question as to why it's a good idea to involve VSPs at all still =
hasn't
> > really been answered. My *opinion* is that the VSP should only be
> involved
> > if the calling device can't call directly to the PSAP. This would =
lead
> to
> > the following logic for a device (assuming the LIS response would
> contain
> > any one or more of coarse location, location-URI, PSAP-URI):
> >
> > 1. Request location
> > 2. PSAP URI provided with loc-URI and device is ECRIT-capable?
> > 	2 a. Route call to PSAP with Loc-URI and preferred callback details
> > 	2.b. End
> > 3. PSAP URI not provided and device is ECRIT-capable?
> > 	3.a. Do LoST procedure to obtain PSAP URI using coarse location
> > 	3.b. Successful LoST lookup?
> > 		3.b.i Route call to PSAP with preferred callback details
> > 		3.b.ii End
> > 4. Either device is not ECRIT-capable or the local jurisdiction or
> access
> > network are not ECRIT-capable (e.g. No LoST service or no successful
> > lookup)
> > 5. Send coarse location and location reference to VSP
> > 4. VSP invokes proxy emergency support using i2 or other solution
> > 5. End
> >
> > The definition of "ECRIT-capable" in the above is my own - and it =
means
> > "permitting emergency services to be located and called with just an
> > Internet connection". In other words, anything that happens once the
> call
> > is sent to a VSP can be out of scope for ECRIT. I figure that's =
probably
> > contentious but I think it's a more pure position - given there are
> > already interim architectures that utilize VSPs.
> >
> > This supports jurisdictions that aren't ECRIT-capable - i.e. the LIS
> won't
> > provide a PSAP URI or there is no LoST service or mapping for that
> > location.
> >
> > It supports devices that aren't ECRIT-capable - i.e. they only know =
how
> to
> > ask for location and initiate calls through the VSP.
> >
> > In my *opinion* the VSP should not be involved unless there is a =
reason
> > the call can't be made directly to the PSAP. I don't accept the
> > "authenticated" argument (if that's what it's about). You can't
> guarantee
> > somebody has a VSP or, indeed, that the VSP's authentication means
> > anything to the PSAP. If authentication is important at all, it's =
only
> > going to be the authentication that occurs at the access. Signed
> location,
> > I believe, is actually more important than access authentication in =
any
> > case. It would bring ECRIT up to par with emergency calls made from
> public
> > pay phones.
> >
> > My suggestion is that we pool resources to make an open-source =
reference
> > implementation of an ECRIT emergency client that embodies the above
> > procedure. Brian says below that he doesn't want devices to =
implement
> two
> > mechanisms. I agree it's not ideal in the long term but it's =
impossible
> > not to recognise this situation in the interim. A reference client
> > implementation would mitigate this issue.
> >
> > Bearing in mind that a given device may have no VSP client or =
multiple
> VSP
> > clients, I believe it would be preferable to have a relatively
> independent
> > and standard emergency client implementation that independent open-
> source
> > and commercial VoIP client implementers could integrate.
> >
> > Cheers,
> > Martin
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Wednesday, 12 December 2007 8:21 AM
> > To: 'Liess, Laura'; hardie@qualcomm.com; Winterbottom, James;
> > bs7652@att.com; Dawson, Martin
> > Cc: ecrit@ietf.org
> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > Yeah, my problem with this is that every client has to implement two
> > mechanisms.  They need to implement the LCP then dereference then =
LoST
> > lookup AND they have to implement the HELD+LoST mechanism.
> >
> > I think this mechanism requires the reverse LoST lookup for VSPs, so
> more
> > work for LoST servers.  I think James wants to ignore that problem
> > (something about letting VSPs charge for emergency calls and working =
it
> > out
> > later).
> >
> > BTW, the HELD return would have to supply ALL of the service URNs,
> > dialstrings, and boundaries that the LoST server knows about.  I'm =
not
> > quite
> > sure how the HELD server figures that out.  If there are commercial
> > services
> > using LoST, all of them would have to be returned.  I think the VSP
> wants
> > to
> > get into the "Location Based Routing" act (they do route calls after
> all,
> > and ISPs don't).  I'm not sure how it would do so with this =
proposal.
> >
> > If the device is mobile, what happens?  The way we specified it so =
far,
> > the
> > endpoint would subscribe to a location update service and get =
location
> > updates.  It would have the service boundary from LoST, and it would
> > requery
> > if it moved beyond the service boundary.  That works, and makes =
sense to
> > me.
> > I'm not sure what James proposes.
> >
> > If we're going to go beyond the basic location hiding idea, using =
what I
> > proposed, which takes no standards changes and puts the burden on =
the
> LIS
> > who is hiding location, then I think Richard's idea of allowing LoST =
to
> > dereference is a better one.  I don't like that idea; we've talked =
about
> > why
> > it's not a great idea in the past, but it's better than James'.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com]
> > > Sent: Tuesday, December 11, 2007 3:58 PM
> > > To: hardie@qualcomm.com; James.Winterbottom@andrew.com;
> bs7652@att.com;
> > > br@brianrosen.net; Martin.Dawson@andrew.com
> > > Cc: ecrit@ietf.org
> > > Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > >
> > > I see two advantages with James URI proposal:
> > >
> > > 1) It's simple. People (also product managers) understand it =
within 2
> > > minutes and like it exactly for this reason. The chance to get it
> > > implemented soon is probably quite high.
> > >
> > > 2) The ISP provider is responsible for most EC functionality. The =
VSP
> is
> > > just "transport". (Marc pointed out this aspect to me last week.)
> > Probably
> > > the regulators would like this because they can control the ISPs
> better
> > > than the VSPs.
> > > The chance for this solution to work, at lest at the beginning, is
> > > probably higher than if 3 different providers (the ISP, the VSP =
and
> the
> > > LOST provider), with eventually conflicting economical interests, =
have
> > to
> > > cooperate to provide the EC functionality.
> > >
> > > What if we have both options, coarse location and ESRP/PSAP URI? =
Does
> > this
> > > mean too high implementation effort for clients?
> > >
> > > Laura
> > >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: Ted Hardie [mailto:hardie@qualcomm.com]
> > > Gesendet: Montag, 10. Dezember 2007 22:38
> > > An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, =
Martin;
> > > Henning Schulzrinne
> > > Cc: ecrit@ietf.org; Liess, Laura
> > > Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art
> > >
> > > At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
> > > >If the device is simply given a PSAP URI, a service URN, and a
> location
> > > >URI, what more does it need?
> > >
> > > As several people have pointed out, it needs/could use the ability =
to
> > > sanity
> > > check the location.  You've argued it doesn't need that as much as
> > > the operators need to be paid for location infrastructure =
deployed,
> > > which set up the whole apples to oranges discussion that has been
> > > going so far.
> > >
> > > Past that, you're introducing a mechanism that combines two =
services
> > > (receiving a location and associating that location with a psap =
URI).
> > If
> > > you gave
> > > that data to a device which has a different LoST server =
configured,
> what
> > > do you expect to happen?  Is it going to pass that location URI to =
its
> > > own LoST server to confirm it gets the same PSAP URI?  The current
> > > system allows a user/device to request service boundaries and to
> > > make reasonable choices about when to refresh URI mappings.  How
> > > are you replicating that functionality?  The service boundaries =
are,
> > > after all, pretty much at the level of Brian's proposal.
> > >
> > > > > For non-emergency cases, you are dealing instead with the
> > > >> case where you have a concern that selling someone location
> > > >> for purpose X gets them location for purpose Y.  That's both
> > > >> a different problem and it falls into an area where there are
> > > >> enough other problems that it is, honestly, probably the least
> > > >> of your worries.  It's also way out of the charter of this =
group.
> > > >>
> > > >
> > > >I would argue that location hiding is not in the charter of this =
WG
> at
> > > >all. How to route to a PSAP is the current charter, so if the =
end-
> point
> > > >is given all it needs to route to the PSAP then we are done =
aren't
> we?
> > > >
> > >
> > > I agree that location hiding is not in the charter of this working
> > group.
> > > You've been among those saying it had to be considered.  What =
you're
> > > proposing goes in a different design direction to the one the
> > > working group has had so far and it goes against some base =
principles
> > > of location in GeoPRIV contexts as well (see:  the user controls
> access
> > to
> > > his/her location)
> > >
> > > If what you were providing were as robust as the other methods =
being
> > > offered we might be done, despite the design difference.  But =
there is
> > > no consensus that this is the case.  At least Henning and I feel =
it is
> > > more
> > > fragile.  I believe there are others as well.
> > >
> > > >Umm, how is providing the end point with where it needs to go =
more
> > > >fragile than giving it a bodgey location?
> > > >
> > >
> > > It can check the location it is provided.  You can be working off =
a
> > bodgey
> > > location, and it would never know.
> > >
> > > Really, try the cocoa.  It's quite nice.
> > > 				Ted
> > >
> > >
> > >
> > > >
> > > >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]
> > > >
> >
> >
> > =
------------------------------------------------------------------------
> --
> > ----------------------
> > 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
>=20
> =
-------------------------------------------------------------------------=
-
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> =
-------------------------------------------------------------------------=
-
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 21:23:47 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2HGE-00005o-KV; Tue, 11 Dec 2007 21:23:46 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2HGD-0008Qn-EX
	for ecrit@ietf.org; Tue, 11 Dec 2007 21:23:45 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2HGB-0000Gz-KV
	for ecrit@ietf.org; Tue, 11 Dec 2007 21:23:45 -0500
X-SEF-Processed: 5_0_0_910__2007_12_11_20_34_46
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, 11 Dec 2007 20:34:46 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 20:23:41 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
Date: Tue, 11 Dec 2007 20:23:38 -0600
Message-ID: 
In-Reply-To: <008c01c83c62$1abee9c0$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Ecrit] Location Hiding -- State of the Art
Thread-Index: Acg7dPSsL6FfIx08S/y5IHLwEmoiMgAufAdwAAKOjiAABk7wYAAC4V0AAABtAtAAAH4NgAAAk82g
References: <4751C54C.4040704@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0691E5D9@crexc4
	1p><069a01c83617$a
	66713e0$0e99f544@cis.neustar.com><47544D20.9070406@gmx.net><06c501c8368b$9
	6348ec0$0e99f544@cis.neustar.com><182C63BFBAF131428EA0C16F7FD2191B03559DB3
	@S4DE8PSAAGM.mitte.t-com.de><45A552C6-135D-4CE4-A252-E0C7134560D7@cs.colum
	bia.edu><7582BC68E4994F4ABF0BD4723975C3FA06ABB47F@crexc41p>
	<03f601c83b3c$dcf242c0$640fa8c0@cis.neustar.com>

	<040b01c83b44$77094410$640fa8c0@cis.neustar.com>

	<040c01c83b46$d86e5cc0$640fa8c0@cis.neustar.com>

	<041b01c83b49$6cfe84d0$640fa8c0@cis.neustar.com>
	<7582BC68E4994F4ABF0BD4723975C3FA06ABB690@crex! ! c41p> 
	<	p0 6240605 c3 8330f2cd7e@[76.126.60.89]>

	<182C63BFBAF131428EA0C16F7FD2191B0355ABCB@S4DE8PSAAGM.mitte.t-com.de>
	<066801c83c3b$bd820150$640fa8c0@cis.neustar.com>

	<007b01c83c5f$4feab280$640fa8c0@cis.neustar.com>

	<008c01c83c62$1abee9c0$640fa8c0@cis.neustar.com>
From: "Dawson, Martin" 
To: "Brian Rosen" ,
	"Liess, Laura" , ,
	"Winterbottom, James" , 
X-OriginalArrivalTime: 12 Dec 2007 02:23:41.0076 (UTC)
	FILETIME=[02C38D40:01C83C66]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

That's tautological - that proportion of calls will only come through VSPs =
if that's they way you define the architecture. In the long term it could b=
e possible that zero percent of calls come through VSPs.=0D=0A=0D=0AAll of =
those other systems already have infrastructure, architecture, and protocol=
s for delivering emergency calls. Trying to reinvent it all in the IETF as =
opposed to just focussing on the long term goal of end-to-end Internet emer=
gency telephony is only serving to confuse all parties - in my view. It fee=
ls like the concepts of having an IP-enabled call centre and Internet deliv=
ered emergency calls have been unnecessarily conflated.=0D=0A=0D=0AI simply=
 don't accept the statement "it's what PSAPs want" at face value. My VoIP p=
rovider is an Australian company called MyNetFone. How does it add any valu=
e for them, me, or the PSAP for them to be involved in an emergency call I =
initiate from a WiFi hotspot in Dallas=3F My cellular provider is an Austra=
lian operator called Optus. They certainly aren't involved if I make an eme=
rgency call from a cellular network in Dallas - all they see is the roaming=
 partner who provides access in that area. It's easy to put words into the =
mouths of PSAPs; you know that perceptions are much more complicated than t=
hat.=0D=0A=0D=0AAs I say, I don't think there's any need to add additional =
burden to the access provider - none that hasn't already been mooted in any=
 case.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=
=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 12=
 December 2007 12:56 PM=0D=0ATo: Dawson, Martin; 'Liess, Laura'; hardie@qua=
lcomm.com; Winterbottom, James; bs7652@att.com=0D=0ACc: ecrit@ietf.org=0D=0A=
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A=0D=0AI d=
on't agree.  Probably 99.999% of emergency calls will come through some=0D=0A=
form of carrier, be they VoIP carrier, mobile carrier or legacy wireline=0D=
=0Acarrier, IM service provider, video service provider, ....=0D=0AThat's w=
hat the PSAPs want.  Generally, that's what the regulators want.=0D=0AIt ha=
s to be possible to place a call without a carrier.  That is the=0D=0Areali=
ty of the Internet.  However, we can, and should let the major=0D=0Arespons=
ibility for handling emergency calls rest with the service provider=0D=0Awh=
o provides session establishment services for the user.  That's the=0D=0Aca=
rrier, and not the access network, which generally is a bit pipe, and=0D=0A=
which we have to deal with solely because they are in the best position to=0D=
=0Asupply location.  I have no desire to burden access networks with any mo=
re=0D=0Aresponsibility.=0D=0A=0D=0ABrian=0D=0A=0D=0A> -----Original Message=
-----=0D=0A> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> =
Sent: Tuesday, December 11, 2007 8:48 PM=0D=0A> To: Brian Rosen; Liess, Lau=
ra; hardie@qualcomm.com; Winterbottom, James;=0D=0A> bs7652@att.com=0D=0A> =
Cc: ecrit@ietf.org=0D=0A> Subject: RE: AW: [Ecrit] Location Hiding -- State=
 of the Art=0D=0A>=20=0D=0A> I'm going to assume you mean "VoIP provider" b=
y carrier.=0D=0A>=20=0D=0A> Yet we are defining a system that allows emerge=
ncy calls to be made=0D=0A> without them. We can't have our cake and eat it=
 too. The guarantee of this=0D=0A> sort of relationship with a "voice carri=
er" was thrown out the window at=0D=0A> the outset.=0D=0A>=20=0D=0A> It's n=
ot the same as the PSTN days. The voice service provider, by=0D=0A> definit=
ion, was part of the local jurisdiction. It simply doesn't apply=0D=0A> for=
 VoIP. The value of this "carrier" proposition has been diluted out of=0D=0A=
> existence.=0D=0A>=20=0D=0A> In addition, there's a new "carrier" - the ac=
cess provider. Unlike VSPs,=0D=0A> this particular carrier does maintain th=
e same characteristic of being=0D=0A> part of the local jurisdiction by def=
inition. It would be more fruitful to=0D=0A> concentrate on getting "authen=
tication" information from them. Similarly,=0D=0A> I think the callback iss=
ue could be more robustly addressed by focussing=0D=0A> on the transient de=
vice-PSAP relationship than the very brittle=0D=0A> assumptions that are ma=
de about VSPs. Has any creativity been applied to=0D=0A> this at all=3F I d=
on't believe it does need a proxy in the access network.=0D=0A>=20=0D=0A> I=
've asked about these basics a number of times and generally have not=0D=0A=
> been answered.=0D=0A>=20=0D=0A> The incredible number of complications th=
at have arisen out of VSP use=0D=0A> cases has certainly been enough for me=
 to conclude that a serious rethink=0D=0A> is required.=0D=0A>=20=0D=0A> Ch=
eers,=0D=0A> Martin=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> -----Original Mess=
age-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: W=
ednesday, 12 December 2007 12:36 PM=0D=0A> To: Dawson, Martin; 'Liess, Laur=
a'; hardie@qualcomm.com; Winterbottom,=0D=0A> James; bs7652@att.com=0D=0A> =
Cc: ecrit@ietf.org=0D=0A> Subject: RE: AW: [Ecrit] Location Hiding -- State=
 of the Art=0D=0A>=20=0D=0A> Although we need to permit emergency calls tha=
t don't come from a carrier,=0D=0A> we really don't want to encourage them.=
  Carriers provide quite a few=0D=0A> things=0D=0A> that PSAPs want, not th=
e least of which is someone to call for help when=0D=0A> things go wrong.  =
Consider, for example, call-backs.  Given NATs, you=0D=0A> can't=0D=0A> cal=
l a bare device back; you can't get a signaling message to it.  You=0D=0A> =
need=0D=0A> an incoming proxy that is reachable.  Further, many devices won=
't accept=0D=0A> calls from arbitrary callers; calls come from their incomi=
ng proxy.=0D=0A> You also don't get P-A-I or Identity.  You don't get addit=
ional=0D=0A> information=0D=0A> about the call (subscriber name and address=
 for example).  You don't get=0D=0A> most forms of default routing.  So, pl=
ease, let's not bypass carriers for=0D=0A> emergency calls.=0D=0A>=20=0D=0A=
> We've been around the notion that access networks provide emergency=0D=0A=
> proxies.=0D=0A> That doesn't work either.  Similar problems, plus the pro=
blem that while a=0D=0A> PSAP can restrict calls to be SIP based (and maybe=
 one or two others),=0D=0A> lots=0D=0A> of services actually use proprietar=
y protocols, or extensions, between the=0D=0A> device and the service provi=
der.  The access network can't deal with that.=0D=0A>=20=0D=0A> I don't thi=
nk it helps to try to redefine the basics here.=0D=0A>=20=0D=0A> Brian=0D=0A=
>=20=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From:=
 Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent: Tuesday, D=
ecember 11, 2007 8:03 PM=0D=0A> > To: Brian Rosen; Liess, Laura; hardie@qua=
lcomm.com; Winterbottom, James;=0D=0A> > bs7652@att.com=0D=0A> > Cc: ecrit@=
ietf.org=0D=0A> > Subject: RE: AW: [Ecrit] Location Hiding -- State of the =
Art=0D=0A> >=0D=0A> > I like Leisa's suggestion and she just beat me to the=
 proposal. My=0D=0A> > question as to why it's a good idea to involve VSPs =
at all still hasn't=0D=0A> > really been answered. My *opinion* is that the=
 VSP should only be=0D=0A> involved=0D=0A> > if the calling device can't ca=
ll directly to the PSAP. This would lead=0D=0A> to=0D=0A> > the following l=
ogic for a device (assuming the LIS response would=0D=0A> contain=0D=0A> > =
any one or more of coarse location, location-URI, PSAP-URI):=0D=0A> >=0D=0A=
> > 1. Request location=0D=0A> > 2. PSAP URI provided with loc-URI and devi=
ce is ECRIT-capable=3F=0D=0A> > =092 a. Route call to PSAP with Loc-URI and=
 preferred callback details=0D=0A> > =092.b. End=0D=0A> > 3. PSAP URI not p=
rovided and device is ECRIT-capable=3F=0D=0A> > =093.a. Do LoST procedure t=
o obtain PSAP URI using coarse location=0D=0A> > =093.b. Successful LoST lo=
okup=3F=0D=0A> > =09=093.b.i Route call to PSAP with preferred callback det=
ails=0D=0A> > =09=093.b.ii End=0D=0A> > 4. Either device is not ECRIT-capab=
le or the local jurisdiction or=0D=0A> access=0D=0A> > network are not ECRI=
T-capable (e.g. No LoST service or no successful=0D=0A> > lookup)=0D=0A> > =
5. Send coarse location and location reference to VSP=0D=0A> > 4. VSP invok=
es proxy emergency support using i2 or other solution=0D=0A> > 5. End=0D=0A=
> >=0D=0A> > The definition of "ECRIT-capable" in the above is my own - and=
 it means=0D=0A> > "permitting emergency services to be located and called =
with just an=0D=0A> > Internet connection". In other words, anything that h=
appens once the=0D=0A> call=0D=0A> > is sent to a VSP can be out of scope f=
or ECRIT. I figure that's probably=0D=0A> > contentious but I think it's a =
more pure position - given there are=0D=0A> > already interim architectures=
 that utilize VSPs.=0D=0A> >=0D=0A> > This supports jurisdictions that aren=
't ECRIT-capable - i.e. the LIS=0D=0A> won't=0D=0A> > provide a PSAP URI or=
 there is no LoST service or mapping for that=0D=0A> > location.=0D=0A> >=0D=
=0A> > It supports devices that aren't ECRIT-capable - i.e. they only know =
how=0D=0A> to=0D=0A> > ask for location and initiate calls through the VSP.=0D=
=0A> >=0D=0A> > In my *opinion* the VSP should not be involved unless there=
 is a reason=0D=0A> > the call can't be made directly to the PSAP. I don't =
accept the=0D=0A> > "authenticated" argument (if that's what it's about). Y=
ou can't=0D=0A> guarantee=0D=0A> > somebody has a VSP or, indeed, that the =
VSP's authentication means=0D=0A> > anything to the PSAP. If authentication=
 is important at all, it's only=0D=0A> > going to be the authentication tha=
t occurs at the access. Signed=0D=0A> location,=0D=0A> > I believe, is actu=
ally more important than access authentication in any=0D=0A> > case. It wou=
ld bring ECRIT up to par with emergency calls made from=0D=0A> public=0D=0A=
> > pay phones.=0D=0A> >=0D=0A> > My suggestion is that we pool resources t=
o make an open-source reference=0D=0A> > implementation of an ECRIT emergen=
cy client that embodies the above=0D=0A> > procedure. Brian says below that=
 he doesn't want devices to implement=0D=0A> two=0D=0A> > mechanisms. I agr=
ee it's not ideal in the long term but it's impossible=0D=0A> > not to reco=
gnise this situation in the interim. A reference client=0D=0A> > implementa=
tion would mitigate this issue.=0D=0A> >=0D=0A> > Bearing in mind that a gi=
ven device may have no VSP client or multiple=0D=0A> VSP=0D=0A> > clients, =
I believe it would be preferable to have a relatively=0D=0A> independent=0D=
=0A> > and standard emergency client implementation that independent open-=0D=
=0A> source=0D=0A> > and commercial VoIP client implementers could integrat=
e.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > -----Origina=
l Message-----=0D=0A> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A>=
 > Sent: Wednesday, 12 December 2007 8:21 AM=0D=0A> > To: 'Liess, Laura'; h=
ardie@qualcomm.com; Winterbottom, James;=0D=0A> > bs7652@att.com; Dawson, M=
artin=0D=0A> > Cc: ecrit@ietf.org=0D=0A> > Subject: RE: AW: [Ecrit] Locatio=
n Hiding -- State of the Art=0D=0A> >=0D=0A> > Yeah, my problem with this i=
s that every client has to implement two=0D=0A> > mechanisms.  They need to=
 implement the LCP then dereference then LoST=0D=0A> > lookup AND they have=
 to implement the HELD+LoST mechanism.=0D=0A> >=0D=0A> > I think this mecha=
nism requires the reverse LoST lookup for VSPs, so=0D=0A> more=0D=0A> > wor=
k for LoST servers.  I think James wants to ignore that problem=0D=0A> > (s=
omething about letting VSPs charge for emergency calls and working it=0D=0A=
> > out=0D=0A> > later).=0D=0A> >=0D=0A> > BTW, the HELD return would have =
to supply ALL of the service URNs,=0D=0A> > dialstrings, and boundaries tha=
t the LoST server knows about.  I'm not=0D=0A> > quite=0D=0A> > sure how th=
e HELD server figures that out.  If there are commercial=0D=0A> > services=0D=
=0A> > using LoST, all of them would have to be returned.  I think the VSP=0D=
=0A> wants=0D=0A> > to=0D=0A> > get into the "Location Based Routing" act (=
they do route calls after=0D=0A> all,=0D=0A> > and ISPs don't).  I'm not su=
re how it would do so with this proposal.=0D=0A> >=0D=0A> > If the device i=
s mobile, what happens=3F  The way we specified it so far,=0D=0A> > the=0D=0A=
> > endpoint would subscribe to a location update service and get location=0D=
=0A> > updates.  It would have the service boundary from LoST, and it would=0D=
=0A> > requery=0D=0A> > if it moved beyond the service boundary.  That work=
s, and makes sense to=0D=0A> > me.=0D=0A> > I'm not sure what James propose=
s.=0D=0A> >=0D=0A> > If we're going to go beyond the basic location hiding =
idea, using what I=0D=0A> > proposed, which takes no standards changes and =
puts the burden on the=0D=0A> LIS=0D=0A> > who is hiding location, then I t=
hink Richard's idea of allowing LoST to=0D=0A> > dereference is a better on=
e.  I don't like that idea; we've talked about=0D=0A> > why=0D=0A> > it's n=
ot a great idea in the past, but it's better than James'.=0D=0A> >=0D=0A> >=
 Brian=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Lies=
s, Laura [mailto:Laura.Liess@t-systems.com]=0D=0A> > > Sent: Tuesday, Decem=
ber 11, 2007 3:58 PM=0D=0A> > > To: hardie@qualcomm.com; James.Winterbottom=
@andrew.com;=0D=0A> bs7652@att.com;=0D=0A> > > br@brianrosen.net; Martin.Da=
wson@andrew.com=0D=0A> > > Cc: ecrit@ietf.org=0D=0A> > > Subject: AW: AW: [=
Ecrit] Location Hiding -- State of the Art=0D=0A> > >=0D=0A> > >=0D=0A> > >=
 I see two advantages with James URI proposal:=0D=0A> > >=0D=0A> > > 1) It'=
s simple. People (also product managers) understand it within 2=0D=0A> > > =
minutes and like it exactly for this reason. The chance to get it=0D=0A> > =
> implemented soon is probably quite high.=0D=0A> > >=0D=0A> > > 2) The ISP=
 provider is responsible for most EC functionality. The VSP=0D=0A> is=0D=0A=
> > > just "transport". (Marc pointed out this aspect to me last week.)=0D=0A=
> > Probably=0D=0A> > > the regulators would like this because they can con=
trol the ISPs=0D=0A> better=0D=0A> > > than the VSPs.=0D=0A> > > The chance=
 for this solution to work, at lest at the beginning, is=0D=0A> > > probabl=
y higher than if 3 different providers (the ISP, the VSP and=0D=0A> the=0D=0A=
> > > LOST provider), with eventually conflicting economical interests, hav=
e=0D=0A> > to=0D=0A> > > cooperate to provide the EC functionality.=0D=0A> =
> >=0D=0A> > > What if we have both options, coarse location and ESRP/PSAP =
URI=3F Does=0D=0A> > this=0D=0A> > > mean too high implementation effort fo=
r clients=3F=0D=0A> > >=0D=0A> > > Laura=0D=0A> > >=0D=0A> > > -----Urspr=FC=
ngliche Nachricht-----=0D=0A> > > Von: Ted Hardie [mailto:hardie@qualcomm.c=
om]=0D=0A> > > Gesendet: Montag, 10. Dezember 2007 22:38=0D=0A> > > An: Win=
terbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin;=0D=0A> > > H=
enning Schulzrinne=0D=0A> > > Cc: ecrit@ietf.org; Liess, Laura=0D=0A> > > B=
etreff: RE: AW: [Ecrit] Location Hiding -- State of the Art=0D=0A> > >=0D=0A=
> > > At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:=0D=0A> > > >If =
the device is simply given a PSAP URI, a service URN, and a=0D=0A> location=0D=
=0A> > > >URI, what more does it need=3F=0D=0A> > >=0D=0A> > > As several p=
eople have pointed out, it needs/could use the ability to=0D=0A> > > sanity=0D=
=0A> > > check the location.  You've argued it doesn't need that as much as=0D=
=0A> > > the operators need to be paid for location infrastructure deployed=
,=0D=0A> > > which set up the whole apples to oranges discussion that has b=
een=0D=0A> > > going so far.=0D=0A> > >=0D=0A> > > Past that, you're introd=
ucing a mechanism that combines two services=0D=0A> > > (receiving a locati=
on and associating that location with a psap URI).=0D=0A> > If=0D=0A> > > y=
ou gave=0D=0A> > > that data to a device which has a different LoST server =
configured,=0D=0A> what=0D=0A> > > do you expect to happen=3F  Is it going =
to pass that location URI to its=0D=0A> > > own LoST server to confirm it g=
ets the same PSAP URI=3F  The current=0D=0A> > > system allows a user/devic=
e to request service boundaries and to=0D=0A> > > make reasonable choices a=
bout when to refresh URI mappings.  How=0D=0A> > > are you replicating that=
 functionality=3F  The service boundaries are,=0D=0A> > > after all, pretty=
 much at the level of Brian's proposal.=0D=0A> > >=0D=0A> > > > > For non-e=
mergency cases, you are dealing instead with the=0D=0A> > > >> case where y=
ou have a concern that selling someone location=0D=0A> > > >> for purpose X=
 gets them location for purpose Y.  That's both=0D=0A> > > >> a different p=
roblem and it falls into an area where there are=0D=0A> > > >> enough other=
 problems that it is, honestly, probably the least=0D=0A> > > >> of your wo=
rries.  It's also way out of the charter of this group.=0D=0A> > > >>=0D=0A=
> > > >=0D=0A> > > >I would argue that location hiding is not in the charte=
r of this WG=0D=0A> at=0D=0A> > > >all. How to route to a PSAP is the curre=
nt charter, so if the end-=0D=0A> point=0D=0A> > > >is given all it needs t=
o route to the PSAP then we are done aren't=0D=0A> we=3F=0D=0A> > > >=0D=0A=
> > >=0D=0A> > > I agree that location hiding is not in the charter of this=
 working=0D=0A> > group.=0D=0A> > > You've been among those saying it had t=
o be considered.  What you're=0D=0A> > > proposing goes in a different desi=
gn direction to the one the=0D=0A> > > working group has had so far and it =
goes against some base principles=0D=0A> > > of location in GeoPRIV context=
s as well (see:  the user controls=0D=0A> access=0D=0A> > to=0D=0A> > > his=
/her location)=0D=0A> > >=0D=0A> > > If what you were providing were as rob=
ust as the other methods being=0D=0A> > > offered we might be done, despite=
 the design difference.  But there is=0D=0A> > > no consensus that this is =
the case.  At least Henning and I feel it is=0D=0A> > > more=0D=0A> > > fra=
gile.  I believe there are others as well.=0D=0A> > >=0D=0A> > > >Umm, how =
is providing the end point with where it needs to go more=0D=0A> > > >fragi=
le than giving it a bodgey location=3F=0D=0A> > > >=0D=0A> > >=0D=0A> > > I=
t can check the location it is provided.  You can be working off a=0D=0A> >=
 bodgey=0D=0A> > > location, and it would never know.=0D=0A> > >=0D=0A> > >=
 Really, try the cocoa.  It's quite nice.=0D=0A> > > =09=09=09=09Ted=0D=0A>=
 > >=0D=0A> > >=0D=0A> > >=0D=0A> > > >=0D=0A> > > >Cheers=0D=0A> > > >Jame=
s=0D=0A> > > >-------------------------------------------------------------=
--------=0D=0A> --=0D=0A> > --=0D=0A> > > -----------------------=0D=0A> > =
> >This message is for the designated recipient only and may=0D=0A> > > >co=
ntain privileged, proprietary, or otherwise private information.=0D=0A> > >=
 >If you have received it in error, please notify the sender=0D=0A> > > >im=
mediately and delete the original.  Any unauthorized use of=0D=0A> > > >thi=
s email is prohibited.=0D=0A> > > >----------------------------------------=
-----------------------------=0D=0A> --=0D=0A> > --=0D=0A> > > ------------=
-----------=0D=0A> > > >[mf2]=0D=0A> > > >=0D=0A> >=0D=0A> >=0D=0A> > -----=
-------------------------------------------------------------------=0D=0A> =
--=0D=0A> > ----------------------=0D=0A> > This message is for the designa=
ted recipient only and may=0D=0A> > contain privileged, proprietary, or oth=
erwise private information.=0D=0A> > If you have received it in error, plea=
se notify the sender=0D=0A> > immediately and delete the original.  Any una=
uthorized use of=0D=0A> > this email is prohibited.=0D=0A> > --------------=
----------------------------------------------------------=0D=0A> --=0D=0A>=
 > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A>=20=0D=0A> -------=
-------------------------------------------------------------------=0D=0A> =
----------------------=0D=0A> This message is for the designated recipient =
only and may=0D=0A> contain privileged, proprietary, or otherwise private i=
nformation.=0D=0A> If you have received it in error, please notify the send=
er=0D=0A> immediately and delete the original.  Any unauthorized use of=0D=0A=
> this email is prohibited.=0D=0A> ----------------------------------------=
----------------------------------=0D=0A> ----------------------=0D=0A> [mf=
2]=0D=0A=0D=0A=0D=0A-------------------------------------------------------=
-----------------------------------------=0D=0AThis message is for the desi=
gnated recipient only and may=0D=0Acontain privileged, proprietary, or othe=
rwise private information. =20=0D=0AIf you have received it in error, pleas=
e notify the sender=0D=0Aimmediately and delete the original.  Any unauthor=
ized use of=0D=0Athis email is prohibited.=0D=0A---------------------------=
---------------------------------------------------------------------=0D=0A=
[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 11 23:50:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2JYZ-00082f-84; Tue, 11 Dec 2007 23:50:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2JYX-0007zn-IO
	for ecrit@ietf.org; Tue, 11 Dec 2007 23:50:49 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2JYV-0005EG-QB
	for ecrit@ietf.org; Tue, 11 Dec 2007 23:50:49 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-2.cisco.com with ESMTP; 11 Dec 2007 20:50:47 -0800
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 lBC4oli6022591; 
	Tue, 11 Dec 2007 20:50:47 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBC4oj9X023512;
	Wed, 12 Dec 2007 04:50:47 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, 11 Dec 2007 20:50:26 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.90.132]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Dec 2007 20:50:26 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 11 Dec 2007 22:50:25 -0600
To: "Brian Rosen" , "'Stark, Barbara'" ,
	"'ECRIT'" 
From: "James M. Polk" 
Subject: RE: [Ecrit] Phonebcp and LoST responses
In-Reply-To: <005f01c83c54$07ba04d0$640fa8c0@cis.neustar.com>
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABBAC1@crexc41p>
	<005f01c83c54$07ba04d0$640fa8c0@cis.neustar.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 12 Dec 2007 04:50:26.0561 (UTC)
	FILETIME=[833DEF10:01C83C7A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2451; t=1197435047;
	x=1198299047; 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]=20Phonebcp=20and=20LoST=20respo
	nses |Sender:=20;
	bh=w9DD3g0Bt4NLGCDC+k5DPtg4Y8ABOal7Qp50WRnAblM=;
	b=NVb/13KAcUU4nn3dJAJ2BAwfWZSnyZMwJg0RMjOl0Kwls3WOwTLVCj+WEs
	HifmznlUIyZc2li+u99h3Q3UeIAJyjuRHixDSdZGi+w8uUS7ZhFBQjs8JpsY
	9l/i/QWa9Z;
Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

But if there is no cached LoST URI, what would go in the Route header 
that isn't supposed to be there now?

I think that if there is no LoST URI (learned at any time), there 
SHOULD be no Route header (because there isn't anything valid to put 
into header, save for anything related to outbound).

So, I think something more needs to be said here, but not necessarily 
"no Route header", because not having a URI to put in the header may 
be good enough to conclude there shouldn't be the header. That said, 
there may be a perfectly valid other reason to have a Route header 
for another purpose - unless we've eliminated all other purposes (and 
said so in text).

James

At 06:14 PM 12/11/2007, Brian Rosen wrote:
>Yeah, probably needed.  Things can go wrong, and no LoST server could be
>found, for example.
>
>Brian
>
> > -----Original Message-----
> > From: Stark, Barbara [mailto:bs7652@att.com]
> > Sent: Tuesday, December 11, 2007 5:23 PM
> > To: ECRIT
> > Subject: [Ecrit] Phonebcp and LoST responses
> >
> >
> > In phonebcp section 8, it says that if a device can't get a LoST
> > response, it must use its cached value. I'm wondering if we could add
> > another statement, that if it has no cached value and no LoST response,
> > it must leave off the route header and just send the Service URN in the
> > Request URI (or whatever the correct description is)? I think that would
> > be consistent with the use of LoST only being a should, in the first
> > place, and the role of the "SP" in phonebcp as being responsible for
> > being able to handle this situation.
> > Barbara
> >
> > *****
> >
> > The information transmitted is intended only for the person or entity to
> > which it is addressed and may contain confidential, proprietary, and/or
> > privileged material. Any review, retransmission, dissemination or other
> > use of, or taking of any action in reliance upon this information by
> > persons or entities other than the intended recipient is prohibited. If
> > you received this in error, please contact the sender and delete the
> > material from all computers. GA621
> >
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Wed Dec 12 11:08:32 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2U8J-0000Pb-3Z; Wed, 12 Dec 2007 11:08:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2U8H-0000PW-SY
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:08:25 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2U8H-00013r-AT
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:08:25 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2U8E-0007c6-5b; Wed, 12 Dec 2007 10:08:22 -0600
From: "Brian Rosen" 
To: "'James M. Polk'" , "'Stark, Barbara'" ,
	"'ECRIT'" 
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABBAC1@crexc41p>
	<005f01c83c54$07ba04d0$640fa8c0@cis.neustar.com>

Subject: RE: [Ecrit] Phonebcp and LoST responses
Date: Wed, 12 Dec 2007 11:08:20 -0500
Message-ID: <025801c83cd9$38c0fa40$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg8epE26Y42nnT8S7e8okp7IigDFAAXnTRQ
In-Reply-To: 
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

If you can't get to LoST, then you have no Route header with the PSAP URI,
and the R-URI is the service URN.  "No Route header" means no PSAP URI (LoST
result), not "no Route header of any kind".

Brian

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, December 11, 2007 11:50 PM
> To: Brian Rosen; 'Stark, Barbara'; 'ECRIT'
> Subject: RE: [Ecrit] Phonebcp and LoST responses
> 
> But if there is no cached LoST URI, what would go in the Route header
> that isn't supposed to be there now?
> 
> I think that if there is no LoST URI (learned at any time), there
> SHOULD be no Route header (because there isn't anything valid to put
> into header, save for anything related to outbound).
> 
> So, I think something more needs to be said here, but not necessarily
> "no Route header", because not having a URI to put in the header may
> be good enough to conclude there shouldn't be the header. That said,
> there may be a perfectly valid other reason to have a Route header
> for another purpose - unless we've eliminated all other purposes (and
> said so in text).
> 
> James
> 
> At 06:14 PM 12/11/2007, Brian Rosen wrote:
> >Yeah, probably needed.  Things can go wrong, and no LoST server could be
> >found, for example.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Stark, Barbara [mailto:bs7652@att.com]
> > > Sent: Tuesday, December 11, 2007 5:23 PM
> > > To: ECRIT
> > > Subject: [Ecrit] Phonebcp and LoST responses
> > >
> > >
> > > In phonebcp section 8, it says that if a device can't get a LoST
> > > response, it must use its cached value. I'm wondering if we could add
> > > another statement, that if it has no cached value and no LoST
> response,
> > > it must leave off the route header and just send the Service URN in
> the
> > > Request URI (or whatever the correct description is)? I think that
> would
> > > be consistent with the use of LoST only being a should, in the first
> > > place, and the role of the "SP" in phonebcp as being responsible for
> > > being able to handle this situation.
> > > Barbara
> > >
> > > *****
> > >
> > > The information transmitted is intended only for the person or entity
> to
> > > which it is addressed and may contain confidential, proprietary,
> and/or
> > > privileged material. Any review, retransmission, dissemination or
> other
> > > use of, or taking of any action in reliance upon this information by
> > > persons or entities other than the intended recipient is prohibited.
> If
> > > you received this in error, please contact the sender and delete the
> > > material from all computers. GA621
> > >
> > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Wed Dec 12 11:33:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2UWn-0002R2-4D; Wed, 12 Dec 2007 11:33:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UWl-0002Qw-Uu
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:33:43 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2UWj-0001cy-Oa
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:33:43 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-2.cisco.com with ESMTP; 12 Dec 2007 08:33:42 -0800
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 lBCGXf2X025555; 
	Wed, 12 Dec 2007 08:33:41 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBCGXf9N004769;
	Wed, 12 Dec 2007 16:33:41 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Dec 2007 08:33:27 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.66.108]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Dec 2007 08:33:26 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 12 Dec 2007 10:33:18 -0600
To: "Brian Rosen" , "'Stark, Barbara'" ,
	"'ECRIT'" 
From: "James M. Polk" 
Subject: RE: [Ecrit] Phonebcp and LoST responses
In-Reply-To: <025801c83cd9$38c0fa40$640fa8c0@cis.neustar.com>
References: <7582BC68E4994F4ABF0BD4723975C3FA06ABBAC1@crexc41p>
	<005f01c83c54$07ba04d0$640fa8c0@cis.neustar.com>

	<025801c83cd9$38c0fa40$640fa8c0@cis.neustar.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 12 Dec 2007 16:33:26.0801 (UTC)
	FILETIME=[B89FC810:01C83CDC]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3458; t=1197477221;
	x=1198341221; 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]=20Phonebcp=20and=20LoST=20respo
	nses |Sender:=20;
	bh=3cG8BTnSjGSHT15efRV5KeH1sHPOsHId3ID1LdznUQg=;
	b=DI7vwyht+DA2MEof7HpNs6D92f+DMytNp388OgJfv+HeIL9oH8a6J4VHeF
	L6SbzL5tBbpg4PnptsRXTPN/vxjxUUl8yomrF2PlWlFjYHfUWPf+BpFll2TW
	0ZIkicfg+p;
Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 10:08 AM 12/12/2007, Brian Rosen wrote:
>If you can't get to LoST, then you have no Route header with the PSAP URI,
>and the R-URI is the service URN.  "No Route header" means no PSAP URI (LoST
>result), not "no Route header of any kind".

I agree with this, but wanted to know this was understood - as 
Barbara's suggestion could have meant "No PSAP URI in the Route 
header" or "no Route header of any kind"; and I don't think we can 
say the latter is the case every time.

>Brian
>
> > -----Original Message-----
> > From: James M. Polk [mailto:jmpolk@cisco.com]
> > Sent: Tuesday, December 11, 2007 11:50 PM
> > To: Brian Rosen; 'Stark, Barbara'; 'ECRIT'
> > Subject: RE: [Ecrit] Phonebcp and LoST responses
> >
> > But if there is no cached LoST URI, what would go in the Route header
> > that isn't supposed to be there now?
> >
> > I think that if there is no LoST URI (learned at any time), there
> > SHOULD be no Route header (because there isn't anything valid to put
> > into header, save for anything related to outbound).
> >
> > So, I think something more needs to be said here, but not necessarily
> > "no Route header", because not having a URI to put in the header may
> > be good enough to conclude there shouldn't be the header. That said,
> > there may be a perfectly valid other reason to have a Route header
> > for another purpose - unless we've eliminated all other purposes (and
> > said so in text).
> >
> > James
> >
> > At 06:14 PM 12/11/2007, Brian Rosen wrote:
> > >Yeah, probably needed.  Things can go wrong, and no LoST server could be
> > >found, for example.
> > >
> > >Brian
> > >
> > > > -----Original Message-----
> > > > From: Stark, Barbara [mailto:bs7652@att.com]
> > > > Sent: Tuesday, December 11, 2007 5:23 PM
> > > > To: ECRIT
> > > > Subject: [Ecrit] Phonebcp and LoST responses
> > > >
> > > >
> > > > In phonebcp section 8, it says that if a device can't get a LoST
> > > > response, it must use its cached value. I'm wondering if we could add
> > > > another statement, that if it has no cached value and no LoST
> > response,
> > > > it must leave off the route header and just send the Service URN in
> > the
> > > > Request URI (or whatever the correct description is)? I think that
> > would
> > > > be consistent with the use of LoST only being a should, in the first
> > > > place, and the role of the "SP" in phonebcp as being responsible for
> > > > being able to handle this situation.
> > > > Barbara
> > > >
> > > > *****
> > > >
> > > > The information transmitted is intended only for the person or entity
> > to
> > > > which it is addressed and may contain confidential, proprietary,
> > and/or
> > > > privileged material. Any review, retransmission, dissemination or
> > other
> > > > use of, or taking of any action in reliance upon this information by
> > > > persons or entities other than the intended recipient is prohibited.
> > If
> > > > you received this in error, please contact the sender and delete the
> > > > material from all computers. GA621
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Ecrit mailing list
> > > > Ecrit@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > >
> > >_______________________________________________
> > >Ecrit mailing list
> > >Ecrit@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Wed Dec 12 11:39:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Uci-0004or-LG; Wed, 12 Dec 2007 11:39:52 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Uch-0004om-DE
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:39:51 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Ucg-0001wF-Ui
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:39:51 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-3.cisco.com with ESMTP; 12 Dec 2007 08:39:50 -0800
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 lBCGdoxi026473; 
	Wed, 12 Dec 2007 08:39:50 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBCGdo0i014843;
	Wed, 12 Dec 2007 16:39:50 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Dec 2007 08:39:50 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.66.108]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Dec 2007 08:39:49 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 12 Dec 2007 10:39:39 -0600
To: "Brian Rosen" , "'Marc Linsner'" , 
	"'ECRIT'" 
From: "James M. Polk" 
Subject: RE: [Ecrit] Forward Progress with "unauthenticated access"
In-Reply-To: <005701c83c51$0df2c290$640fa8c0@cis.neustar.com>
References: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
	<005701c83c51$0df2c290$640fa8c0@cis.neustar.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 12 Dec 2007 16:39:49.0611 (UTC)
	FILETIME=[9CCBF3B0:01C83CDD]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2261; t=1197477590;
	x=1198341590; 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]=20Forward=20Progress=20with=20=
	22unauthenticated=20access=22 |Sender:=20;
	bh=B8itxaZqFh6o87zD3ZD6UdwSMmhp0qHhqTA5cemWPpw=;
	b=LrKJ/BI570f01wR1xePtyTDgDnvaOka/8KLgB+cF7OJFju7AuZ71Nn9M2d
	aRSbpSHkl5dgMAEt1AMZtwVATs/AFd0Fqi20LJODarPilCATGm8cwuaz1Jeu
	DPdeBtEESswldCAKL0+Y2bPagaD2LE6wX5DEL+oKeKs+wEvatcxSc=;
Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Regarding "unauthenticated access" - I'd like a specific (likely 
detailed) definition of what this is in a VoIP environment (and not a 
cellular one) before we go about solving for it. I don't believe 
enough folks know what this is, exactly (in VoIP) - as that was the 
general sentiment last week in Vancouver.

At 05:53 PM 12/11/2007, Brian Rosen wrote:
>With respect to unauthenticated access, I do think we need mechanism,
>because it's not possible for a VSP to know what to do.  The access network
>can just obey its own local regulations, so no problem there, but a VSP on
>the Internet doesn't know what to do; it's location dependent.
>
>I think we need a solution.  I don't think it's hard, since the only thing a
>VSP can do is pass or not pass the call through.  What I think we need is a
>flag from LoST that says whether unauthenticated calling is required in the
>location specified.  It might be able to be a single bit, but perhaps an
>enumerated type makes more sense for possible future variations in what the
>VSP has to do.
>
>Endpoints can try regardless.  PSAPs take calls they get, generally.  It's
>really the VSP that is in the dark.
>
>Brian
>
> > -----Original Message-----
> > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > Sent: Tuesday, December 11, 2007 4:38 PM
> > To: 'ECRIT'
> > Subject: [Ecrit] Forward Progress
> >
> > It appears that forward progress with regards to 'Location Hiding' and
> > 'Unauthenticated Access' is going to take some time.  In an effort to
> > complete current milestones, what are opinions about adding the text below
> > to phonebcp/framework?
> >
> > "This document provides guidance for generic network configurations.  It
> > is
> > recognized that unique issues may exist in some network deployments.  The
> > IETF will continue to investigate these unique situations and provide
> > further guidance, if warranted, in future documents."
> >
> > -Marc-
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Wed Dec 12 11:52:11 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Uob-00067k-4v; Wed, 12 Dec 2007 11:52:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UoZ-00067d-Rp
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:52:07 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2UoX-00029F-M7
	for ecrit@ietf.org; Wed, 12 Dec 2007 11:52:07 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J2UoV-0003qS-00; Wed, 12 Dec 2007 10:52:03 -0600
From: "Brian Rosen" 
To: "'James M. Polk'" ,
	"'Marc Linsner'" , "'ECRIT'" 
References: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com>
	<005701c83c51$0df2c290$640fa8c0@cis.neustar.com>

Subject: RE: [Ecrit] Forward Progress with "unauthenticated access"
Date: Wed, 12 Dec 2007 11:52:01 -0500
Message-ID: <027d01c83cdf$534789f0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acg83Z0HGaz0MS1VRLa0tKeyAankUQAAHlzA
In-Reply-To: 
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I supplied a definition:
An uninitialized device does not have permission to use the access and/or
calling network but local regulation requires the access and calling
networks to grant such permission for the sole purpose of making emergency
calls.

We're changing terminology to use "unauthenticated access", so we would have
to change this slightly.

Brian

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Wednesday, December 12, 2007 11:40 AM
> To: Brian Rosen; 'Marc Linsner'; 'ECRIT'
> Subject: RE: [Ecrit] Forward Progress with "unauthenticated access"
> 
> Regarding "unauthenticated access" - I'd like a specific (likely
> detailed) definition of what this is in a VoIP environment (and not a
> cellular one) before we go about solving for it. I don't believe
> enough folks know what this is, exactly (in VoIP) - as that was the
> general sentiment last week in Vancouver.
> 
> At 05:53 PM 12/11/2007, Brian Rosen wrote:
> >With respect to unauthenticated access, I do think we need mechanism,
> >because it's not possible for a VSP to know what to do.  The access
> network
> >can just obey its own local regulations, so no problem there, but a VSP
> on
> >the Internet doesn't know what to do; it's location dependent.
> >
> >I think we need a solution.  I don't think it's hard, since the only
> thing a
> >VSP can do is pass or not pass the call through.  What I think we need is
> a
> >flag from LoST that says whether unauthenticated calling is required in
> the
> >location specified.  It might be able to be a single bit, but perhaps an
> >enumerated type makes more sense for possible future variations in what
> the
> >VSP has to do.
> >
> >Endpoints can try regardless.  PSAPs take calls they get, generally.
> It's
> >really the VSP that is in the dark.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > Sent: Tuesday, December 11, 2007 4:38 PM
> > > To: 'ECRIT'
> > > Subject: [Ecrit] Forward Progress
> > >
> > > It appears that forward progress with regards to 'Location Hiding' and
> > > 'Unauthenticated Access' is going to take some time.  In an effort to
> > > complete current milestones, what are opinions about adding the text
> below
> > > to phonebcp/framework?
> > >
> > > "This document provides guidance for generic network configurations.
> It
> > > is
> > > recognized that unique issues may exist in some network deployments.
> The
> > > IETF will continue to investigate these unique situations and provide
> > > further guidance, if warranted, in future documents."
> > >
> > > -Marc-
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Wed Dec 12 14:49:54 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Xab-0000xy-2v; Wed, 12 Dec 2007 14:49:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2XaZ-0000tJ-Fg
	for ecrit@ietf.org; Wed, 12 Dec 2007 14:49:51 -0500
Received: from aismt06p.bellsouth.com ([139.76.165.211])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2XaX-0008Ih-LX
	for ecrit@ietf.org; Wed, 12 Dec 2007 14:49:51 -0500
Received: from ([139.76.131.31])
	by aismt06p.bellsouth.com with ESMTP  id KP-AXPRN.35851100;
	Wed, 12 Dec 2007 14:49:28 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by
	01GAF5142010625.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Wed, 12 Dec 2007 14:49:28 -0500
Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by
	01NC27689010627.AD.BLS.COM with Microsoft
	SMTPSVC(6.0.3790.2499); Wed, 12 Dec 2007 14:49:28 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ecrit] Forward Progress with "unauthenticated access"
Date: Wed, 12 Dec 2007 14:49:27 -0500
Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06ABBCBA@crexc41p>
In-Reply-To: <027d01c83cdf$534789f0$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Forward Progress with "unauthenticated access"
thread-index: Acg83Z0HGaz0MS1VRLa0tKeyAankUQAAHlzAAACeb5A=
References: <001501c83c3e$0aa40760$1f0d0d0a@cisco.com><005701c83c51$0df2c290$640fa8c0@cis.neustar.com>
	<027d01c83cdf$534789f0$640fa8c0@cis.neustar.com>
From: "Stark, Barbara" 
To: "Brian Rosen" , "James M. Polk" ,
	"Marc Linsner" , "ECRIT" 
X-OriginalArrivalTime: 12 Dec 2007 19:49:28.0301 (UTC)
	FILETIME=[1B0641D0:01C83CF8]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I just don't see why a "calling network" that operates out of a foreign
country and that only markets to people in that foreign country, should
care at all what "local regulations" in other countries require.
Historically, the only regulations that a calling network is subject to,
are the regulations of the country it operates and markets in. That's
certainly true with current emergency services regulations for VoIP.

I think "calling networks" will have no problem routing emergency calls
they can authenticate. But I don't think there's any way the IETF or
some country can mandate that a foreign "calling network" has to route
unauthenticated calls, no matter how they're marked, unless you're
expecting countries to sign agreements and treaties for the sake of
supporting emergency calls by unauthenticated callers. Given that
current trends appear to be shifting away from even having cellular
access carriers support this, my intuition says "not likely" on this
one. I could be wrong...

I agree with James P, that we need to get a better characterization of
this problem in the VoIP scenario where the access network has no role
in recognizing emergency calls.=20

As a "calling network" provider, I would expect to know the regulations
of the countries I operate in. I don't need a flag to tell me what those
regulations are. And I don't see why a "calling network" provider should
care at all what the regulations are of the foreign country where
someone is calling from. Those regulations historically have never
applied. If you need to make an unauthenticated VoIP emergency call,
then I think you'd do best to point yourself to a "calling network" that
operates within the country where you are (assuming that country allows
such unauthenticated calls). I think the FCC would have a real hard time
telling a VSP operating and marketing in Germany that it MUST route
unauthenticated calls from the US, going to a US PSAP, if the German
regulations say that it doesn't have to route unauthenticated calls.

I'm just not seeing a real need for the added complexity and changes. My
intuition says that if there were a parameter, like you (Brian) suggest,
that it would be completely ignored, all the time, when coming from a
foreign country. And the local regulations are known. Find some people
with regulatory or legislative powers, from influential countries, who
really believe in the need to support this scenario, and are willing to
say so, and I'll admit I'm wrong. Till then, I think this is
unnecessary.
Barbara =20

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]=20
Sent: Wednesday, December 12, 2007 11:52 AM
To: 'James M. Polk'; 'Marc Linsner'; 'ECRIT'
Subject: RE: [Ecrit] Forward Progress with "unauthenticated access"

I supplied a definition:
An uninitialized device does not have permission to use the access
and/or
calling network but local regulation requires the access and calling
networks to grant such permission for the sole purpose of making
emergency
calls.

We're changing terminology to use "unauthenticated access", so we would
have
to change this slightly.

Brian

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Wednesday, December 12, 2007 11:40 AM
> To: Brian Rosen; 'Marc Linsner'; 'ECRIT'
> Subject: RE: [Ecrit] Forward Progress with "unauthenticated access"
>=20
> Regarding "unauthenticated access" - I'd like a specific (likely
> detailed) definition of what this is in a VoIP environment (and not a
> cellular one) before we go about solving for it. I don't believe
> enough folks know what this is, exactly (in VoIP) - as that was the
> general sentiment last week in Vancouver.
>=20
> At 05:53 PM 12/11/2007, Brian Rosen wrote:
> >With respect to unauthenticated access, I do think we need mechanism,
> >because it's not possible for a VSP to know what to do.  The access
> network
> >can just obey its own local regulations, so no problem there, but a
VSP
> on
> >the Internet doesn't know what to do; it's location dependent.
> >
> >I think we need a solution.  I don't think it's hard, since the only
> thing a
> >VSP can do is pass or not pass the call through.  What I think we
need is
> a
> >flag from LoST that says whether unauthenticated calling is required
in
> the
> >location specified.  It might be able to be a single bit, but perhaps
an
> >enumerated type makes more sense for possible future variations in
what
> the
> >VSP has to do.
> >
> >Endpoints can try regardless.  PSAPs take calls they get, generally.
> It's
> >really the VSP that is in the dark.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > Sent: Tuesday, December 11, 2007 4:38 PM
> > > To: 'ECRIT'
> > > Subject: [Ecrit] Forward Progress
> > >
> > > It appears that forward progress with regards to 'Location Hiding'
and
> > > 'Unauthenticated Access' is going to take some time.  In an effort
to
> > > complete current milestones, what are opinions about adding the
text
> below
> > > to phonebcp/framework?
> > >
> > > "This document provides guidance for generic network
configurations.
> It
> > > is
> > > recognized that unique issues may exist in some network
deployments.
> The
> > > IETF will continue to investigate these unique situations and
provide
> > > further guidance, if warranted, in future documents."
> > >
> > > -Marc-
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

*****

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

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 17 03:15:09 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4B7u-0001au-Cm; Mon, 17 Dec 2007 03:15:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4B7t-0001al-Hx
	for ecrit@ietf.org; Mon, 17 Dec 2007 03:15:01 -0500
Received: from fk-out-0910.google.com ([209.85.128.185])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4B7s-00040w-WD
	for ecrit@ietf.org; Mon, 17 Dec 2007 03:15:01 -0500
Received: by fk-out-0910.google.com with SMTP id z23so1330888fkz.5
	for ; Mon, 17 Dec 2007 00:14:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	bh=hOUaSyBXQR68atA8CP0qtH7VWQuWyCoe+3IL1h/k3AE=;
	b=g5xR12QHWnHbnZUDDlAO8g6OKBNvM/apiRBT7M/LeXID6g/E1eYeKXao7b3GDbfc7fhJ5koTlPoj7FVpReT6KZGKVI8nNDzJ8DmvS3jc7nHV/mf15RPRwVV/hyT3bXs1pd54r/KriVOTMwYh+CXgdlAfv+Vmn1Osn4mO2cFqup0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=hi+tGcSWYAIP8fnMAZt9xGEE0q0maAYU+I3LxwRt9p6SFL3he1ZJIxBaUUal/+v7BnhqH5AGa9S5/pYNS+9Ocys3WK/ywoBe3kWWh2Ore5qspm/M00B9fQ+trjEOYEY/3/TBZ4EGnSDJfIorxYzFExi4W4Si38Wb18D7VelpTZ4=
Received: by 10.82.150.20 with SMTP id x20mr4701831bud.37.1197879299416;
	Mon, 17 Dec 2007 00:14:59 -0800 (PST)
Received: by 10.82.182.18 with HTTP; Mon, 17 Dec 2007 00:14:59 -0800 (PST)
Message-ID: 
Date: Mon, 17 Dec 2007 09:14:59 +0100
From: "Karl Heinz Wolf" 
To: "Ted Hardie" 
Subject: Re: LoST serviceNumber [Re: [Ecrit] Comments on framework-03]
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
	<474F2C7E.9010809@ntt-at.com> 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: ecrit@ietf.org
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I just had a look at the Warnings Section in LoST. Figure 19 shows an
example findServiceResponse. Again, there is no serviceNumber. Should
the default PSAP have a default serviceNumber?

cheers
karl heinz

On Nov 29, 2007 10:33 PM, Ted Hardie  wrote:
> At 1:17 PM -0800 11/29/07, Shida Schubert wrote:
> >I think the text for mandating the inclusion of  in case of
> >an emergency probably belongs to the phone BCP.
> >
> >Regards
> > Shida
> >
>
> The example should clearly include it, no matter where the normative text is,
> and I have no problem making that fix in the next round (there will
> need to be one round before IETF Last call for a number of small issues
> that came up).
>
>                         regards,
>                                 Ted
>
>
>
>
> >Karl Heinz Wolf wrote:
> >>On Oct 16, 2007 1:12 PM, Henning Schulzrinne  wrote:
> >>
> >>>>>ed. For
> >>>>>example, when LoST is used only to validate civic addresses then
> >>>>>it is
> >>>>>not needed.
> >>>>>Another example, when a proxy uses LoST for location based routing
> >>>>>then
> >>>>>the  element will not be helpful.
> >>>>>
> >>>>but it wouldn't harm, would it?
> >>>>
> >>>Not all services may have dial strings, at least in the long term.
> >>>Remember that LoST can be used for things other than emergency calls.
> >>>
> >>>
> >>
> >>It is a long time ago, I started this discussion because the LoST
> >>serviceNumber element is just optional. The response here was that the
> >>service number will be returned for an emergency service.
> >>
> >>Unfortunately, the example of mapping an emergency service in
> >>draft-ietf-ecrit-lost-06 on page 34 has NO  element!
> >>
> >>cheers,
> >>karl heinz
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>Ecrit@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/ecrit
> >>
> >>
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ecrit
>
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 17 15:29:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4Mao-0001Kr-SJ; Mon, 17 Dec 2007 15:29:38 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Man-0001KM-0O
	for ecrit@ietf.org; Mon, 17 Dec 2007 15:29:37 -0500
Received: from mx11.bbn.com ([128.33.0.80])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4Mam-0007FN-NM
	for ecrit@ietf.org; Mon, 17 Dec 2007 15:29:36 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx11.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1J4Mam-0003bm-3E; Mon, 17 Dec 2007 15:29:36 -0500
Received: from col-dhcp33-244-180.bbn.com ([128.33.244.180] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1J4Mal-00026i-PH; Mon, 17 Dec 2007 15:29:35 -0500
Message-ID: <4766DC2E.7010304@bbn.com>
Date: Mon, 17 Dec 2007 15:29:34 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: ECRIT , Brian Rosen 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: 
Subject: [Ecrit] Minor comment on phonebcp
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

In draft-ietf-ecrit-phonebcp-03, requirement ED-60 says (among other things)

"
    9.   If a device understands the SIP location conveyance
         [I-D.ietf-sip-location-conveyance] extension and has its
         location available, it MUST include location either by-value or
         by-reference.
"

It seems like this requirement should be stronger.  In particular, if an 
endpoint has an LbyR, it's likely to point to a more timely location 
than an LbyV that it has (ignoring Henning's classification of LbyR for 
the moment).  Should it be MUST include LbyR if you have it?

--Richard

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 17 15:35:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4Mgb-0007r7-A7; Mon, 17 Dec 2007 15:35:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MgZ-0007qV-U8
	for ecrit@ietf.org; Mon, 17 Dec 2007 15:35:35 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4MgX-0008HE-OX
	for ecrit@ietf.org; Mon, 17 Dec 2007 15:35:35 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J4MgQ-0001BX-B9; Mon, 17 Dec 2007 14:35:26 -0600
From: "Brian Rosen" 
To: "'Richard Barnes'" ,
	"'ECRIT'" 
References: <4766DC2E.7010304@bbn.com>
Date: Mon, 17 Dec 2007 15:35:30 -0500
Message-ID: <00da01c840ec$5f411760$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchA65C/lbzhGGNNTGKHH2jgHTt6wgAALN2A
In-Reply-To: <4766DC2E.7010304@bbn.com>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
Subject: [Ecrit] RE: Minor comment on phonebcp
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

If you have both, send both.  If you have one, send what you have.

Brian

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Monday, December 17, 2007 3:30 PM
> To: ECRIT; Brian Rosen
> Subject: Minor comment on phonebcp
> 
> In draft-ietf-ecrit-phonebcp-03, requirement ED-60 says (among other
> things)
> 
> "
>     9.   If a device understands the SIP location conveyance
>          [I-D.ietf-sip-location-conveyance] extension and has its
>          location available, it MUST include location either by-value or
>          by-reference.
> "
> 
> It seems like this requirement should be stronger.  In particular, if an
> endpoint has an LbyR, it's likely to point to a more timely location
> than an LbyV that it has (ignoring Henning's classification of LbyR for
> the moment).  Should it be MUST include LbyR if you have it?
> 
> --Richard

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 17 15:41:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4Mm6-0001l9-C9; Mon, 17 Dec 2007 15:41:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Mm5-0001l3-6c
	for ecrit@ietf.org; Mon, 17 Dec 2007 15:41:17 -0500
Received: from mx12.bbn.com ([128.33.0.81])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4Mm4-0007cb-S0
	for ecrit@ietf.org; Mon, 17 Dec 2007 15:41:17 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx12.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1J4Mm4-0007qP-45; Mon, 17 Dec 2007 15:41:16 -0500
Received: from col-dhcp33-244-180.bbn.com ([128.33.244.180] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1J4Mm4-00039y-49; Mon, 17 Dec 2007 15:41:16 -0500
Message-ID: <4766DEEB.3080700@bbn.com>
Date: Mon, 17 Dec 2007 15:41:15 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Brian Rosen 
References: <4766DC2E.7010304@bbn.com>
	<00da01c840ec$5f411760$640fa8c0@cis.neustar.com>
In-Reply-To: <00da01c840ec$5f411760$640fa8c0@cis.neustar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: 'ECRIT' 
Subject: [Ecrit] Re: Minor comment on phonebcp
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Right.  That's what we mean, but not what the document says.  How about 
if we change it to "... it MUST include location by-value or 
by-reference, or in both forms if both are available."

--Richard

Brian Rosen wrote:
> If you have both, send both.  If you have one, send what you have.
> 
> Brian
> 
>> -----Original Message-----
>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>> Sent: Monday, December 17, 2007 3:30 PM
>> To: ECRIT; Brian Rosen
>> Subject: Minor comment on phonebcp
>>
>> In draft-ietf-ecrit-phonebcp-03, requirement ED-60 says (among other
>> things)
>>
>> "
>>     9.   If a device understands the SIP location conveyance
>>          [I-D.ietf-sip-location-conveyance] extension and has its
>>          location available, it MUST include location either by-value or
>>          by-reference.
>> "
>>
>> It seems like this requirement should be stronger.  In particular, if an
>> endpoint has an LbyR, it's likely to point to a more timely location
>> than an LbyV that it has (ignoring Henning's classification of LbyR for
>> the moment).  Should it be MUST include LbyR if you have it?
>>
>> --Richard
> 
> 
> 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 17 16:47:34 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4NoE-0002Mc-6I; Mon, 17 Dec 2007 16:47:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4NoC-0002H4-Sf
	for ecrit@ietf.org; Mon, 17 Dec 2007 16:47:32 -0500
Received: from mx11.bbn.com ([128.33.0.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4NoB-0002tF-HO
	for ecrit@ietf.org; Mon, 17 Dec 2007 16:47:32 -0500
Received: from mail.bbn.com ([128.33.1.19])
	by mx11.bbn.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1J4No7-0004az-6Q; Mon, 17 Dec 2007 16:47:28 -0500
Received: from col-dhcp33-244-180.bbn.com ([128.33.244.180] helo=[127.0.0.1])
	by mail.bbn.com with esmtp (Exim 4.67)
	(envelope-from )
	id 1J4No7-00009M-L7; Mon, 17 Dec 2007 16:47:27 -0500
Message-ID: <4766EE76.80607@bbn.com>
Date: Mon, 17 Dec 2007 16:47:34 -0500
From: Richard Barnes 
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: ECRIT , Ted Hardie , 
	Henning Schulzrinne ,
	Hannes Tschofenig , Andrew Newton 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: 
Subject: [Ecrit] What does LoST return for a polygon?
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I'm bothered by the following text in draft-ietf-ecrit-lost-06:

"
    When clients place a , ,  or 
    element within the  element then it indicates that the
    query is about any point contained in the given area; it is left to
    the server to select an appropriate matching algorithm, such as using
    computing the centroid.
"

The case that worries me is when I have an imprecise location that 
crosses service boundaries, and the LoST server chooses the wrong one. 
I don't have anything else to try, since the LoST server didn't tell me 
any other possibilities.

In addition, I don't think this behavior is compatible with the "return 
all possible results" philosophy in the draft-ietf-mapping-arch-03. 
Even though that was said in the context of multiple service boundaries 
overlapping a single point, the same logic would seem to apply to a 
single location that spans multiple service boundaries.

Can we change this to say that the server MUST return all appropriate 
 elements when the polygon extends over multiple service areas?

--RB

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 17 20:14:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4R2Q-0007Lr-9W; Mon, 17 Dec 2007 20:14:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4R2O-0007Lk-Bm
	for ecrit@ietf.org; Mon, 17 Dec 2007 20:14:24 -0500
Received: from ironportdmz5.qualcomm.com ([199.106.114.254]
	helo=wolverine01.qualcomm.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4R2N-0007bf-TB
	for ecrit@ietf.org; Mon, 17 Dec 2007 20:14:24 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns;
	h=X-IronPort-AV:Received:Received:Received:Mime-Version:
	Message-Id:In-Reply-To:References:Date:To:From:Subject:
	Content-Type;
	b=Xu45B8wzzgx9n11JBPIQI2LNPuMWstv7ooWACTBW0SWySeDrashIDMqf
	ZeCsZIiH3IGGQT5OPbgKKwmzXZOUhAvJsksB3CgKorcUI+1Cm7D74Uei/
	ug4sYMgxfSHLhQ7Bz6y0UIqctBY+VcIcYrms2+vqukeMlO9YpDyvF8sFy
	Y=;
X-IronPort-AV: E=McAfee;i="5100,188,5187"; a="173082"
Received: from numenor.qualcomm.com ([129.46.51.58])
	by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
	17 Dec 2007 17:14:23 -0800
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by numenor.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id
	lBI1EMxq005912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 17 Dec 2007 17:14:22 -0800
Received: from [76.126.60.89] (carbuncle.qualcomm.com [129.46.226.27])
	by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id
	lBI1EKl5007609; Mon, 17 Dec 2007 17:14:21 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4766EE76.80607@bbn.com>
References: <4766EE76.80607@bbn.com>
Date: Mon, 17 Dec 2007 17:14:23 -0800
To: Richard Barnes , ECRIT ,
	Henning Schulzrinne ,
	Hannes Tschofenig , Andrew Newton 
From: Ted Hardie 
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: 
Subject: [Ecrit] Re: What does LoST return for a polygon?
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 4:47 PM -0500 12/17/07, Richard Barnes wrote:
>I'm bothered by the following text in draft-ietf-ecrit-lost-06:
>
>"
>   When clients place a , ,  or 
>   element within the  element then it indicates that the
>   query is about any point contained in the given area; it is left to
>   the server to select an appropriate matching algorithm, such as using
>   computing the centroid.
>"
>
>The case that worries me is when I have an imprecise location that crosses service boundaries, and the LoST server chooses the wrong one. I don't have anything else to try, since the LoST server didn't tell me any other possibilities.

>In addition, I don't think this behavior is compatible with the "return all possible results" philosophy in the draft-ietf-mapping-arch-03. Even though that was said in the context of multiple service boundaries overlapping a single point, the same logic would seem to apply to a single location that spans multiple service boundaries.

I don't think this is the same context, honestly.  This fits in within a previous
design decision, that the URIs returned should be deterministic; the end user
shouldn't have to try them each in turn.  If I get a URI that returns me to
a PSAP/ESRP that happens to be across the state line from where I am
(in the real corner case that the selected point in the arc band would return
the wrong ESRP with state-level ESRPs),  the call takers will have to determine where I
really am.  Once that determination is made, they will need to forward me to the right
PSAP/ESRP or do a LoST lookup on my behalf to provide me a way to do it.  

But *someone* would have to do the real location determination anyway; giving
me a list of potential match URIs doesn't help that.  I still have to call and
tell someone where I am before getting any further.  This just gives me a second
URI to try after getting through that point with the first; assuming the first one
is a valid URI *at all*, that's not really an advantage as the call taker interaction
will get me further than a blind drop to the second item on the list will.  It also
avoids the whole issue of how to order the list, something which is rife with
potential issues.

I oppose this change.
				Ted

>Can we change this to say that the server MUST return all appropriate  elements when the polygon extends over multiple service areas?
>
>--RB

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Mon Dec 17 20:34:27 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4RLm-00065I-LI; Mon, 17 Dec 2007 20:34:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4RLm-00064r-4p
	for ecrit@ietf.org; Mon, 17 Dec 2007 20:34:26 -0500
Received: from serrano.cc.columbia.edu ([128.59.29.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4RLl-0007vE-MM
	for ecrit@ietf.org; Mon, 17 Dec 2007 20:34:26 -0500
Received: from Henning-Schulzrinnes-Computer
	(pool-70-21-187-251.nwrk.east.verizon.net [70.21.187.251] (may
	be forged)) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lBI1YDcH011592
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Mon, 17 Dec 2007 20:34:14 -0500 (EST)
Message-Id: <49A4F46A-B53F-4B05-96F6-8DA63D8392EC@cs.columbia.edu>
From: Henning Schulzrinne 
To: Ted Hardie 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Mon, 17 Dec 2007 20:34:13 -0500
References: <4766EE76.80607@bbn.com> 
X-Mailer: Apple Mail (2.915)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: ECRIT 
Subject: [Ecrit] Re: What does LoST return for a polygon?
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I agree with Ted.

This occurs today, given that sector-based routing may well span  
multiple PSAPs. In practice, what should happen is that the location  
fix gets more precise by the time the call gets answered, and the call  
taker can then transfer the call automatically to the right place,  
doing another LoST dip. If you get location fixes that routinely span  
multiple jurisdictions by significant amounts, I have a hard time  
seeing how this location accuracy can be useful for dispatch. It's  
certainly not FCC-compliant.

Henning

On Dec 17, 2007, at 8:14 PM, Ted Hardie wrote:

> At 4:47 PM -0500 12/17/07, Richard Barnes wrote:
>> I'm bothered by the following text in draft-ietf-ecrit-lost-06:
>>
>> "
>>  When clients place a , ,  or 
>>  element within the  element then it indicates that the
>>  query is about any point contained in the given area; it is left to
>>  the server to select an appropriate matching algorithm, such as  
>> using
>>  computing the centroid.
>> "
>>
>> The case that worries me is when I have an imprecise location that  
>> crosses service boundaries, and the LoST server chooses the wrong  
>> one. I don't have anything else to try, since the LoST server  
>> didn't tell me any other possibilities.
>
>> In addition, I don't think this behavior is compatible with the  
>> "return all possible results" philosophy in the draft-ietf-mapping- 
>> arch-03. Even though that was said in the context of multiple  
>> service boundaries overlapping a single point, the same logic would  
>> seem to apply to a single location that spans multiple service  
>> boundaries.
>
> I don't think this is the same context, honestly.  This fits in  
> within a previous
> design decision, that the URIs returned should be deterministic; the  
> end user
> shouldn't have to try them each in turn.  If I get a URI that  
> returns me to
> a PSAP/ESRP that happens to be across the state line from where I am
> (in the real corner case that the selected point in the arc band  
> would return
> the wrong ESRP with state-level ESRPs),  the call takers will have  
> to determine where I
> really am.  Once that determination is made, they will need to  
> forward me to the right
> PSAP/ESRP or do a LoST lookup on my behalf to provide me a way to do  
> it.
>
> But *someone* would have to do the real location determination  
> anyway; giving
> me a list of potential match URIs doesn't help that.  I still have  
> to call and
> tell someone where I am before getting any further.  This just gives  
> me a second
> URI to try after getting through that point with the first; assuming  
> the first one
> is a valid URI *at all*, that's not really an advantage as the call  
> taker interaction
> will get me further than a blind drop to the second item on the list  
> will.  It also
> avoids the whole issue of how to order the list, something which is  
> rife with
> potential issues.
>
> I oppose this change.
> 				Ted
>
>
>
>> Can we change this to say that the server MUST return all  
>> appropriate  elements when the polygon extends over  
>> multiple service areas?
>>
>> --RB
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 18 08:43:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4cje-0003E3-Kk; Tue, 18 Dec 2007 08:43:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cjc-00039U-St
	for ecrit@ietf.org; Tue, 18 Dec 2007 08:43:48 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4cjc-0002wa-7F
	for ecrit@ietf.org; Tue, 18 Dec 2007 08:43:48 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J4cjW-0000An-W3; Tue, 18 Dec 2007 07:43:43 -0600
From: "Brian Rosen" 
To: "'Henning Schulzrinne'" ,
	"'Ted Hardie'" 
References: <4766EE76.80607@bbn.com> 
	<49A4F46A-B53F-4B05-96F6-8DA63D8392EC@cs.columbia.edu>
Subject: RE: [Ecrit] Re: What does LoST return for a polygon?
Date: Tue, 18 Dec 2007 08:43:44 -0500
Message-ID: <027401c8417c$03c45dd0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchBFhzmW+ppdJYBRS+P/RueAGiVNgAZavPQ
In-Reply-To: <49A4F46A-B53F-4B05-96F6-8DA63D8392EC@cs.columbia.edu>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: 'ECRIT' 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Yeah, they are right.

Once you call a PSAP, you don't hang up and try another one if you got the
wrong one.  They transfer you to the right one.

So, you want the best guess from the information given.  The LoST server is
in the best position to determine that, and the answer it gets is where you
send the call.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Monday, December 17, 2007 8:34 PM
> To: Ted Hardie
> Cc: ECRIT
> Subject: [Ecrit] Re: What does LoST return for a polygon?
> 
> I agree with Ted.
> 
> This occurs today, given that sector-based routing may well span
> multiple PSAPs. In practice, what should happen is that the location
> fix gets more precise by the time the call gets answered, and the call
> taker can then transfer the call automatically to the right place,
> doing another LoST dip. If you get location fixes that routinely span
> multiple jurisdictions by significant amounts, I have a hard time
> seeing how this location accuracy can be useful for dispatch. It's
> certainly not FCC-compliant.
> 
> Henning
> 
> On Dec 17, 2007, at 8:14 PM, Ted Hardie wrote:
> 
> > At 4:47 PM -0500 12/17/07, Richard Barnes wrote:
> >> I'm bothered by the following text in draft-ietf-ecrit-lost-06:
> >>
> >> "
> >>  When clients place a , ,  or 
> >>  element within the  element then it indicates that the
> >>  query is about any point contained in the given area; it is left to
> >>  the server to select an appropriate matching algorithm, such as
> >> using
> >>  computing the centroid.
> >> "
> >>
> >> The case that worries me is when I have an imprecise location that
> >> crosses service boundaries, and the LoST server chooses the wrong
> >> one. I don't have anything else to try, since the LoST server
> >> didn't tell me any other possibilities.
> >
> >> In addition, I don't think this behavior is compatible with the
> >> "return all possible results" philosophy in the draft-ietf-mapping-
> >> arch-03. Even though that was said in the context of multiple
> >> service boundaries overlapping a single point, the same logic would
> >> seem to apply to a single location that spans multiple service
> >> boundaries.
> >
> > I don't think this is the same context, honestly.  This fits in
> > within a previous
> > design decision, that the URIs returned should be deterministic; the
> > end user
> > shouldn't have to try them each in turn.  If I get a URI that
> > returns me to
> > a PSAP/ESRP that happens to be across the state line from where I am
> > (in the real corner case that the selected point in the arc band
> > would return
> > the wrong ESRP with state-level ESRPs),  the call takers will have
> > to determine where I
> > really am.  Once that determination is made, they will need to
> > forward me to the right
> > PSAP/ESRP or do a LoST lookup on my behalf to provide me a way to do
> > it.
> >
> > But *someone* would have to do the real location determination
> > anyway; giving
> > me a list of potential match URIs doesn't help that.  I still have
> > to call and
> > tell someone where I am before getting any further.  This just gives
> > me a second
> > URI to try after getting through that point with the first; assuming
> > the first one
> > is a valid URI *at all*, that's not really an advantage as the call
> > taker interaction
> > will get me further than a blind drop to the second item on the list
> > will.  It also
> > avoids the whole issue of how to order the list, something which is
> > rife with
> > potential issues.
> >
> > I oppose this change.
> > 				Ted
> >
> >
> >
> >> Can we change this to say that the server MUST return all
> >> appropriate  elements when the polygon extends over
> >> multiple service areas?
> >>
> >> --RB
> >
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 18 14:25:19 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4i45-0008OT-8Q; Tue, 18 Dec 2007 14:25:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4i43-0008Dg-N8
	for ecrit@ietf.org; Tue, 18 Dec 2007 14:25:15 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4i41-0000bV-He
	for ecrit@ietf.org; Tue, 18 Dec 2007 14:25:15 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 18 Dec 2007 11:25:13 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBIJPCow031810; 
	Tue, 18 Dec 2007 11:25:13 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBIJP811025183;
	Tue, 18 Dec 2007 19:25:08 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, 18 Dec 2007 11:25:01 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.65.5]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 18 Dec 2007 11:25:01 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 18 Dec 2007 13:25:00 -0600
To: Richard Barnes , Brian Rosen 
From: "James M. Polk" 
Subject: Re: [Ecrit] Re: Minor comment on phonebcp
In-Reply-To: <4766DEEB.3080700@bbn.com>
References: <4766DC2E.7010304@bbn.com>
	<00da01c840ec$5f411760$640fa8c0@cis.neustar.com>
	<4766DEEB.3080700@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 18 Dec 2007 19:25:01.0525 (UTC)
	FILETIME=[AF3C8050:01C841AB]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1922; t=1198005913;
	x=1198869913; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Ecrit]=20Re=3A=20Minor=20comment=20on=
	20phonebcp |Sender:=20;
	bh=ymrguhchQakAjo8fsqO1bthPOZnsKOvvk11c8LDsJ6I=;
	b=G9GoeSeemXUja7pCsoVoIYD3/frx4cjsHpKwkHD9qrZSzIN5GU5Ber/SM1
	hzmwB5MA56lObE9fneswhxgHsYKZ94mxl+tQXepvlNtWy8IO3Ust+avyoebS
	jLPTZLhDS7;
Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 'ECRIT' 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

At 02:41 PM 12/17/2007, Richard Barnes wrote:
>Right.  That's what we mean, but not what the document says.  How 
>about if we change it to "... it MUST include location by-value or 
>by-reference, or in both forms if both are available."

well, I disagree here

for one, since including *both* could be pointing to TWO (different) locations

Let's not instantly create a situation of confusion by all Location 
Recipients by making it have to decide which location is better, ok?

Deciding that LbyR is more up-to-date than LbyV is a function of a 
local network, not for an international standard to decide.

The text, as written, makes providing either (LbyR or LbyV) location 
mandatory, and leaves which to those local policies and 
configurations - where they belong.

>--Richard
>
>
>
>Brian Rosen wrote:
>>If you have both, send both.  If you have one, send what you have.
>>Brian
>>
>>>-----Original Message-----
>>>From: Richard Barnes [mailto:rbarnes@bbn.com]
>>>Sent: Monday, December 17, 2007 3:30 PM
>>>To: ECRIT; Brian Rosen
>>>Subject: Minor comment on phonebcp
>>>
>>>In draft-ietf-ecrit-phonebcp-03, requirement ED-60 says (among other
>>>things)
>>>
>>>"
>>>     9.   If a device understands the SIP location conveyance
>>>          [I-D.ietf-sip-location-conveyance] extension and has its
>>>          location available, it MUST include location either by-value or
>>>          by-reference.
>>>"
>>>
>>>It seems like this requirement should be stronger.  In particular, if an
>>>endpoint has an LbyR, it's likely to point to a more timely location
>>>than an LbyV that it has (ignoring Henning's classification of LbyR for
>>>the moment).  Should it be MUST include LbyR if you have it?
>>>
>>>--Richard
>>
>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 18 16:49:16 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4kJP-0006rS-8Z; Tue, 18 Dec 2007 16:49:15 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kJN-0006m2-9Y
	for ecrit@ietf.org; Tue, 18 Dec 2007 16:49:13 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4kJM-0008Hg-E9
	for ecrit@ietf.org; Tue, 18 Dec 2007 16:49:13 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-3.cisco.com with ESMTP; 18 Dec 2007 13:49:11 -0800
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 lBILnBK0009683; 
	Tue, 18 Dec 2007 13:49:11 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBILn241006464;
	Tue, 18 Dec 2007 21:49:07 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, 18 Dec 2007 13:49:02 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.146.207]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 18 Dec 2007 13:49:02 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 18 Dec 2007 15:48:37 -0600
To: Matt Lepinski 
From: "James M. Polk" 
Subject: Re: [Ecrit] Re: Minor comment on phonebcp
In-Reply-To: <47682CE6.4030805@bbn.com>
References: <4766DC2E.7010304@bbn.com>
	<00da01c840ec$5f411760$640fa8c0@cis.neustar.com>
	<4766DEEB.3080700@bbn.com>

	<47682CE6.4030805@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 18 Dec 2007 21:49:02.0182 (UTC)
	FILETIME=[CD782060:01C841BF]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4790; t=1198014551;
	x=1198878551; 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]=20Re=3A=20Minor=20comment=20on=
	20phonebcp |Sender:=20;
	bh=8rDX8zsgBg+xhyzL47OQABrZ/ZmyJNzVGdwDT8GIDhw=;
	b=Hp+4TFwiuhqq0CFKGHOwM6koQwzlQ4XlzWu2X17TwgQ6bH92psHCMeFAj3
	Ts+3AHyv/8u/xz9NoIhDn4OqhKAi3d04D8RqoBUNORG7SLJl0r5IhzrQ8YV6
	TvpH0LA51O;
Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: 'ECRIT' 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Matt

in-line

At 02:26 PM 12/18/2007, Matt Lepinski wrote:
>James,
>
>I agree that there may be cases where a device ends up with both 
>LbyV and LbyR and the LbyV is more useful/up-to-date than the LbyR.
>
>However, there is certainly a common use-case where a mobile device

how isn't mobile devices "a local network decision" (from my message below)?

BTW - what if LbyR is mandatory and the UA has a GPS with the most 
precise location information? Isn't this defeating the purpose of 
what you want (i.e., the most up-to-date and precise location information)?

>obtains an LbyV for use in call-routing and an LbyR which can be 
>used to obtain more update location information (within some window 
>of time). In this case where the LbyV is used for routing and the 
>LbyR is able to provide more up-to-date location as the target moves,

SIP Conveyance has the UA sending an UPDATE every time it moves, so 
this case isn't ignore.

>I think we agree that the endpoint should include both locations in 
>the SIP INVITE (marking the LbyV with the "used-for-routing" parameter).

no, I said I don't agree with this, and I gave a reason previously - 
which is a valid one (confusing situation for a Location Recipient)

>Currently, it is unclear from the text that when a mobile device has 
>both LbyV and LbyR that it should often include both locations. It 
>would be nice if this were clarified.

I think sending both creates confusion more often than it won't, 
since there will likely be two different Sighters, with different 
measuring techniques

>If there are important cases where a device has both LbyV and LbyR, 
>but should only include one or the other, then instead of "MUST 
>include both when both are available", we can instead use 
>"SHOULD"-strength text with an explanation of when sending both is 
>appropriate and when sending only one is appropriate.

The text currently says "MUST send Location", it doesn't say which, 
and it shouldn't in the protocol spec.  Local policy can always 
specify (or extend) which one to send or both, knowing Recipients 
know what to do if they receive two or more locations - but right 
now, we don't tell a Recipient what to do if receiving both types, 
nor do we state which is more trustworthy.  For example, in an 
IP-cellular environment, 3GPP is more appropriate to specify that the 
LbyR from a server is more trustworthy - than an IETF doc that 
shouldn't make that underlying network type distinction.

James

>- Matt Lepinski
>
>James M. Polk wrote:
>
>>At 02:41 PM 12/17/2007, Richard Barnes wrote:
>>
>>>Right.  That's what we mean, but not what the document says.  How 
>>>about if we change it to "... it MUST include location by-value or 
>>>by-reference, or in both forms if both are available."
>>
>>
>>well, I disagree here
>>
>>for one, since including *both* could be pointing to TWO 
>>(different) locations
>>
>>Let's not instantly create a situation of confusion by all Location 
>>Recipients by making it have to decide which location is better, ok?
>>
>>Deciding that LbyR is more up-to-date than LbyV is a function of a 
>>local network, not for an international standard to decide.
>>
>>The text, as written, makes providing either (LbyR or LbyV) 
>>location mandatory, and leaves which to those local policies and 
>>configurations - where they belong.
>>
>>
>>>--Richard
>>>
>>>
>>>
>>>Brian Rosen wrote:
>>>
>>>>If you have both, send both.  If you have one, send what you have.
>>>>Brian
>>>>
>>>>>-----Original Message-----
>>>>>From: Richard Barnes [mailto:rbarnes@bbn.com]
>>>>>Sent: Monday, December 17, 2007 3:30 PM
>>>>>To: ECRIT; Brian Rosen
>>>>>Subject: Minor comment on phonebcp
>>>>>
>>>>>In draft-ietf-ecrit-phonebcp-03, requirement ED-60 says (among other
>>>>>things)
>>>>>
>>>>>"
>>>>>     9.   If a device understands the SIP location conveyance
>>>>>          [I-D.ietf-sip-location-conveyance] extension and has its
>>>>>          location available, it MUST include location either by-value or
>>>>>          by-reference.
>>>>>"
>>>>>
>>>>>It seems like this requirement should be stronger.  In particular, if an
>>>>>endpoint has an LbyR, it's likely to point to a more timely location
>>>>>than an LbyV that it has (ignoring Henning's classification of LbyR for
>>>>>the moment).  Should it be MUST include LbyR if you have it?
>>>>>
>>>>>--Richard
>>>>
>>>
>>>
>>>_______________________________________________
>>>Ecrit mailing list
>>>Ecrit@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ecrit
>>
>>
>>_______________________________________________
>>Ecrit mailing list
>>Ecrit@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Tue Dec 18 19:07:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4mSs-000280-2i; Tue, 18 Dec 2007 19:07:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J4mSr-00027u-Bp
	for ecrit@ietf.org; Tue, 18 Dec 2007 19:07:09 -0500
Received: from ebru.winwebhosting.com ([74.54.111.226])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4mSp-0003QL-3I
	for ecrit@ietf.org; Tue, 18 Dec 2007 19:07:09 -0500
Received: from [209.173.53.233] (helo=BROSLT41xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.68)
	(envelope-from )
	id 1J4mSf-0007Pm-EY; Tue, 18 Dec 2007 18:06:57 -0600
From: "Brian Rosen" 
To: "'James M. Polk'" , "'Matt Lepinski'" 
References: <4766DC2E.7010304@bbn.com>
	<00da01c840ec$5f411760$640fa8c0@cis.neustar.com>
	<4766DEEB.3080700@bbn.com>

	<47682CE6.4030805@bbn.com>

Subject: RE: [Ecrit] Re: Minor comment on phonebcp
Date: Tue, 18 Dec 2007 19:07:02 -0500
Message-ID: <045e01c841d3$173eb6b0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchBv8++k5g1nqJXR5G3Rgg3yHJrkwAEmHjQ
In-Reply-To: 
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Cc: 'ECRIT' 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

I disagree.

It's always better to send both the LbyR and an LbyV if you have them and
its possible that you are mobile.  If you are not mobile, it wastes bits and
bandwidth, but does no harm.

It avoids needing to dereference to route, and yet gives you the ability to
get location updates when you can get them.

The LbyV, if it's "fresh" is going to be as good as it gets for all the
routing decisions, because they happen fast.  Avoiding the dereference at
every routing step is a good thing.

If you mark the LbyV as used for routing, it's crystal clear what you are
doing: supplying an "I'm here now as best as anyone can tell" and a "check
this for more information later".  I really want that.

I think the answer to phonebcp is "send what you got, mark one
used-for-routing".  It's always right for emergency calls.

Brian

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, December 18, 2007 4:49 PM
> To: Matt Lepinski
> Cc: Richard Barnes; Brian Rosen; 'ECRIT'
> Subject: Re: [Ecrit] Re: Minor comment on phonebcp
> 
> Matt
> 
> in-line
> 
> At 02:26 PM 12/18/2007, Matt Lepinski wrote:
> >James,
> >
> >I agree that there may be cases where a device ends up with both
> >LbyV and LbyR and the LbyV is more useful/up-to-date than the LbyR.
> >
> >However, there is certainly a common use-case where a mobile device
> 
> how isn't mobile devices "a local network decision" (from my message
> below)?
> 
> BTW - what if LbyR is mandatory and the UA has a GPS with the most
> precise location information? Isn't this defeating the purpose of
> what you want (i.e., the most up-to-date and precise location
> information)?
> 
> >obtains an LbyV for use in call-routing and an LbyR which can be
> >used to obtain more update location information (within some window
> >of time). In this case where the LbyV is used for routing and the
> >LbyR is able to provide more up-to-date location as the target moves,
> 
> SIP Conveyance has the UA sending an UPDATE every time it moves, so
> this case isn't ignore.
> 
> >I think we agree that the endpoint should include both locations in
> >the SIP INVITE (marking the LbyV with the "used-for-routing" parameter).
> 
> no, I said I don't agree with this, and I gave a reason previously -
> which is a valid one (confusing situation for a Location Recipient)
> 
> 
> >Currently, it is unclear from the text that when a mobile device has
> >both LbyV and LbyR that it should often include both locations. It
> >would be nice if this were clarified.
> 
> I think sending both creates confusion more often than it won't,
> since there will likely be two different Sighters, with different
> measuring techniques
> 
> 
> >If there are important cases where a device has both LbyV and LbyR,
> >but should only include one or the other, then instead of "MUST
> >include both when both are available", we can instead use
> >"SHOULD"-strength text with an explanation of when sending both is
> >appropriate and when sending only one is appropriate.
> 
> The text currently says "MUST send Location", it doesn't say which,
> and it shouldn't in the protocol spec.  Local policy can always
> specify (or extend) which one to send or both, knowing Recipients
> know what to do if they receive two or more locations - but right
> now, we don't tell a Recipient what to do if receiving both types,
> nor do we state which is more trustworthy.  For example, in an
> IP-cellular environment, 3GPP is more appropriate to specify that the
> LbyR from a server is more trustworthy - than an IETF doc that
> shouldn't make that underlying network type distinction.
> 
> James
> 
> 
> >- Matt Lepinski
> >
> >James M. Polk wrote:
> >
> >>At 02:41 PM 12/17/2007, Richard Barnes wrote:
> >>
> >>>Right.  That's what we mean, but not what the document says.  How
> >>>about if we change it to "... it MUST include location by-value or
> >>>by-reference, or in both forms if both are available."
> >>
> >>
> >>well, I disagree here
> >>
> >>for one, since including *both* could be pointing to TWO
> >>(different) locations
> >>
> >>Let's not instantly create a situation of confusion by all Location
> >>Recipients by making it have to decide which location is better, ok?
> >>
> >>Deciding that LbyR is more up-to-date than LbyV is a function of a
> >>local network, not for an international standard to decide.
> >>
> >>The text, as written, makes providing either (LbyR or LbyV)
> >>location mandatory, and leaves which to those local policies and
> >>configurations - where they belong.
> >>
> >>
> >>>--Richard
> >>>
> >>>
> >>>
> >>>Brian Rosen wrote:
> >>>
> >>>>If you have both, send both.  If you have one, send what you have.
> >>>>Brian
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Richard Barnes [mailto:rbarnes@bbn.com]
> >>>>>Sent: Monday, December 17, 2007 3:30 PM
> >>>>>To: ECRIT; Brian Rosen
> >>>>>Subject: Minor comment on phonebcp
> >>>>>
> >>>>>In draft-ietf-ecrit-phonebcp-03, requirement ED-60 says (among other
> >>>>>things)
> >>>>>
> >>>>>"
> >>>>>     9.   If a device understands the SIP location conveyance
> >>>>>          [I-D.ietf-sip-location-conveyance] extension and has its
> >>>>>          location available, it MUST include location either by-
> value or
> >>>>>          by-reference.
> >>>>>"
> >>>>>
> >>>>>It seems like this requirement should be stronger.  In particular, if
> an
> >>>>>endpoint has an LbyR, it's likely to point to a more timely location
> >>>>>than an LbyV that it has (ignoring Henning's classification of LbyR
> for
> >>>>>the moment).  Should it be MUST include LbyR if you have it?
> >>>>>
> >>>>>--Richard
> >>>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>Ecrit@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/ecrit
> >>
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>Ecrit@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 28 17:19:01 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J8NXX-0006Ej-1P; Fri, 28 Dec 2007 17:18:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J8NXW-0006Ed-1A
	for ecrit@ietf.org; Fri, 28 Dec 2007 17:18:50 -0500
Received: from jalapeno.cc.columbia.edu ([128.59.29.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8NXU-0000N3-6X
	for ecrit@ietf.org; Fri, 28 Dec 2007 17:18:50 -0500
Received: from dhcp-10-52-6-37.rhod.uc.edu (dynamic-187-251.natpool.uc.edu
	[129.137.187.251]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id
	lBSMIkRf013414
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Fri, 28 Dec 2007 17:18:47 -0500 (EST)
Message-Id: <35AE6994-68D9-45B8-AD8C-0AD920914572@cs.columbia.edu>
From: Henning Schulzrinne 
To: "Rosen, Brian" 
In-Reply-To: <31D151A3D66E404AACBBB0247ACA54A78BDE17@STNTEXCH11.cis.neustar.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 28 Dec 2007 17:18:46 -0500
References: <31D151A3D66E404AACBBB0247ACA54A78BDE17@STNTEXCH11.cis.neustar.com>
X-Mailer: Apple Mail (2.915)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Cc: ECRIT 
Subject: [Ecrit] Re: Henning's comments on -phonebcp
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

Trying to catch up with ECRIT mail... Any comments refer to -02.

On Nov 19, 2007, at 9:48 AM, Rosen, Brian wrote:

>
> 1. Henning and one or two other commenter's don't like my coarse
> location (<1KM).  First of all, there is no real source for the 1  
> KM.  I
> made it up.  What you want is something with a high enough accuracy  
> that
> the call will usually route to the right PSAP when you are near a
> boundary.  It will never be 100% accurate.  I needed to supply some
> useful advice.  I picked a number.  I have modified this text slightly
> (typically <1km except when hiding location).
>

I realize that one has to pick something, so a motivation indicating  
that this is arbitrary and simply is meant to likely result in the  
correct PSAP should be sufficient.

Somebody may also object to the use of your term "accuracy" :-)

> 2. On ED-27, about the frequency of refresh, Henning asked for text
> discussing that civic location may be an indication that the device is
> not mobile.   Devices can be mobile and report civic.  WiFi devices
> reporting the location of an AP may very well report civic.  I did not
> change the text.

I think this indicates a broader terminology confusion that we run  
into occasionally. We have two classes of devices:

(1) The measured location changes when the device moves.

(2) It doesn't change.

After all, even many corded (and, even more so, DECT-style cordless)  
phones are "mobile" in the sense that they can move. DECT-style  
cordless phones can easily move beyond the typical range of an 802.11  
device, with the Panasonic Gigarange devices promising mobility all  
the way across the farm. Radio Shack used to sell spools of 100' phone  
cords... About the only non-mobile phones are the ones truly nailed to  
a wall.

But we generally distinguish between such devices and truly mobile  
devices, such as cell phones.

Thus, maybe the term "mobile" isn't sufficiently precise, at least not  
without further qualification.

>
>
> 3. Henning raised some questions about default location.  I changed  
> the
> text to refer to -framework which does discuss this.  Generally, it's
> "best you can do" and -framework uses the example of the location of a
> CMTS in a cable modem system.  I'd welcome suggestions to improve  
> this;
> it's an important area.

I think this is about as close as we can make it without going through  
every network architecture. Since this is likely to be common, adding  
WiFi access point and cellular base station may be useful.

The wording "subscriber to any unit less" seems awkward, however. I  
assume you mean "accuracy" or "resolution"?

However, I'm not sure what you mean by "appropriate" in

Default locations MUST be marked with method=Default and
    an appropriate provided-by in the PIDF-LO.

I'm guessing that this should say "whoever provided the default  
location", but it might not hurt to be explicit here.

>
>
> 4. Notwithstanding Hannes' questioning of un-initialized device text,
> Henning raised the issue at ED-44 of how an un-initialized device
> determines if local regulation requires support of emergency  
> calling.  I
> think this is a good question.  I suspect we need something returned
> from LoST that tells it.  Discussion on this point is welcome.

This goes back to our 'un-initialized' discussion in Vancouver. I  
think we agreed that this has many more facets and is beyond our  
current ability to compress into a paragraph or two.

>
>
>
> 6.  Henning added the comment "dubious" to the text "User agents and
> proxies MUST Support Session Timer [RFC4028] to guard against session
> corruption."
> I do think we should have it.  Henning, what is the "dubious" part.  I
> can downgrade "guard against" to something milder if you are pointing
> out that session timers won't reliably determine session  
> corruption.  I
> can change corruption to some other term.
>

Session corruption isn't defined, so I'm not quite sure what threat  
you are protecting against. The only threat I know of that session  
timer addresses is that a phone will stay off-hook forever. That's not  
really a problem in our case, where the PSAP can terminate a call at  
any time. In my personal opinion, 4028 adds significant complexity  
without concomitant benefits; as far as I know, it has seen only very  
modest deployment. Requiring it requires significant changes in SIP  
libraries, so we shouldn't do this lightly.

> 7. I'd ask Henning to expand on the "confusing" comment on ED-64 and  
> the
> "don't understand" comment on ED-68.  On the latter, the prior
> requirement is disabling of features on call backs.  ED-68 is how you
> determine a call back, which I propose is simply a call from the same
> domain as the PSAP that answered the original emergency call.

I just find the wording hard to follow. Plus, the SHOULD seems  
inappropriate here - no guidance is given to the implementor how to  
handle this rather special case and when to ignore the advice.

I think you're trying to handle the case when a PSAP calls while the  
caller is in another emergency call. After all, the caller has no way  
to distinguish whether call signaling was lost or not. Also, "same  
domain" comparisons are underspecified. Do you mean that the whole  
domain has to be the same? The one in the From header? The Contact  
header?

Also, if not done carefully, this has significant denial-of-service  
opportunities if somebody manages to fake the relevant header field.

This requires further discussion, probably as a separate thread.

Also, for ED-63, I don't know what "when answered" means. I'm guessing  
that this means that

The device should alert the user and re-connect the user to the same  
URL when the user picks up.

>
>
> 8.  I'd also like a little more information on the "check spec"  
> comment
> on ED-76.  Which spec am I checking for what?

This was a note to myself...

The problem is that the service URN draft does not have a ;test  
parameter. Indeed, it doesn't have any semicolon-parameters at all.  
Thus, the mechanism proposed does not work.

There are two alternatives that come to mind immediately:

- Define a 'test' request URI parameter that's valid for all SIP  
request URIs. This presumably requires a new draft.

- Define a sub-service for each service, as in

urn:service:sos.police.test

This has the advantage that LoST can easily return a special URL just  
for testing, to keep test calls out of the PSAP. The default behavior  
for LoST would return the URL for urn:service:sos.police if there's no  
separate test URL.

A third alternative is to define such a parameter for the service URN.  
Given the AUTH48 state of the document, this might require an  
emergency brake.

>
>
>
> Brian
> 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

From ecrit-bounces@ietf.org Fri Dec 28 21:31:52 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J8RUK-0001hD-Ef; Fri, 28 Dec 2007 21:31:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J8RUJ-0001h5-Lf
	for ecrit@ietf.org; Fri, 28 Dec 2007 21:31:47 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8RUH-0005Be-VS
	for ecrit@ietf.org; Fri, 28 Dec 2007 21:31:47 -0500
X-SEF-Processed: 5_0_0_910__2007_12_28_20_43_05
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Fri, 28 Dec 2007 20:43:05 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 20:31:41 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ecrit] Re: Henning's comments on -phonebcp
Date: Fri, 28 Dec 2007 20:31:38 -0600
Message-ID: 
In-Reply-To: <35AE6994-68D9-45B8-AD8C-0AD920914572@cs.columbia.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Re: Henning's comments on -phonebcp
Thread-Index: AchJn6nxRzHX2fymR3uTJkrKWDjJgAAIiqMg
References: <31D151A3D66E404AACBBB0247ACA54A78BDE17@STNTEXCH11.cis.neustar.com>
	<35AE6994-68D9-45B8-AD8C-0AD920914572@cs.columbia.edu>
From: "Winterbottom, James" 
To: "Henning Schulzrinne" ,
	"Rosen, Brian" 
X-OriginalArrivalTime: 29 Dec 2007 02:31:41.0482 (UTC)
	FILETIME=[F22170A0:01C849C2]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: ECRIT 
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ecrit-bounces@ietf.org

A few comments inline.=0D=0A=0D=0A=0D=0A> >=0D=0A> > 1. Henning and one or =
two other commenter's don't like my coarse=0D=0A> > location (<1KM).  First=
 of all, there is no real source for the 1=0D=0A> > KM.  I=0D=0A> > made it=
 up.  What you want is something with a high enough accuracy=0D=0A> > that=0D=
=0A> > the call will usually route to the right PSAP when you are near a=0D=
=0A> > boundary.  It will never be 100% accurate.  I needed to supply some=0D=
=0A> > useful advice.  I picked a number.  I have modified this text=0D=0As=
lightly=0D=0A> > (typically <1km except when hiding location).=0D=0A> >=0D=0A=
>=20=0D=0A=0D=0A[AJW] This actually misses the point. The point is that loc=
ation used=0D=0Afor determining a route to a local PSAP MUST be sufficientl=
y precise to=0D=0Aminimize/eliminate call misrouting. This has nothing to d=
o with location=0D=0Ahiding, it is to do with route determination. In many =
cases, Australia=0D=0Ais just one, indication of country is sufficiently go=
od for routing.=0D=0A=0D=0A=0D=0A=0D=0A> >=0D=0A> > 3. Henning raised some =
questions about default location.  I changed=0D=0A> > the=0D=0A> > text to =
refer to -framework which does discuss this.  Generally,=0D=0Ait's=0D=0A> >=
 "best you can do" and -framework uses the example of the location of=0D=0A=
a=0D=0A> > CMTS in a cable modem system.  I'd welcome suggestions to improv=
e=0D=0A> > this;=0D=0A> > it's an important area.=0D=0A>=20=0D=0A> I think =
this is about as close as we can make it without going through=0D=0A> every=
 network architecture. Since this is likely to be common, adding=0D=0A> WiF=
i access point and cellular base station may be useful.=0D=0A>=20=0D=0A> Th=
e wording "subscriber to any unit less" seems awkward, however. I=0D=0A> as=
sume you mean "accuracy" or "resolution"=3F=0D=0A>=20=0D=0A> However, I'm n=
ot sure what you mean by "appropriate" in=0D=0A>=20=0D=0A> Default location=
s MUST be marked with method=3DDefault and=0D=0A>     an appropriate provid=
ed-by in the PIDF-LO.=0D=0A>=20=0D=0A=0D=0A[AJW] There is no such thing as =
default method, at least at the moment.=0D=0AValues for method need to be d=
efined in the IANA registry. If you want=0D=0Ato register a value of defaul=
t, I would request that you clearly=0D=0Aindicate what it means, because it=
 isn't at all clear to me what it=0D=0Ameans.=0D=0A=0D=0A=0D=0A> I'm guessi=
ng that this should say "whoever provided the default=0D=0A> location", but=
 it might not hurt to be explicit here.=0D=0A>=20=0D=0A> >=0D=0A> >=0D=0A> =
> 4. Notwithstanding Hannes' questioning of un-initialized device=0D=0Atext=
,=0D=0A> > Henning raised the issue at ED-44 of how an un-initialized devic=
e=0D=0A> > determines if local regulation requires support of emergency=0D=0A=
> > calling.  I=0D=0A> > think this is a good question.  I suspect we need =
something returned=0D=0A> > from LoST that tells it.  Discussion on this po=
int is welcome.=0D=0A>=20=0D=0A> This goes back to our 'un-initialized' dis=
cussion in Vancouver. I=0D=0A> think we agreed that this has many more face=
ts and is beyond our=0D=0A> current ability to compress into a paragraph or=
 two.=0D=0A>=0D=0A=0D=0A[AJW] I totally agree with Henning on this point.=0D=
=0A=0D=0A=20=0D=0A=0D=0A---------------------------------------------------=
---------------------------------------------=0D=0AThis message is for the =
designated recipient only and may=0D=0Acontain privileged, proprietary, or =
otherwise private information. =20=0D=0AIf you have received it in error, p=
lease notify the sender=0D=0Aimmediately and delete the original.  Any unau=
thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------=
-------------------------------------------------------------------------=0D=
=0A[mf2]=0D=0A

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit