Subject: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04

From: James Winterbottom <[email-masked]>
Date: Fri, 25 Jul 2014 09:02:50 +1000

Hi All,

This is a bit of rant, for which I am only partially apologetic because Laura and I first presented the need for this draft more than years ago when there was time for a debate. I think that that time has largely passed now. I sent emails to the list at the end of May and the start of June asking for feedback on this draft and again stated why it was needed and got next to zero response back.

http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html
http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html

The specification that is dependent on a solution to this problem has a milestone set for end of 1H15.
There simply isn’t time to have a 3 month mailing list debate on this topic and then “maybe” have something that can be adopted in the nov/dec timeframe.
If this topic can move “very quickly” then I see some benefit in continuing a discussion, otherwise I see little point as decisions to address the need will be made elsewhere.

Cheers
James

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 28 Jul 2014 13:19:55 +0000

The milestone you are referring to is a document so far from the IETF approach on emergency calls that I fail to see the benefit of getting one protocol, HELD, used by the group pushing this architecture.  

I am convinced we will need to support an environment where it is not acceptable to have the end device in the path for location.  The level of paranoia about that is so high, if we want to make progress in the countries where it exists, we need to do something.  In some of these environments, it’s unacceptable to have the CSP get location.  Using HELD with some non-IP identifier to get location by reference works okay.  What is needed is a way for routing to work.  This can be done in two ways.  One is allowing HELD to return route, which is how this doc does it.  The other is to allow LoST to do LbyR.  I prefer the latter, but would be willing to go along with the HELD mechanism if consensus was to do it that way.  Please don’t use the “one less query” argument.  It just moves the route query from the CSP to the LIS.  

Brian

On Jul 24, 2014, at 7:02 PM, James Winterbottom <[email-masked]> wrote:

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

---

From: James Winterbottom <[email-masked]>
Date: Tue, 29 Jul 2014 06:27:56 +1000

I totally disagree with your opening statement Brian.

The IETF approach allows a VSP to acquire the endpoint location and obtain routing information to the correct ESRP. This option allows exactly this, but it adds the advantages or being a single query AND allowing not requiring a trust relationship between the LS and the VSP. If anything it enhances the security of the ECRIT proposal.

LoST with LbyR is not going to meet the European needs, and on top of this LoST using LbyR breaks the moment you introduce forest guides or don’t have the authoritative server at the get-go. Which, you won’t. Please don’t try and push this solution, it won’t address what is needed and any work done will go the way of rough location. There really is not time for a 5 year debate on this topic only for the IETF to come around in the end like other protocol suggestions that I won’t name!

Let’s be clear about a LIS holding civic address record EVEN in a LoST-based environment. If, the LIS is required to validate records then, if it ued LoST to do this it has EXACTLY and same informant that any public LoST server would have, including the expiry times for the bindings. Quite simply it has everything you need. What possible conceivable benefits are there is forcing a to query approach except that you want to delay the call from getting through or want to divulge location values to entities that may not be entitled to see them?

This debate should have happened 2 years ago. LbyR for LoST simply doesn’t work. 

Cheers
James

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 28 Jul 2014 20:44:12 +0000

Anyone who has access to the document is welcome to make their own
judgement on what I said.

LbyR in LoST allows the VSP to acquire an endpoint location reference and
obtain routing information to the correct ESRP.  It does¹t require a trust
relationship between the LS and the VSP.

LoST using LbyR would work just fine with forest guides.  The forest guide
would have to accept LbyR, but since it uses LoST as its interface, no
problem if that¹s the way we decide to do it.

You need an authoritative route server that accepts geo and civic
addresses and returns SIP URIs.  If your interface to that server isn¹t
LoST, it has to be something that duplicates it pretty closely.

Routes should not be static.  Things can change, and especially, in
disaster situations, routes can change with no notice.  The route you get
at validation may not be the route you get when you query at call time.
LoST provides a TTL, but its a TTL on the binding, not the validation.
Civic addresses validation can change, and the fact that we don¹t have a
way to push a change from the validation server back to the entity that
validated is a problem.  -planned-changes addresses that.  Of course, you
are only discussing civic addresses (geos don¹t get validated), so using
the validation query to obtain route doesn¹t work with geos.

None of this changes anything.  LoST LbyR is as least as good of a
solution as HELD-returns-route.  HELD-returns-route has to have the TTL,
the boundary, and the other LoST return things to be useful.

Brian

On 7/28/14, 4:27 PM, "James Winterbottom" <[email-masked]>
wrote:

>The IETF approach allows a VSP to acquire the endpoint location and
>obtain routing information to the correct ESRP. This option allows
>exactly this, but it adds the advantages or being a single query AND
>allowing not requiring a trust relationship between the LS and the VSP.
>If anything it enhances the security of the ECRIT proposal.
>
>LoST with LbyR is not going to meet the European needs, and on top of
>this LoST using LbyR breaks the moment you introduce forest guides or
>don¹t have the authoritative server at the get-go. Which, you won¹t.
>Please don¹t try and push this solution, it won¹t address what is needed
>and any work done will go the way of rough location. There really is not
>time for a 5 year debate on this topic only for the IETF to come around
>in the end like other protocol suggestions that I won¹t name!
>
>Let¹s be clear about a LIS holding civic address record EVEN in a
>LoST-based environment. If, the LIS is required to validate records then,
>if it ued LoST to do this it has EXACTLY and same informant that any
>public LoST server would have, including the expiry times for the
>bindings. Quite simply it has everything you need. What possible
>conceivable benefits are there is forcing a to query approach except that
>you want to delay the call from getting through or want to divulge
>location values to entities that may not be entitled to see them?
>
>This debate should have happened 2 years ago. LbyR for LoST simply
>doesn¹t work. 
>
>Cheers
>James
>
>
>
>
>
>> The milestone you are referring to is a document so far from the IETF
>>approach on emergency calls that I fail to see the benefit of getting
>>one protocol, HELD, used by the group pushing this architecture.
>> 
>> I am convinced we will need to support an environment where it is not
>>acceptable to have the end device in the path for location.  The level
>>of paranoia about that is so high, if we want to make progress in the
>>countries where it exists, we need to do something.  In some of these
>>environments, it¹s unacceptable to have the CSP get location.  Using
>>HELD with some non-IP identifier to get location by reference works
>>okay.  What is needed is a way for routing to work.  This can be done in
>>two ways.  One is allowing HELD to return route, which is how this doc
>>does it.  The other is to allow LoST to do LbyR.  I prefer the latter,
>>but would be willing to go along with the HELD mechanism if consensus
>>was to do it that way.  Please don¹t use the ³one less query² argument.
>>It just moves the route query from the CSP to the LIS.
>> 
>> Brian
>> 
>>> This is a bit of rant, for which I am only partially apologetic
>>>because Laura and I first presented the need for this draft more than
>>>years ago when there was time for a debate. I think that that time has
>>>largely passed now. I sent emails to the list at the end of May and the
>>>start of June asking for feedback on this draft and again stated why it
>>>was needed and got next to zero response back.
>>> 
>>> There simply isn¹t time to have a 3 month mailing list debate on this
>>>topic and then ³maybe² have something that can be adopted in the
>>>nov/dec timeframe.
>>> If this topic can move ³very quickly² then I see some benefit in
>>>continuing a discussion, otherwise I see little point as decisions to
>>>address the need will be made elsewhere.
>>> 
>>> Cheers
>>> James
>>> 
>>> 
>>>

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Mon, 28 Jul 2014 20:58:39 +0000

James,

(with wg chair hat off)

The IETF ECRIT architecture is designed to provide a clean approach to
enabling emergency calls in the multi-layered Internet, by allowing the
service provider of each layer to perform functions reasonably adaptable
to their discipline.  Forcing a L2/L3 provider to be responsible for
emergency call routing is a "layer violation" that we normally don¹t go
out of our way to support.

Reverse-engineering requirements to the benefit of a non-layered solution
will be temporary at best.

-Marc-

---

From: James Winterbottom <[email-masked]>
Date: Tue, 29 Jul 2014 06:59:55 +1000

inline:

> relationship between the LS and the VSP.
[AJW] Huh??  Which LoST server does the VSP contact in your scenario? The ANP won’t have put any record into the DNS for its domain and even if it did that domain span several geographic areas LbyR in LoST can’t recurse or redirect.. BREAK.. The only way that it could work would require the ANP to establish its own LoST server and simply spit back the records from the LS anyway. Why is this being made as two queries again?

> problem if that¹s the way we decide to do it.
[AJW] This means that any forest guide anywhere in the world is allowed to get location from any LS in the world using an LbyR. This has huge security and privacy implications apart from the fact imposing certain constraints in countries that may well not want or need these constraints.
The problem with deciding to it that was is that you will end up in the same position as with rough location after 2 years of debate, by which time an alternative will have been found an used.

> LoST, it has to be something that duplicates it pretty closely.
[AJW] No, we don’t really need that. In the US you have highly-structured civic addresses, for most of the rest of the world they don’t. In countries like German, ESRP addresses will be based on who the ANP is, not necessarily the area served by the ANP. In the mobile case, point of attachment is good enough usually to get to the ESRP, again, I don’t need a complex route server, just a table. 

> LoST provides a TTL, but its a TTL on the binding, not the validation.
[AJW] Is this or is this not used by servers that cache the data and can return a response?

> the validation query to obtain route doesn¹t work with geos.
[AJW] The route is no more static in the proposal I have made than it would using forest guides or ached data sets.

> the boundary, and the other LoST return things to be useful.
[AJW] See above, I have still not heard from anyone how the will work despite having asked a number of times.

---

From: James Winterbottom <[email-masked]>
Date: Tue, 29 Jul 2014 07:04:19 +1000

Hi Marc,

The IETF architecture already quasi-requires them to do this.
They need to put a UNAPTR record for their domain into the DNS to enable LoST to work for their domain.
They need to ensure that civic address information will work with the LoST server so that the call gets to the right ESRP.

These are quasi-routing requirements placed on the ANP. 
If you introduce LbyR to LoST then you now require them to have a LoST server interface too.

So quite honestly, I think it is a real stretch to say that we don’t place routing requirements on ANPs today.

Cheers
James

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 28 Jul 2014 21:22:46 +0000

Inline

From: James Winterbottom <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 28, 2014 at 4:59 PM
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Cc: "ecrit_ietf.org" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04

inline:

On 29 Jul 2014, at 6:44 am, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

<br>The VSP contacts any LoST server.  Using recursion or iteration, it gets to the authoritative one.  If LoST does LbyR, then the VSP gets an LbyR by querying the LS.  It then queries any LoST server to get route.

<br>Spare me the polemics.  Yes, the route infrastructure has to be trusted.  The LS can return something appropriately rough, with no standardization, to an FG or a LoST server it doesn’t recognize, if it wants to.  Any point in the country, for example.  Recursion would probably be required if everyone was paranoid about location.  Note that the VSP can figure out location to a country with the route URI, no leakage there.

<br>In the US, like most places, you route by cell and sector, but the way that is mechanized is the cell and sector is turned into some kind of location – a civic or a geo.  The LoST database can be a simple table if you only have a small range of addresses.  We’re discussing the protocol, not the complexity of the data.

I’ll agree that if the VSP has the entire route table for all the jurisdictions it operates in, then it doesn’t need LoST for query and could use something proprietary.  Not sure what will happen in 3GPP, which is taking that approach.  I think that is a big mistake, but you still need a protocol that is queried with location and delivers URI.

<br>Yes, but the route server determines the binding TTL.  If it’s set for 15 minutes, it can change routes in a disaster situation reasonably promptly.  As long as the cache is invalidated after the binding TTL, everything works.  You described a scenario where route was cached at validation.  That’s fine, as long as the binding TTL is respected.

<br>If you accept the binding time as the validation period, okay, but I don’t think that is what you meant.

Brian

On 7/28/14, 4:27 PM, "James Winterbottom" <[email-masked]<mailto:[email-masked]>>
wrote:

Cheers
James

On 28 Jul 2014, at 11:19 pm, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian

On Jul 24, 2014, at 7:02 PM, James Winterbottom
<[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

The specification that is dependent on a solution to this problem has
a milestone set for end of 1H15.
There simply isn¹t time to have a 3 month mailing list debate on this
topic and then ³maybe² have something that can be adopted in the
nov/dec timeframe.
If this topic can move ³very quickly² then I see some benefit in
continuing a discussion, otherwise I see little point as decisions to
address the need will be made elsewhere.

Cheers
James

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Mon, 28 Jul 2014 21:30:40 +0000

James,

In the ECRIT architecture, location does not have to come from the ANP,
the end-device can supply location to it’s VSP.

-----Original Message-----
From: James Winterbottom <[email-masked]>
Date: Monday, July 28, 2014 at 5:04 PM
To: Marc Linsner <[email-masked]>
Cc: "ecrit_ietf.org" <[email-masked]>
Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04

>LoST to work for their domain.

I don’t understand, LbyR points to the LS, what is UNAPTR for?

>They need to ensure that civic address information will work with the
>LoST server so that the call gets to the right ESRP.
>

No, if the ANP is providing location, it needs to provide the data in a
form adhering to local standards.  I don’t consider that call routing.

>If you introduce LbyR to LoST then you now require them to have a LoST

No, dereferencing LbyR doesn’t require LoST.

>
>So quite honestly, I think it is a real stretch to say that we don’t
>place routing requirements on ANPs today.
>
>Cheers
>James
>
>
>
>>>> <[email-masked]> wrote:
>>>> 
>>>>> Hi All,
>>>>>

---

From: James Winterbottom <[email-masked]>
Date: Tue, 29 Jul 2014 07:38:38 +1000

On 29 Jul 2014, at 7:22 am, Rosen, Brian <[email-masked]> wrote:

> To: Brian Rosen <[email-masked]>
> [AJW] FAIL… How does the LoST server know where to go? It only has a location URI and doesn’t have permission to dereference it so it can’t determine where the authoritative server is using either recursion or redirect. The model is broken.
> 
>  
>> 
[AJW] So you are re-advocating rough location? Hmm.. I though that that option was just dropped. This doesn’t provide the same benefits at all of what is in the draft I proposed. The proposal in the draft only requires the ANP, PSAP or entities inside the emergency network to have access to location values. Requiring a global route server network to have access to this is simply not join to meet the security/privacy requirements in some countries.
> <br>In the US, like most places, you route by cell and sector, but the way that is mechanized is the cell and sector is turned into some kind of location – a civic or a geo.  The LoST database can…
[AJW] You conflating the route issue and the location display issue. I don’t need to turn the cell-id to location at routing time, the route was predetermined. I only need a table, this cell-id maps to this URI. Whether the PSAP gets the cell-id and then converts that into a area to display, or it gets an area from the GMLC is immaterial. I only need a table for routing.

> <br>If you accept the binding time as the validation period, okay, but I don’t think that is what you meant.

[AJW] You are right, I didn’t. But in most cases the kind of catastrophe you describe can and will be done using a different approach.

> [AJW] See above, I have still not heard from anyone how the will work despite having asked a number of times.

[AJW] Question still answered, I provided the failure in LbyR for LoST and it has not been addressed.

---

From: James Winterbottom <[email-masked]>
Date: Tue, 29 Jul 2014 07:39:43 +1000

I don’t think that I said it had to come form the ANP, I think I said that it can.
When it can, why do two queries?

Cheers
James

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Mon, 28 Jul 2014 21:49:30 +0000

-----Original Message-----
From: James Winterbottom <[email-masked]>
Date: Monday, July 28, 2014 at 5:39 PM
To: Marc Linsner <[email-masked]>
Cc: "ecrit_ietf.org" <[email-masked]>
Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04

>When it can, why do two queries?

For the same reason a DNS query for www.foo.bar doesn’t automagically give
you foobar's webpage.  Two functions, two different responsibilities.

-Marc-

>>> They need to put a UNAPTR record for their domain into the DNS to
>>>enable
>>> LoST to work for their domain.
>> 
>>> On 29 Jul 2014, at 6:58 am, Marc Linsner (mlinsner)
>>><[email-masked]>
>>> wrote:
>>> 
>>>> James,
>>>> 
>>>> (with wg chair hat off)
>>>> 
>>>>>> okay.  What is needed is a way for routing to work.  This can be
>>>>>>done
>>>>>> in
>>>>>>> start of June asking for feedback on this draft and again stated
>>>>>>>why
>>>>>>> it

---

From: James Winterbottom <[email-masked]>
Date: Tue, 29 Jul 2014 07:51:29 +1000

Hardly time critical!

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Mon, 28 Jul 2014 21:57:21 +0000

James,

-----Original Message-----
From: James Winterbottom <[email-masked]>
Date: Monday, July 28, 2014 at 5:51 PM
To: Marc Linsner <[email-masked]>
Cc: "ecrit_ietf.org" <[email-masked]>
Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04

>Hardly time critical!

My only response to this is WOW!

And you¹re advocating how many DNS queries to discover the ANP LS????

At least 3, mostly likely 4 or 5.

-Marc-

>>> I don¹t think that I said it had to come form the ANP, I think I said
>>> that it can.
>> For the same reason a DNS query for www.foo.bar doesn¹t automagically
>>give

Š.snipŠ.

---

From: James Winterbottom <[email-masked]>
Date: Tue, 29 Jul 2014 08:11:51 +1000

And you would advocate that many again and then add LoST recurs ion or redirect on top of it. Triple WOW!

Sent from my iPhone

> On 29 Jul 2014, at 7:57 am, "Marc Linsner (mlinsner)" <[email-masked]> wrote:
> 
> James,
>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 28 Jul 2014 16:27:47 -0700

At 1:19 PM +0000 7/28/14, Brian Rosen wrote:

>  I am convinced we will need to support an environment where it is 
> not acceptable to have the end device in the path for location.

We already do support such environments.  In the cellular world, it's 
more likely that the operator will obtain location (usually with 
cooperation of the device, but that's besides the point) and routing. 
The operator might use LoST, but might not, at least in the short to 
medium term.

>   The level of paranoia about that is so high, if we want to make 
> progress in the countries where it exists, we need to do something.

We already permit proxies to do this.  That's what made the cellular 
world compliant.

>  In some of these environments, it's unacceptable to have the CSP 
> get location.  Using HELD with some non-IP identifier to get 
> location by reference works okay.  What is needed is a way for 
> routing to work.  This can be done in two ways.  One is allowing 
> HELD to return route, which is how this doc does it.  The other is 
> to allow LoST to do LbyR.  I prefer the latter, but would be 
> willing to go along with the HELD mechanism if consensus was to do 
> it that way.  Please don't use the "one less query" argument.  It 
> just moves the route query from the CSP to the LIS.

Right, it's a query no matter which entity does it, or which protocol is used.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Oh, dear, where can the matter be
When it's converted to energy?
There is a slight loss of parity.
Johnny's so long at the fair.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Jul 2014 12:44:54 +0000

> 
>> I am convinced we will need to support an environment where it is not acceptable to have the end device in the path for location.
> 
> We already do support such environments.  In the cellular world, it's more likely that the operator will obtain location (usually with cooperation of the device, but that's besides the point) and routing. The operator might use LoST, but might not, at least in the short to medium term.
Yes, but that only works if the access network = communications network.  The work that James is really hot about includes nomadic VoIP over ISP provided access networks.  

> 
>>  The level of paranoia about that is so high, if we want to make progress in the countries where it exists, we need to do something.
> 
> We already permit proxies to do this.  That's what made the cellular world compliant.
Agree, but see above

> 
>> In some of these environments, it's unacceptable to have the CSP get location.  Using HELD with some non-IP identifier to get location by reference works okay.  What is needed is a way for routing to work.  This can be done in two ways.  One is allowing HELD to return route, which is how this doc does it.  The other is to allow LoST to do LbyR.  I prefer the latter, but would be willing to go along with the HELD mechanism if consensus was to do it that way.  Please don't use the "one less query" argument.  It just moves the route query from the CSP to the LIS.
> 
Yeah.  That’s why even though I have a preference for LoST-does-LbyR, I am not really against HELD-returns-route.  

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Jul 2014 13:00:33 +0000

Getting a bit deep, but I’ll keep playing along.

\LbyR in LoST allows the VSP to acquire an endpoint location reference and
obtain routing information to the correct ESRP.  It does¹t require a trust
relationship between the LS and the VSP.
[AJW] Huh??  Which LoST server does the VSP contact in your scenario? The ANP won’t have put any record into the DNS for its domain and even if it did that domain span several geographic areas LbyR in LoST can’t recurse or redirect.. BREAK.. The only way that it could work would require the ANP to establish its own LoST server and simply spit back the records from the LS anyway. Why is this being made as two queries again?

<br>The VSP contacts any LoST server.  Using recursion or iteration, it gets to the authoritative one.  If LoST does LbyR, then the VSP gets an LbyR by querying the LS.  It then queries any LoST server to get route.
[AJW] FAIL… How does the LoST server know where to go? It only has a location URI and doesn’t have permission to dereference it so it can’t determine where the authoritative server is using either recursion or redirect. The model is broken.
This is the fundamental way LoST works.  The LbyR has to return something (country is okay), if the result is within it’s authoritative area, it can return the response.  If not, it has a path to get resolution (up it’s local tree, across the forest via FG, down the authoritative tree.

You remind me of arguments against DNS.  DNS does work right?  You have heard all the “security in obscurity” stuff about knowing IP addresses of various things, right?  For those who still have these fears, they have external resolution trees that have public addresses so the query can get to something that gives them an externally accessible address.  This is directly analogous to how that’s done.

Rough location was dropped because we could not come up with an algorithm to return a rough location that would not leak actual location.  Here, we’re only trying to get to the authoritative FG, and country is okay.  That leaks information, but country is readily determined by existing methods.  If nothing else, domain of route would provide such information.

No.  The ROUTE is determined by looking up a cell-associated location in a location database.  The location is selected so that it is within the service area of the PSAP that serves it.  In some systems, the route query is done in advance of the call, but in others, it’s done at call time.

[AJW] You are right, I didn’t. But in most cases the kind of catastrophe you describe can and will be done using a different approach.
In emergency calling “most” is a word we use to describe optimization.  We don’t design systems that literally fail a small percentage of the time.  Static routes fail often enough in the real world that you should not depend on the ability to manipulate the destination of the static route.  Failure here is not misroute, it’s failure to be able to get to someone that can help.

Don’t agree.  See above.

---

From: James Winterbottom <[email-masked]>
Date: Wed, 30 Jul 2014 06:58:26 +1000

Brian,

If this really is your sentiment then why are we having this debate?
By your own admission LbyR in LoST requires at least some rough location, this doesn’t meet the requirements we have outlined.
The routing returned in HELD will meet the requirements in Europe, can’t we just get on with producing a spec please?

Cheers
James

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Tue, 29 Jul 2014 21:13:06 +0000

-----Original Message-----
From: James Winterbottom <[email-masked]>
Date: Tuesday, July 29, 2014 at 4:58 PM
To: "Rosen, Brian" <[email-masked]>
Cc: Randall Gellens <[email-masked]>, "ecrit_ietf.org"
<[email-masked]>

>By your own admission LbyR in LoST requires at least some rough location,
>this doesn¹t meet the requirements we have outlined.
>The routing returned in HELD will meet the requirements in Europe, can¹t
>we just get on with producing a spec please?

The problem is the requirements are for the most part fallacious.

When queried why the VSP can¹t have LbyV if it¹s covered by their EULA,
the answer is, in that case they can have LbyV.

-Marc-

>> Yeah.  That¹s why even though I have a preference for LoST-does-LbyR, I
>>am not really against HELD-returns-route.
>> 
>> Brian
>> 
>> 
>

---

From: James Winterbottom <[email-masked]>
Date: Wed, 30 Jul 2014 08:37:51 +1000

Brain,

Like NENA i3, on thick the EENA architecture is based, anything outside the ESInet is out of scope. As a consequence, how the call arrives at the ESInet is also out of scope. If the ESInet deploys LoST internally great, for sure in some networks it will and for sure in others it won’t. The ETSI architecture doesn’t bet either way.

Cheers
James

On 30 Jul 2014, at 8:22 am, Rosen, Brian <[email-masked]> wrote:

> Let’s also qualify that “In Europe” is this specific ETSI work.  There is other work (EENA) that uses the IETF approach holistically.  It may be that the ETSI work succeeds and is deployed in some countries for some time, but I would not recommend betting against the EENA approach long term.
> 
> Brian
> 
> On Jul 29, 2014, at 5:13 PM, Marc Linsner (mlinsner) <[email-masked]> wrote:
> 
>> 
>>

---

From: James Winterbottom <[email-masked]>
Date: Wed, 30 Jul 2014 08:54:39 +1000

Marc,

Hannes and I pointed out what was going on in that WG to you and others well over 2 years ago, and the preliminary work in EMTEL even longer ago than that.
I have made suggestions on what you might do to evolve the ETSI architecture to fit your needs, but I have also pointed out the issue you likely to face trying to that in this release. I believe that the best course of action is request a new work item some time next year to perform this evolution. In the mean time trying to drive a solution in the IETF that your most likely customers don’t want is an exercise in futility.

I have stated why pure LbyR in LoST doesn’t work, and Brian has confirmed this. Nobody has said why returning routing information in HELD won’t work.
Responses to the list question are 2 for this proposal and 2 against. Hardly consensus in either direction. It is likely that I will not be able convince you or Brian of the merits of this proposal or the possible outcomes of doing something else, so I am not going to continue to try.

It would be good to have a few more people expressing on the list the direction they wish to take as I think that this will provide a better indication of the overall mood of the WG on this topic.

Cheers
James

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Jul 2014 22:22:16 +0000

Brian

---

From: Roger Marshall <[email-masked]>
Date: Tue, 29 Jul 2014 23:31:15 +0000

I'm a believer in the discrete query model.  It's basic, it's ECRIT std.
1. Query for location, then 
2. Query for routing

This two-query approach can be done (including from the VSP to the ASP) by reusing the existing ECRIT model:

a. from the VSP, a HELD query to the LS to retrieve location information (LbyV) or retrieve Location URI (LbyR)
b. from the VSP, a Routing query (you can reuse LoST here) with either
   --  Location Info payload (RFC 5222) to a LoST server (this could be a new ETSI contribution), or
   --  Location by Reference sent in a LoST query (if you don't want the VSP to ever "see" the location info, though this would require an extension to RFC5222)

The ASP's LS could simply be a LoST Server containing a table, or GIS data layers - and if not found, it could recurse to a different LoST server/FG.

-roger.

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Tuesday, July 29, 2014 3:22 PM
To: Marc Linsner
Cc: ecrit_ietf.org
Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04

Let's also qualify that "In Europe" is this specific ETSI work.  There is other work (EENA) that uses the IETF approach holistically.  It may be that the ETSI work succeeds and is deployed in some countries for some time, but I would not recommend betting against the EENA approach long term.

Brian

On Jul 29, 2014, at 5:13 PM, Marc Linsner (mlinsner) <[email-masked]> wrote:

>> By your own admission LbyR in LoST requires at least some rough 
>> location, this doesn¹t meet the requirements we have outlined.
>> The routing returned in HELD will meet the requirements in Europe, 
>> can¹t we just get on with producing a spec please?
> 
> 
> When queried why the VSP can¹t have LbyV if it¹s covered by their 
> EULA, the answer is, in that case they can have LbyV.
> 
> -Marc-
> 
> 
> 
>> 
>> Cheers
>> James
>> 
>> 
>>>> 
>>>> 
>>> Yeah.  That¹s why even though I have a preference for 
>>> LoST-does-LbyR, I am not really against HELD-returns-route.
>>> 
>>> Brian
>>> 
>>> 
>> 

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jul 2014 18:07:40 -0700

There are multiple issues with LbyV, though. It isn't just about the VSP (agree that this is probably bogus), or even trustworthiness. Some large ANPs are just not inclined to provide it for business reasons.

> On Jul 29, 2014, at 2:13 PM, "Marc Linsner (mlinsner)" <[email-masked]> wrote:

> When queried why the VSP can¹t have LbyV if it¹s covered by their EULA, the answer is, in that case they can have LbyV.
> 
> -Marc-
> 
> 
> 
>> 
>> Cheers
>> James
>> 
>> 
>>>> 
>>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 31 Jul 2014 12:08:42 +0000

I'd ask why do you think you are in a better position to know.

I supsect I could make the same assertion against the NENA work with much the same level of confidence.

I do know what the asserted position of at least a couple of the European regulators is.

Keith 

> Sent: 29 July 2014 23:22
> Let's also qualify that "In Europe" is this specific ETSI 
> work.  There is other work (EENA) that uses the IETF approach 
> holistically.  It may be that the ETSI work succeeds and is 
> deployed in some countries for some time, but I would not 
> recommend betting against the EENA approach long term.
> 
> Brian
>