Subject: [Ecrit] Issue 35: Location Validation

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Apr 2006 23:12:06 +0200

Hi all,

we need to close issue#35 about location validation. The issue can be 
found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35.

Note that I provide a summary at the end of my mail.

http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt
says:

"
    Location validation: A caller location is considered valid if the
       civic or geographic location is recognizable within an acceptable
       location reference systems (e.g., USPS, WGS-84, etc.), and can be
       mapped to one or more PSAPs.  While it is desirable to determine
       that a location exists, validation may not ensure that such a
       location exists.  Location validation ensures that a location is
       able to be referenced for mapping, but makes no assumption about
       the association between the caller and the caller's location.
"

We had a discussion about this subject during the interim meeting:
http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html

----------------

[07:53:24] <anewton> roger: issue 15 re validation of civic
[07:53:39] <anewton> andy: I thought the list left the issue not about 
not doing it, but how.
[07:53:46] <anewton> roger: need to know about the language in the draft
[07:54:08] <anewton> brian: something about a way to do it
[07:54:24] <anewton> jon: related to other req. such as querying it 
anywhere.
[07:54:37] <anewton> james p.: we are no validating
[07:54:56] <anewton> ted: text in the issue tracker is not the meaning 
of validation in NENA, etc...
[07:55:12] <anewton> ted: this is a valuable piece of protocol machinery.
[07:55:39] <anewton> james: that makes sense, but the text doesn't say that
[07:56:03] <anewton> brian: if validation is defined as succesful 
mapping to the PSAP, then that is what we want.
[07:56:11] <anewton> james: need other word than "valid"
[07:56:28] <anewton> brian: what we have can be used for NENA view of 
the world
[07:57:01] <anewton> james: anything out of this building to the proper 
PSAP, but not floor by floor
[07:57:16] <anewton> brian: the requirement is to know that you can send 
a responder.
[07:57:32] <anewton> marc: not sure that is the NENA view, re ESN
[07:58:04] <anewton> brian: the location is knowing we can send a responder
[07:58:09] <anewton> nadine: agree
[07:58:52] <anewton> brian: definition of valdiation to be successful 
mapping to occur for the location
[07:59:10] <anewton> ted: this requirement needs the point brian is making
[07:59:49] <anewton> james: concerned with people thinking we mean 
something much more precise
[08:00:12] <anewton> hannes: the definition does not match the requirmenet
[08:00:26] <anewton> roger: let's examine the definition first
[08:01:09] <anewton> nadine & brian: this is a good defintion
[08:01:15] <anewton> james: no, that is cumbersome
[08:03:04] <anewton> henning: problem is that this is trying to define 
validation for both civic and geo. first test is syntactic validity. the 
description is not clear if the actual address exists.
[08:03:49] <anewton> henning: second test, is there a valid mapping, 
third, is there a street address that can be routed to.
[08:04:14] <anewton> brian: clarifying this is a good idea.
[08:04:21] <anewton> nadine: agree with 1 and 2, but not 3
[08:04:27] <anewton> roger: we cannot achieve 3
[08:04:38] <anewton> henning: then we need to be clear about it
[08:05:36] <anewton> roger: "but not equivicate to an address" ?
[08:05:58] <anewton> brian: add new sentence to clarify it. "while 
desirable to have the address exist, not guarnateed."
[08:06:46] <anewton> ted: wandering from the protocol requirement. an 
address could be invalid for other purposes but could get mapped to a PSAP.
[08:07:46] <anewton> ted: could I give you a PSAP based on the location 
given, if answer is yes then that is the one thing we care about
[08:08:01] <anewton> henning: just need a qualification of what it does 
not mean
[08:08:42] <anewton> brian: agree, see my previous wording
[08:09:17] <anewton> marc: mentions some use case in Texas.
[08:09:25] <anewton> brian: but that is not how it will work
[08:09:40] <anewton> marc: but if the address does not exist, no PSAP
[08:09:46] <anewton> brian: that is making an assumption
[08:10:35] <anewton> brian: current MSAG does address ranges, but we 
should have ability in future to work on single addresses
[08:11:07] <anewton> marc: do you believe it shouldn't return an answer?
[08:11:10] <anewton> brian: ?
[08:11:41] <anewton> ted: in some administrations, the answer will be 
"here is your PSAP, and btw the address you gave is foobar"
[08:13:18] <anewton> nadine: be able to distinguish if it is the "right" 
PSAP vs "default" PSAP?
[08:13:47] <anewton> ted: for validation it would be "right".
[08:14:33] <anewton> henning: this has implication on protocol design 
choices.
[08:15:57] <anewton> henning: difference in use case in validation and 
non-validation (emergency case) and the bits on the wire in the protocol
[08:16:00] <anabolism> If the case is that the address is 125 main 
street, and 124 and 126 exist but 125 does not, would validation 
indicate that the address is syntactically valid, the psap returned 
would be for 124 and/or 126?
[08:17:19] <anewton> are you asking a question for the room?
[08:17:36] <anabolism> yes, but we've moved on abit
[08:18:06] <anabolism> I was trying to clarify comments from several people
[08:19:21] <anewton> brian: answering randy's q: "I can map it, but it 
isn't really valid. But in an emergency, it would send you to the 
closest PSAP."
[08:19:32] <anabolism> Thanks, sounds reasonable to me
[08:19:46] <anewton> marc: result should be saying there is a problem in XML
[08:19:51] <anewton> brian: yes
[08:20:12] <anewton> brian: it is desirable to say you can get a 
mapping, but there is a problem with the address.
[08:21:20] <anewton> henning: even in a real emergency query, this is 
nothing wrong with indicating that the address is foobar as long as the 
PSAP is returned
[08:22:11] <anewton> ted: in a real emergency only look at the one thing 
they map on. validation may be a different task.
[08:22:47] <anewton> brian: but that work for you
[08:22:56] <anewton> ted: that is why this is desirable.
[08:23:04] <anewton> nadine: ?
[08:23:17] <anewton> nadine: if you only know that it is a known range
[08:24:34] <anewton> andy: just need to make sure that implementers 
don't let the error show up in the emergency case
[08:24:58] <anewton> roger: do we agree that in addition to the URL that 
it is desirable to have a result code?
[08:25:10] <anewton> henning: generally, yup/
[08:25:27] <anewton> is the audio being recorded?
[08:26:10] <anewton> henning: it is more than a status code
[08:26:16] <anewton> roger: additional information?
[08:27:13] <anewton> hannes: Validation Resolution: it MAY be possible 
to return additional information which can be used to determine the 
preceision or resolution of the returned sip uri, for example

----------------

The meeting minutes of the interim meeting indicate:
http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html

----------------

Issue 15

Validation of civil location has been hanging around for a while. Should 
it stay in the 02 draft? Andrew thought the issue was how we would do 
validation, not whether. Brian wants to leave the language in, but would 
like to know if people think it's adequate (we're using motivations text 
to describe what validation means). "A successful mapping will work".

We actually do have other requirements that talk about this (doing 
queries at any time), but we don't describe it anywhere else.

Are we actually validating? We don't mean NEMA validation, only asking 
whether it's enough to get back a PSAP mapping. Passing back "here's the 
PSAP" would be sufficient. Can we use another word? "Validation" has 
lots of baggage. Brian wants to make sure that we can get to NEMA 
validation - "a location that a responder knows how to get to". "A 
location that can be sucessfully mapped to one or more PSAPs".

We're trying to encompass both civil location and geolocation in one 
sentence - this is one reason why it's cumbersome. If all of the city of 
Washington goes to one PSAP but the location isn't valid, we still have 
a problem. MSAG values have the same problem, because they carry street 
number ranges and a "valid" street number may not exactly exist - and 
the best MSAG validators today can't guarantee that the address exists.

An address can be "valid enough" to get to the right PSAP, even if it's 
not valid to respond to. Texas has one PSAP entry - so anything would 
work as long as it's in Texas? No, the current MSAG works on address 
ranges - but the street exists. Brian would like for this to work on 
individual addresses, not ranges.

Brian thinks that local PSAPs should be determining what happens for 
various values of "invalid", since calls are going to go somewhere!

Ted thinks that there's a lot of variation in what administrations do 
now and will do in the future.

Will the protocol allow us to tell that we got to the right PSAP, or 
just got a PSAP?

Henning - just returning a SIP URI to let someone ask "where the heck 
are you?" isn't sufficient when we're actually routing an emergency call.

We always get a SIP URI, we're trying to figure out what getting a SIP 
URI actually means for an operational system.

"I got a match on all the XML tags except this one" would be an 
acceptable response, and this would be desirable. This could happen at 
validation time or at emergency call routing time.

Validation may mean "I like the only tags that I care about, and didn't 
look at the ones I don't care about".

Do we agree that we need a result code, in addition to a URI? Partial 
validation may be the common case (public verifiers won't know suite 
numbers/room numbers, for example).

Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether 
it gets used or not is up to the administration).

And we need to be consistent in our RFC 2119 usage (which is always 
problematic for requirements documents anyway, since the meaning is a 
protocol-mechanism meaning, not a protocol-usage meaning). We're making 
a lot of these requirements MUSTs, and that may make the resulting 
protocols clumsy. If we use 2119, we should be using MUST, MAY and 
SHOULD, not just MUST.

Tom pointed out that some mechanisms may be provided by extensions, but 
are not required in the base protocol.

Henning says we're not writing a BCP, so we should consider NOT using 
2119 language.

Randy suggested that we actually spell out "must support", etc. and not 
rely on 2119. Henning - then we should have consistent terminology, 
whether it's upper case or lower case. Randy will audit the existing 
document, but needs input from others.

What about returning an indicator of the resolution of the mapping that 
is returned?

Brian suggested text for a mechanism to indicate that a location or part 
of location does not exist, even if it can be mapped. Should this point 
out the invalid pieces? Aren't these administration-specific? Tags are 
roughly self-describing, but we can't pick one hierarchy - what gets 
returned needs to be free-form.

James - doesn't the text say "location should be sent even if it's 
considered unreliable?" Is this OK?

We will leave L01 language as is, change "location validation" in 
terminology, and we are adding two new requirements to this section.

----------------

The discussions regarding Issue#15 caused us to change the following 
requirement into two requirements:
http://www.ietf-ecrit.org:8080/ecrit-req/issue15

"
 >   Lo1.  Validation of Civic Location: It MUST be possible to
 >validate a
 >      civic location prior to its use in an actual emergency call.
 >
 >      Motivation: Location validation provides an opportunity to help
 >      assure ahead of time, whether successful mapping to the
 >      appropriate PSAP will likely occur when it is required.
 >      Validation may also help to avoid delays during emergency call
 >      setup due to invalid locations.

"

to:

"
Lo1X.  Validation Resolution: The mapping protocol
MUST support the return of additional information which can be used
to determine the precision or resolution of the data elements used to
determine a PSAP URI, for example.

Lo1XX.  Indication of non-existent location: The
protocol MUST support a mechanism to indicate that a location or a
part of a location is known to not exist, even if a valid location-to-PSAP
uri mapping can be provided.
"

The term validation appears only in the following sections.

Section 1 (Introduction):

"
    As used in this document, validation of location does not require to
    ascertain whether the location actually exists.  For example,
    validation might only check that the house number in a civic address
    falls within the assigned range, not whether that building exists at
    that spot.  However, such higher precision validation is desirable.
"

Section 2 (Terminology):
"
    Location validation: A caller location is considered valid if the
       civic or geographic location is recognizable within an acceptable
       location reference systems (e.g., USPS, WGS-84, etc.), and can be
       mapped to one or more PSAPs.  While it is desirable to determine
       that a location exists, validation may not ensure that such a
       location exists.  Location validation ensures that a location is
       able to be referenced for mapping, but makes no assumption about
       the association between the caller and the caller's location.
"

Section 7 (Mapping Protocol):

"
    Ma22.  Validation of civic location: The mapping protocol MUST
       implement a method via a mapping request, that makes it possible
       for a mapping server to validate a civic location prior to that
       location's use in an actual emergency call.

       Motivation: Location validation provides an opportunity to help
       assure ahead of time, whether successful mapping to the
       appropriate PSAP will likely occur when it is required.
       Validation may also help to avoid delays during emergency call
       setup due to invalid locations.

    Ma23.  Validation resolution: The mapping protocol MUST support
       (i.e., required to implement, but not required for use) the return
       of additional information which can be used to determine the
       precision or resolution of the data elements used to determine a
       PSAP URI.

       Motivation: The mapping server may not use all the data elements
       in the provided location information to determine a match, or may
       be able to find a match based on all of the information except for
       some specific data elements.  The uniqueness of this information
       set may be used to differentiate among emergency jurisdictions.
       Precision or resolution in the context of this requirement might
       mean, for example, explicit identification of the data elements
       that were used successfully in the mapping.

    Ma25.  Limits to validation: Successful validation of a civic
       location MUST NOT be required to place an emergency call.

       Motivation: In some cases, a civic location may not be considered
       valid.  This fact should not result in the call being dropped or
       rejected by any entity along the signaling path to the PSAP.
"

I think we need to differentiate civic and geospatial location information.

Geospatial location information:

  * Can the request be mapped to one or more PSAPs?

    This is normal mapping protocol operation. Nothing special here.

  * Does the address exist?

    There is no question that this address exists
    if the coordinate reference system was understood.

Civic location information:

  * Can the request be mapped to one or more PSAPs?

    The text from Ma23 is applicable here:

       Motivation: The mapping server may not use all the data elements
       in the provided location information to determine a match, or may
       be able to find a match based on all of the information except for
       some specific data elements.  The uniqueness of this information
       set may be used to differentiate among emergency jurisdictions.
       Precision or resolution in the context of this requirement might
       mean, for example, explicit identification of the data elements
       that were used successfully in the mapping.

  * Does the address exist?

    It is possible that a given civic address does not exist.
    An additional database, which contains the list of existing
    addresses, needs to be available.

What we can do is to be more specific about the type of behavior we want 
from the mapping protocol.
Do we want the client to be able to express that the mapping server 
should check the civic address for existence?
Do we want the mapping server to be able to indicate that the civic 
address was checked against the database?
I don't think anything needs to be done with regard to geospatial 
location info.

Do we need something else?

Ciao
Hannes

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

---

From: [email-masked]
Date: Wed, 19 Apr 2006 17:02:58 -0500 (CDT)

In North America, validation is a well known, and required step in
processing a civic location.  In the current system, there is no
validation of geo.

In the end, validation in the current system means:
   Do we know where this location is; can we send someone to help
   by giving him this location?

To do that, there is presently a database, called the Master Street
Address Guide, which contains a list of all the "known" street addresses. 
Validation, today, means that before a location is put into the database
that is actually used to determine address when an emergency call is made
(the "ALI" database), the location is looked up in the MSAG.  If there is
a match, the update to the ALI is permitted.  If there is no match, the
update is not allowed and the carrier attempting to update the ALI has to
go figure out what happened.

The MSAG database sometimes also is aligned with the database used to
dispatch responders.  A location submitted to the responder Computer Aided
Dispatch system must be "MSAG Valid".

The emergency call system in North America is heavily dependent on
validation; many attempts at coming up with a location don't yield
something unique enough to use for locating where someone is unambiguously
so that help can be dispatched correctly to where they are when they can't
answer questions.  This is a firm requirement for us, and we really,
really need to have it.

The current MSAG would be the natural beginning source of the mapping
database envisioned by ecrit.  There are a whole host of formatting and
correlation issues.

It is essential that validation happen BEFORE an emergency call.  Ideally,
it would happen when it happens now; when a location is put into the
database that stores location (the Location Server).

Given the current design of the ecrit mechanisms, and accepted
requirements, the minimal way to do validation is to allow a mapping any
time (like when the location is put into the Location Server), and return
some kind of error when the location presented is not in the database.  So
validation means "I have no mapping for that location".

A better answer would be to have a mechanism in LoST specifically for
validation that could return more information than just "I have no
mapping".  For example, it would be helpful to return possible alternative
valid mappings.  A typical example is you query for "100 Main St" and the
mapping server returns "I don't have a 100 Main St, but I have a 100 N
Main St or 100 S Main St".  You could also return an indication of which
elements in the input location were valid (Country, State, and City was
valid, but Street Name was not).  It would also be useful to return
information not included in the original request (for example, you query
with the postal community name, but leave off county and jurisdictional
community name, if a unique mapping was found, the missing data was
supplied).

It would also be good to have a form of validation for geo, which amounts
to "there are no URIs for the service you requested with the <geo>
location you provided".  If you ask for police while you are in the middle
of the Atlantic Ocean, you might get that response.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Apr 2006 17:23:17 -0500

I agree with almost everything Brian says (surprise!), especially about how 
to work out additional info if a match isn't made.

I'm weary about how to pull this off for geo though, due to the rigidity of 
what doesn't constitute a match.  Given that GPS accuracy is roughly within 
15 ft after a few minutes and within a few feet after a bit longer (you get 
the idea of increasing accuracry with time), with some reports where they 
are might fall *just* outside of a valid location match, and return an 
error.  This might just occur for someone in the middle of the street, say 
at a car accident or a hurt child next to their bike, and no one wants this 
not getting through to a PSAP.

Geo almost should have a match to some PSAP if the caller is within a 
jurisdiction (say a country or state or province or county), and not only 
when they are at a street address that's nice and neat like civic 
addresses, but this is an interesting problem we haven't really gotten into 
to solve for yet, have we.

How does the Phase-II cellular world solve this validation question when 
presented with GPS coordinates to a wreck down a canyon road that has no 
(housing) lot addresses?

If this isn't solved for in an agreed upon way, this almost begs for a "Geo 
Considerations" ID to have a specific discussion about.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Apr 2006 22:05:06 +0200

Hi Brian,

thanks for the detailed explanation.
Let me focus on requirement specific to the mapping protocol:

* Allow a mapping any time

   No problem.

* Return an error when the location presented is not in the database 
(i.e., when the mapping from location to the URI is "Error - I have no 
mapping for that location"

   No problem.

Now, things get tricky when we want to provide some clever "debugging" 
mechanisms when the mapping protocol cannot provide offer a full match.

It might be possible to provide some useful error responses for civic 
information. For geospatial information I am not sure that this is 
particularly useful.

Since we are already working on the mapping protocol I would like to see 
a detailed algorithmic description of the type of error responses people 
  have in mind. Examples do not help.

Ciao
Hannes

PS: I would really like to avoid the term 'validation' since it is soo 
confusing. We can compile requirements without using the term validation 
at all.