Re: [Ecrit] Location Validation

["Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig at nsn.com>]

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
 

>-----Original Message-----
>From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] 
>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-
>
>
>On 4/29/09 4:24 AM, "Hannes Tschofenig" 
><Hannes.Tschofenig at gmx.net> wrote:
>
>> 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
>> 
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit at ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit at ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>