Subject: RE: AW: AW: [Ecrit] requirements

From: "Abbott, Nadine B." <[email-masked]>
Date: Mon, 28 Mar 2005 16:59:07 -0500

Mike,

I think that your understanding of location validation is basically correct.
This function is particularly important for routing in environments that
support routing to a PSAP based upon detailed location information. In other
countries, there may be only one Emergency Call Center, and the location
information is used primarily in dispatch of emergency responders.

It's probably sufficient for the ecrit WG to require that location
information be pre-validated to determine that it is useful for routing
emergency calls.  For the US and Canada, the National Emergency Number
Association has been discussing proposals for an interface for location
validation in relation to the MSAG, including consideration of addressing
abbreviation conventions specific to those countries.  At this time, a Web
Services-like query approach is being investigated to support this
interface. The specification of this interface may have value for other
countries that support location-based routing, but the usefulness of the
underlying data of course is probably local in nature. Nothing is final or
approved at this time, but I think we'd be happy to share what we have been
thinking about, if it is deemed useful for discussion by the rest of the
ecrit WG.   I think that data exchange interfaces to support the
maintenance/upkeep of [MSAG-based] location validation data is probably out
of scope for ecrit.

With respect to "A similar question relates to any database that maps from
geographic coordinates to a civil space identified by a civil address"--are
you asking if there are interfaces for data exchanges or data conversions of
routing data that should be addressed by the ecrit WG?  I personally think
that this is perhaps outside the expertise, as well as the scope, of the
ecrit WG?  

With respect to the interesting side note that you raised, in the US some
PSAP call-takers do have access to geo-coded landmark data to assist in
locating callers, at least within their local serving areas.  When it is
available, shared PSAP access to such data is not typical today.  I think
that an alternative may be more accurate/specific default routing and/or
location-based call transfer capabilities to get the call closer to a
knowledgable PSAP?  

Nadine Abbott  

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Monday, March 28, 2005 3:43 PM
To: Abbott, Nadine B.; [email-masked]
Subject: RE: AW: AW: [Ecrit] requirements

Nadine,

As I understand it, location validation is not call-related, but is a
process to ensure that each location to be used by the location service are
registered with the PSAP system and assigned a specific PSAP to route to,
i.e. the MSAG is up to date.  My question is whether this maintenance of the
MSAG involves a protocol that ECRIT is to define?

A similar question relates to any database that maps from geographic
coordinates to a civil space identified by a civil address.

On a side note related to default to verbal confirmation of location by the
caller, I know of a case where the police could not dispatch a car to a
location even when the caller could identify they were near a particular
type of store (only one within many miles) in a specific town because the
PSAP person was in a different geographic area.  These PSAPs need to be able
to search (Google?) on landmarks to find street addresses.  Asking the
caller about street names and building numbers doesn't help when street
signs and numbers are not visible, but marketing signs are.

Mike

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Abbott, Nadine B.
>Sent: Friday, March 25, 2005 1:22 PM
>To: [email-masked]
>Subject: RE: AW: AW: [Ecrit] requirements
>
>Hannes,
>
>At least as we have framed it in the Rosen contribution to
>ECRIT, "location validation" refers to capabilities necessary 
>to ensure that a civic location object is routable and also 
>useful for dispatch of emergency responders.
>Since there are so many different representations of civic 
>location information, human user confusion can contribute to 
>incorrect, unroutable information being provided.  The 
>"location validation" function is intended to allow for 
>corrections of errors and confusion BEFORE there is an
>emergency.   (We have been informed that the term "location 
>validation" may
>cause confusion because of other connotations in other 
>contexts, but have tried to qualify and explain the use of the 
>term to alleviate this.) I think that if non-routable civic 
>addresses were commonplace, it wouldn't really matter what 
>mechanism ecrit specified for routing them--garbage
>in-->garbage out.
>
>"Location validation" is not the same as authenticating that
>any given location object has been provided by a particular entity.
>
>Thanks,
>Nadine
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of James M. Polk
>Sent: Wednesday, March 23, 2005 2:49 PM
>To: Tschofenig Hannes; 'Henning Schulzrinne'
>Cc: Ciesla, Larry; [email-masked]
>Subject: Re: AW: AW: [Ecrit] requirements
>
>
>At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote:
>
>> >
>> > Allowed by whom? Do we assume that one has to have a license to
>> > provide such services? Who would hand out such licenses? 
>(As far as
>> > I know, nobody has licensed Columbia University to provide
>> > telecommunication services and I guess we thus would not 
>be able to
>> > legally provide campus-level location information.)
>>
>>that's exactly my point.
>>if we dig deeper into the authorization issues then we encounter
>>various problems.
>
>Isn't "location validation" another form of "authorized
>location information for usage"?
>
>Is this part of our message routing charter?
>
>
>>ciao
>>hannes
>>
>> >
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>cheers,
>James
>
>                                *******************
>                 Truth is not to be argued... it is to be presented
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Mar 2005 17:13:01 -0500

Before having some dauntingly large number of protocols, it would be 
nice to have some idea as to what the ECRIT lookup protocol might be. 
There has been one fairly concrete proposal (DNS) and one fairly vague 
proposal (IRIS, which I mentioned in a few slides). I believe the issue 
raised for DNS was the lack of detailed error feedback.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 28 Mar 2005 17:55:20 -0500

I think we figured out a simple way to do detailed error resolution with the
DNS proposal.

Of course, I'm in favor of the DNS idea.

My major reason is that we know that the DNS is very reliable in the face of
failure.  That's a very nice property for something used to route emergency
calls when disasters strike.  No new protocol with limited deployment can
make such a claim.  The current proposal is a by-the-book DDDS application,
but following recent guidance, I'm happy to propose some new RRs
specifically for the purpose.

BTW I'm aware of a couple of cases of folks trying the DNS idea; we have
some running code.  It's pretty trivial, so if we want to organize some
demos, it's pretty easy to do.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henning Schulzrinne
> Sent: Monday, March 28, 2005 5:13 PM
> To: Abbott, Nadine B.
> Cc: [email-masked]