Subject: [Geopriv] responseTime reprise

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 10 Sep 2007 02:21:50 -0500

I'm probably due to step into the ring on this topic.  I apologise for anything that is rehashed, I have not read the _entire_ archive on this topic.

The main reason the responseTime parameter was proposed was our collective experience with cellular systems.

3GPP have defined two values: "low delay" and "delay tolerant", which roughly correspond to what some have been advocating.  However, where multiple network nodes are involved in serving a request (and 3GPP relies on about 6), engineering is required to ensure smooth operation.  Each node is configured with a different timeout so that the time that the node adds to the transaction doesn't cause failures.  This engineering ensures that each location client receives a certain level of service.

Of course, each network is engineered differently.  Everyone has a different idea of what "low delay" and "delay tolerant" mean.  In a closed network this more or less works; although this isn't assured for roamers.  We wanted to avoid this problem.  It makes sense to allow devolve the parameter; rather than place an arbitrary value on some abstract codes, allow the client to decide.

To add to this, during my break, we had a request for further control over these values on one of our cellular products.  In this request, different types of clients would be given varying amounts of time.  Thus, from our perspective, we have a clear requirement for responseTime.

To those who want hard limits; BCP documents are a good place for recommendations.  You can add nice statements like: "if routing for emergency calls, set responseTime to x seconds; if you don't care, allow y seconds".

Ta,
Martin 
------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 09:25:22 -0400

I was working in updates to phonebcp and framework and here is the spec I
want to have:

ED-25/AN-14 It is RECOMMENDED that location determination not take longer
than 250 ms to obtain routing location and systems SHOULD be designed such
that the typical response is under 100ms. However, as much as 3 seconds to
obtain routing location MAY be tolerated if location accuracy can be
substantially improved over what can be obtained in 250 ms.

How would you express that with your parameter?

The equivalent for dispatch location is:
Generally, the PSAP can wait for an accurate location for dispatch.
However, there is no fixed time known in advance which is the limit; it
depends on the nature of the emergency.  At some point the PSAP must
dispatch.  In a subscription environment, the PSAP could update the
parameters in the filter (immediate response required).  In a HELD
dereference, there is no way to cancel and the PSAP will have to choose a
ResponseTime that it will wait for even if it wants to dispatch sooner than
that.  <Change as the discussion on ResponseTime evolves>

We then get to a complication.  It may be the case in some jurisdictions
that there are regulations that govern this.  In those cases, we may need a
way to say "I need the regulation-imposed values for emergency call route",
or the equivalent for dispatch.

Brian

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Monday, September 10, 2007 3:22 AM
> To: [email-masked]
> Subject: [Geopriv] responseTime reprise
> 
> I'm probably due to step into the ring on this topic.  I apologise for
> anything that is rehashed, I have not read the _entire_ archive on this
> topic.
> 
> 3GPP have defined two values: "low delay" and "delay tolerant", which
> roughly correspond to what some have been advocating.  However, where
> multiple network nodes are involved in serving a request (and 3GPP relies
> on about 6), engineering is required to ensure smooth operation.  Each
> node is configured with a different timeout so that the time that the node
> adds to the transaction doesn't cause failures.  This engineering ensures
> that each location client receives a certain level of service.
> 
> Of course, each network is engineered differently.  Everyone has a
> different idea of what "low delay" and "delay tolerant" mean.  In a closed
> network this more or less works; although this isn't assured for roamers.
> We wanted to avoid this problem.  It makes sense to allow devolve the
> parameter; rather than place an arbitrary value on some abstract codes,
> allow the client to decide.
> 
> To add to this, during my break, we had a request for further control over
> these values on one of our cellular products.  In this request, different
> types of clients would be given varying amounts of time.  Thus, from our
> perspective, we have a clear requirement for responseTime.
> 
> To those who want hard limits; BCP documents are a good place for
> recommendations.  You can add nice statements like: "if routing for
> emergency calls, set responseTime to x seconds; if you don't care, allow y
> seconds".
> 
> Ta,
> Martin

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Sep 2007 09:26:09 -0500

You put three seconds in as the response time. If a more accurate
location can be provided in 3 seconds, it will take that long, if not it
will respond even faster.

What's more, if the next application running on the device can actually
wait 20 seconds, it can state "20 seconds" and may actually subsequently
get a more accurate location which may take anywhere from 3 to 20
seconds to return.

Simple.

If you really think that there is a need for a "please give me location
in the time mandated by the jurisdiction in which I am currently
operating" semantic then please send text. Nobody has suggested that is
what response time satisfies - and you have not proposed anything that
satisfies it either. Such a mechanism is not mutually exclusive to an
optional response time parameter.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, 10 September 2007 11:25 PM
To: Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] responseTime reprise

I was working in updates to phonebcp and framework and here is the spec
I
want to have:

ED-25/AN-14 It is RECOMMENDED that location determination not take
longer
than 250 ms to obtain routing location and systems SHOULD be designed
such
that the typical response is under 100ms. However, as much as 3 seconds
to
obtain routing location MAY be tolerated if location accuracy can be
substantially improved over what can be obtained in 250 ms.

The equivalent for dispatch location is:
Generally, the PSAP can wait for an accurate location for dispatch.
However, there is no fixed time known in advance which is the limit; it
depends on the nature of the emergency.  At some point the PSAP must
dispatch.  In a subscription environment, the PSAP could update the
parameters in the filter (immediate response required).  In a HELD
dereference, there is no way to cancel and the PSAP will have to choose
a
ResponseTime that it will wait for even if it wants to dispatch sooner
than
that.  <Change as the discussion on ResponseTime evolves>

We then get to a complication.  It may be the case in some jurisdictions
that there are regulations that govern this.  In those cases, we may
need a
way to say "I need the regulation-imposed values for emergency call
route",
or the equivalent for dispatch.

Brian

> The main reason the responseTime parameter was proposed was our
collective
> experience with cellular systems.
> 
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 11:10:07 -0400

I don't think so.  Someone needs to judge "substantial improvement".  It
could be the server if it knew that is what you want.  It could be the
client if it knew what the server could do.  Just putting the time parameter
doesn't have a way to express anything other than the simplistic "wait 3
seconds" if anything can be done in those 3 seconds.  You might get, say,
30% improvement from .25 sec to 3 sec.  If that was the case, your mechanism
would wait 3 seconds.  I would not want that to happen.  I want someone to
judge when it's not worth waiting more for.  That might be 1 second, or 2
seconds.  Depends on the shape of the curve. 

Whatever parameters are decided upon, we may need two distinguished values
that are "use locally mandated limits for emergency call routing" and the
same for dispatch.  If we're stuck with ResponseTime alone:

In some jurisdictions, there are regulations which govern the time and/or
accuracy required for emergency calls.  When processing an emergency call
location is used in two circumstances: routing a call to the most
appropriate PSAP, and later, dispatching responders to help the caller.
Regulations may govern one or both of these circumstances and the regulation
may specify the accuracy without specifying time, time without specifying
accuracy, or both time and accuracy.  The protocol supports this
possibility.  There are two distinguished values for ResponseTime which are
used for emergency calls, where there is a locally mandated time/accuracy
requirements for routing or dispatch.  The two values are:

* EmergencyCallRoute: Used to signal that the locally required values for
emergency call routing are needed.  If there are no local mandates, and this
parameter is used, the server should assume <1KM uncertainty with 95%
confidence in <250 ms unless the accuracy can be substantially improved by
waiting as much as 3 seconds.  If the measurement mechanism can make
substantial improvement by waiting, the wait time should be judged by the
server to minimize the time the call is held while getting most of the gain
in accuracy.  If most of the improved uncertainty is achieved in 2 seconds,
do not wait the entire 3 seconds.

* EmergencyCallDispatch: Used to signal that the locally required values for
emergency call dispatch are needed.  If there are no local mandates, and
this parameter is used, the server should assume <100M uncertainty with 95%
confidence in <30 sec.  

As HELD is a text language, perhaps these strings can be used.  If we need
to assign integer values to them, then we'll pick something.

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Monday, September 10, 2007 10:26 AM
> To: Brian Rosen; Thomson, Martin; [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Sep 2007 15:33:37 -0500

Brian,

As has been pointed out more times than I can count now.
The shape of the curve CANNOT be quantified ahead of time.

You state below "In some jurisdictions, there are regulations which
govern the time and/or accuracy required for emergency calls." 
Can you explain what happens if the accuracy cannot be met in any place,
does the PSAP get no location at all? I am prepared to bet you a beer at
the next IETF that they get something, and that it is the probably the
best location that the network can provide before the ALI transaction
times out.

Until recently you said that you only had two requirement AGAP and ASAP,
responseTime will give you that, and it will give us what we want.
Win-win, and 'best-basis'.

If you want something more than repsonseTime, as you indicate below,
then that can be an extension and I challenge you to write a draft that
can do this.

Cheers
James

> Sent: Tuesday, 11 September 2007 1:10 AM
> To: Dawson, Martin; Thomson, Martin; [email-masked]
> possibility.  There are two distinguished values for ResponseTime
which
> are
> emergency call routing are needed.  If there are no local mandates,
and
> this
> * EmergencyCallDispatch: Used to signal that the locally required
values
> for
> this parameter is used, the server should assume <100M uncertainty
with
> 95%
> > > node is configured with a different timeout so that the time that
the
> > node
> > > different idea of what "low delay" and "delay tolerant" mean.  In
a
> > closed
> > > To add to this, during my break, we had a request for further
control
> > over
> > > types of clients would be given varying amounts of time.  Thus,
from
> > our

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 17:19:55 -0400

James

In the past, I thought a generalized "roughly now, whatever accuracy you can
give me" and "roughly as accurate as you can get, in a reasonable, but
longish time frame" was acceptable.  It was pointed out to me that where
there is actual regulation, what I asked for may not be one of the above.
To my knowledge, there are no other uses where there is, or might be,
regulation.  So, I'm proposing that there be something that alerts the LIS
that the request is one of those that have to conform to such regulation if
there is any.

I think what happens when the network cannot deliver what the regulation
says is that they get some answer. The authorities also get some statistics
that shows them whether the regulation is being met within the confidence
requirement.  After all, confidence is never 100%.  Addressing what they do
about it when the result doesn't meet the regulation is beyond scope no
matter how you define it.

I thought I made a pretty reasonable proposal, with text, as asked.  I think
I have provided a pretty decent motivation.  I fail to see why this should
be an extension, since this is one of (not the only) driving use cases.  You
can assail me for not recognizing sooner that there may have to be something
that gets a predefined accuracy/time trade-off for the emergency case, but I
think that, having recognized it, defined it, made a specific text proposal,
and defended it, that perhaps you need to show me where I am wrong.

In North America, at present, there is an accuracy requirement for emergency
dispatch on mobile handsets.  For handset driven systems like GPS, it's
<100m 95% of the time.  That may or may not conform to some LIS' notion of
AGAP.  On the other hand, if you tell it that you need dispatch location for
an emergency call, and it's in the U.S., it knows EXACTLY what it needs to
do.  There is no setting of a generalized ResponseTime with or without
AGAP/ASAP which would indicate <100M with 95% confidence.  You will note
that the regulation states accuracy without stating response time.  

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Monday, September 10, 2007 4:34 PM
> To: Brian Rosen; Dawson, Martin; Thomson, Martin; [email-masked]

---

From: "Stuard, Doug" <[email-masked]>
Date: Mon, 10 Sep 2007 17:30:17 -0400

Perhaps it's worthwhile dragging this one out of the archives:

On August 14th I posted:

RECOMMENDATION: What this boils down to is to include both an (optional)
ResponseTime parameter specifying the maximum time permitted for a
response, as well as an (also optional) desired accuracy parameter
(uncertainty value at a "standard" confidence).  

The inclusion of accuracy and/or time parameters in a client request
would then result in the following response types:

1) No stated requirement - Best achievable accuracy, no time limit
(Open ended - Response provided at convergence or on receipt of "that's
enough!" command).
 
2) Time limit only - Best achievable accuracy within specified time
limit. 

3) Accuracy requirement only - Provide response when specified
accuracy reached, no time limit.

4) Both time and accuracy - Provide response when specified
accuracy is reached or time limit expires, whichever comes first.
 
In all cases, an accuracy estimate should be included in the response,
and would be at a standard.
This will allow the client to decide if further requests are necessary
based on the situation/application. 

In implementation, case 4 would be "first on wins".  You either achieve
your required accuracy within the time limit specified in the client
request, or you take the best that the server can provide when the clock
runs out.  If you then need additional time, you can re-issue the
request, either without the time parameter or with a longer time window.

As James pointed out this meets the full range of requirements and is
"best basis".

Doug

> > doesn't have a way to express anything other than the simplistic
> "wait
> 3
> > that are "use locally mandated limits for emergency call routing"
and
> > * EmergencyCallRoute: Used to signal that the locally required
values
> > substantial improvement by waiting, the wait time should be judged
by
> the
> > server to minimize the time the call is held while getting most of
> the
> > gain
> > As HELD is a text language, perhaps these strings can be used.  If
we
> need
> > > operating" semantic then please send text. Nobody has suggested
> that
> is
> > > However, there is no fixed time known in advance which is the
> limit;
> it
> > > > I'm probably due to step into the ring on this topic.  I
> apologise
> for
> > > > anything that is rehashed, I have not read the _entire_ archive
> on
> > > this
> > > > topic.
> > > >
> > > > multiple network nodes are involved in serving a request (and
> 3GPP
> > > relies
> > > > adds to the transaction doesn't cause failures.  This
engineering
> > > ensures
> > > > We wanted to avoid this problem.  It makes sense to allow
devolve
> > > > emergency calls, set responseTime to x seconds; if you don't
> care,
> > > allow y
> > > > seconds".
> > > >
> > > > Ta,
> > > > Martin
> > > >
> > >
>
-----------------------------------------------------------------------
> -
-----------------------------------------------------------------------
> -
-----------------------------------------------------------------------
> -
-----------------------------------------------------------------------
> -
-----------------------------------------------------------------------
> -------------------------
-----------------------------------------------------------------------
> -------------------------
> [mf2]
> 
> 
>

---

From: "Stuard, Doug" <[email-masked]>
Date: Mon, 10 Sep 2007 17:43:27 -0400

The accuracy requirements in North America do NOT apply to individual
locations, but to overall system performance.  100 m uncertainty at 95%
confidence for a given geolocation is neither compliant or
non-compliant, it is just one data point in overall accuracy evaluation
(obviously if all locations came it with these results, the overall
system would in fact be compliant).   

AGAP for a given call instance is just that - AGAP for THAT CALL.  If
you need dispatch location for an emergency call in the US, you need
AGAP within your dispatch time window (generally taken to be 30 seconds
or less).  Whether it is within the 100m uncertainty at whatever
confidence is irrelevant for any given call.  Those factors are for the
analysts to evaluate after the fact on a statistical sampling of calls
in the defined service are to determine whether the accuracy standards
have been met.

Doug

> Sent: Monday, September 10, 2007 5:20 PM
> To: Winterbottom, James; Dawson, Martin; Thomson, Martin;
> [email-masked]
><snip>
> <100m 95% of the time.  That may or may not conform to some LIS'
notion
> of
> an emergency call, and it's in the U.S., it knows EXACTLY what it
needs
> > does the PSAP get no location at all? I am prepared to bet you a
beer
> at
> > > I don't think so.  Someone needs to judge "substantial
> improvement".
> > It
> > > seconds" if anything can be done in those 3 seconds.  You might
> get,
> > say,
> > > judge when it's not worth waiting more for.  That might be 1
> second,
> > or 2
> > > Whatever parameters are decided upon, we may need two
distinguished
> > > accuracy required for emergency calls.  When processing an
> emergency
> > call
> > > emergency call dispatch are needed.  If there are no local
> mandates,
> > and
> > > > location can be provided in 3 seconds, it will take that long,
if
> > not it
> > > > what response time satisfies - and you have not proposed
anything
> > that
> > > > satisfies it either. Such a mechanism is not mutually exclusive
> to
> > an
> > > > I was working in updates to phonebcp and framework and here is
> the
> > spec
> > > > I
> > > > want to have:
> > > >
> > > > obtain routing location MAY be tolerated if location accuracy
can
> be
> > > > > 3GPP have defined two values: "low delay" and "delay
tolerant",
> > which
> > > > > roughly correspond to what some have been advocating.
However,
> > where
> > > > > on about 6), engineering is required to ensure smooth
> operation.
> > Each
> > > > > network this more or less works; although this isn't assured
> for
> > > > roamers.
> > > > > parameter; rather than place an arbitrary value on some
> abstract
> > > > codes,
> > > > > these values on one of our cellular products.  In this
request,
> > > > different
> > > > > recommendations.  You can add nice statements like: "if
routing
> > > > > emergency calls, set responseTime to x seconds; if you don't
---------------------------------------------------------------------
> ---
---------------------------------------------------------------------
> ---
---------------------------------------------------------------------
> ---
---------------------------------------------------------------------
> ---
---------------------------------------------------------------------
> -----
---------------------------------------------------------------------
> -----

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Sep 2007 16:47:25 -0500

Brian,

I think that the first part is actually totally achievable with the
responseTime parameter, and you can certainly check the stats later.
This further stresses my point that applications almost always know
whether the accuracy is good enough to do something with. But I think
what I am hearing from you is that you see a need for a service
indicator to the LIS saying, I need this for emergency purposes please.

Perhaps I missed what your proposed text was then, the only solutions I
recall seeing were ones that required network URI profiling ahead of
time and I know that that can't be done. So would you please repeat your
proposal?

On the last point, the legislation might not provide a time constraint,
but we all know that there is one. If it were to take an hour or even 5
minutes to get a location that that would be totally unacceptable in
this use case. I have described mobile concierge applications that only
have a time constraint and not really an accuracy one, because they can
work with either geodetic or civic locations.

I am not discounting the use case you propose, I just don't believe that
any proposed solution I have describes how:

1) It can apply to civic and geo location information
2) If I can't meet it, what is the semantic
3) If I request a civic and geo in the same location request, which
takes precedence, time or accuracy and why?
4) How it interacts with other attributes that are already agreed upon

Basically any proposed solution needs to address at least all of those
and in an unambiguous way, otherwise I don't see it as doing much more
than throwing a spanner(wrench) in the works.

Cheers
James 

> Sent: Tuesday, 11 September 2007 7:20 AM
[email-masked]
> In the past, I thought a generalized "roughly now, whatever accuracy
you
> that the request is one of those that have to conform to such
regulation
> requirement.  After all, confidence is never 100%.  Addressing what
they
> do
> be an extension, since this is one of (not the only) driving use
cases.
> You
> that gets a predefined accuracy/time trade-off for the emergency case,
but
> <100m 95% of the time.  That may or may not conform to some LIS'
notion of
> AGAP.  On the other hand, if you tell it that you need dispatch
location
> an emergency call, and it's in the U.S., it knows EXACTLY what it
needs to
> > does the PSAP get no location at all? I am prepared to bet you a
beer at
improvement".
"wait
get,
second,
distinguished
and
emergency
values
by
the
mandates,
we
if
that
anything
to
the
> > > > obtain routing location MAY be tolerated if location accuracy
can be
limit;
apologise
> > for
> > > > > anything that is rehashed, I have not read the _entire_
archive on
tolerant",
However,
3GPP
operation.
engineering
for
devolve
abstract
request,
routing
care,

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 18:17:21 -0400

The proposed text was in the message.  Here it is again:

It would apply to civic as well as geo, although I don't think any LIS that
reports civic has any response time (unless it converts and it should not
convert).

If the LIS can't meet the regulation, it returns the best it can.

You can request a civic and a geo in the same message.  I don't want to say
that you could not have an implementation which could give you an accurate
civic and an accurate geo by two different mechanisms and thus the request
might make sense.  I think that will be rare.  As long as you don't convert,
I'm okay with asking for both.  If you do that, and the implementation can
do both, then you get both.

I'm not sure what interactions are issues.  It's really just a distinguished
value for ResponseTime (and/or accuracy if we go with Doug's proposal, which
I like better than just time).

Brian

> Sent: Monday, September 10, 2007 5:47 PM

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Sep 2007 17:32:30 -0500

Brian,

I think what you have actually done is taken the first step to
acknowledging that different applications have different time
requirements. What your proposal does, is provide an *application
specific* flag that then translates to a specific hard-coded response
time (best fit) for an emergency application. You now need to take the
next step and recognize that you've just covered one possible
application - and you've chosen one that the LIS may be in the best
place to ascribe the response time for. Now you need to recognize that
there are applications that the client wants to ascribe the response
times for.

" To my knowledge, there are no other uses where there is, or might be,
regulation." - this I find to be a strange statement. It seems to
suggest that response time is only relevant if there's a regulatory
imperative to have it. Friend finders, fleet and asset tracking,
presence registration, hot desk location registration, navigation,
location concierge,... all these applications can and do have their own
optimal response times.

Now - I'm happy to support your suggestion of what is effectively an
"emergency request" indicator flag in the base request semantics. Let
the LIS apply local policy as to what is the standard response time for
that request in that jurisdiction - good idea. As I think you note, you
may want "emergency route", and "emergency dispatch" flags. Frankly, I
think the emergency dispatch request is likely to originate from the
PSAP and it will know what response time applies and could just use the
response time parameter; then PSAPs could apply their own requirements
and not assume a one size fits all by jurisdiction. This flag can
co-exist with the response time parameter so there's no reason to block
either on the basis of the other in the spec unless you just want to be
difficult.

I don't think you've provided any useful text on a "LIS profiling" set
of semantics. It is going to have to be quite involved - including the
second phase aspect of how the client identifies which of the profile
points it wants to invoke as the actual request. I certainly haven't
seen a comprehensive and coherent proposal for this. Since I neither
feel the need for the mechanism, nor see any practical way to implement
it given the state of the art, I have no inclination to spend time
developing that proposal. That ball is in your court. Hopefully we can
both agree that it can comfortably live in extension land. BTW - any LIS
that decided to take an order of magnitude longer for a location
technology that generally only provided a miniscule or generally
negligible improvement in accuracy would be a poor LIS. Your point is
valid in theory; your profiling technology addresses it in theory. I
don't think that either have any practical basis.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 11 September 2007 7:20 AM
To: Winterbottom, James; Dawson, Martin; Thomson, Martin;
[email-masked]

James

In the past, I thought a generalized "roughly now, whatever accuracy you
can
give me" and "roughly as accurate as you can get, in a reasonable, but
longish time frame" was acceptable.  It was pointed out to me that where
there is actual regulation, what I asked for may not be one of the
above.
To my knowledge, there are no other uses where there is, or might be,
regulation.  So, I'm proposing that there be something that alerts the
LIS
that the request is one of those that have to conform to such regulation
if
there is any.

I think what happens when the network cannot deliver what the regulation
says is that they get some answer. The authorities also get some
statistics
that shows them whether the regulation is being met within the
confidence
requirement.  After all, confidence is never 100%.  Addressing what they
do
about it when the result doesn't meet the regulation is beyond scope no
matter how you define it.

I thought I made a pretty reasonable proposal, with text, as asked.  I
think
I have provided a pretty decent motivation.  I fail to see why this
should
be an extension, since this is one of (not the only) driving use cases.
You
can assail me for not recognizing sooner that there may have to be
something
that gets a predefined accuracy/time trade-off for the emergency case,
but I
think that, having recognized it, defined it, made a specific text
proposal,
and defended it, that perhaps you need to show me where I am wrong.

In North America, at present, there is an accuracy requirement for
emergency
dispatch on mobile handsets.  For handset driven systems like GPS, it's
<100m 95% of the time.  That may or may not conform to some LIS' notion
of
AGAP.  On the other hand, if you tell it that you need dispatch location
for
an emergency call, and it's in the U.S., it knows EXACTLY what it needs
to
do.  There is no setting of a generalized ResponseTime with or without
AGAP/ASAP which would indicate <100M with 95% confidence.  You will note
that the regulation states accuracy without stating response time.  

Brian

"wait
and
values
by
the
we
that
limit;
apologise
on
3GPP
engineering
devolve
care,

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Sep 2007 17:40:30 -0500

I think the text you have below is suitable for inclusion in, say, the
ECRIT BCP. We need text for the HELD spec - which I don't think should
be quantifying anything. I gather you'd like an optional parameter in
the HELD request that is binary and used to indicate that the purpose of
the location is for emergency route/dispatch?

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 11 September 2007 8:17 AM
To: Winterbottom, James; Dawson, Martin; Thomson, Martin;
[email-masked]

The proposed text was in the message.  Here it is again:
In some jurisdictions, there are regulations which govern the time
and/or
accuracy required for emergency calls.  When processing an emergency
call
location is used in two circumstances: routing a call to the most
appropriate PSAP, and later, dispatching responders to help the caller.
Regulations may govern one or both of these circumstances and the
regulation
may specify the accuracy without specifying time, time without
specifying
accuracy, or both time and accuracy.  The protocol supports this
possibility.  There are two distinguished values for ResponseTime which
are
used for emergency calls, where there is a locally mandated
time/accuracy
requirements for routing or dispatch.  The two values are:

* EmergencyCallRoute: Used to signal that the locally required values
for
emergency call routing are needed.  If there are no local mandates, and
this
parameter is used, the server should assume <1KM uncertainty with 95%
confidence in <250 ms unless the accuracy can be substantially improved
by
waiting as much as 3 seconds.  If the measurement mechanism can make
substantial improvement by waiting, the wait time should be judged by
the
server to minimize the time the call is held while getting most of the
gain
in accuracy.  If most of the improved uncertainty is achieved in 2
seconds,
do not wait the entire 3 seconds.

* EmergencyCallDispatch: Used to signal that the locally required values
for
emergency call dispatch are needed.  If there are no local mandates, and
this parameter is used, the server should assume <100M uncertainty with
95%
confidence in <30 sec.  

It would apply to civic as well as geo, although I don't think any LIS
that
reports civic has any response time (unless it converts and it should
not
convert).

You can request a civic and a geo in the same message.  I don't want to
say
that you could not have an implementation which could give you an
accurate
civic and an accurate geo by two different mechanisms and thus the
request
might make sense.  I think that will be rare.  As long as you don't
convert,
I'm okay with asking for both.  If you do that, and the implementation
can
do both, then you get both.

I'm not sure what interactions are issues.  It's really just a
distinguished
value for ResponseTime (and/or accuracy if we go with Doug's proposal,
which
I like better than just time).

Brian

> > > > could be the server if it knew that is what you want.  It could
be
> the
> > > > client if it knew what the server could do.  Just putting the
time
> > > > parameter
> > > > 30% improvement from .25 sec to 3 sec.  If that was the case,
your
> > > > mechanism
> > > > In some jurisdictions, there are regulations which govern the
time
> > > and/or
> > > > Regulations may govern one or both of these circumstances and
the
> > > > parameter is used, the server should assume <1KM uncertainty
with
> > > > in accuracy.  If most of the improved uncertainty is achieved in
2
> > > > seconds,
> > > > > that the typical response is under 100ms. However, as much as
3
> > > seconds
> > > > > depends on the nature of the emergency.  At some point the
PSAP
> must
> > > > > dispatch.  In a subscription environment, the PSAP could
update
> > > > > dereference, there is no way to cancel and the PSAP will have
to
> > > choose
> > > > > a
> > > > > ResponseTime that it will wait for even if it wants to
dispatch
> > > sooner
> > > > > that there are regulations that govern this.  In those cases,
we
> may
> > > > > > different idea of what "low delay" and "delay tolerant"
mean.
> In
> > > > > > To those who want hard limits; BCP documents are a good
place

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 22:27:04 -0400

I want a distinguished value in the ResponseTime field if that is all there
is.

> Sent: Monday, September 10, 2007 6:41 PM
> To: Brian Rosen; Winterbottom, James; Thomson, Martin; [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Sep 2007 21:35:49 -0500

OK - we can do that.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 11 September 2007 12:27 PM
To: Dawson, Martin; Winterbottom, James; Thomson, Martin;
[email-masked]

I want a distinguished value in the ResponseTime field if that is all
there
is.

which
and
values
with
> > Perhaps I missed what your proposed text was then, the only
solutions
> > but we all know that there is one. If it were to take an hour or
even
> 5
> > > about it when the result doesn't meet the regulation is beyond
scope
> > no
> > > I thought I made a pretty reasonable proposal, with text, as
asked.
> > > AGAP/ASAP which would indicate <100M with 95% confidence.  You
will
> > note
> > > > Can you explain what happens if the accuracy cannot be met in
any
> > place,
> > > > the next IETF that they get something, and that it is the
probably
> > > > Until recently you said that you only had two requirement AGAP
and
> > ASAP,
> > > > then that can be an extension and I challenge you to write a
draft
> > > > > would wait 3 seconds.  I would not want that to happen.  I
want
> > > > someone to
> > > > > appropriate PSAP, and later, dispatching responders to help
the
> > > > caller.
> > > > > waiting as much as 3 seconds.  If the measurement mechanism
can
> > make
> > > > > server to minimize the time the call is held while getting
most
> > > > > > What's more, if the next application running on the device
can
> > > > actually
> > > > > > get a more accurate location which may take anywhere from 3
to
> > 20
> > > > > > seconds to return.
> > > > > >
> > > > > > Simple.
> > > > > >
> > > > > > If you really think that there is a need for a "please give
me
> > > > > > ED-25/AN-14 It is RECOMMENDED that location determination
not
> > take
> > > > > > parameters in the filter (immediate response required).  In
a
> > HELD
> > > > > > way to say "I need the regulation-imposed values for
emergency
> > > > > > > The main reason the responseTime parameter was proposed
was
> > > > > > > node is configured with a different timeout so that the
time
> > > > > > > Of course, each network is engineered differently.
Everyone
> > has a

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 22:39:11 -0400

I suggested that there may be regulation that defines what the LIS must do,
and asked for a way for the client to signal the server that it needed to
follow the regulation.

I don't think we should extend this to another application that did not have
a regulatory or other fixed, and known to the LIS requirement.

I used the actual requirement, which has no time value and only has an
accuracy value, albeit that there are generally accepted time values.  The
requirement is stated as an accuracy requirement.  There is no way for the
PSAP to signal that it requires <100M accuracy with 95% confidence.  It
could only signal <30 sec.  That is most decidedly NOT the same thing.  The
distinguished value in ResponseTime is specifically to get around the
limitation you want to have that only time can be specified.  It's much more
specific than ASAP/AGAP, and it has to be.

I WANT something that allows me to specify accuracy as well as time.  I WANT
a way to find out what a reasonable request of the server is.  I can
compromise through those things.

On the other hand I NEED (as in hard requirement), a way to tell the LIS to
meet the regulation.  I don't think I can compromise there.  I don't need to
use my suggested mechanism, but I need a way to signal that the LIS must
meet the regulation, if any.  I don't think ASAP/AGAP does that.  I know
just having a scalar in ResponseTime can't do that.

Brian  

> Sent: Monday, September 10, 2007 6:33 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Sep 2007 23:01:11 -0500

So here is my proposal.

<locationRequest svc='emergencyRouting' responseTime='3'>
	<locationType>
		civic
		geodetic
		locationURI
	</locationType>
</locationRequest>

This request says give me location for routing an emergency call within
3 seconds please. Where svc is a new attribute specifying what you want
it for. This could be an IANA registry item if we wanted to go that far.

Similarly if you want location for dispatch:

<locationRequest svc='emergencyDispatch' responseTime='30'>
	<locationType>
		civic
		geodetic
	</locationType>
</locationRequest>

You could even ditch the 30 seconds if the thing making the request
doesn't care how long it takes.

Brian, can you live with this?

Cheers
James

> From: Dawson, Martin
> Sent: Tuesday, 11 September 2007 12:36 PM
[email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Sep 2007 08:24:32 -0400

Can I live with it?  Yes.
I think defining two tokens that can go in ResponseTime is easier.

Brian

> Sent: Tuesday, September 11, 2007 12:01 AM
> To: Dawson, Martin; Brian Rosen; Thomson, Martin; [email-masked]

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 11 Sep 2007 13:41:44 -0500

First, thanks to Martin Thomson for restarting this discussion.

I've been following this ping pong match and trying to figure out how we
could get consensus and it seems there is a proposal on the table with
which both camps A and camps B agree.   I know there was a camp C that
didn't see the need at all for a responseTime, but I'm hoping that this
compromise is agreeable at this point in time. 

Are others that had not been so entrenched in camps A, B or C okay with
this approach?  It seems similar to several of the other past compromise
proposals in allowing specification of two elements to meet everyone's
requirements.

In the case that folks are agreeable to the general approach, do we have
any other opinions on whether the "svc" is part of the responseTime
rather than a separate element. I would actually prefer the approach of
having two tokens in responseTime, as Brian suggested, since it would
then restrict the "svc" as a qualifer associated with the time. And, in
this case, I think an IANA registry would be unnecessary.  So, I'm
hoping folks are now in the mode to debate and comment on this detail
rather than the general approach. 

Regards,
Mary
- HELD editor 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 7:25 AM
To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin';
[email-masked]

Can I live with it?  Yes.

Brian

> 3 seconds please. Where svc is a new attribute specifying what you 
> want it for. This could be an IANA registry item if we wanted to go
that far.
> > I want a distinguished value in the ResponseTime field if that is 
> > all there is.
> >
> >
> >
> ----------------------------------------------------------------------
> ----
> ----------------------
> 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]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Sep 2007 13:58:22 -0500

The only reason that I suggested svc as a separate attribute was that it
makes adding other "special cases" easier later. If this isn't a concern
then I have no objection to Brian's approach.

I would point out one further thing, and that is if you specify
emergencyRouting or emergencyDispatch, then also providing a
locationType is moot as the LIS MUST provide location in the form
suitable for those services.

Cheers
James

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Wednesday, 12 September 2007 4:42 AM
> To: Brian Rosen; Winterbottom, James; Dawson, Martin; Thomson, Martin;
> [email-masked]
> > > > I think the text you have below is suitable for inclusion in,
say,
> > > > be quantifying anything. I gather you'd like an optional
parameter
> > in
immediately

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Sep 2007 15:05:49 -0400

I think there are two, somewhat separable issues here:
1. Do we need something beyond time in the basic protocol?  Doug Stuard had
a specific proposal
2. Do we need something that indicates a requirement to conform to local
regulations for emergency calls?

The latest set of messages is on the latter question, and you know where I
stand - I prefer two distinguished values.

The former question is still open.  I think something along the lines of
what Doug proposed could be the basis of something workable.  I would like
some way for the server to tell the client what kinds of values it could
reasonably handle.  I'm willing to make that an extension if we need to in
order to make progress.

Brian

> Sent: Tuesday, September 11, 2007 2:42 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Sep 2007 14:13:35 -0500

Thankyou Brian.

I would prefer accuracy request to be an extension to be developed as
required.

Cheers
James

> Sent: Wednesday, 12 September 2007 5:06 AM
> To: 'Mary Barnes'; Winterbottom, James; Dawson, Martin; Thomson,
Martin;
> 1. Do we need something beyond time in the basic protocol?  Doug
Stuard
> had
say,
> > > the
> > > > > ECRIT BCP. We need text for the HELD spec - which I don't
think
parameter
immediately

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Sep 2007 15:15:35 -0400

I don't understand that.

Let's first see if we agree on basic principals:
1. Conversion should never be done implicitly.  It could be explict if you
want.
2. Conversion on emergency calls must not be done.
3. A LIS may have multiple determination mechanisms.  It's possible, albeit
unlikely, that one could determine a civic and another determine a geo.
Despite the fact that I don't think it will happen very often, I'd rather
not prohibit that.
4. It may be even more unlikely that a LIS would have multiple determination
mechanisms one or more of which resulted in civic and one or more that
resulted in geo AND that at least one civic and at least one geo meet the
local regulatory requirements, but again, I wouldn't want to prohibit it.

That means that locationType still matters, right?  Unlikely perhaps, but
possible.  I don't think we need extra text for this.  I don't think we
imply any locationType with the distinguished values.

Brian

> Sent: Tuesday, September 11, 2007 2:58 PM
> To: Mary Barnes; Brian Rosen; Dawson, Martin; Thomson, Martin;
> [email-masked]

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 11 Sep 2007 14:16:12 -0500

That sounds like a great plan - Marc

Marc Berryman, ENP
Geographic Information Systems
Greater Harris County 9-1-1 Emergency Network
Houston, Texas      (713) 407-2254
[email-masked]

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 2:14 PM
To: Brian Rosen; Mary Barnes; Dawson, Martin; Thomson, Martin;
[email-masked]

Thankyou Brian.

Cheers
James

Martin;
Stuard
say,
think
parameter
immediately

------------------------
------------------------
[mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Sep 2007 14:22:04 -0500

Yes, let's just add extra text.

> Sent: Wednesday, 12 September 2007 5:16 AM
> To: Winterbottom, James; 'Mary Barnes'; Dawson, Martin; Thomson,
Martin;
> > > I've been following this ping pong match and trying to figure out
how
> > > In the case that folks are agreeable to the general approach, do
we
> > have
> > > rather than a separate element. I would actually prefer the
approach
> > > then restrict the "svc" as a qualifer associated with the time.
And,
think
> > > > > > the HELD request that is binary and used to indicate that
the
> > > > purpose of
contain

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Sep 2007 15:41:35 -0400

Huh?  I just made an argument that you don't need any extra text and
LocationType COULD be used with the distinguished values

Brian

> Sent: Tuesday, September 11, 2007 3:22 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Sep 2007 14:54:42 -0500

Let me try again.

Requesting emergencyRouting stipulates an application and flags this to
the LIS. The LIS knows what the local PSAP can handle, and application
making the request shouldn't care about the form since it has already
stated what it plans to do with it.

Does that make sense?

> Sent: Wednesday, 12 September 2007 5:42 AM
Martin;
> > > 1. Conversion should never be done implicitly.  It could be
explict if
> > > 3. A LIS may have multiple determination mechanisms.  It's
possible,
> > > albeit
> > > resulted in geo AND that at least one civic and at least one geo
meet
> > the
> > > local regulatory requirements, but again, I wouldn't want to
prohibit
> > it.
> > >
> > > That means that locationType still matters, right?  Unlikely
perhaps,
> > but
> > > possible.  I don't think we need extra text for this.  I don't
think
> > > > > could get consensus and it seems there is a proposal on the
table
> > with
> > > > > which both camps A and camps B agree.   I know there was a
camp C
> > that
> > > > > didn't see the need at all for a responseTime, but I'm hoping
that
> > > > > Are others that had not been so entrenched in camps A, B or C
okay
> > > > > having two tokens in responseTime, as Brian suggested, since
it
> > would
> > > > > > This request says give me location for routing an emergency
call
> > > > > > within
> > > > > > 3 seconds please. Where svc is a new attribute specifying
what
> > you
> > > > > > want it for. This could be an IANA registry item if we
wanted to
> > go
> > > > > > > I want a distinguished value in the ResponseTime field if
that
> > > > > > > > I think the text you have below is suitable for
inclusion
> > in,

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Sep 2007 16:09:34 -0400

Sorry, no.

I agree that the LIS knows what the use is, and therefore does know what is
acceptable.  However, as I explained, it could be that the LIS could, for
example, deliver either civic or geo meeting local requirements.  In that
case, the client's choice may be appropriate.

Brian

> Sent: Tuesday, September 11, 2007 3:55 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Sep 2007 15:10:38 -0500

I can live with that.

> Sent: Wednesday, 12 September 2007 6:10 AM
Martin;
> I agree that the LIS knows what the use is, and therefore does know
what
> > > > > unlikely, that one could determine a civic and another
determine a
> > > > geo.
> > > > > Despite the fact that I don't think it will happen very often,
I'd
> > > > rather
> > > > > mechanisms one or more of which resulted in civic and one or
more
> > > > > > The only reason that I suggested svc as a separate attribute
was
> > > > that it
> > > > > > makes adding other "special cases" easier later. If this
isn't a
> > > > concern
> > > > > > > To: Brian Rosen; Winterbottom, James; Dawson, Martin;
Thomson,
> > > > > > > I've been following this ping pong match and trying to
figure
> > out
> > > > > > > this approach?  It seems similar to several of the other
past
> > > > > > compromise
> > > > > > > proposals in allowing specification of two elements to
meet
> > > > everyone's
> > > > > > > requirements.
> > > > > > >
> > > > > > > In the case that folks are agreeable to the general
approach,
> > > > > > > this case, I think an IANA registry would be unnecessary.
So,
> > I'm
> > > > > > > hoping folks are now in the mode to debate and comment on
this
> > > > detail
> > > > > > > > You could even ditch the 30 seconds if the thing making
the
> > > > > > > > > > -----Original Message-----
[mailto:[email-masked]]
> > > > > > > > > > To: Brian Rosen; Winterbottom, James; Thomson,
Martin;
> > > > > > > > and delete the original.  Any unauthorized use of this
email

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Sep 2007 13:18:48 -0700

>stated what it plans to do with it.

Doesn't make sense to me yet because "The LIS knows what the local PSAP
can handle" presumes a pretty well-serviced out of band channel that passes
this information and keeps it up to date. 

>imply any locationType with the distinguished values.

I thought that this was a reasonable set of points for "locationType still
matters", and presuming an out-of-band channel doesn't really seem
to eliminate it for me. What am I missing about your point?

					Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Sep 2007 15:44:07 -0500

Hi Ted,

A LIS services local areas, and it may service several jurisdictions.
The LIS needs to know what kinds of location are applicable for PSAP
routing in those areas. This may be out of band, but it has been a very
strong assumption of the LIS in i3 and i3 which is where the LIS was
born. I think it has been somewhat assumed even in these circles,
because a LIS providing a civic location that doesn't validate through
the local LoST server is kind of silly.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, 12 September 2007 6:19 AM
> To: Winterbottom, James; Brian Rosen; Mary Barnes; Dawson, Martin;
> Thomson, Martin; [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Sep 2007 14:27:12 -0700

>the local LoST server is kind of silly.
Imagine for a moment  a 12k-person enterprise.  It has a wiremap database
that it wishes to make available as a HELD-enabled LIS, rather than using
DHCP to push down the information on login.

Our organization has sites in San Diego, Campbell, San Jose, Palo Alto
(all California), plus sites in Oregon, Massachusetts, North Carolina, Texas,
England, Germany, China,  and Japan that are served by its corporate network;
it has some 40+ other sites that are not served directly by its corporate network,
but which have users using VPNs in fixed locations where the wire map
database might be included to cover the endpoint.

That's a lot of local knowledge of PSAP routing mechanisms.  And note that
our example is pretty small fry in terms of sites.....

					Ted

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 11 Sep 2007 14:32:35 -0700

Agreed.  I also think that the 12k-person enterprise might become
subject to a requirement for any/all civic locations to be validated via
LoST, for example - but that'd probably be the extent of local PSAP
knowledge.

-roger marshall. 

> Sent: Tuesday, September 11, 2007 2:27 PM
> To: Winterbottom, James; Brian Rosen; Mary Barnes; Dawson, 
> Martin; Thomson, Martin; [email-masked]
> Imagine for a moment  a 12k-person enterprise.  It has a 
> wiremap database that it wishes to make available as a 
> HELD-enabled LIS, rather than using DHCP to push down the 
> information on login.
> 
> Our organization has sites in San Diego, Campbell, San Jose, 
> Palo Alto (all California), plus sites in Oregon, 
> Massachusetts, North Carolina, Texas, England, Germany, 
> China,  and Japan that are served by its corporate network; 
> it has some 40+ other sites that are not served directly by 
> its corporate network, but which have users using VPNs in 
> fixed locations where the wire map database might be included 
> to cover the endpoint.
> 
> That's a lot of local knowledge of PSAP routing mechanisms.  
> And note that our example is pretty small fry in terms of sites.....
> 
> 					Ted
> 
> 
> 
> 
> 
> 
> >
> >
> >
> >> >Requesting emergencyRouting stipulates an application and 
> flags this
> >to
> >> >making the request shouldn't care about the form since it has 
> >> >already stated what it plans to do with it.
> >> >
> >> >Does that make sense?
> >>
> >> can handle" presumes a pretty well-serviced out of band 
> channel that 
> >> passes this information and keeps it up to date.
> >>
> >> Brian said:
> >>
> >> >3. A LIS may have multiple determination mechanisms.  
> It's possible,
> >> albeit
> >> >possible.  I don't think we need extra text for this.  I 
> don't think
> >we
> >> I thought that this was a reasonable set of points for 
> "locationType
> >still
> >> matters", and presuming an out-of-band channel doesn't 
> really seem to 
> >> eliminate it for me. What am I missing about your point?
> >>
> >>					Ted
> >>
> >
> >------------------------- This message is for the designated 
> recipient 
> >only and may contain privileged, proprietary, or otherwise private 
> >information.

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 11 Sep 2007 19:03:01 -0400

James, 

> The LIS needs to know what kinds of location are applicable 
> for PSAP routing in those areas. This may be out of band, but 
> it has been a very strong assumption of the LIS in i3 and i3 
> which is where the LIS was born. I think it has been somewhat 
> assumed even in these circles, because a LIS providing a 
> civic location that doesn't validate through the local LoST 
> server is kind of silly.

Silly is quite subjective.

What incentive does a LIS operator (SP or Enterprise) have to 'validate' via
LoST?

XYZ Corp. located in the U.S. loads up it's LIS with USPS approved/formated
civic locations.  It doesn't validate, 911 call fails routing. Who is
liable?

My point: There is no basis for putting responsibility on the LIS operator
for knowing/caring about civic location formats nor jurisdicational required
response time/accuracy.

fyi, LIS first was defined in TIA TSB-146 in 2001.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Sep 2007 18:07:54 -0500

Marc,

Let us, as so commonly do, agree to disagree on whether there is a point
in the LIS operator ensuring that locations can be used for emergency
routing or not. While I don't believe that that is the only reason for
having LIS, I fully recognize that meeting regulations in this area will
be the impetus for them being deployed. That said, they will need to
work for that purpose and so the LIS operator will make sure that they
do.

Disagree if you like.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 12 September 2007 9:03 AM
> To: Winterbottom, James; [email-masked]
> What incentive does a LIS operator (SP or Enterprise) have to
'validate'
> via

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 11 Sep 2007 18:43:38 -0500

Hi Ted,

Yes - that's the implication. You might be able to rely on somebody
else's efforts for routing and call on a global network of LoST servers
to do emergency call routing. But if a jurisdiction has particular
requirements on the form of the location information, the administrator
of LIS covering those sites will need to be aware of that.

Frankly, I wouldn't expect to be able to rely on a robust global network
of LoST servers any time soon either, so you'll probably need to have
the local knowledge necessary to query the local LoST service in any
case.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, 12 September 2007 7:27 AM
To: Winterbottom, James; Brian Rosen; Mary Barnes; Dawson, Martin;

>the local LoST server is kind of silly.
Imagine for a moment  a 12k-person enterprise.  It has a wiremap
database
that it wishes to make available as a HELD-enabled LIS, rather than
using
DHCP to push down the information on login.

Our organization has sites in San Diego, Campbell, San Jose, Palo Alto
(all California), plus sites in Oregon, Massachusetts, North Carolina,
Texas,
England, Germany, China,  and Japan that are served by its corporate
network;
it has some 40+ other sites that are not served directly by its
corporate network,
but which have users using VPNs in fixed locations where the wire map
database might be included to cover the endpoint.

That's a lot of local knowledge of PSAP routing mechanisms.  And note
that
our example is pretty small fry in terms of sites.....

					Ted

>> >making the request shouldn't care about the form since it has
already
meet
prohibit
perhaps,

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 11 Sep 2007 19:31:45 -0500

Certainly - if the LIS operator has no incentive (private or regulatory)
to make emergency calls work then they mightn't work. The point is
somewhat moot.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 12 September 2007 9:03 AM
To: Winterbottom, James; [email-masked]
Subject: RE: [Geopriv] responseTime reprise

James, 

What incentive does a LIS operator (SP or Enterprise) have to 'validate'
via
LoST?

XYZ Corp. located in the U.S. loads up it's LIS with USPS
approved/formated
civic locations.  It doesn't validate, 911 call fails routing. Who is
liable?

My point: There is no basis for putting responsibility on the LIS
operator
for knowing/caring about civic location formats nor jurisdicational
required
response time/accuracy.

-Marc-

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 11 Sep 2007 19:22:53 -0600

I have no objection to the proposal. I would only say that if there is no 
responseTime parameter, then guaranteed as soon as the draft is approved, 
then someone will say, "Hey what about some sort of response time 
parameter".

Also, FYI, it is easy to encode time info using GML if there is that 
requirement.

Regards

Carl

----- Original Message ----- 
From: "Mary Barnes" <[email-masked]>
To: "Brian Rosen" <[email-masked]>; "Winterbottom, James" 
<[email-masked]>; "Dawson, Martin" 
<[email-masked]>; "Thomson, Martin" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, September 11, 2007 12:41 PM
Subject: RE: [Geopriv] responseTime reprise

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 12 Sep 2007 09:01:20 -0400

James,

The point of my comment continues the mantra I've stated for several years.
The more unique you make the requirements for successful emergency calling,
the more likely there will be failures.

I believe we all agree and wish that emergency calling will be significantly
less than 1% of the uses of location information in the future.  To this
point, let's make emergency calling work just like the remaining 99% of the
location based applications.  Yes, there will be a few 'small' adjustments
to accommodate ES due to it's nature.  But making assumptions that a LIS
operator will do more than load the wire map db with locally recognized
civic location data AND basing the ES calling architecture on this fact is,
IMO, asking for failure.  I'm simply stating my experience with various
other Internet-based/IP applications.

I realize not all I'm advocating can/will be solved within IETF protocols.

So, it worries me when we start adding things to protocols like, 'give me an
ES location-type'.

Carry-on,

-Marc-

> 
> Let us, as so commonly do, agree to disagree on whether there 
> is a point in the LIS operator ensuring that locations can be 
> used for emergency routing or not. While I don't believe that 
> that is the only reason for having LIS, I fully recognize 
> that meeting regulations in this area will be the impetus for 
> them being deployed. That said, they will need to work for 
> that purpose and so the LIS operator will make sure that they do.
> 
> Disagree if you like.
> 
> Cheers
> James
> 
> > > routing in those areas. This may be out of band, but it 
> has been a 
> > > very strong assumption of the LIS in i3 and i3 which is where the 
> > > LIS was born. I think it has been somewhat assumed even in these 
> > > circles, because a LIS providing a civic location that doesn't 
> > > validate through the local LoST server is kind of silly.
> > 
> > approved/formated civic locations.  It doesn't validate, 911 call 
> > fails routing. Who is liable?
> > 
> > required response time/accuracy.
> >