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

["Marc Linsner" <mlinsner at cisco.com>]

Terry,

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

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

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
> location."   To date I am not aware of anyone that has 
> proposed the use
> of LoST for root discovery.

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?

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

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-


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