But it doesn't matter. The text is good enough. The PSAPs and the LIS operators can work it out.
Brian
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Thursday, June 04, 2009 7:14 PM
> To: Rosen, Brian; Brian Rosen; Richard Barnes
> Cc: geopriv@ietf.org; Dawson, Martin
> Subject: RE: [Geopriv] HELD ResponseTime parameter withvalue
> emergencyRouting
>
> Hi Brian,
>
> I think that it WILL be a problem.
>
> Any modification or adjustment of location by the emergency authority
> degrades the quality of the location. Hiding aside, the result that is
> provided by a LIS is the best available within the allotted time.
> Anything else is worse.
>
> Without proof positive that the request is intended for emergency use,
> an emergency authority that instructs the network operator to modify
> location will impose the negative consequences of that modification on
> non-emergency uses.
>
> By taking this position, you force users of location into meta-
> reasoning. This reasoning goes: "I think that my emergency authority
> has a mandate that dictates modification of location information.
> Therefore I cannot use emergencyDispatch to request location for
> anything other than emergency calling because it might be altered
> somehow." That extends to implementers having to avoid
> emergencyDispatch for all non-emergency cases because some
> jurisdiction, somewhere, might have such a mandate.
>
> That's a dishonest way of forcing the interpretation you desire.
>
> --Martin
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
> > Sent: Thursday, 4 June 2009 11:04 PM
> > To: Thomson, Martin; Brian Rosen; Richard Barnes
> > Cc: geopriv@ietf.org; Dawson, Martin
> > Subject: RE: [Geopriv] HELD ResponseTime parameter withvalue
> > emergencyRouting
> >
> > That would be up to the LIS operator.
> >
> > 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]
> -----------------------------------------------------------------------
> -------------------------
> 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
