Re: [Ecrit] Location Validation

["Brian Rosen" <br at brianrosen.net>]

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

Brian

-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] 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,

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- 


On 4/29/09 9:11 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<hannes.tschofenig at nsn.com> wrote:

> 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
>> 


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit