exist for the LIS to simply return the destination URIs. This also
addresses the issues of what happens if LoST servers take a long time to
publically rollout.
Cheers
James
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Wednesday, 3 June 2009 1:40 PM
> To: Winterbottom, James
> Cc: Dawson, Martin; geopriv@ietf.org; Rosen, Brian
> Subject: Re: [Geopriv] HELD ResponseTime parameter withvalue
> emergencyRouting
>
> It's just clean protocol design to keep these two functions (location
> and location-based routing) separate in general. Some jurisdictions
may
> require a local LIS to perform some emergency-related functions, but
> this need not be the case. A client should be able to use a LIS of
> either type without having to modify its behavior.
>
> You could also view this as preserving the simplicity of the LIS,
except
> when regulators require it to be more complicated.
>
> --Richard
>
>
>
> Winterbottom, James wrote:
> > Hi Richard,
> >
> > That said, if the LIS has to get this information anyway and then do
the
> > polygon-in-polygon check, it may as well return the resulting
> > destination URIs as well and do away with having to have 2 protocols
> > supported by the end-point when one will do.
> >
> > At what point do we stop?
> >
> > Cheers
> > James
> >
> >> -----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]
> >
> >
------------------------------------------------------------------------------------------------
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
