[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