I think we're in violent agreement. The only expectation that the
client can have by setting the responseTime parameter is that the LIS
will respond in a time frame that matches it.
As long as a LIS can meet that expectation, though, it's free to do what
it wants, according to the protocol. Including returning a geography of
its choosing (even in Martian coordinates!).
--Richard
Thomson, Martin wrote:
> It wasn't the fact that it was onerous. I could care less either way. I'm talking about providing unexpected results.
>
> HELD defines a contract and emergencyRouting and emergencyDispatch are (to me*) clearly related to response time alone. Altering the semantics of these unilaterally has consequences.
>
> Local policy can be invoked on a lot of things, but only within the bounds of reasonableness - if the location is still usable and accurate, then that's OK, but that's not the story I'm hearing on the NENA list.
>
> --Martin
>
> * sure, we can (and maybe should) discuss whether greater clarity is needed...
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Richard Barnes
>> Sent: Wednesday, 3 June 2009 1:09 PM
>> To: Dawson, Martin
>> Cc: geopriv@ietf.org; Rosen, Brian
>> Subject: Re: [Geopriv] HELD ResponseTime parameter withvalue
>> emergencyRouting
>>
>> Martin,
>>
>> It actually isn't that onerous for the LIS to check whether a given
>> location is 'good enough for routing'. Basically, it involves a lot of
>> LoST queries to collect service boundaries for the relevant areas, some
>> off-line computations, then only a polygon-in-polygon check at query
>> time. We describe an algorithm in draft-barnes-ecrit-rough-loc:
>> <http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc#section-3>
>> Picking a service region (as I think your quote from Brian suggests a
>> LIS would do) is then just a matter of intersecting the two polygons.
>>
>> That said, it seems to me that whether the LIS applies such an
>> algorithm
>> is still a matter of local policy, with no protocol changes necessary.
>>
>> --Richard
>>
>>
>>
>>
>>
>>
>>
>> Dawson, Martin wrote:
>>> The NENA discussion hinged around the question of whether the routing
>>> service (LoST) should apply weighted routing to the location offered
>> by
>>> the device - and let's assume the relevant use case is that the
>> network
>>> LIS provided this location in, say, a cellular network. Proponents of
>>> weighted routing pointed out that the uncertainty around a cell may
>>> overlap two or more routing boundaries and that the optimal approach
>> is
>>> to determine which routing area the largest proportion (weight) of
>> the
>>> uncertainy falls into.
>>>
>>> Those opposed to this approach said that, in fact, the location
>> should
>>> just be provided as point - ignoring the fact that uncertainty is
>>> associated with it. And this proposal was made on the basis that *the
>>> LIS should ensure that the point provided falls into the correct
>>> (optimal?) routing area before providing it to the client*
>>>
>>> This sentiment is reflected in the following from Brian's post on
>> this
>>> thread:
>>>
>>>> I claim that it is perfectly reasonable to expect the LIS to
>> construct
>>> a
>>>> PIDF suitable for the purpose of emergency routing when it
>> encounters
>>> the
>>>> emergencyRouting value in responseTime
>>> The real kicker in this is that the LIS *has to perform actual
>> routing
>>> analysis before providing the location*. The inevitable consequence
>> of
>>> this is that the LIS has to have some sort of access to the routing
>>> boundary information in order to do this - don't forget a cellular
>>> location can't be stored in the LIS before hand; it's generated
>>> dynamically. So now, the LoST data, including multiple adjacent
>> boundary
>>> information, also has to live in the LIS or be otherwise accessible
>> to
>>> it.
>>>
>>> Now - if this is a reasonable expectation, and I'm not saying it
>> isn't,
>>> then it must raise the question of why use LoST at all to do the PSAP
>>> URI lookup, why not have the LIS deliver it directly since it's
>> already
>>> had to perform routing? I don't buy an interoperability argument
>> against
>>> this. An optional extension in the HELD response could contain the
>> PSAP
>>> URI. Any device not supporting it can fall back to looking for LoST.
>> It
>>> means that broadband providers could start providing ECRIT emergency
>>> call routing without the public LoST deployment/management problem
>>> having to be solved. Public network operators already do this routing
>>> analysis for the PSTN including cellular; it's not a new ask.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>> -----Original Message-----
>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>>> Behalf Of Rosen, Brian
>>> Sent: Wednesday, 3 June 2009 10:42 AM
>>> To: geopriv@ietf.org
>>> Subject: [Geopriv] HELD ResponseTime parameter with value
>>> emergencyRouting
>>>
>>> In NENA, there is a discussion on the best form (shape) to send to
>> the
>>> LoST server when the shape is a cell sector. The discussion itself
>> is
>>> pretty specific to NENA, although it involves the fact that it might
>> be
>>> necessary for the LIS to choose the shape of the response for
>> emergency
>>> routing that might be different than it would return for other
>> purposes.
>>>
>>> Martin Thompson is worried about something that I seek advice on.
>>>
>>> The wording choice for ResponseTime in HELD is:
>>> 6.1. "responseTime" Parameter
>>>
>>> The "responseTime" attribute MAY be included in a location request
>>> message. The "responseTime" attribute includes a time value
>>> indicating to the LIS how long the Device is prepared to wait for
>> a
>>> response or a purpose for which the Device needs the location.
>>>
>>> In the case of emergency services, the purpose of obtaining the LI
>>> could be either for routing a call to the appropriate PSAP or
>>> indicating the location to which responders should be dispatched.
>>> The values defined for the purpose, "emergencyRouting" and
>>> "emergencyDispatch", will likely be governed by jurisdictional
>>> policies, and should be configurable on the LIS.
>>>
>>> Please note the construction of the last sentence of the first
>> paragraph
>>> about "purpose".
>>>
>>> I claim that it is perfectly reasonable to expect the LIS to
>> construct a
>>> PIDF suitable for the purpose of emergency routing when it encounters
>>> the emergencyRouting value in responseTime, and the fact that it is
>> in
>>> the "responseTime" parameter doesn't limit the LIS from sending an
>>> appropriate PIDF content as well as within an appropriate time limit.
>>> The LIS knows the purpose, and can reasonably be expected to respond
>>> appropriately in both time and content. Otherwise, we would need
>>> another parameter to ask for the right content, which is silly.
>>>
>>> I have been okay with the current wording because I believed that the
>>> LIS could use the emergencyRouting (or emergencyDispatch for that
>>> matter) as an all purpose "purpose" (as it were) and wasn't hung up
>> on
>>> the fact that it's in the responseTime parameter.
>>>
>>> Am I wrong?
>>>
>>> Brian
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>> ---------------------------------------------------------------------
>> ---------------------------
>>> 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]
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> ------------------------------------------------------------------------------------------------
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
