The point that I make is that a value of emergencyRouting in responseTime is not proof positive that the request being made is for the sole purpose of routing an emergency call. Therefore, it would be misguided for an authority to mandate specific emergency behaviour in relation to a request just because this parameter is used.
--Martin
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, 4 June 2009 12:31 AM
> To: 'Richard Barnes'; Thomson, Martin
> Cc: geopriv@ietf.org; Dawson, Martin; Rosen, Brian
> Subject: RE: [Geopriv] HELD ResponseTime parameter withvalue
> emergencyRouting
>
> I agree with this. We're discussing what I think is North American
> specific
> behavior, and not something appropriate for IETF standardization.
> We're
> implementing a process that exists now, that PSAPs want to keep, at
> least
> for now, which is that the initial routing decision where there is a
> large,
> known in advance area, like a traditional cell site or sector, is not
> algorithmic, but made by people in a meeting, taking a number of
> factors
> into account.
>
> Again, very specific to NENA, we have a desire to make ALL actual
> routing
> decisions in the LoST server, primarily so that, in disaster
> situations, we
> have ONE place to change routing, and not several places.
>
> The notion that a cell site is represented by a point or a civic
> location
> decided in advance by the operator and the affected PSAPs, in a
> meeting, is
> what we do today, is reasonable, and is not in violation of the current
> HELD
> text. If some day the PSAPs wish the site to be represented by a
> shape, and
> use the routing algorithm in the LoST server to choose a route based on
> that
> shape, they can have the LIS operator change.
>
> Brian
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of Richard Barnes
> > Sent: Wednesday, June 03, 2009 1:05 AM
> > To: Thomson, Martin
> > Cc: geopriv@ietf.org; Dawson, Martin; Rosen, Brian
> > Subject: Re: [Geopriv] HELD ResponseTime parameter withvalue
> > emergencyRouting
> >
> > Martin,
> >
> > 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
>
------------------------------------------------------------------------------------------------
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
