Subject: [Ecrit] Location Validation

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 29 Apr 2009 11:24:28 +0300

Hi all, 

There was an interesting today in the NENA ECRF LVF Working Group phone
conference all about location validation and the definition of it. 

Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the term
location is: 

   Location validation:  A caller location is considered valid if the
      civic or geographic location is recognizable within an acceptable
      location reference system (e.g., United States Postal Address or
      the WGS-84 datum) 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, but rather may only
      ensure that the location falls within some range of known values.
      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.

This definition is useful for geo- and civic location information. 

The LoST specification, see Section 8.4.2 of
http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling the
check whether an address maps to a PSAP URI. We provided this functionality
in response to the interaction we had with NENA. 

LoST determines whether there is an civic address in an address database
that corresponds to the civic address provided in the request (using the
<valid>, <unchecked> and <invalid> elements). 

In the conf. call then the differentiation between 'location validation for
routing' and location validation for dispatch' was made. The former would
match the definition in RFC 5012 while the latter is more related to the
question whether a particular civic address exists so that dispatched first
responders can actually go there. 

Do we need to need to clarify or enhance our definition of location
validation? 

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Apr 2009 08:07:31 -0400

I'm sorry I wasn't on that call but the LoST definition is sufficient
because it doesn't differentiate.

Within the NENA i3 effort, we have defined valid as there is exactly one
point in the LoST database that matches the fields supplied by the PIDF with
sufficient accuracy to dispatch a responder.  That means if you give us, for
example, a street name and number, a state and a country, if it happens that
there is only one street with that name in the state, and there is an
address point with that street number, then the location is valid.  Of
course, we would prefer all of the fields to be present, but as long as we
locate a single dispatchable location, it's valid.  Correspondingly, if you
gave every field but the street name suffix, and there were two streets
within that community, neighborhood and zipcode that differed only in the
suffix, then it isn't valid.  The database has every valid address point,
represented by a point or polygon, with attributes or polygons on other
layers that define all of the required PIDF elements above the address point
(postal code, municipality, ....

As you can see, valid is dispatch valid.  If you supplied a location that
turned out to be accurate enough to determine which PSAP should get the
call, then you would have a route valid location, but it would not validate
in a North American LoST server.

Technically, the definition says "within an acceptable location reference
system", which for North America will be the LoST database map, or a geo
with WGS84 datum, which has a regulatory accuracy requirement.  It also says
"and can be mapped to one or more PSAPs", which gets the route validity
test.

So, I don't think a change is needed.

I do think we should consider allowing the server to return possible
interesting information if a location is not valid.  In North America, we
will return a PIDF with all the fields if the location is valid: if you
don't send in a value for a field, but the LoST server determines what you
did send is valid, we return all the other fields.  We would like to return
some possible valid locations if the PIDF submitted is invalid ("There is no
Main Ave, but we have a Main St or a North Main Ave").

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Wednesday, April 29, 2009 4:24 AM
To: 'ECRIT'
Subject: [Ecrit] Location Validation

Hi all, 

Ciao
Hannes

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

---

From: Marc Linsner <[email-masked]>
Date: Wed, 29 Apr 2009 09:05:36 -0400

Hannes,

We had discussions around this topic 'way back when'.  I agree with Brian,
we don't need to change anything.  We designed the support of validation
within LoST to return any/all tags that were found to be 'in the database'.
If in fact a tag is found valid but not suitable for dispatch, it's a
database problem.  Concerned parties should pay close attention to this LoST
feature and how the database is constructed.  If a tag is found to be not
valid, then it's up to the provider/source of the location determination to
fix it.  Obviously the protocol can't nor shouldn't try to force such a
'fix'.

-Marc-

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 29 Apr 2009 16:11:34 +0300

Hi Brian, Hi Marc, 

The problem is that the definition in RFC 5012 does not correspond to
the usage of the term in LoST. The same term 'validation' means
different things in these two documents.
 
The definition used in the NENA i3 document does not seem to correspond
to RFC 5012 either. 

The source of the confusion is the lack of differentiation between
validation for routing and validation for dispatch. 

I am not saying that any of the protocol mechanisms should be changed. 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Marc Linsner
>Sent: 29 April, 2009 16:06
>To: Hannes Tschofenig; 'ECRIT'
>Subject: Re: [Ecrit] Location Validation
>
>Hannes,
>
>We had discussions around this topic 'way back when'.  I agree 
>with Brian, we don't need to change anything.  We designed the 
>support of validation within LoST to return any/all tags that 
>were found to be 'in the database'.
>If in fact a tag is found valid but not suitable for dispatch, 
>it's a database problem.  Concerned parties should pay close 
>attention to this LoST feature and how the database is 
>constructed.  If a tag is found to be not valid, then it's up 
>to the provider/source of the location determination to fix 
>it.  Obviously the protocol can't nor shouldn't try to force 
>such a 'fix'.
>
>-Marc-
>
>
>> There was an interesting today in the NENA ECRF LVF Working Group 
>> phone conference all about location validation and the 
>definition of it.
>> 
>> Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the 
>> term location is:
>> 
>> http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling 
>> the check whether an address maps to a PSAP URI. We provided this 
>> functionality in response to the interaction we had with NENA.
>> 
>> LoST determines whether there is an civic address in an address 
>> database that corresponds to the civic address provided in 
>the request 
>> (using the <valid>, <unchecked> and <invalid> elements).
>> 
>> In the conf. call then the differentiation between 'location 
>> validation for routing' and location validation for dispatch' was 
>> made. The former would match the definition in RFC 5012 while the 
>> latter is more related to the question whether a particular civic 
>> address exists so that dispatched first responders can 
>actually go there.
>>

---

From: Marc Linsner <[email-masked]>
Date: Wed, 29 Apr 2009 09:20:09 -0400

Hannes,

I don't see any differentiation required in our documents.  From a protocol
perspective, there are no differences between a 'valid for routing' location
and a 'valid for dispatch' location.  Each tag is evaluated on whether there
is a matching value in the database.  The results of a non-match are of no
consequences to LoST.  The actions taken based on the non-match are outside
of IETF purview.

I suggest that NENA provide procedures on the consequences of the various
types of validation matches/non-matches.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Apr 2009 09:47:47 -0400

Agree.  The definition in 5012 is accurate, and no IETF action on
definitions is warranted in my opinion.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Linsner
Sent: Wednesday, April 29, 2009 9:20 AM
To: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; ECRIT
Subject: Re: [Ecrit] Location Validation

Hannes,

-Marc-