Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00

From: "Reese, Theresa E" <[email-masked]>
Date: Fri, 2 Mar 2007 07:43:36 -0500

Brian -

One comment in-line.

Terry Reese

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 8:39 PM
To: 'Shida Schubert'
Cc: 'ECRIT'
Subject: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00

I'm editing -framework and resolving comments.

See in line for my responses

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]]
> Sent: Sunday, November 05, 2006 6:55 PM
> To: [email-masked]
> Cc: Henning Schulzrinne; [email-masked]
> Subject: Comments on draft-ietf-ecrit-framework-00
> 
> 
> Hi;
> 
>  Few comments on the draft.
> 
>  1. What is the early URL? I can guess what this is but I think
>     it should be clarified somewhere as it
I removed the "early".  It's just a URI now.
> 
>  2. Section 3, 4th paragraph explains how the proxy(ESRP)
>    would query the LoST server to resolve a Service URN but
>    this is based on the assumption that the URI in the route header
>    addressing the PSAP(assuming we are using the loose-route
>    Jonathan proposed.) is stale. But is it really? And how do we
>    know. There is no indication to show how fresh the psap-URI
>    is. So UA can literally have obtained a new psap-URI just before
>    it initiated an emergency call but according to the draft, ESRP or
>    proxy would still redo the mapping.. Worse yet, because there is
>    no indication that mapping has been accomplished, we may see
>    multiple proxies redoing the mapping as it can't tell if the
mapping
>    has been executed already.. I don't know if there is any resolution
>    to this and I actually don't know if this is really a problem but I
> figured
>    I should share my concern..
I'm in the midst of changing the example to be endpoint routed, rather
than
proxy routed.  We want to promote the endpoint routed model anyway.
This
should eliminate the confusion in the text.  I think we need an
unambiguous
indication that LoST mapping has been done.  We should discuss this
point.

[TER]  It should be made clear that the presence of such an indication
should in no way constrain a subsequent proxy from querying a LoST
server.  As we have discussed in the NENA Long Term Definition Working
Group, it is very likely that emergency call routing will involve
multiple queries being done by ESRPs of different levels (e.g., state,
county, city), with the potential for each to result in different
routing information.
 
> 
>  3. Section 5.8 talks about location being validated prior to a device
> placing
>    an actual emergency call. I don't understand what the text is
trying
> to say here.
>    How could the validation take place without the actual request?? I
am
> probably
>    being stupid here and not fully understanding the text here so
> clarification would
>    be much appreciated.
If you read on, you will see that the real validation is loading the
value
IN to the LIS.  The endpoint can revalidate when it gets location (which
is
boot time and when it is reading location from the LIS), and any time
thereafter.

> 
>  4. Section 16.5. Call Signaling Integrity I think is better provided
by
> SIP-Identity,
>    which can provide over some headers and message body end-to-end
over
> TLS
>    which only provides integrity hop-by-hop. You already recommend the
> use of
>    sip-identity to provide caller-authentication, it won't hurt to
> recommend its use
>    to provide signaling integrity.
Well, most of the text talks about maintaining the privacy of the
location
header, but I added text for the integrity protection Identity would get
you.

Thanks
Brian

_______________________________________________
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: "Brian Rosen" <[email-masked]>
Date: Fri, 2 Mar 2007 08:15:16 -0500

Sure.  We're just trying to make sure that proxies who try to be helpful
don't screw up when a prior element already did the dip.  The reliability of
the information tends to go down the farther you get from the endpoint.  

Brian

> From: Reese, Theresa E [mailto:[email-masked]]
> Sent: Friday, March 02, 2007 7:44 AM
> To: Brian Rosen; Shida Schubert
> Cc: ECRIT
> Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00
> 
> Brian -
> 
> One comment in-line.
> 
> Terry Reese
>