Subject: RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

From: "Reese, Theresa E" <[email-masked]>
Date: Fri, 9 Feb 2007 10:18:09 -0500

Hannes, Marc - 

Actually, this raises another whole issue. 

In the context of i3, location validation and routing are separable
functions.  There will be instances where only routing information is
desired (as I previously discussed), and there will also be instances
where only location validation information is desired.  An example of
the latter case is where a Location Information Server (LIS) queries a
Validation Function to validate location information before storing it.
(In some implementations, a LIS serves as a repository for location
information.  The LIS is configured with mappings between location
information and the logical representations of the physical locations
with which they are associated. The LIS operator is responsible for
ensuring that civic location data is pre-validated by a Validation
Function. The LIS may be used during location determination and
acquisition.)

Another example of when it would be desirable to request validation
without routing is when a PSAP, upon interacting with a caller, is given
location information that is different from the location information
delivered with the call. The PSAP would want the ability to validation
the caller-provided location information by accessing a Validation
Function.

With lost-02, it was possible, in a <findService> message to explicitly
identify, via the 'include' element, whether validation information was
being requested, routing information was being requested, etc.  With
lost-03, it is possible to explicitly request validation information,
but a request for routing information is implicit in every <findService>
request.  It is no longer possible to only request validation
information - - a need that is still present in the context of i3.  

To address your question of how a client would be able to discover a
server that does validation vs. one that does routing - - in i3 (and i2
for that matter) there is a root discovery mechanism defined that would
allow a client to learn the address of the server that provides the
desired service.  Providers of validation and routing services would be
responsible for communicating the identity, URL, coverage of their
service area(s) to the host of the root discovery service, and the host
of the root discovery service will publish a URL that can be used by
clients for discovering validation or routing services. 

I would appreciate your thoughts on these issues, and also any
information you could provide on what motivated the removal of the
'include' element in going from lost-02 to lost-03.

Thank you.

Terry

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, February 08, 2007 3:29 PM
To: Marc Linsner
Cc: Reese, Theresa E; [email-masked]
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

I would like to learn more about this aspect as well.

Ciao
Hannes

> Terry,
>
>   
>> [TER]  Location validation is still a necessary part of the NENA i3
>> Solution.  However, in the context of the i3 Solution, it is assumed
>> that the validation can be performed independently of call 
>> routing, and
>> that it will be done prior to an emergency call origination. 
>> The server
>> that supports the validation request may not necessarily be 
>> the same as
>> the server that supports emergency call routing requests.  When an
>> emergency call is originated, a query to the Emergency Call Routing
>> Function (routing server) will be attempted using the pre-validated
>> location information.  
>>
>>     
>
> What is your expectation of the LoST client being able to
> discover/distinguish between a routing LoST server and validation LoST
> server?
>
> Thanks,
>
> -Marc-
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
>   

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

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 9 Feb 2007 16:01:18 -0500

Terry,

> 
> To address your question of how a client would be able to 
> discover a server that does validation vs. one that does 
> routing - - in i3 (and i2 for that matter) there is a root 
> discovery mechanism defined that would allow a client to 
> learn the address of the server that provides the desired 
> service.  Providers of validation and routing services would 
> be responsible for communicating the identity, URL, coverage 
> of their service area(s) to the host of the root discovery 
> service, and the host of the root discovery service will 
> publish a URL that can be used by clients for discovering 
> validation or routing services. 
> 

There seems to be a disconnect between the ecrit requirements for LoST and
what you have outlined here, at least IMO.  The main requirement driving
validation in LoST is:

'Lo4.  Validation of civic location: The mapping protocol MUST support
      location validation for civic locations (street addresses).

      Motivation:  Location validation provides an opportunity to help
      ascertain ahead of time whether or not a successful mapping to the
      appropriate PSAP will likely occur when it is required.
      Validation may also help to avoid delays during emergency call
      setup due to invalid location data.'

It seems now you are proposing a requirement that LoST support a separate
function for validation including a separate discovery mechanism, is this
correct?

I would be curious what the perceived benefit would be to separating these
functions, especially since they reference the identical data.

In reviewing the NENA documents you referenced, I'm confused how that root
discovery mechanism (v9?) might work, but that's not the issue here.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 10 Feb 2007 15:21:15 -0500

A brief comment:

The existing LoST (04) spec easily supports the separation of  
validation and lookup, if that is desired.

- Validation can be requested explicitly.

- The service URI is optional. Thus, a validation-only server would  
simply not return that URI (or the service boundary).

If a LoST server supports both validation and mapping, the cost of  
including a service URI or a service boundary reference is  
essentially zero, so there is no advantage in offering an explicit  
request for this information, just additional complexity.

(I'm still unsure as to why separating the two functions would be a  
good idea, but that's a separate discussion.)

Henning

---

From: Andrew Newton <[email-masked]>
Date: Sat, 10 Feb 2007 15:33:16 -0500

> good idea, but that's a separate discussion.)

Actually, that is a good question.  We seem to be taking stabs in the  
dark regarding the satisfaction of some NENA requirements that are,  
to my knowledge, not publicly available.  If NENA wants the IETF to  
create a protocol that meets its requirements, they need to make the  
requirements publicly available.

And I can't help but wonder why the separation of the validation  
function from the mapping function is such a big deal.  My  
understanding was that validation required mapping, which means  
returning the URI.  Otherwise trying to determine if a particular  
civic address is mapping to the proper PSAP would be difficult.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Feb 2007 23:06:05 +0100

Hi Andy

Andrew Newton wrote:
> dark regarding the satisfaction of some NENA requirements that are, to 
> my knowledge, not publicly available.  If NENA wants the IETF to 
I don't really know what I should say. Many things come to my mind but 
nothing that really helps....

> civic address is mapping to the proper PSAP would be difficult.
I agree.

Ciao
Hannes

> -andy
> ------------------------------------------------------------------------
>