Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00

From: James Winterbottom <[email-masked]>
Date: Tue, 2 Aug 2016 06:55:20 +1000

Thanks Gunnar,

I very much support the concern of once it is implemented it is here to stay and that once the Geo URI is used for this application the flood gates will open for everything else.

The draft talks heavily about the North American situation, and even the authors' comments seem to suggest that North America is the focus of the solution. I wonder if, rather than risking the above, whether this specification might not better fit into NENA or ATIS or has that path already been considered?

Cheers
James

> On 1 Aug 2016, at 4:43 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> Den 2016-07-26 kl. 23:32, skrev Paul Kyzivat:
>> On 7/26/16 5:07 PM, James Winterbottom wrote: 
>>> Thanks Henning and Paul, 
>>> 
>>> The argument still feels a bit like “we don’t have anything today, HELD 
>>> is too heavy weight, give us encoded location in the header”. I guess my 
>>> worry with this is two fold: 
>>> 1) providing this means there is never an incentive to move towards a 
>>> more standardised location approach, I will cite the eCall MSD is a good 
>>> example of where this has occurred. 
>>> 2) It gives the first push down the very long slide of “geo URIs are 
>>> fine for conveying target location”. 
>> 
>> I think the incentive to move will be NG911. 
>> 
>> Also, this is a small community that operates under rules set by the FCC. 
>> 
>>> My strongest preference would be to find someway for this to provide a 
>>> serious stepping-stone towards NG formats and protocols, rather than 
>>> providing a mechanism that once implemented gives no incentive to move 
>>> mainstream. 
>> 
>> Just including location is a big step. And currently the VRS providers handle their 911 calls via separate providers, using static location information. Working through moving to dynamic location information will also be a step. 
>> 
>>     Thanks, 
>>     Paul 
>> 
>>> It would be good to hear if anyone else on the list has similar concerns. 
> GH: I see this as a step towards eternal interoperability problems and finally requirements for geo: location acceptance in the NGxxx services. 
> 
> Some reasons:
> 
> When the services get direct interface with NG9-1-1, they will be required to deliver location according to RFC 6442. Then it will be tempting to force the terminals to do so from the source. But then the terminals may need to  deliver GEO: to some vrs services and PIDF-LO in other calls, depending on at what step the services are in adaptation to NG9-1-1. 
> 
> Further delaying proper multipart body handling in UEs and servers is not good. More and more RFCs are appearing that require multipart body handling. Support of RUE:s could instead be a good incentive to get multipart body support implemented.
> 
> In the introduction, it is stated: 
> "
>    This RUE profile supports the requirements of relay services in the
>    United States, as described in 47 CFR 64.601 et seq., but may be
>    applicable to similar uses elsewhere."
> 
>  "
> This limitation to USA should be stated in the scope as well. There are many US-specific aspects in the draft that need to be modified before applied elsewhere. The MUST for use of GEO:  is likely one of them. If not, the conflict between use of geo: and rfc 6442 compliant location will spread.
> 
> What is the goal for the draft? Does it have ambitions to be dispatched and accepted as a WG document? 
> 
> Regards
> Gunnar
> 
>>> 
>>> Cheers 
>>> James 
>>> 
>>> 
>>>> On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne 
>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>> 
>>>> [Typing this from the Athen's airport] 
>>>> 
>>>> Adding to this: 
>>>> 
>>>> In this particular use case, there is indeed a "device location" - the 
>>>> only location reported is what the handset (Android/IOS) device 
>>>> believes the location is - and this better be the location of the 
>>>> device, not something else. Anything else would be a bug or malicious 
>>>> location spoofing. There is no HELD or other external reference involved. 
>>>> 
>>>> Given that the privacy indicators convey no information in this case 
>>>> (and thus would have to be hard-coded to the no-restrictions values to 
>>>> avoid emergency call failures), I fail to see the substantive, as 
>>>> opposed to protocol-lawyering, difference. The information is going to 
>>>> be exactly the same, whether I do this by cdata PIDF-LO attachment 
>>>> "legally" or by geo URL "illegally". 
>>>> 
>>>> Also, the VRS 911 situation is somewhat unique in that there are three 
>>>> entities involved in the call: the VRS provider and its communication 
>>>> assistant (the person translating between voice and ASL), a 
>>>> third-party emergency service provider and the PSAP with related 
>>>> system service providers. Until native NG911/i3 is common, the most 
>>>> likely case is that the VRS provider will pick apart the SIP request 
>>>> and inject the location via a proprietary API. 
>>>> 
>>>> All three entities have their own data retention and disclosure rules, 
>>>> which may vary by state, and are likely unknown upstream. 
>>>> 
>>>> Given the absence of HELD in this environment, at least for the 
>>>> foreseeable future, insisting on carrying the same information in an 
>>>> XML attachment instead of a header, means that the emergency calls 
>>>> need a completely different code path since they are the only ones 
>>>> with multi-part. This is seen as a really bad trade-off of reliability 
>>>> and simplicity vs. formal requirements that serve no obvious privacy 
>>>> or functionality purpose. 
>>>> 
>>>> If there's a technical argument, rather than a legalistic one, please 
>>>> explain in more detail, as I'm obviously missing it. 
>>>> 
>>>> I assume you mean "illegal" figuratively, as I might need to get a 
>>>> protocol lawyer otherwise :-) 
>>>> 
>>>> 
>>>> Henning 
>>>> 
>>>> ------------------------------------------------------------------------ 
>>>> *From:* dispatch <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> on behalf of Paul Kyzivat 
>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>> *Sent:* Tuesday, July 26, 2016 11:20:08 AM 
>>>> *To:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>> *Subject:* Re: [dispatch] Strong concerns with location encoding in 
>>>> draft-vrs-rue-dispatch-00 
>>>> 
>>>> James, 
>>>> 
>>>> Henning is traveling, so we may not hear from him for a bit. 
>>>> 
>>>> Using geo: was not my first choice, precisely because it isn't included 
>>>> among the permissible ways of conveying the information. But it is a 
>>>> hard sell among the VRS community. For this use the alternative would be 
>>>> putting the location in the body, which is felt to be complex. 
>>>> 
>>>> Note that the context for this usage is only 911 calls. I got the 
>>>> following private comment from Henning: 
>>>> 
>>>> > Privacy indicators in US 911 SIP requests are both meaningless and 
>>>> > possibly disruptive. Since US VRS and 911 retention and disclosure 
>>>> > policies are given by law and custom and not subject to user control, 
>>>> > there are only two options: 
>>>> > 
>>>> > (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing 
>>>> > that's happening, but reality is something else. 
>>>> > 
>>>> > (2) Reject the 911 call, since the VRS provider and 911 provider cannot 
>>>> > and will not honor the requested privacy policy. Clearly not acceptable. 
>>>> 
>>>> (I'm not personally familiar with the US regulations - I trust Henning 
>>>> on this.) 
>>>> 
>>>> The current situation is that VRS users *are* using mobile devices for 
>>>> 911 calls, and the location initially communicated for those calls is 
>>>> currently *static*. The actual location must be provided within the call 
>>>> by the deaf caller, using ASL. We are trying to improve on that. 
>>>> 
>>>>         Thanks, 
>>>>         Paul 
>>>> 
>>>> On 7/25/16 4:51 AM, James Winterbottom wrote: 
>>>> > Hi Paul and Henning, 
>>>> > 
>>>> > I was reading through your draft but had to have a double take in 
>>>> > Section 11.4, it says the following: 
>>>> > 
>>>> > " 
>>>> >> location information MUST be conveyed with a "geo:" URI in a 
>>>> >>       Geolocation header field, as defined in [RFC5870 <https://tools.ietf.org/html/rfc5870> <https://tools.ietf.org/html/rfc5870>]. 
>>>> >> 
>>>> >>       (While section 4.1 of [RFC6442] <https://tools.ietf.org/html/rfc6442#section-4.1> <https://tools.ietf.org/html/rfc6442#section-4.1> prohibits this usage, 
>>>> the reasons 
>>>> >>       for doing so do not apply to emergency calls.) 
>>>> > “ 
>>>> > 
>>>> > The problem here that this is an illegal used of the encoding in RFC 
>>>> > 5870. The reason is that the way it is being used directly identifies as 
>>>> > device or user and so it falls subject to the requirements of a Geopriv 
>>>> > using protocol. From section 9.2 of RFC 5870: 
>>>> > " 
>>>> >> A 'geo' URI by itself is just an opaque reference to a physical 
>>>> >>    location, expressed by a set of spatial coordinates.  This does not 
>>>> >>    fit the "Location Information" definition according to Section 5.2 <https://tools.ietf.org/html/rfc5870#section-5.2> <https://tools.ietf.org/html/rfc5870#section-5.2> of 
>>>> >>    GEOPRIV Requirements [RFC3693 <https://tools.ietf.org/html/rfc3693> <https://tools.ietf.org/html/rfc3693>], because there is not necessarily a 
>>>> >>    "Device" involved. 
>>>> >> 
>>>> >>    Because there is also no way to specify the identity of a "Target" 
>>>> >>    within the confines of a 'geo' URI, it also does not fit the 
>>>> >>    specification of a "Location Object" (Section 5.2 of RFC 3693 <https://tools.ietf.org/html/rfc3693#section-5.2> <https://tools.ietf.org/html/rfc3693#section-5.2>). 
>>>> >> 
>>>> >>    However, if a 'geo' URI is used in a context where it identifies the 
>>>> >>    location of a Target, it becomes part of a Location Object and is 
>>>> >>    therefore subject to GEOPRIV rules. 
>>>> >> 
>>>> >>    Therefore, when 'geo' URIs are put into such contexts, the privacy 
>>>> >>    requirements of RFC 3693 <https://tools.ietf.org/html/rfc3693> <https://tools.ietf.org/html/rfc3693> MUST be met. 
>>>> > “ 
>>>> > In order for encoding of location to proceed in this form for the VRS 
>>>> > application I think far better rationale needs to be provided and it 
>>>> > needs to be demonstrated why the use case falls outside of the 
>>>> > constraints imposed by RFC 3693. 
>>>> > 
>>>> > Cheers 
>>>> > James 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > _______________________________________________ 
>>>> > dispatch mailing list 
>>>> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>> > https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> 
>>>> > 
>>>> 
>>>> _______________________________________________ 
>>>> dispatch mailing list 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> 
>>>> 
>>>> _______________________________________________ 
>>>> dispatch mailing list 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> 
>>> 
>> 
>> _______________________________________________ 
>> dispatch mailing list 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> 
> 
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 1 Aug 2016 17:20:18 -0400

On 8/1/16 4:55 PM, James Winterbottom wrote:
> Thanks Gunnar,
>
> I very much support the concern of once it is implemented it is here to
> stay and that once the Geo URI is used for this application the flood
> gates will open for everything else.
>
> The draft talks heavily about the North American situation, and even the
> authors' comments seem to suggest that North America is the focus of the
> solution. I wonder if, rather than risking the above, whether this
> specification might not better fit into NENA or ATIS or has that path
> already been considered?

Thank you for the feedback. I will discuss this further with Henning and 
the principals who will have to implement it.

	Thanks,
	Paul

> Cheers
> James
>
>
>> On 1 Aug 2016, at 4:43 PM, Gunnar Hellström
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> Just including location is a big step. And currently the VRS
>>> providers handle their 911 calls via separate providers, using static
>>> location information. Working through moving to dynamic location
>>> information will also be a step.
>>>
>>>     Thanks,
>>>     Paul
>>>
>> GH: I see this as a step towards eternal interoperability problems and
>> finally requirements for geo: location acceptance in the NGxxx services.
>>
>> Some reasons:
>>
>> When the services get direct interface with NG9-1-1, they will be
>> required to deliver location according to RFC 6442. Then it will be
>> tempting to force the terminals to do so from the source. But then the
>> terminals may need to  deliver GEO: to some vrs services and PIDF-LO
>> in other calls, depending on at what step the services are in
>> adaptation to NG9-1-1.
>>
>> Further delaying proper multipart body handling in UEs and servers is
>> not good. More and more RFCs are appearing that require multipart body
>> handling. Support of RUE:s could instead be a good incentive to get
>> multipart body support implemented.
>>
>> This limitation to USA should be stated in the scope as well. There
>> are many US-specific aspects in the draft that need to be modified
>> before applied elsewhere. The MUST for use of GEO:  is likely one of
>> them. If not, the conflict between use of geo: and rfc 6442 compliant
>> location will spread.
>>
>> What is the goal for the draft? Does it have ambitions to be
>> dispatched and accepted as a WG document?
>>
>> Regards
>> Gunnar
>>
>>>>
>>>> Cheers
>>>> James
>>>>
>>>>
>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>> wrote:
>>>>>
>>>>> *From:* dispatch <[email-masked]
>>>>> <mailto:[email-masked]>> on behalf of Paul Kyzivat
>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>> *To:* [email-masked] <mailto:[email-masked]>
>>>>> >>       Geolocation header field, as defined in [RFC5870
>>>>> <https://tools.ietf.org/html/rfc5870>].
>>>>> >>
>>>>> >>       (While section 4.1 of [RFC6442]
>>>>> <https://tools.ietf.org/html/rfc6442#section-4.1> prohibits this
>>>>> usage,
>>>>> the reasons
>>>>> >>    fit the "Location Information" definition according to
>>>>> Section 5.2 <https://tools.ietf.org/html/rfc5870#section-5.2> of
>>>>> >>    GEOPRIV Requirements [RFC3693
>>>>> <https://tools.ietf.org/html/rfc3693>], because there is not
>>>>> necessarily a
>>>>> >>    "Device" involved.
>>>>> >>
>>>>> >>    specification of a "Location Object" (Section 5.2 of RFC 3693
>>>>> <https://tools.ietf.org/html/rfc3693#section-5.2>).
>>>>> >>
>>>>> >>    requirements of RFC 3693
>>>>> <https://tools.ietf.org/html/rfc3693> MUST be met.
>>>>> > “
>>>>> > https://www.ietf.org/mailman/listinfo/dispatch
>>>>> >
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>> --
>> [email-masked]
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 1 Aug 2016 17:23:10 -0400

> and accepted as a WG document?

Given the (intentionally) bounded scope of the document it isn't 
entirely clear to me what the right path is.

	Thanks,
	Paul

---

From: James Winterbottom <[email-masked]>
Date: Tue, 2 Aug 2016 07:34:07 +1000

Then I think an alternative to current use of the Geo URI is required for the concerns Gunnar and I have raised.

Cheers
James

Sent from my iPhone

> On 2 Aug 2016, at 7:23 am, Paul Kyzivat <[email-masked]> wrote:
> 
> Given the (intentionally) bounded scope of the document it isn't entirely clear to me what the right path is.
> 
>    Thanks,
>    Paul
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 1 Aug 2016 17:36:54 -0400

It may help to inform the providers that NG9-1-1 will require location in a
PIDF-LO and its being implemented fairly widely now so they only have a
short time before they have to deal with it anyway.

Brian

On Monday, August 1, 2016, James Winterbottom <
[email-masked]> wrote:

> > On 2 Aug 2016, at 7:23 am, Paul Kyzivat <[email-masked]
> <javascript:;>> wrote:
> >
> [email-masked] <javascript:;>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 1 Aug 2016 17:55:44 -0400

On 8/1/16 5:36 PM, Brian Rosen wrote:
> It may help to inform the providers that NG9-1-1 will require location
> in a PIDF-LO and its being implemented fairly widely now so they only
> have a short time before they have to deal with it anyway.

I already informed them. I had first proposed using PIDF-LO, but was a 
minority of one. There was *strong* desire (from providers) to use geo: 
and only geo:. I pointed out the need to migrate to adopt NG911, but 
that didn't sway them.

My impression is that it is thought to be difficult to get existing sip 
stacks and SBCs to support the PIDF-LO in multipart bodies.

	Thanks,
	Paul

> Brian
>
> On Monday, August 1, 2016, James Winterbottom
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Then I think an alternative to current use of the Geo URI is
>     required for the concerns Gunnar and I have raised.
>
>     Cheers
>     James
>
>     Sent from my iPhone
>

---

From: James Winterbottom <[email-masked]>
Date: Tue, 2 Aug 2016 09:12:03 +1000

I don't think that this will help if we give them an easy out now. Nobody will spend money if there is an adequate cheap option.

My view is that we should not allow this option.

Cheers
James

Sent from my iPhone

> On 2 Aug 2016, at 7:36 am, Brian Rosen <[email-masked]> wrote:
> 
> It may help to inform the providers that NG9-1-1 will require location in a PIDF-LO and its being implemented fairly widely now so they only have a short time before they have to deal with it anyway. 
> 
> Brian
> 
>> On Monday, August 1, 2016, James Winterbottom <[email-masked]> wrote: