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

From: "Reese, Theresa E" <[email-masked]>
Date: Fri, 2 Mar 2007 08:18:28 -0500

Brian -

In the context of a multi-level ESRP model, I don't agree that
"reliability of the information tends to go down the farther you get
from the endpoint."

Terry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, March 02, 2007 8:15 AM
To: Reese, Theresa E; 'Shida Schubert'
Cc: 'ECRIT'
Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00

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

> -----Original Message-----
> 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
> 
> -----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:38:15 -0500

Ah, we're talking past each other. 

I'm referring to proxies in the origination network, not in the emergency
services network.  Agree that within the emergency services networks, you
may well do multiple levels of location based routing.  State level ESRPs to
PSAPs, PSAP ESRP to call takers.

Brian

> Sent: Friday, March 02, 2007 8:18 AM