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

From: "Reese, Theresa E" <[email-masked]>
Date: Fri, 9 Feb 2007 17:29:04 -0500

Marc -

My responses, in-line.

Terry

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, February 09, 2007 4:01 PM
To: Reese, Theresa E
Cc: [email-masked]
Subject: RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

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.'
>
[TER]  The comparable requirement in the i3 TRD says the following:

"Validation 0100-0100: It must be possible to determine BEFORE an
emergency call is placed, if civic address is valid."

The concept of doing validation during call setup is not required or
assumed  in the i3 TRD. 

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

 [TER]  What I have described is not new in the context of the i3
Solution.  It is what is documented in the TRD and draft i3
specification as i3 Solution functionality.  If LoST is to be used to
support i3, and in particular to serve as the interface to the
Validation Function, then there is a need for it to support requests for
location validation that are decoupled from requests for emergency call
routing.  

A Root Discovery function is also described in the i3 TRD.  It is
defined to be "used by entities to discover the appropriate Location
Validation Function or Emergency Call Routing Function for a given
location."   To date I am not aware of anyone that has proposed the use
of LoST for root discovery.

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

[TER]  Are you referring to whether or not both of these functions are
implemented in the same box?  The i3 Solution doesn't specify one way or
the other.  If you are referring to whether or not there are cases where
either the location validation function OR the validation function would
need to be accessed, BUT NOT BOTH, I believe I described such scenarios
in my previous e-mail.

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

[TER]  We have been working in the NENA i2.5 WG to clarify the
definition of the root discovery mechanism and the V9 interface.  The
clarifications will be reflected in an update to NENA 08-001.    

-Marc-

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

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 9 Feb 2007 19:09:47 -0500

Terry,

> "Validation 0100-0100: It must be possible to determine 
> BEFORE an emergency call is placed, if civic address is valid."

I believe LoST-03 supports this requirement.

> 
> The concept of doing validation during call setup is not 
> required or assumed  in the i3 TRD. 

OK
  
>  [TER]  What I have described is not new in the context of 
> the i3 Solution.  It is what is documented in the TRD and 
> draft i3 specification as i3 Solution functionality.  If LoST 
> is to be used to support i3, and in particular to serve as 
> the interface to the Validation Function, then there is a 
> need for it to support requests for location validation that 
> are decoupled from requests for emergency call routing.

This is new to ecrit.  So what you are asking for is a whole separate query
that includes location validation and specifically excludes routing data?
BTW, I very quickly did a find (validat) in both NENA docs and found that
validation and routing are discussed separately, but did not find anything
to requires them to be separate.  Did I miss something (very possible, I did
a very quick look)?
 
> 
> A Root Discovery function is also described in the i3 TRD.  
> It is defined to be "used by entities to discover the 
> appropriate Location Validation Function or Emergency Call 
> Routing Function for a given

OK, I believe that LoST resolver discovery is a LoST client configuration
issue.  Authoritative data discovery performed by a LoST resolver is covered
in the Mapping Arch draft.  What I hear you asking for is a parallel/like
system dedicated for the sole purpose of validation?

> [TER]  Are you referring to whether or not both of these 
> functions are implemented in the same box?  The i3 Solution 
> doesn't specify one way or the other.  If you are referring 
> to whether or not there are cases where either the location 
> validation function OR the validation function would need to 
> be accessed, BUT NOT BOTH, I believe I described such 
> scenarios in my previous e-mail.

I assume this is a typo, you meant 'validation function OR the routing
function'.  If assumption is correct, you described use cases where a LoST
client may be interested in only validation or only routing data.  This is
handled in LoST-03, the client simply ignores the data not required (the
beauty of xml tags :^)).

So I'm not yet clear on what you are asking for, the use cases you describe
are, IMO, are handled with LoST-03, but yet you list a requirement to
separate validation from routing.

-Marc-