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
