Subject: [Ecrit] A compromise to move us forward

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 11:53:19 -0400

All,

While we might find an answer to the location hiding scenario in the  
long term, I think it is rather apparent that a near-term solution  
the satisfies all/most constituencies is unlikely to materialize.   
Caught in the middle of this is all the other work we've done.

I propose we do the following:

1) Move forward with the modest modifications to LoST to enable  
Henning's Location Fuzzing proposal (#1 on the wiki).
2) Note in some document somewhere (phonebcp, LoST, ecrit- 
framework... I don't care) how the location fuzzing proposal works  
and state that it is not ideal and a better solution is in the works.
3) Seek new charter items for a more thorough location-hiding solution.

-andy

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 20:08:08 +0200

Hi Andy

thank you for the proposal. Sounds good to me.

Ciao
Hannes

Andrew Newton wrote:
> long term, I think it is rather apparent that a near-term solution the 
> satisfies all/most constituencies is unlikely to materialize.  Caught 
> in the middle of this is all the other work we've done.
>
> 2) Note in some document somewhere (phonebcp, LoST, ecrit-framework... 
> I don't care) how the location fuzzing proposal works and state that 
> it is not ideal and a better solution is in the works.

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 5 Jun 2007 15:02:21 -0400

I would prefer that, in addition to moving forward with #1, we also
allow the LoST info to be returned via the L7 LCP. And use Richard's
proposal on how end points should work. Don't deal with the LoST reverse
look-up at this time. If national/state regulations permit use of LbyR +
PSAP URI (no LbyV at all), then those same regulations can publish PSAP
URIs for VSPs to use as look-up, and they can admit that VSPs based in
other countries are beyond their regulation and can charge for calls to
emergency services. I really don't think the EU can insist that US VSPs,
who provide US phone numbers, and market in the US, should be required
to provide free routing for emergency calls destined for the EU. If this
is done by treaty, then we ca agree to swap PSAP URI lists.

It's possible to deal with the VSP billing issue "out-of-band". Let the
regulators and effected parties decide if it's a problem. Just give us
the capability.
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2007 11:53 AM
To: ECRIT
Subject: [Ecrit] A compromise to move us forward

All,

1) Move forward with the modest modifications to LoST to enable
Henning's Location Fuzzing proposal (#1 on the wiki).
2) Note in some document somewhere (phonebcp, LoST, ecrit- framework...
I don't care) how the location fuzzing proposal works and state that it
is not ideal and a better solution is in the works.
3) Seek new charter items for a more thorough location-hiding solution.

-andy

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Liess, Laura" <[email-masked]>
Date: Tue, 5 Jun 2007 21:57:14 +0200

Andy,

I think it is a good idea.  

Thanks
Laura

> -----Ursprüngliche Nachricht-----
> Von: Andrew Newton [mailto:[email-masked]]
> Gesendet: Dienstag, 5. Juni 2007 17:53
> An: ECRIT
> Betreff: [Ecrit] A compromise to move us forward
> 
> 
> All,
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 16:00:50 -0400

Barbara,

Let's leave the details to item 3 for later.  Unless you are  
suggesting that we complete your proposal immediately... which is not  
what I'm proposing.

-andy

On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote:

> framework...
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential,  
> proprietary, and/or privileged material. Any review,  
> retransmission, dissemination or other use of, or taking of any  
> action in reliance upon this information by persons or entities  
> other than the intended recipient is prohibited. If you received  
> this in error, please contact the sender and delete the material  
> from all computers. GA625
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 5 Jun 2007 18:24:43 -0500

Andy,

I would like your point 2 to go a bit further.
I want it state that if the End-Point is provide the PSAP URI and a
location URI that it has to use those for the emergency call. This
should be in phone BCP. However the end-point gets this information I
agree is the subject of further work.

Cheers
James

> Sent: Wednesday, 6 June 2007 6:01 AM
> To: Stark, Barbara
> Cc: ECRIT
> Subject: Re: [Ecrit] A compromise to move us forward
> 
> Barbara,
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 20:48:48 -0400

James,

Your suggestion presupposes a solution for item 3, which is not in  
the spirit of what I proposed.

Besides, what does it mean that a client has to use a PSAP URI?  Does  
that mean it has to resolve the URI and attempt a connection or can  
it send that URI in an INVITE to an outbound proxy?

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 05 Jun 2007 20:11:34 -0500

James

what if the endpoint in question is provided more than one PSAP 
URI?  What then?

I think this falls into Andy's #3 to flesh out in another, future effort.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 5 Jun 2007 20:13:47 -0500

Andy,

If you cover item 3 in phone BCP now, then you don't need to revisit it
later, even if we don't have a standard way to provide this now. Note
that I am only interested in how the end-point behaves at this point,
not necessarily how any in-path call-server or a call-service provider
behaves.

To my mind solution 3 is providing a subset of the output of LoST
directly to the end-point. The end-point gets this information using the
same mechanism that it would use to obtain location if location provider
was prepared to give location.

So, what would the end-point do with the output of LoST, because it is
the same thing?

As I have said before, what an end-point does with "location-associated"
information in regards to emergency calling is in scope for ECRIT, how
it gets this information is not. So I question the need to recharter
ECRIT to address this issue at all as long as we accept how the
end-point should behave if it is only given "location-associated"
information.

Cheers
James

> Sent: Wednesday, 6 June 2007 10:49 AM
> To: Winterbottom, James
> Cc: Stark, Barbara; ECRIT
> >>> URIs for VSPs to use as look-up, and they can admit that VSPs
based
> > in
> >>> to provide free routing for emergency calls destined for the EU.
If
> >>> this
> >>> It's possible to deal with the VSP billing issue "out-of-band".
Let
> >>> the
> >>> regulators and effected parties decide if it's a problem. Just
give
> > us
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
> >
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 5 Jun 2007 20:15:58 -0500

Hi James,

What does the end-point do now if it gets this from LoST?
The issue is the same, and the end-point is in no better position to
determine which URI to use. So I don't see why this problem is either
complicated or obscured more by solution 3.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 6 June 2007 11:12 AM
> To: Winterbottom, James; Andrew Newton; Stark, Barbara
> Cc: ECRIT
> Subject: RE: [Ecrit] A compromise to move us forward
> 
> James
> 
> > > > look-up at this time. If national/state regulations permit use
of
> > > > LbyR +
> > > > PSAP URI (no LbyV at all), then those same regulations can
publish
> > > > PSAP
based
> > > > emergency services. I really don't think the EU can insist that
US
> > > > VSPs,
If
Let
give
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Liess, Laura" <[email-masked]>
Date: Wed, 6 Jun 2007 12:21:17 +0200

James,

I woudn't like clients sending emergency calls with URIs to our proxy without a reverse LOST mechanism in place, which enable us to verify the URI. It is not just the billing issue. I expect the regulation will require carriers to route unauthenticated emergency calls. I see here a risk for us to become a nice intermediary for all kind of SPIT, DoS, whatever.  Clients sending URIs together with reverse LOST are OK for me, but as I understand the reverse LOST needs more work.  I think Andy's proposal is for the moment a good compromise... 

Or do you see some error in my reasoning?

Laura

> Von: Winterbottom, James [mailto:[email-masked]] 
> Gesendet: Mittwoch, 6. Juni 2007 03:14
> An: Andrew Newton
> Cc: ECRIT
> Betreff: RE: [Ecrit] A compromise to move us forward
> 
> 
> Andy,
> 
> If you cover item 3 in phone BCP now, then you don't need to 
> revisit it later, even if we don't have a standard way to 
> provide this now. Note that I am only interested in how the 
> end-point behaves at this point, not necessarily how any 
> in-path call-server or a call-service provider behaves.
> 
> To my mind solution 3 is providing a subset of the output of 
> LoST directly to the end-point. The end-point gets this 
> information using the same mechanism that it would use to 
> obtain location if location provider was prepared to give location.
> 
> So, what would the end-point do with the output of LoST, 
> because it is the same thing?
> 
> As I have said before, what an end-point does with 
> "location-associated" information in regards to emergency 
> calling is in scope for ECRIT, how it gets this information 
> is not. So I question the need to recharter ECRIT to address 
> this issue at all as long as we accept how the end-point 
> should behave if it is only given "location-associated" information.
> 
> Cheers
> James
> 
> > Your suggestion presupposes a solution for item 3, which is 
> not in the 
> > spirit of what I proposed.
> > 
> > that mean it has to resolve the URI and attempt a 
> connection or can it 
> > send that URI in an INVITE to an outbound proxy?
> > 
> > -andy
> > 
> > > should be in phone BCP. However the end-point gets this 
> information
> I
> > >>> proposal on how end points should work. Don't deal with 
> the LoST 
> > >>> reverse look-up at this time. If national/state 
> regulations permit 
> > >>> use of LbyR +
> > >>> PSAP URI (no LbyV at all), then those same regulations 
> can publish
> > >>> PSAP
> > >>> other countries are beyond their regulation and can charge for 
> > >>> calls to emergency services. I really don't think the EU can 
> > >>> insist that US VSPs,
> > >>> and state that it
> > >>> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> > >>>
> > >>> *****
> > >>>
> > >> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > >
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information. If you 
> > > have received it in error, please notify the sender 
> immediately and 
> > > delete the original.  Any unauthorized use of this email is 
> > > prohibited.
> > >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 6 Jun 2007 08:46:00 -0400

I have to admit to being confused by this discussion about URLs. Any  
URL produced by whatever means is subject to the normal RFC 3261 and  
3263 process ("Locating SIP Servers"). Doesn't matter if the URL was  
copied off the side of a bus or was delivered by LoST or any other  
protocol. RFC 3261 and RFC 3361, along with any configuration  
mechanism (such as the ones being discussed in SIPPING), dictates  
whether an outbound proxy is used and which one. None of this changes  
just because this is an emergency call.

Henning

On Jun 6, 2007, at 6:21 AM, Liess, Laura wrote:

> James,
>
> I woudn't like clients sending emergency calls with URIs to our  
> proxy without a reverse LOST mechanism in place, which enable us to  
> verify the URI. It is not just the billing issue. I expect the  
> regulation will require carriers to route unauthenticated emergency  
> calls. I see here a risk for us to become a nice intermediary for  
> all kind of SPIT, DoS, whatever.  Clients sending URIs together  
> with reverse LOST are OK for me, but as I understand the reverse  
> LOST needs more work.  I think Andy's proposal is for the moment a  
> good compromise...
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 6 Jun 2007 08:49:06 -0400

I would consider it more efficient, as a VSP, to have a cached list of known, valid PSAP URIs, than to do a reverse LoST query for every emergency call. If a nation wants to allow LbyR-only responses to endpoints, then it needs to make its PSAP URIs known.

I think reverse LoST would be a nice feature, but I don't see it as necessary. Initially, the utopian view of a worldwide LoST network won't exist, anyway. It will be possible for a VSP to get a call to a completely valid foreign PSAP URI, but not be able to validate that URI either through reverse LoST or through regular LoST look-up of a coarse location. If the Forest Guide pointers (or whatever they are) don't exist for a VSP to get to the correct foreign LoST server, then the VSP will be unable to validate the URI. I'm pretty sure I've read somewhere on this list that Forests will most likely initially grow in disconnected clumps -- but please correct me if I'm wrong here.

Independent of whether we do scenario 1 or 3, the case will exist where the VSP cannot validate the PSAP URI. Therefore, it is imperative that regulators specifically address this case (unvalidated PSAP URI) and its desired behavior, independent of which scenario is implemented. It will exist.

The VSP must also determine its billing policy for this case, no matter what.
Barbara

-----Original Message-----
From: Liess, Laura [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 6:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: AW: [Ecrit] A compromise to move us forward

James,

Laura

> If you cover item 3 in phone BCP now, then you don't need to revisit 
> it later, even if we don't have a standard way to provide this now. 
> Note that I am only interested in how the end-point behaves at this 
> point, not necessarily how any in-path call-server or a call-service 
> provider behaves.
> 
> directly to the end-point. The end-point gets this information using 
> the same mechanism that it would use to obtain location if location 
> provider was prepared to give location.
> 
> "location-associated" information in regards to emergency calling is 
> in scope for ECRIT, how it gets this information is not. So I question 
> the need to recharter ECRIT to address this issue at all as long as we 
> accept how the end-point should behave if it is only given 
> "location-associated" information.
> 
> Cheers
> James
> 
> > >>> insist that US VSPs, who provide US phone numbers, and market in 
> > >>> the US, should be
> > > required
> privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender immediately 
> and delete the original.  Any unauthorized use of this email is 
> prohibited.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Ted Hardie <[email-masked]>
Date: Wed, 6 Jun 2007 15:11:41 -0700

At 11:53 AM -0400 6/5/07, Andrew Newton wrote:
>All,
>
>While we might find an answer to the location hiding scenario in the long term, I think it is rather apparent that a near-term solution the satisfies all/most constituencies is unlikely to materialize.  
>1) Move forward with the modest modifications to LoST to enable Henning's Location Fuzzing proposal (#1 on the wiki).
>2) Note in some document somewhere (phonebcp, LoST, ecrit-framework... I don't care) how the location fuzzing proposal works and state that it is not ideal and a better solution is in the works.
>___

I agree with this.  After reading through the rest of the thread, I'm pretty convinced
that a solution in the space covered by #3 is going to take some time to bake.  We
need to finish off LoST and get it out the door; this allows us to do that and still
develop a more elegant solution in the future.
					Ted

---

From: Andrew Newton <[email-masked]>
Date: Sat, 9 Jun 2007 10:13:20 -0400

> 3) Seek new charter items for a more thorough location-hiding  

Since I proposed this compromise, there have been many suggestions  
about how to accomplish goal #3 above.  I think it is fair to say  
that with so many ideas and proposals, we are unlikely to discuss  
them all and come to resolution and conclusion within a short  
timeframe.  Is there anyone who disagrees with this assessment?

Is there anyone who does not agree with the proposal stated above on  
how to move this working group forward?

-andy