I don't think that will be a problem.
Brian
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Wednesday, June 03, 2009 9:25 PM
> To: Brian Rosen; Richard Barnes
> Cc: geopriv@ietf.org; Dawson, Martin; Rosen, Brian
> Subject: RE: [Geopriv] HELD ResponseTime parameter withvalue
> emergencyRouting
>
> Sorry Richard, Brian, I do not agree, despite whatever you perceive.
>
> 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
