Subject: RE: [sipping] comment on draft-polk-sipping-location-requirements -01.txt

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Dec 2003 10:11:28 -0500

Tom

There is a considerable amount of pressure by those who are
concerned about privacy to keep location information under
very tight control.  One attempt to deal with location in the
IETF went down in flames, and the present one has 90% of
its efforts directed to privacy and 10% to location.

This is a reality we have to deal with, or we aren't going
to get anything through the process.

On emergency calls, we have achieved of late, compromises,
which in my opinion are very reasonable, which will allow
us to make emergency calls work well.  These compromises
deal directly with the issue of making location available
to routing entities.  The protection for location information
will be hop-by-hop, precisely so that routing based on location
can be done.

See this thread:
http://www1.ietf.org/mail-archive/working-groups/geopriv/current/msg00138.ht
ml

Brian

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Friday, December 12, 2003 9:50 AM
> To: Rosen, Brian
> Cc: 'PROUVOST Sébastien FTRD/DAC/ISS'; [email-masked];
> [email-masked]
> Subject: Re: [sipping] comment on
> draft-polk-sipping-location-requirements -01.txt
> 
> 
> I still maintain that location is no more sensitive in terms 
> of privacy 
> requirements than the rest of call signalling.
> 
> As a separate issue, I also still maintain that even if a 
> proxy does not 
> insert location, it must stiull be able to read it in order 
> to route an 
> emergency call correctly.  I've been considering when to reraise this 
> issue, but Sébastien has created the occasion.
> 
> Rosen, Brian wrote:
> > I think that the issue is one of privacy control.  If some
> > intermediary puts your location on the message without your
> > consent, there is a significant breach of privacy.
> > 
> > The emergency case is somewhat different, and we are looking
> > into how best to accommodate it.  In general, our approach
> > is to get the UA to know its location and report it with
> > the call.  We understand the issue of authentication of
> > location, and will need to assure that the location is accurate
> > when a carrier knows what it is.   If the location is
> > provided to the UA, and it chooses to NOT send it, I believe
> > he should be allowed to do so.  There are several ways the UA
> > could learn its location from some other entity.  One of them
> > is DHCP (for a non-mobile UA). 
> > 
> > Do you see any problem with that approach?
> > 
> > Brian
> > 
> > 
> >>-----Original Message-----
> >>From: PROUVOST Sébastien FTRD/DAC/ISS
> >>[mailto:[email-masked]]
> >>Sent: Monday, December 08, 2003 10:10 AM
> >>To: [email-masked]; [email-masked]
> >>Cc: [email-masked]
> >>Subject: [sipping] comment on
> >>draft-polk-sipping-location-requirements-01.txt
> >>
> >>
> >>Hi,
> >>
> >>I fully support the idea of having location information 
> >>conveyed in SIP.
> >>
> >>However, I fail to see in the draft a requirement for a proxy 
> >>to be able to insert the location object on behalf of the UA. 
> >>It is likely that in some cases terminals may not have this 
> >>information. In some architectures, an outbound proxy may be 
> >>able to retrieve this information (eg. Through a MIDCOM or 
> >>COPS interface with an entity in the transport plane) and it 
> >>is useful to allow such an outbound proxy to insert this 
> >>location object.  
> >>
> >>As stated in requirement E-3 regarding emergency calls, it 
> >>may be a regulatory obligation for an operator to make this 
> >>location information available to certain users. Operators 
> >>may therefore be mandated to have this information inserted 
> >>by proxies if the terminal does not insert it.
> >>
> >>Regards,
> >>
> >>Sébastien Prouvost
> >>France Télécom R&D/DAC/CAR
> >>http://www.francetelecom.com/rd
> >>
> >>
> >>_______________________________________________
> >>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >>This list is for NEW development of the application of SIP
> >>Use [email-masked] for questions on current sip
> >>Use [email-masked] for new developments of core SIP
> >>
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Tue, 16 Dec 2003 08:34:59 EST

> to get anything through the process.

Unfortunately, I don't believe that the previous attempt (or the present one 
in GEOPRIV) is concerned with "the reality" of the situation. It continues to 
believe that it will somehow be forever exempt from government regulations, so 
it can ignore "reality".

The truth is, today I can not make a 911 call in the US and expect to keep my 
location private (from the service provider or the emergency service 
provider). In fact, recent regulations are closing the gap where exact locatoin was 
not being provided due to technical limitations, such as for cellular and PBXs.

Yes, one needs to be concerned with privacy, but the requirements of 
emergency calling (e.g., 911) override this pricavy because of government 
requirements. (I know, many in this effort want to ignore govenments, but they still 
exist, and probablu will for some time.) If the UA doesn't know it's location and 
report it, then an entity that claims to provide telephone service must provide 
that location information.

Now that I've inflamed this discssuion more with the truth ...

Mike

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 16 Dec 2003 10:17:05 -0500

What you claim may be true, or it may be an exaggeration.
Regardless, does the idea that a phone knows its location
and reports it on an emergency call meet what you see
as the requirements for emergency calls?

The current proposal is that TLS is used on an emergency
call.  The geopriv guys want this to protect location (privacy).
The emergency guys would like authentication.  TLS would
provide both.  The emergency center is highly likely to
accept a call that didn't have location and/or was not
protected by TLS.  They might, as a follow up, go looking
for the reason why it didn't.  

If I were designing a UA or a proxy server that was handling
emergency calls, I would implement what I needed to
get location, and I would implement TLS.  I wouldn't fail
if I didn't get location, and I'd probably retry an emergency
call with sip: if the sips: call failed.

Would that be reasonable?

Brian
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 16, 2003 8:35 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sipping] comment on draft-polk-sipping-location-requirements
-01.txt

Unfortunately, I don't believe that the previous attempt (or the present one
in GEOPRIV) is concerned with "the reality" of the situation. It continues
to believe that it will somehow be forever exempt from government
regulations, so it can ignore "reality". 

The truth is, today I can not make a 911 call in the US and expect to keep
my location private (from the service provider or the emergency service
provider). In fact, recent regulations are closing the gap where exact
locatoin was not being provided due to technical limitations, such as for
cellular and PBXs. 

Yes, one needs to be concerned with privacy, but the requirements of
emergency calling (e.g., 911) override this pricavy because of government
requirements. (I know, many in this effort want to ignore govenments, but
they still exist, and probablu will for some time.) If the UA doesn't know
it's location and report it, then an entity that claims to provide telephone
service must provide that location information. 

Mike

---

From: [email-masked]
Date: Thu, 18 Dec 2003 09:02:26 -0000

I think Jonathon has summed up the needs for emergency calling. The proxy must be allowed to add to the SIP-device's location information. Then let the operator make the decision about accuracy.

Dick

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 17 December 2003 05:43
To: Henning Schulzrinne
Cc: Rosen, Brian; Knight,RR,Dick,XJG4 KNIGHTRR R;
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [sipping] comment on
draft-polk-sipping-location-requirements -01.txt

inline.

Henning Schulzrinne wrote:

> To avoid further repeating discussions: We do need to design things so 
> that a proxy can, in real-time, provide the 911-calling UA with its 
> estimate of the location, in particular if the INVITE does not contain 
> this location. This does not necessarily imply that the proxy has to 
> insert the location into request; it could, for example, return it as 
> part of a redirect response.
> 
> This mechanism allows the UA to (theoretically) inspect the location, 
> thus increasing user control over his or her information.

In the case of 911, though, does this matter? Calling 911 does imply 
that you have waived your right to privacy. Furthermore, I doubt that, 
while in the process of having a heart attack and having managed to 
dial 911, I will really want to inspect the location information 
provided by my proxy. A 911 call is exactly the kind of case where you 
dont want user interaction for the call to proceed.

> 
> However, it is unclear to me why such control does not treat me as 
> mature enough to provide explicit consent - "please insert location 
> object". (The UI issues of obtaining consent are similar whether the 
> location object is reflected or included.)
> 
> This model comes at a cost, namely requiring UA upgrades and additional 
> round-trip times over a potentially slow air interface. (If the location 
> object is signed by the proxy, it can be quite large, so the additional 
> delay could reach a second or two.)
> 
> This same cost makes it unrealistic to assume that the proxy or some 
> other entity will continuously update the mobile with its location. The 
> 911 location requirements would require updates at least every second if 
> the mobile is moving at highway speeds.
> 
> A secondary disadvantage is that the prankster can remove the location 
> information; more relevantly, a proxy probably has to somehow 
> distinguish that it tried to redirect with location information, but got 
> the same call back later, still without location information (since the 
> UA was buggy or old) and then has to forward the INVITE, without 
> location information.

You have quoted several disadvantages to the redirect model, but no 
advantages over the proxy-inserted model. I really don't see what is 
lost, but see that a lot can potentially be gained. Indeed, I see no 
problem with having the proxy insert location inforamtion in addition 
to that provided by the device. This would allow the emergency call 
center, in many cases, to get verification of accuracy of the address 
when the device has more accurate data than the network; they would 
see that the network indicated a location of "New Jersey", and the 
handset indicated a location of "600 Lanidex Plaza, Parsippany, NJ", 
giving some confidence that the handset-provided location is not 
falsified. Havign vastly different addresses would also send a signal 
to the emergency operator that they really need to verify the address.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: [email-masked]
Date: Thu, 18 Dec 2003 15:46:57 EST

In a message dated 12/18/2003 3:05:36 PM Eastern Standard Time, 
[email-masked] writes:

> It doesn't say you can't provide more than one type of measurement, does it?
> 
> What liability would a carrier assume if the handset using GPS provided a 
> location to 10 meters, and that got over-ridden by a carrier network using 
> TOA providing an accuracy of 100 meters, and the ambulance arrives too late?
> 

More than one type of location is not the problem. I believe all the past 
discussion was that the "handset" and the "carrier" came up with conflicting 
information. If they were not conflicting, then why have two. If they are 
conflicting, that is a problem. If the handset gives a physical location to 10 meters, 
why would the carrier network bother to include a value of 100 meters 
accuracy, if the value from the end user were within that 100 meters? If it isn't, 
what should the PSAP do, send an ambulance to both?

If the handset gave a value within 10 meters and the carrier overwrote it 
with a value accurate to only 100 meters, there would be serious liability 
issues, especially if the requirement were for an accuracy of 50 feet.

Like I said, NENA (or some such organization) needs to say what the 
requirements are (in the US). It is silly and hopeless for the IETF to try to agree on 
"requirements".

Mike

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 18 Dec 2003 16:48:11 -0500

And NENA is working on such requirements, and is starting to engage other 
organizations in other parts of the world.  It has not been decided whether 
there will be multiple, possibly conflicting requirements sent in from 
different organizations, or whether an effort will be mounted to negotiate 
a single set of requirements.  I favor the latter, because we don't have 
the expertise in the IETF to deal with conflicts if they were to arise.  

I'd ask that anyone who knows people who should be involved (NENA 
equivalents in other parts of the world), please contact me. 

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 18, 2003 3:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sipping] comment on draft-polk-sipping-location-requirements
-01.txt

More than one type of location is not the problem. I believe all the past
discussion was that the "handset" and the "carrier" came up with conflicting
information. If they were not conflicting, then why have two. If they are
conflicting, that is a problem. If the handset gives a physical location to
10 meters, why would the carrier network bother to include a value of 100
meters accuracy, if the value from the end user were within that 100 meters?
If it isn't, what should the PSAP do, send an ambulance to both? 

Like I said, NENA (or some such organization) needs to say what the
requirements are (in the US). It is silly and hopeless for the IETF to try
to agree on "requirements". 

Mike

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 19 Dec 2003 16:59:55 -0000

At least as far as 3GPP is concerned, the proposal is more likely to work the other way round.

For SIP calls, the phone will be able to provide an indication of which cell location the phone is currently in.

The network will have access to the GMLC which will be able to provide a more accurate location. 

In some locations the cell location may be sufficient to determine which emergency centre to route to. If this is insufficient some intermediate entity will have the capability of contacting the GMLC for a more accurate set of location information, on which it can base the routeing decision to find the emergency centre. As the cell location is sent entirely independently from the GMLC provided information, then I assume the emergency centre would have access to both sets of information - programmes already exist for converting cell location into geographic information.

I believe the emergency centre also has the option of either believing the information sent with the call, or it can also contact the GMLC for the current location information.

Of course there is always the possibility that someone has built GPS into the phone and that it is able to insert something more accurate than the GMLC can provide into the SIP message. I believe that for 3GPP environments, it is understood that the GMLC will provide sufficiently accurate information to route to the emergency centre. Therefore any decisions on comparative accuracy and authenticity of information will be an issue for the emergency centre alone, assuming we send all aavailable information to the emergency centre.

I also gather that different methods of location determination have different accuracies depending on the quality of the implementation, and on the environment where the user currently is, so this may not be a simple excercise.

This does of course mean that we need to provide the option of carrying multiple sets of information, and also providing some indication of where the information came from.

regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 18 December 2003 20:47
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sipping] comment on draft-polk-sipping-location-requirements -01.txt

In a message dated 12/18/2003 3:05:36 PM Eastern Standard Time, [email-masked] writes: 

More than one type of location is not the problem. I believe all the past discussion was that the "handset" and the "carrier" came up with conflicting information. If they were not conflicting, then why have two. If they are conflicting, that is a problem. If the handset gives a physical location to 10 meters, why would the carrier network bother to include a value of 100 meters accuracy, if the value from the end user were within that 100 meters? If it isn't, what should the PSAP do, send an ambulance to both? 

If the handset gave a value within 10 meters and the carrier overwrote it with a value accurate to only 100 meters, there would be serious liability issues, especially if the requirement were for an accuracy of 50 feet. 

Like I said, NENA (or some such organization) needs to say what the requirements are (in the US). It is silly and hopeless for the IETF to try to agree on "requirements". 

Mike