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

From: James Winterbottom <[email-masked]>
Date: Mon, 25 Jul 2016 18:51:34 +1000

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>].
> 
>       (While section 4.1 of [RFC6442] <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> of
>    GEOPRIV Requirements [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>).
> 
>    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> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jul 2016 11:20:08 -0400

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:
> 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:
> "
> 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]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Jul 2016 16:17:33 +0000

[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]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Tuesday, July 26, 2016 11:20:08 AM
To: [email-masked]
Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00

James,

        Thanks,
        Paul

---

From: James Winterbottom <[email-masked]>
Date: Wed, 27 Jul 2016 07:07:10 +1000

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”.

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. 

It would be good to hear if anyone else on the list has similar concerns.

Cheers
James

> On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne <[email-masked]> wrote:
> 
> >>       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
> >>    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.
> >>
> >>    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>>).
> >>
> >>    requirements of RFC 3693 <https://tools.ietf.org/html/rfc3693 <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 <https://www.ietf.org/mailman/listinfo/dispatch>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jul 2016 17:32:23 -0400

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.

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

>> On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> 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.
>>
>> ------------------------------------------------------------------------
>> *From:* dispatch <[email-masked]
>> <mailto:[email-masked]>> on behalf of Paul Kyzivat
>> <[email-masked] <mailto:[email-masked]>>
>> *Sent:* Tuesday, July 26, 2016 11:20:08 AM
>> *To:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [dispatch] Strong concerns with location encoding in
>> draft-vrs-rue-dispatch-00
>>
>> James,
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 1 Aug 2016 08:43:31 +0200

Den 2016-07-26 kl. 23:32, skrev Paul Kyzivat:

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

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

>>> >>       (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>).
>>> >>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]