[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] Location Validation



I agree with Marc L on this and have issues with the manner that the LVF work group is defining a valid location.
Marc B

----- Original Message -----
From: ecrit-bounces at ietf.org <ecrit-bounces at ietf.org>
To: Hannes Tschofenig <Hannes.Tschofenig at gmx.net>; 'ECRIT' <ecrit at ietf.org>
Sent: Wed Apr 29 08:05:36 2009
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