Subject: [Geopriv] On behalf of - OBO

From: Marc Linsner <[email-masked]>
Date: Fri, 20 Jun 2008 17:31:02 -0400

Looking through the draft minutes and thinking about the discussion at the
Interim meeting, I want to bring the discussion of OBO to the list.  As I
stated at the meeting, IMO, GeoPriv was created for the purpose of providing
mechanisms for the end-user to protect the privacy of his/her location
information.   To date, this wg has created two location configuration
protocols, modified SIP Presence to carry location information, and location
conveyance via SIP appears imminent.

IMO, there appears to be a strong desire to solve all the world problems wrt
location, regardless if the solutions to these problems run amuck with the
charter/intention of the GeoPriv work group.  OBO runs amuck with the
end-user being able to protect the privacy of his/her location information.
I understand there are desires to support any/all use cases, some of which
can only be solved by using solutions like OBO.  Not all requirements have
solutions.  I think GeoPriv needs to acknowledge/accept this fact, or change
it¹s charter.

-Marc-
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Jun 2008 18:31:39 -0500

At 04:31 PM 6/20/2008, Marc Linsner wrote:
>Looking through the draft minutes and thinking about the discussion 
>at the Interim meeting, I want to bring the discussion of OBO to the 
>list.  As I stated at the meeting, IMO, GeoPriv was created for the 
>purpose of providing mechanisms for the end-user to protect the 
>privacy of his/her location information.   To date, this wg has 
>created two location configuration protocols, modified SIP Presence 
>to carry location information, and location conveyance via SIP 
>appears imminent.
>
>IMO, there appears to be a strong desire to solve all the world 
>problems wrt location, regardless if the solutions to these problems 
>run amuck with the charter/intention of the GeoPriv work group.  OBO 
>runs amuck with the end-user being able to protect the privacy of 
>his/her location information.  I understand there are desires to 
>support any/all use cases, some of which can only be solved by using 
>solutions like OBO.  Not all requirements have solutions.

some solutions to some requirements require an upgrade to existing 
equipment (HW and/or SW), and several of the OBO solutions do not 
want to mandate or require such an upgrade in order to realize a 
desired/particular solution.

I believe, in certain situations, a server can insert location into a 
request and be right about the location it is inserting for a 
Target.  3GPP is probably the best example of such a network. 
However, 3GPP has designed their network to have "sighters" 
retrieving location for each target, in order to tell the x-CSCF 
where it is, which then inserts a Geolocation header with the right 
locationValue.

Few other networks are going to be this controlled ==> meaning, few 
other SIP servers are going to be right when they insert a 
locationValue in a Geolocation header.

Who's going to pay (what price) when location is wrong?

If emergency calling is but one use of OBO, which can be wrong in so 
many environments, does this justify its (WG approved) standardization?

>  I think GeoPriv needs to acknowledge/accept this fact, or change 
> it's charter.
>
>-Marc-

---

From: "TSG" <[email-masked]>
Date: Fri, 20 Jun 2008 16:49:55 -0800

Mssr Polk - I should tell you folks about a US patent which controls this 
area already especially since the IETF was made aware of its existence years 
ago. See IETF IPR Notice #201...

Todd Glassey

----- Original Message ----- 
From: "James M. Polk" <[email-masked]>
To: "Marc Linsner" <[email-masked]>; <[email-masked]>
Sent: Friday, June 20, 2008 3:31 PM
Subject: Re: [Geopriv] On behalf of - OBO

>>stated at the meeting, IMO, GeoPriv was created for the purpose of 
>>providing mechanisms for the end-user to protect the privacy of his/her 
>>location information.   To date, this wg has created two location 
>>configuration protocols, modified SIP Presence to carry location 
>>information, and location conveyance via SIP appears imminent.
>>
>>IMO, there appears to be a strong desire to solve all the world problems 
>>wrt location, regardless if the solutions to these problems run amuck with 
>>the charter/intention of the GeoPriv work group.  OBO runs amuck with the 
>>end-user being able to protect the privacy of his/her location 
>>information.  I understand there are desires to support any/all use cases, 
>>some of which can only be solved by using solutions like OBO.  Not all 
>>requirements have solutions.
>
> equipment (HW and/or SW), and several of the OBO solutions do not want to 
> mandate or require such an upgrade in order to realize a 
> request and be right about the location it is inserting for a Target. 
> 3GPP is probably the best example of such a network. However, 3GPP has 
> designed their network to have "sighters" retrieving location for each 
> target, in order to tell the x-CSCF where it is, which then inserts a 
> Geolocation header with the right locationValue.
>
> Few other networks are going to be this controlled ==> meaning, few other 
> SIP servers are going to be right when they insert a locationValue in a 
> Geolocation header.
>
> If emergency calling is but one use of OBO, which can be wrong in so many 
> environments, does this justify its (WG approved) standardization?
>
>>  I think GeoPriv needs to acknowledge/accept this fact, or change it's 
>> charter.
>>
>>-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 21 Jun 2008 05:59:07 -0500

Hi Marc,

Which clause(s) in the charter do you consider to prohibit OBO?

Do you favour changing the charter? Do we need a different WG to define
useful location service protocols? Can we do these things without
slowing down practical progress? There are forums out there - e.g. OMA,
WiMAX forum - who are continuing to define technology-specific location
protocols that don't observe the Internet model for consistent service
definitions and which will ultimately impede the reliable deployment of
emergency services amongst other things. A routine objection when IETF
protocols are proposed is that the specifications don't exist yet.

Saying that people are running amuck (sic) is emotive language - I don't
believe it is an accurate representation of what is going on.

Cheers,

Martin

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Linsner
Sent: Saturday, 21 June 2008 7:31 AM
To: [email-masked]
Subject: [Geopriv] On behalf of - OBO

Looking through the draft minutes and thinking about the discussion at
the Interim meeting, I want to bring the discussion of OBO to the list.
As I stated at the meeting, IMO, GeoPriv was created for the purpose of
providing mechanisms for the end-user to protect the privacy of his/her
location information.   To date, this wg has created two location
configuration protocols, modified SIP Presence to carry location
information, and location conveyance via SIP appears imminent. 

IMO, there appears to be a strong desire to solve all the world problems
wrt location, regardless if the solutions to these problems run amuck
with the charter/intention of the GeoPriv work group.  OBO runs amuck
with the end-user being able to protect the privacy of his/her location
information.  I understand there are desires to support any/all use
cases, some of which can only be solved by using solutions like OBO.
Not all requirements have solutions.  I think GeoPriv needs to
acknowledge/accept this fact, or change it's charter.

-Marc- 

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 21 Jun 2008 05:59:17 -0500

Hi James,

How do you justify the following comment?

" Few other networks are going to be this controlled ==> meaning, few 
other SIP servers are going to be right when they insert a 
locationValue in a Geolocation header."

3GPP networks use gateways that authenticate/authorize requestors before
performing OBO. Almost all requests in 3G networks are OBO -
particularly for commercial services. Any LIS that performs OBO must
also perform authentication/authorization.

It sounds like you think the 3GPP network procedures are acceptable. Why
do you think it is not acceptable in other technologies? It seems
self-evident that the principle should, in fact, be
technology-independent.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James M. Polk
Sent: Saturday, 21 June 2008 9:32 AM
To: Marc Linsner; [email-masked]
Subject: Re: [Geopriv] On behalf of - OBO

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 21 Jun 2008 14:42:15 -0500

>locationValue in a Geolocation header."

which device is the RFC 3693 defined "Sighter"? The LIS or the SIP Server?

You do agree that only the SIP server can insert a Geolocation header 
into a SIP request, right?

That means something else will need to tell the SIP server what to 
put into which message.

Presumably that's a LIS.  Therefore, there is a LIS to SIP server 
communication protocol, right?

OBO is a function that is all about the LIS getting the right 
location information for a target's SIP request message, and telling 
the SIP server (after it requests this information, using some 
protocol) where the target is at this particular instance, right?

The SIP server doesn't verify anything, it just inserts what it's 
been told to insert, cuz it can't verify this is the right location 
for the target because it doesn't have the functionality to be a 
"sighter" in the first place. I hope you agree with me so far?

If a LIS does something really boneheaded and tells the SIP server to 
insert Bob's location into Alice's SIP INVITE, the SIP server has 
zero means to verify this.

I submit, therefore, that only in controlled environments, can this 
be done with any reliability, with 3GPP (with the interactions 
between the P-CSCF and E-CSCF and LRF functions) being built 
specifically to do this.

WiMAX will be relying on a lower layer protocol to do this 
functionality, just as wifi does.  I'm not saying _some_ WiMAX or 
_some_ WiFi installations cannot do this, I'm saying that not all 
will be configured and implemented to do this.

>also perform authentication/authorization.

to the UE or to the SIP server (i.e., x-CSCF)?

I'm suggesting that within all servers that are (IP based) 3G, theirs 
is a network architecture that does this function, and is fully 
accounted for, or their butt is on the line.  I don't believe this is 
equally true for every other implementation technology that OBO 
considers a sighter.

I don't have a problem with OBO *with stated limitations*, I just 
don't like how often I, and others, have had to say OBO isn't for 
everywhere, and not for every implementation of whatever 
infrastructure type.  I haven't read the text that makes the reader 
of the spec that's going to code OBO aware enough about the 
limitations of OBO sufficiently.

>self-evident that the principle should, in fact, be

but it's not, because SIP, by itself, is an example of organized 
chaos.  So is all Internet communications.  3GPP created so many more 
"functions" than SIP originally had, or has today, that their 
network, in order to function properly, needs a level of control few 
others implement.  That's the difference.  That's my opinion, you're 
free to believe otherwise.  I'm not going to change my opinion until 
I "see" the evidence to satisfy why I should change it.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 21 Jun 2008 18:30:18 -0500

Hi Marc,

Both Geopriv (in the L7 LCP requirements and problems statement) and ECRIT (phone BCP and framework) site very clearly that there is a need for OBO. All you sare syaing now, as you have stated previously, is that while there is a need for it, it must not be defined in such a way that it can be implemented without interoperability problems. I have a significant problem with approach. If you are suggesting that this work is outside of the scope of geopriv, and that geopriv should resist altering its charter (if that is indeed required) to adopt this work, then it seems to me that it does not have a working group home. That being the case, both ECRIT and geopriv MUST strike from their respective documents any reference to a proxy or trusted node being able to request location on behalf of an end-point, as this is not a recognized mechanism for location acquisition by the IETF.

I am tired of the double-talk, either our documents say no, don't ever do it, it is not allowed. Or, they say it may be allowed in some cases, and we adopt the accepted outcome of the interim meeting, which is to say when this is okay, and how it may be done. You can't have it both ways, which is it?

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Marc Linsner
Sent: Fri 6/20/2008 4:31 PM
To: [email-masked]
Subject: [Geopriv] On behalf of - OBO
 
Looking through the draft minutes and thinking about the discussion at the Interim meeting, I want to bring the discussion of OBO to the list.  As I stated at the meeting, IMO, GeoPriv was created for the purpose of providing mechanisms for the end-user to protect the privacy of his/her location information.   To date, this wg has created two location configuration protocols, modified SIP Presence to carry location information, and location conveyance via SIP appears imminent. 

IMO, there appears to be a strong desire to solve all the world problems wrt location, regardless if the solutions to these problems run amuck with the charter/intention of the GeoPriv work group.  OBO runs amuck with the end-user being able to protect the privacy of his/her location information.  I understand there are desires to support any/all use cases, some of which can only be solved by using solutions like OBO.  Not all requirements have solutions.  I think GeoPriv needs to acknowledge/accept this fact, or change it's charter.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jun 2008 00:33:17 -0500

Hi James,

As I understand what you have written, your concern is with the scenario
where the LIS provides the wrong location to the SIP proxy for insertion
into the call signalling.

This is no more/less likely than the LIS providing an erroneous result
to a request from the target-device. As with any network technology, the
location server in a 3G network could also return a wrong location.

This isn't a question of OBO versus target-originated requests; it's a
question of how reliable the location service is.

OBO is only applicable where the requester and the LIS belong in the
same trust domain. If it comes to "butts on the line" then an OBO
scenario is one where the requester and the LIS are working in concert
and have shared responsibility for the outcome. Of course, the question
of "butts on the line" is a product of the environment in which
implementations live (e.g. applicable legislative environment) and is
outside the scope of what the IETF specifications need to deal with. As
such, we shouldn't be concerning ourselves with butts and lines
generally; just what we can do to help people solve the practical
problems.

Consider a system administrator running an Asterisk server on a
university campus with the responsibility to meet a newly imposed legal
requirement to support MLTS emergency calling. Note that NENA are about
to publish a recommendation that there be a national obligation for
enterprise-granular location for MLTS environments (Circuit-PABX and
VoIP). If this admin has to support a large population of standard form
factor IP desk phones with no native location capability (i.e. ability
to query a LIS and convey location to the call server) then they are
going to need the call server to provide that functionality on behalf of
the devices. Having the Asterisk server do an OBO to the LIS for those
devices is a very efficient solution; it capitalizes on the same
location server infrastructure, uses the same protocol set, and only
needs the LIS to authenticate the Asterisk queries before providing the
response. It's not reasonable to insist that an enterprise replace their
entire handset population because of a limitation that can be addressed
quite economically and equally securely with OBO (it's not
environmentally sound either).

I absolutely agree with the sentiment that OBO does not represent a
scalable solution for the general Internet application model. There is
no way to scale trust relationships to the point where every LIS knows
about every location application and will authenticate/authorize them
accordingly (that's the 3GPP model and it's only suitable to walled
garden networks with limited application clients). Any application for
OBO has to be restricted to a trust domain with due recognition of the
implicit responsibility binding between the location service and the
application.

It's not like it's not going to be done anyway and the IETF can provide
more integrity by defining the mechanism and the appropriate usage rules
than by pretending the situation doesn't exist and making people define
proprietary and potentially insecure solutions.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Sunday, 22 June 2008 5:42 AM
To: Dawson, Martin
Cc: Marc Linsner; [email-masked]
Subject: Re: [Geopriv] On behalf of - OBO

>locationValue in a Geolocation header."

which device is the RFC 3693 defined "Sighter"? The LIS or the SIP
Server?

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 23 Jun 2008 09:44:20 +0300

Hi Marc, 

we discussed this so many times already in this working group. 

I understand that not everyone can be happy about everything. I believe
it is fine to acknowledge that. 

We should just move on with our work. Discussing the same stuff again
and again will not help anyone.

We should also listen a bit more to those people who are currently
deploying emergency services. In that sense I would even give some of
the current GEOPRIV work items a lower priority and finish HELD Identity
and the HELD Measurements draft. 

Ciao
Hannes

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Marc Linsner
	Sent: 21 June, 2008 00:31
	To: [email-masked]
	Subject: [Geopriv] On behalf of - OBO

	Looking through the draft minutes and thinking about the
discussion at the Interim meeting, I want to bring the discussion of OBO
to the list.  As I stated at the meeting, IMO, GeoPriv was created for
the purpose of providing mechanisms for the end-user to protect the
privacy of his/her location information.   To date, this wg has created
two location configuration protocols, modified SIP Presence to carry
location information, and location conveyance via SIP appears imminent. 
	
	IMO, there appears to be a strong desire to solve all the world
problems wrt location, regardless if the solutions to these problems run
amuck with the charter/intention of the GeoPriv work group.  OBO runs
amuck with the end-user being able to protect the privacy of his/her
location information.  I understand there are desires to support any/all
use cases, some of which can only be solved by using solutions like OBO.
Not all requirements have solutions.  I think GeoPriv needs to
acknowledge/accept this fact, or change it's charter.
	
	-Marc-

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 23 Jun 2008 09:54:24 +0300

Martin, 

This is a very nice summary of the discussions we also had during the
GEOPRIV interim meeting.

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Dawson, Martin
>Sent: 23 June, 2008 08:33
>To: James M. Polk
>Cc: [email-masked]; Marc Linsner
>As I understand what you have written, your concern is with 
>the scenario where the LIS provides the wrong location to the 
>SIP proxy for insertion into the call signalling.
>
>This is no more/less likely than the LIS providing an 
>erroneous result to a request from the target-device. As with 
>any network technology, the location server in a 3G network 
>could also return a wrong location.
>
>This isn't a question of OBO versus target-originated 
>requests; it's a question of how reliable the location service is.
>
>OBO is only applicable where the requester and the LIS belong 
>in the same trust domain. If it comes to "butts on the line" 
>then an OBO scenario is one where the requester and the LIS 
>are working in concert and have shared responsibility for the 
>outcome. Of course, the question of "butts on the line" is a 
>product of the environment in which implementations live (e.g. 
>applicable legislative environment) and is outside the scope 
>of what the IETF specifications need to deal with. As such, we 
>shouldn't be concerning ourselves with butts and lines 
>generally; just what we can do to help people solve the 
>practical problems.
>
>Consider a system administrator running an Asterisk server on 
>a university campus with the responsibility to meet a newly 
>imposed legal requirement to support MLTS emergency calling. 
>Note that NENA are about to publish a recommendation that 
>there be a national obligation for enterprise-granular 
>location for MLTS environments (Circuit-PABX and VoIP). If 
>this admin has to support a large population of standard form 
>factor IP desk phones with no native location capability (i.e. 
>ability to query a LIS and convey location to the call server) 
>then they are going to need the call server to provide that 
>functionality on behalf of the devices. Having the Asterisk 
>server do an OBO to the LIS for those devices is a very 
>efficient solution; it capitalizes on the same location server 
>infrastructure, uses the same protocol set, and only needs the 
>LIS to authenticate the Asterisk queries before providing the 
>response. It's not reasonable to insist that an enterprise 
>replace their entire handset population because of a 
>limitation that can be addressed quite economically and 
>equally securely with OBO (it's not environmentally sound either).
>
>I absolutely agree with the sentiment that OBO does not 
>represent a scalable solution for the general Internet 
>application model. There is no way to scale trust 
>relationships to the point where every LIS knows about every 
>location application and will authenticate/authorize them 
>accordingly (that's the 3GPP model and it's only suitable to 
>walled garden networks with limited application clients). Any 
>application for OBO has to be restricted to a trust domain 
>with due recognition of the implicit responsibility binding 
>between the location service and the application.
>
>It's not like it's not going to be done anyway and the IETF 
>can provide more integrity by defining the mechanism and the 
>appropriate usage rules than by pretending the situation 
>doesn't exist and making people define proprietary and 
>potentially insecure solutions.
>
>Cheers,
>Martin
>
>You do agree that only the SIP server can insert a Geolocation 
>header into a SIP request, right?
>
>That means something else will need to tell the SIP server 
>what to put into which message.
>
>Presumably that's a LIS.  Therefore, there is a LIS to SIP 
>server communication protocol, right?
>
>location information for a target's SIP request message, and 
>telling the SIP server (after it requests this information, using some
>The SIP server doesn't verify anything, it just inserts what 
>it's been told to insert, cuz it can't verify this is the 
>right location for the target because it doesn't have the 
>functionality to be a "sighter" in the first place. I hope you 
>agree with me so far?
>
>If a LIS does something really boneheaded and tells the SIP 
>server to insert Bob's location into Alice's SIP INVITE, the 
>SIP server has zero means to verify this.
>
>I submit, therefore, that only in controlled environments, can 
>this be done with any reliability, with 3GPP (with the 
>interactions between the P-CSCF and E-CSCF and LRF functions) 
>being built specifically to do this.
>
>functionality, just as wifi does.  I'm not saying _some_ WiMAX 
>or _some_ WiFi installations cannot do this, I'm saying that 
>not all will be configured and implemented to do this.
>
>
>I'm suggesting that within all servers that are (IP based) 3G, 
>theirs is a network architecture that does this function, and 
>is fully accounted for, or their butt is on the line.  I don't 
>believe this is equally true for every other implementation 
>technology that OBO considers a sighter.
>
>I don't have a problem with OBO *with stated limitations*, I 
>just don't like how often I, and others, have had to say OBO 
>isn't for everywhere, and not for every implementation of 
>whatever infrastructure type.  I haven't read the text that 
>makes the reader of the spec that's going to code OBO aware 
>enough about the limitations of OBO sufficiently.
>
>
>but it's not, because SIP, by itself, is an example of 
>organized chaos.  So is all Internet communications.  3GPP 
>created so many more "functions" than SIP originally had, or 
>has today, that their network, in order to function properly, 
>needs a level of control few others implement.  That's the 
>difference.  That's my opinion, you're free to believe 
>otherwise.  I'm not going to change my opinion until I "see" 
>the evidence to satisfy why I should change it.
>
>
>>Cheers,
>>Martin
>>
>>equipment (HW and/or SW), and several of the OBO solutions do 
>not want 
>>to mandate or require such an upgrade in order to realize a 
>Target.  
>>3GPP is probably the best example of such a network.
>>retrieving location for each target, in order to tell the 
>x-CSCF where 
>>it is, which then inserts a Geolocation header with the right 
>>locationValue.
>>
>>--------------------------------------------------------------
>---------
>-------------------------
>>This message is for the designated recipient only and may contain 
>>privileged, proprietary, or otherwise private information.
>immediately 
>>and delete the original.  Any unauthorized use of this email is 
>>prohibited.
>>--------------------------------------------------------------
>---------
>-------------------------
>>[mf2]
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Jun 2008 08:38:20 -0400

This is pretty much where I think we stand, with a couple more thoughts:

1. The cost of being wrong for non-emergency use is much lower than for
emergency cases.  OBO is likely even more suitable for non-emergency cases.

2. One of the largest uses for OBO is transition: getting us from the
current situation in which zero devices are location aware and the hopeful
future state where nearly all are.  How do we do that?  Today, in the U.S.,
the way we do it is "self registration"; the user manually tells the calling
network where it is.  What do you think is more reliable: OBO using an IP
address or self reported location?  I suspect OBO is better by quite a large
percentage if the proxy does even a small amount of sanity checking.

3. Once again, this is a deployment choice, and it is clear from a number of
providers that they will implement OBO one way or another.  You can argue
with whatever reasons they have, but they intend to implement.  If we don't
provide the protocol support, implementation will be delayed.  This is bad.

I think the warnings on the conditions that have to me met to successfully
deploy OBO need very careful review, but if the conditions are met, OBO will
work as well as LCPs do using the same identifier.  The privacy and security
concerns ARE significantly larger, and thus a LCP should always be used in
preference to OBO, but nevertheless, OBO can be deployed successfully, and
relatively quickly.

For those reasons, I think the work should proceed in geopriv.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Monday, June 23, 2008 2:44 AM
> To: ext Marc Linsner; [email-masked]

---

From: Marc Linsner <[email-masked]>
Date: Tue, 24 Jun 2008 14:16:02 -0400

Martin,

Here is my viewpoint.

The IETF is about:

(1) enhancing the end user experience
(2) making the network work better.

GeoPriv is about providing the end user tools to assist with the
privacy/security of his/her location information.

I don¹t find a fit for OBO in the above.

-Marc-

On 6/21/08 6:59 AM, "Dawson, Martin" <[email-masked]> wrote:

> Do you favour changing the charter? Do we need a different WG to define useful
> location service protocols? Can we do these things without slowing down
> practical progress? There are forums out there  e.g. OMA, WiMAX forum - who
> are continuing to define technology-specific location protocols that don¹t
> observe the Internet model for consistent service definitions and which will
> ultimately impede the reliable deployment of emergency services amongst other
> things. A routine objection when IETF protocols are proposed is that the
> specifications don¹t exist yet.
>  
> Saying that people are running amuck (sic) is emotive language  I don¹t
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marc Linsner
> charter/intention of the GeoPriv work group.  OBO runs amuck with the end-user
> being able to protect the privacy of his/her location information.  I
> understand there are desires to support any/all use cases, some of which can
> only be solved by using solutions like OBO.  Not all requirements have

---

From: "TSG" <[email-masked]>
Date: Tue, 24 Jun 2008 11:35:35 -0800

Re: [Geopriv] On behalf of - OBONo Mark - the IETF is NOT about making the NETWORK BETTER. That's the problem. The IETF is chartered to create TCP/IP standards and that is all. 

Please note the inclusion of Cisco's IP Lawyer Sherman Chu on this as well.

Todd Glassey
  ----- Original Message ----- 
  From: Marc Linsner 
  To: Dawson, Martin ; [email-masked] 
  Sent: Tuesday, June 24, 2008 10:16 AM
  Subject: Re: [Geopriv] On behalf of - OBO

  Martin,

  Here is my viewpoint.

  The IETF is about:

  GeoPriv is about providing the end user tools to assist with the privacy/security of his/her location information.

  I don't find a fit for OBO in the above.

  -Marc-

    Hi Marc,

    Do you favour changing the charter? Do we need a different WG to define useful location service protocols? Can we do these things without slowing down practical progress? There are forums out there - e.g. OMA, WiMAX forum - who are continuing to define technology-specific location protocols that don't observe the Internet model for consistent service definitions and which will ultimately impede the reliable deployment of emergency services amongst other things. A routine objection when IETF protocols are proposed is that the specifications don't exist yet.
     
    Saying that people are running amuck (sic) is emotive language - I don't believe it is an accurate representation of what is going on.
     
    Cheers,
    Martin

----------------------------------------------------------------------------

    From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Linsner
    Sent: Saturday, 21 June 2008 7:31 AM
    To: [email-masked]
    Subject: [Geopriv] On behalf of - OBO

    -Marc- 

----------------------------------------------------------------------------
    _______________________________________________
    Geopriv mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Jun 2008 15:36:03 -0500

Marc -

I don't think you'll find many people disagreeing with you for an  
unrestricted use of the OBO concept, but I'm seeing a critical
mass of people that think it _is_ within reason to specify an OBO  
mechanism for a certain highly-restricted set of environments.

Are you disagreeing with specifying an OBO mechanism for those highly- 
restricted environments or reiterating that and unrestricted use of  
OBO is not appropriate?

RjS

On Jun 24, 2008, at 1:16 PM, Marc Linsner wrote:

> I don’t find a fit for OBO in the above.
>
> -Marc-
>
>
>
>
>> Do you favour changing the charter? Do we need a different WG to  
>> define useful location service protocols? Can we do these things  
>> without slowing down practical progress? There are forums out there  
>> – e.g. OMA, WiMAX forum - who are continuing to define technology- 
>> specific location protocols that don’t observe the Internet model  
>> for consistent service definitions and which will ultimately impede  
>> the reliable deployment of emergency services amongst other things.  
>> A routine objection when IETF protocols are proposed is that the  
>> specifications don’t exist yet.
>>
>> Saying that people are running amuck (sic) is emotive language – I  
>> don’t believe it is an accurate representation of what is going on.
>>
>> Cheers,
>> Martin
>>
>> at the Interim meeting, I want to bring the discussion of OBO to  
>> the list.  As I stated at the meeting, IMO, GeoPriv was created for  
>> problems wrt location, regardless if the solutions to these  
>> problems run amuck with the charter/intention of the GeoPriv work  
>> group.  OBO runs amuck with the end-user being able to protect the  
>> privacy of his/her location information.  I understand there are  
>> desires to support any/all use cases, some of which can only be  
>> solved by using solutions like OBO.  Not all requirements have  
>> solutions.  I think GeoPriv needs to acknowledge/accept this fact,  
>> or change it’s charter.
>>
>> -Marc-
>>
>>
>>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jun 2008 20:51:04 -0500

Hey Marc,

Not that I see these goals being expressed in this fashion in RFC3935
but nevertheless:

Having the location of their emergency call delivered through the
Asterisk server likely qualifies as an enhanced experience for a user I
should think. As does having their call for the janitorial officer being
routed to the guy who works their actual building for that matter.

Comparing the situation above where, on the one hand, the enterprise
VoIP services don't work and, on the other, they do work - I think we
can consider the latter as "better".

Cheers,

Martin

From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 25 June 2008 4:16 AM
To: Dawson, Martin; [email-masked]
Subject: Re: [Geopriv] On behalf of - OBO

Martin,

Here is my viewpoint.

The IETF is about:

-Marc-

Hi Marc,

 
 
Cheers,
Martin

-Marc- 

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: Francois Menard <[email-masked]>
Date: Wed, 25 Jun 2008 07:11:36 -0400

OBO is by design 'intelligence in the network' rather than end-to-end.

OBO is all about NOT being allowed to do 'SIP Location Conveyance' for  
E-9-1-1.

It would be a disservice to the market to allow the big telcos to get  
OBO standardized at the IETF, such that this become imposed in the end  
by the CRTC and the FCC.

Given the opportunity, they'll scrap the Internet in a few seconds.

OBO is out of scope of Geopriv.

F.

On 24-Jun-08, at 9:51 PM, Dawson, Martin wrote:

> Hey Marc,
>
> Not that I see these goals being expressed in this fashion in  
> RFC3935 but nevertheless:
>
> Asterisk server likely qualifies as an enhanced experience for a  
> user I should think. As does having their call for the janitorial  
> officer being routed to the guy who works their actual building for  
> that matter.
>
> VoIP services don’t work and, on the other, they do work - I think  
> we can consider the latter as “better”.
>
> Cheers,
> Martin
>
> solutions like OBO.  Not all requirements have solutions.  I think  
> GeoPriv needs to acknowledge/accept this fact, or change it’s charter.
>
> -Marc-
>
>
>

--
François D. Ménard
[email-masked]

--
Francois Menard
[email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 25 Jun 2008 14:23:48 +0300

I would like to understand what parts of the overall exchange you are unhappy about. 

Explain me the difference between: 

* Getting location information from a GPS receiver. Since the first fix takes some time the initial call uses imprecise location information. A later update provides the most detailed information to the PSAP when available. 

* Getting location information by value from a LIS and making an emergency call. 

* Getting location information from a LIS via a reference and making an emergency call. The PSAP needs to resolve that reference. It may resolve the reference more than once with different location being returned if the Target is still moving.

* Routing an emergency call through a SIP-based LIS and allowing that LIS to attach location information. 

* Routing an emergency call through a SIP proxy that contacts a LIS for location information that is then attached when forwarded to a PSAP. 

Ciao
Hannes 

>[mailto:[email-masked]] On Behalf Of ext Francois Menard
>Sent: 25 June, 2008 14:12
>To: Dawson, Martin
>OBO is all about NOT being allowed to do 'SIP Location 
>Conveyance' for E-9-1-1.
>
>It would be a disservice to the market to allow the big telcos 
>to get OBO standardized at the IETF, such that this become 
>imposed in the end by the CRTC and the FCC.
>
>> Asterisk server likely qualifies as an enhanced experience 
>for a user 
>> I should think. As does having their call for the janitorial officer 
>> being routed to the guy who works their actual building for that 
>> matter.
>>
>> without slowing down practical progress? There are forums 
>out there - 
>> e.g. OMA, WiMAX forum - who are continuing to define technology- 
>> specific location protocols that don't observe the Internet 
>model for 
>> consistent service definitions and which will ultimately impede the 
>> reliable deployment of emergency services amongst other things.
>> specifications don't exist yet.
>>
>> Saying that people are running amuck (sic) is emotive language - I 
>> don't believe it is an accurate representation of what is going on.
>>
>> Cheers,
>> Martin
>>
>discussion at 
>> the Interim meeting, I want to bring the discussion of OBO to the 
>> created two location configuration protocols, modified SIP 
>Presence to 
>> carry location information, and location conveyance via SIP appears 
>> imminent.
>>
>> GeoPriv needs to acknowledge/accept this fact, or change 
>it's charter.
>>
>> -Marc-
>>
>>
>>
>> 
>----------------------------------------------------------------------
>> -------------------------- This message is for the designated 
>> recipient only and may contain privileged, proprietary, or otherwise 
>> private information.
>----------------------------------------------------------------------
>> -------------------------- This message is for the designated 
>> recipient only and may contain privileged, proprietary, or otherwise 
>> private information.

---

From: Francois Menard <[email-masked]>
Date: Wed, 25 Jun 2008 08:01:07 -0400

> * Getting location information from a GPS receiver. Since the first  
> fix takes some time the initial call uses imprecise location  
> information. A later update provides the most detailed information  
> to the PSAP when available.
>

If I decide to include GPS receiver information in my call, then the  
network should not rewrite my packet to overreide it.

> * Getting location information by value from a LIS and making an  

I do not consider that I would necessarily get the LbyV from a LIS...  
I may get it from a DHCP server, which you may be calling a LIS.  The  
point is the knowledge of the location resides in the end-point, which  
in the case of OBO, does not exist.

>
> * Getting location information from a LIS via a reference and making  
> an emergency call. The PSAP needs to resolve that reference. It may  
> resolve the reference more than once with different location being  
> returned if the Target is still moving.
>

I do believe that location by reference is a form of OBO and I have  
the same opinion about it than OBO.

> that LIS to attach location information.

How is that different from the scenario below?  Somewhow, your SIP- 
based LIS is not a SIP proxy?  How can it see the SIP signaling?

> * Routing an emergency call through a SIP proxy that contacts a LIS  
> for location information that is then attached when forwarded to a  
> PSAP.

Proxies are by design stateless.  Rewriting a SIP header to change a  
location by reference, to a location by value, is not end-to-end -  
same opinion.

Conclusion:

In my book, its SIP-location conveyance  across NENA i2/i3 V-0  
interface, with the PIDF-LO being PSAP civic-valid.

When you dial SIP: S.O.S., you should not attempt to hide your  
location, so all that is needed, is somekind of digital signature on a  
clear text location, which the PSAP can recognize as valid.  Push that  
through DHCP to the SIP end-point and regurgitate it back to the PSAP  
when seeking emergency.  That is doable under IETF policy, but not  
OBO, which is not an Internet application.

F.

F.

--
Francois Menard
[email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 25 Jun 2008 15:44:17 +0300

It seems that only 2 sort of solutions seem to be acceptable for you: 

* GPS
* Location obtained via DHCP

That's fine. At least for GPS we can anticipate that there will be far
more GPS devices available in the future. That's good news. 

If you, Francois Menard, happen to run a network then you can deploy
DHCP location conveyance (or other IEEE related protocols). 

However, you need to understand that other players in this entire
emergency services architecture who have a different role and they see
their ability with respect to location a bit differently. For example,
if you happen to be a VoIP provider today without ability to control the
access network provider nor the end host then how the hack can you get
the "location-to-endhost" story to work? 

Since we in the IETF cannot mandate what different players have to
deploy we should react on what people are actually doing (since
otherwise we will likely produce something that nobody wanted to deploy
-- did not happen for the first time).

I also need to comment on your "LbyR is a way of OBO". In some sense you
are right. But in this case you would have to reject the entire presence
architecture as well. Since presence is also about accessing something
by reference; the reference to the information stored at the presence
server is the SIP URI. 

Ciao
Hannes

PS: Btw, it is not uncommon in the IETF to address incremental
deployment stories. For example, in the IPv6 space people realized that
it will be difficult to switch from IPv4 to IPv6 without having a
transition story. IPv6 will not be deployed in an end-to-end fashion for
a long time. Is that a problem for some clean slate architectural minded
people. Sure it is. What can you do about it? Nothing. Just bad luck
(and lack of incentives from the different players). 

>From: ext Francois Menard [mailto:[email-masked]] 
>Sent: 25 June, 2008 15:01
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: Dawson, Martin; [email-masked]; Marc Linsner
>> information. A later update provides the most detailed 
>information to 
>> the PSAP when available.
>>
>
>If I decide to include GPS receiver information in my call, 
>then the network should not rewrite my packet to overreide it.
>
>
>I may get it from a DHCP server, which you may be calling a 
>LIS.  The point is the knowledge of the location resides in 
>the end-point, which in the case of OBO, does not exist.
>
>>
>I do believe that location by reference is a form of OBO and I 
>have the same opinion about it than OBO.
>
>> * Routing an emergency call through a SIP-based LIS and 
>allowing that 
>> LIS to attach location information.
>>
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 25 Jun 2008 08:54:15 -0400

Please drop the rhetoric and name-calling. It's really not necessary.

I never heard OBO being proposed as a mechanism to prevent SIP location conveyance. In my discussions with service providers, many would prefer not to ever do OBO for emergency services, because of potential liability if they get it wrong. Others agree, but are concerned that regulators in their countries will insist on the capability as part of a transition (when few end devices are deployed that support location), and that lack of a standard will make it more difficult to meet such a regulatory requirement.

With that said, I don't give a flip if IETF does anything about OBO. I certainly won't be trying to fight for it if means weathering attacks, accusing me of wanting to damage the Internet. [But I do still want a LIS-LIS mechanism, which I assume is now completely separate from OBO?]
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Menard
Sent: Wednesday, June 25, 2008 7:12 AM
To: Dawson, Martin
Cc: [email-masked]; Marc Linsner
Subject: Re: [Geopriv] On behalf of - OBO

F.

On 24-Jun-08, at 9:51 PM, Dawson, Martin wrote:

> VoIP services don't work and, on the other, they do work - I think  
> we can consider the latter as "better".
>
> Cheers,
> Martin
>
> - e.g. OMA, WiMAX forum - who are continuing to define technology- 
> specific location protocols that don't observe the Internet model  
> GeoPriv needs to acknowledge/accept this fact, or change it's charter.
>
> -Marc-
>
>
>

--
François D. Ménard
[email-masked]

--
Francois Menard
[email-masked]

---

From: "Francois Menard" <[email-masked]>
Date: Wed, 25 Jun 2008 09:53:12 -0400

> * Location obtained via DHCP

Actually, location obtained via any protocol will do just fine, for as long
as it is stored in the end-point.

> DHCP location conveyance (or other IEEE related protocols).

Hannes, please keep the tone of the conversation in a manner that is
respectful.  You are entitled to your Telco opinion, but that doesn't make
it necessarily right for the Internet.

Yes, I do happen to be able to deploy DHCP location conveyance.  

However, even in my DSL wholesale environment, I would like to transition
away from PPPoE.  

I happen to know that radius accounting from Juniper ERXs and other RASes,
can carry an originating unique DSLAM port identifier which can then be used
to provision the back-end of the DHCP server.

Now its too bad that there is no standard for PPPoE to push through a
PIDF-LO.

It is really up to the proponents of this technology (not an IETF standard
either ;) btw.), to demonstrate how PPPoE remains in the public interest in
the context of E-9-1-1.  I appreciate that OBO may be needed because of the
costs to replace the firmware in 35$ routers with firmware capable of
performing a HELD query or something.  However,  last I checked, the costs
in Canada to implement OBO were in excess of fixing the 35$ router problem.

On our network, we do both, PPPoE on a VLAN, and DHCP on another VLAN, but
that's just because PBB is not yet available.  I expect that on a moving
forward basis, PBB will take care of that and the need to use PPPoE will go
away.

> the "location-to-endhost" story to work?

VoIP service providers can ensure that underlying ISPs do deploy LbyV
download capability in the underlying networks, or they can remain on basic
9-1-1 as opposed to enhanced 9-1-1.  It's the classic NAT problem where the
IETF stays away from the policy issues tied to that.

> Since we in the IETF cannot mandate what different players have to

Do you say 'we in the IETF' to exclude me???  I may be silent, but that
doesn't mean I do not participate in the IETF.  I have been participating in
the IETF since 1994.

I am used to be dealing with similar positions taken by the ILECs in Canada,
that they are free to mess-up the Internet.

There is lots of history to the position being advanced herein on the
Canadian market, complex interrogatories, deficiency process, cost studies
and a CRTC which will expose itself to a generic refusal by ISPs to pay for
OBO functionality given the cheaper alternative to support LbyV download and
SIP Location Conveyance. 

So please accept my position is one which is founded, thought through, and
mindful of the consequences.

> -- did not happen for the first time).

The IETF is not there to solve NAT problems.  NAT users have to take care of
that. Same thing for Location conveyance and OBO.  The IETF is not there to
solve problems tied to the unwillingness of service providers to send LByV
to end-points.

> by reference; the reference to the information stored at the presence

Presence is by design not end-to-end. This is not the same problem set than
the end-to-end problem of getting an ambulance dispatched to your home.

I do not see the relevance of comparing LByV acquisition for purposes of
getting an ambulance dispatched to your home, with any architecture for
presence indication.

> (and lack of incentives from the different players).

I just finished a long argument about the relevance of IPv6 in open access
architectures for municipal FTTH and how to use the flow field to
discriminate between service providers, rather than between applications.  I
went back on the IETF main mailing list to a old email of mine dated July
17th 2005, below:
http://www.ietf.org/mail-archive/web/ietf/current/msg36399.html

So this is as contemporary today as it was then. This working group is
needed and I will one day get to run it, so it seems.  But I am not paid by
my employer to participate in IETF conferences, so this is difficult. It's
the kind of philanthropy which exceeds my investment capabilities.

However, not getting screwed by a regulator, which would buy a Telco
argument that OBO should be mandated as standardized by the IETF, is within
my investment capabilities so folks, you will be condemned to take me to the
grave with this nonsensical argument that the IETF should standardize OBO.

Its like saying that the IETF should standardize NAT mechanisms ;)

-=Francois=-

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 25 Jun 2008 08:59:02 -0500

I think this position is purely dogmatic - and I'm dubious that there's any "official policy" behind it. There's lots of "intelligence" in network elements that aren't end points.

In any case, I don't see any justification for the paranoia either. The Internet can't be stopped; it's simply not that vulnerable. I have a great deal of faith in its ability to succeed whatever walled garden mentalities may still exist in the minds of some individuals.

In the mean time, OBO is required to address a practical interim issue. It won't be worth holding onto once the scalability limits have been reached and devices have had time to migrate to being location aware. IMO emergency calls won't even be mediated by VoIP providers in the long term; I see that aspect as simply unnecessary; and removing VSP dependencies is a good thing.

http://blog.nominet.org.uk/tech/2008/06/24/voip-and-emergency-calls-where-is-the-caller/

What we need is to stop taking so long getting our specifications released. What's happening at the moment is that the lack of "formal status" of IETF specs is being used in other forums to push through point solution architectures that are access specific and which will contribute to the fragmentation of the Internet experience. I don't think this will kill the Internet; it'll just slow down the deployment of a reliable consistent location infrastructure for important services like emergency calling.

Cheers,
Martin
-----Original Message-----
From: Francois Menard [mailto:[email-masked]] 
Sent: Wednesday, 25 June 2008 9:11 PM
To: Dawson, Martin
Cc: Marc Linsner; [email-masked]
Subject: Re: [Geopriv] On behalf of - OBO

F.

--
François D. Ménard
[email-masked]

---

From: Matt Lepinski <[email-masked]>
Date: Wed, 25 Jun 2008 09:56:33 -0400

Barbara,

I belive that HELD identity extensions (the OBO mechanism discussed at 
the Interim) would work as a mechanism for LIS-LIS as well.

As written, HELD identity extensions allows the HELD requestor (the 
proxy for the legacy device in the OBO use-case, but potentially a LIS 
in the LIS-LIS use-case) to attach identity information about the target 
(e.g. IP address, MAC address, etc). In response to such a requrest the 
HELD responder (the LIS who knows the target's location) could then 
respond with the location of the target.

Clearly, for the LIS-LIS use-case (as with the OBO use-case) there would 
need to be authentication of the requestor to ensure the request came 
from a trusted LIS, and the target would need to have ultimate control 
over when this mechanism could be used, as should always be the case in 
Geopriv (with the ussual caveat that if this mechanism is used to 
provide location for emergency calls, in most jurisdications a user will 
not be allowed to opt-out of providing location in the event of an 
emergency).

There's still significant work to be done to draft suitable text on when 
(in what network scenarios) the OBO use-case of Identity Extensions can 
and cannot be reasonably deployed, and what privacy safe-guards must be 
put in place to ensure that only trusted entities (as defined by the 
target) gain access to the target's location. However, it seems to me 
that there's no reason we could not also draft similar text for the 
LIS-LIS use-case if we wished to use HELD w/Identity Extensions as a 
LIS-LIS mechanism

- Matt Lepinski

---

From: [email-masked]
Date: Wed, 25 Jun 2008 15:16:19 +0100

I was just about to mention this article which I published yesterday and 
Martin's subsequent comment to it as a solid use case for OBO, but I see 
that he has already beaten me to it :)

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 25 Jun 2008 09:11:18 -0500

Absolutely it is suitable for LIS-LIS communications and it is what will, for example, allow a LIS in an ISP to bridge to the LIS in the wholesale broadband access provider to support a seamless location service. It was the major part of the reason for defining the identity-extension component in the first place. It's definitely an OBO query as well - but one that has nothing to do with inherent device limitations.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Lepinski
Sent: Wednesday, 25 June 2008 11:57 PM
To: Stark, Barbara
Cc: [email-masked]; Dawson, Martin; Marc Linsner
Subject: Re: [Geopriv] On behalf of - OBO

Barbara,

- Matt Lepinski

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 25 Jun 2008 10:48:41 -0400

I agree that if an OBO mechanism is defined, then it can be used for LIS-LIS. But we also, in the past, I think, decided to consider LIS-LIS and OBO as distinct use cases. 

Anyway, I need a LIS-LIS solution for this whole thing to work, because the ISP is so often not the same as the access provider. When the end user discovers a LIS, it will be the ISP LIS, because access providers frequently do not "see" or have access to the IP layer, and isn't responsible for IP connectivity. But the ISP doesn't know what physical circuit the target is on. The ISP LIS in such a case will need to send the access provider LIS a query for location. 

I agree absolutely that the requesting LIS must be authenticated by the requested LIS. And, I think, the requesting LIS should also be able to trust the requested LIS.

I'm not sure how you would expect the target to control use of LIS-LIS communication. The target has no ability to communicate with the access provider LIS to express preferences, because there is no direct relationship. Or should the target tell the ISP LIS to relay a message to the access provider LIS, that it shouldn't talk to the ISP LIS? If the access provider isn't supposed to trust the ISP LIS, then that relayed message can't be trusted, either. I'm having a hard time understanding the idea that the target can control LIS-LIS.
Barbara

-----Original Message-----
From: Matt Lepinski [mailto:[email-masked]] 
Sent: Wednesday, June 25, 2008 9:57 AM
To: Stark, Barbara
Cc: Francois Menard; Dawson, Martin; [email-masked]; Marc Linsner
Subject: Re: [Geopriv] On behalf of - OBO

Barbara,

- Matt Lepinski

>>GeoPriv needs to acknowledge/accept this fact, or change it's charter.

*****

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

---

From: Francois Menard <[email-masked]>
Date: Wed, 25 Jun 2008 07:10:58 -0400

F.

--
François D. Ménard
[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Jun 2008 18:13:56 +0300

Hi Francois,

> it necessarily right for the Internet.
This was not meant to be aggressive in any way. Not everyone on this 
list runs networks; hence I wanted to point specifically to you.

If "telco opinion" means "considering the opinion of different players 
in the field of emergency services" then I probably have such a "telco 
opinion". Standardization means balancing interests rather than "only my 
opinion counts".

I have contributed also to the work of providing location to end points 
and we have even implemented a number of the things we worked on. 
Nevertheless, there are different deployments we are going to see in the 
emergency services space.

So, do you deploy the protocols that have been produced in this working 
group (or the stuff the IEEE has done)? If you do then for you 
everything is great.

> doesn't mean I do not participate in the IETF.  I have been participating in
No. I did not mean to exclude you or anyone else.

What I wanted to say is that the IETF in general does not mandate 
specific deployments. Even playing "protocol police" is difficult.

> The IETF is not there to solve NAT problems.
Well, see the work on NAT handling all over the place in the IETF. E.g.: 
STUN, TURN, ICE

>   NAT users have to take care of
You obviously don't think that two location servers talking to each 
other is not the IETF business either.

> getting an ambulance dispatched to your home, with any architecture for
.... I often encounter that people have some thinking of end-to-end and 
then they get very religious but in other cases they don't have a 
problem with very similar concepts.

The problem is that I cannot see the harm of the OBO and LIS-to-LIS 
communication for the Internet. The guys who would like to deploy an 
emergency services architecture today have no other choice than going 
for this OBO approach. Even in an architecture where location is then 
finally provided to the end host there will still be a need for a 
LIS-to-LIS communication.

So, I am not sure what you would tell them.

Additionally, you have guys from the enterprise space that are likely to 
have a proxy in the access network and may want to go for the OBO 
approach as well. They can do that without these documents in a 
proprietary way -- without out guidance on security.

Ciao
Hannes

---

From: "TSG" <[email-masked]>
Date: Wed, 25 Jun 2008 08:36:11 -0800

Actually that type of language is very useful in demonstrating that the 
member's of the IETF practice a form of tortuous interference in allowing 
others initiatives to proceed because of what they feel are political 
issues. That makes this a PAC and changes its total tax profile.

Todd
----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Francois Menard" <[email-masked]>
Cc: <[email-masked]>; "'Dawson, Martin'" <[email-masked]>; 
"'Marc Linsner'" <[email-masked]>; "'Tschofenig,Hannes (NSN - 
FI/Espoo)'" <[email-masked]>
Sent: Wednesday, June 25, 2008 7:13 AM
Subject: Re: [Geopriv] On behalf of - OBO

> This was not meant to be aggressive in any way. Not everyone on this list 
> runs networks; hence I wanted to point specifically to you.
>
> If "telco opinion" means "considering the opinion of different players in 
> the field of emergency services" then I probably have such a "telco 
> group (or the stuff the IEEE has done)? If you do then for you everything 
> is great.
>
> What I wanted to say is that the IETF in general does not mandate specific 
> deployments. Even playing "protocol police" is difficult.
>
> You obviously don't think that two location servers talking to each other 
> is not the IETF business either.
>
>>
> then they get very religious but in other cases they don't have a problem 
> with very similar concepts.
>
> emergency services architecture today have no other choice than going for 
> this OBO approach. Even in an architecture where location is then finally 
> provided to the end host there will still be a need for a LIS-to-LIS 
> communication.
>
> have a proxy in the access network and may want to go for the OBO approach 
> as well. They can do that without these documents in a proprietary way --  
> without out guidance on security.
>
> Ciao
> Hannes
>

---

From: Marc Linsner <[email-masked]>
Date: Wed, 25 Jun 2008 11:43:34 -0400

Todd,

Thanks for including Sherman, I didn¹t realize he was interested in this
topic.

-Marc-

On 6/24/08 3:35 PM, "TSG" <[email-masked]> wrote:

> No Mark - the IETF is NOT about making the NETWORK BETTER. That's the problem.
> The IETF is chartered to create TCP/IP standards and that is all.
>  
>> From:  Marc Linsner <mailto:[email-masked]>
>>  
>> To: Dawson, Martin <mailto:[email-masked]>  ; [email-masked]
>>  
>>> useful location service  protocols? Can we do these things without slowing
>>> down practical progress?  There are forums out there  e.g. OMA, WiMAX forum
>>> - who are continuing to  define technology-specific location protocols that
>>> don¹t observe the  Internet model for consistent service definitions and
>>> which will ultimately  impede the reliable deployment of emergency services
>>> amongst other things. A  routine objection when IETF protocols are proposed
>>> is that the  specifications don¹t exist yet.
>>>  
>>> Of Marc Linsner
>>> solutions.  I think GeoPriv needs  to acknowledge/accept this fact, or
>>> change it¹s  charter.
>>> 
>>> -Marc- 
>>> 
>>> 
>>> 
>>> --------------------
>>> --------------------

---

From: Marc Linsner <[email-masked]>
Date: Wed, 25 Jun 2008 12:29:55 -0400

Robert,

>From the macro viewpoint I disagree with OBO.  It conflicts with the
architecture of applications on the Internet, smart endpoints and dumb
network.  Second, it conflicts with the basis of GeoPriv by not allowing the
end-user to have control of their location information.

>From the micro viewpoint, the proposed solution is taking a mechanism that
we¹ve spent considerable time on to ensure the privacy and security of the
location information, throwing all of that out and justifying it by stating,
ŒUse this only where the entities can be trusted.¹

I do understand the use case and the problem as presented.   There was also
an early requirement we dealt with, Œwe can¹t depend on or force a
relationship between the access provider and the voip provider¹.  Our
mechanisms to date are designed to the meet this requirement.  Any solution
that meets all requirements, including the most difficult, are never going
to be optimum when a lesser set of requirements are the only considerations.
But the solution that meets the more stringent requirements will also work,
albeit less optimal, in all environments.  Providing the OBO solution as
proposed does nothing for VoIP emergency calling as a whole, it only
provides a short-cut solution for a small set of use cases at the longer
term expense of privacy and security of the end-user location information.

I do find this solution interesting as proposed, it seems to me there are
plenty of existing mechanisms to move data between entities within a
Œtrusted¹ environment.  Applications like this have been deployed since the
beginning of networked computers.

-Marc-

On 6/24/08 4:36 PM, "Robert Sparks" <[email-masked]> wrote:

> Marc -
> 
> I don't think you'll find many people disagreeing with you for an unrestricted
> use of the OBO concept, but I'm seeing a critical
> mass of people that think it _is_ within reason to specify an OBO mechanism
> for a certain highly-restricted set of environments.
> 
> Are you disagreeing with specifying an OBO mechanism for those
> highly-restricted environments or reiterating that and unrestricted use of OBO
> is not appropriate?
> 
> RjS
>

---

From: "Francois Menard" <[email-masked]>
Date: Wed, 25 Jun 2008 12:38:25 -0400

> group (or the stuff the IEEE has done)? If you do then for you

I would attempt to deploy HELD for LIS to LIS, but for as long as a LIS in
not in the realtime call path.

However, I do not know of an open source implementation of  HELD, or a LIS
for that matter.

How is that coming up?

Are there two known interoperable implementations of HELD by now, especially
the portion required for LIS to LIS?

> other is not the IETF business either.

That's different. LIS to LIS is end to end.  I do support that, and the use
of HELD as a protocol to achieve LIS to LIS communications.  Furthermore,
HELD as a wiremap update protocol may also be important, i.e. implement a
HELD stack in FreeRadius such as to make FreeRadius speak to a LIS and
ISCDHCPD.

> LIS-to-LIS communication.

OBO is not a substitute for LIS-to-LIS. I will agree with this.
 
> proprietary way -- without out guidance on security.

In the enterprise, location servers, implementing LLDP-MED to Ethernet
switches, will need to speak to SIP Location Conveyance across a SIPConnect
SIP TRUNK.  That is not yet part of the scope of SIPConnect 2.0, but I would
like it to be.

F.

---

From: Matt Lepinski <[email-masked]>
Date: Wed, 25 Jun 2008 13:16:57 -0400

Francois,

There is an open source HELD client and LIS implementation at:
http://sourceforge.net/projects/held-location

Currently, the LIS supports requests containing Identity Extensions, but 
the client API does not yet allow for the generation of such requests.

- Matt Lepinski

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Jun 2008 20:40:38 +0300

Hi Francois,

> However, I do not know of an open source implementation of  HELD, or a LIS

I can, for example, point you to
http://sourceforge.net/project/showfiles.php?group_id=172377
http://www.schreck-thomas.de/projects/held

At the last IETF meeting we also played around with the code, see
http://www.ietf.org/mail-archive/web/geopriv/current/msg05468.html

Richard Barnes also had an additional implementation but I don't know 
where to find it.

Henning, I believe, also has HELD implementations that are being used 
for the NG911 prototype.

> the portion required for LIS to LIS?
We did not focus on this aspect with our testing. Maybe that's something 
we could try at the next meeting, if sufficient folks show up in Dublin.

> HELD stack in FreeRadius such as to make FreeRadius speak to a LIS and
To make sure I understood you correctly: In this LIS to LIS example 
mentioned above you would put one LIS in the FreeRADIUS server and the 
second one in the DHCP server. Correct?

> SIP TRUNK.  That is not yet part of the scope of SIPConnect 2.0, but I would
Ok.

Ciao
Hannes

---

From: "Francois Menard" <[email-masked]>
Date: Wed, 25 Jun 2008 12:03:54 -0400

How is that coming up?

 

F.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Jun 2008 18:39:32 -0500

Hi Barbara,

LIS to LIS can be achieved using HELD with measurements (http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-02) and/or HELD with identity extensions (http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-05)

I think all we need is a BCP around these two drafts saying how this is done. I had a draft some time ago saying how this could be done, it needs some modifications now, but is basically still sound.

This was given as much support to go forward with as the location URI in DHCP if you check the meeting minutes from Prague last year. Consequently it should already be supported in the charter. I didn't push it further because nobody seemed to be asking for it, since they are now I will resurrect it.

Cheers
James

> Of Stark, Barbara
> Sent: Thursday, 26 June 2008 12:49 AM
> To: Matt Lepinski
> I agree that if an OBO mechanism is defined, then it can be used for LIS-
> LIS. But we also, in the past, I think, decided to consider LIS-LIS and
> OBO as distinct use cases.
> 
> Anyway, I need a LIS-LIS solution for this whole thing to work, because
> the ISP is so often not the same as the access provider. When the end user
> discovers a LIS, it will be the ISP LIS, because access providers
> frequently do not "see" or have access to the IP layer, and isn't
> responsible for IP connectivity. But the ISP doesn't know what physical
> circuit the target is on. The ISP LIS in such a case will need to send the
> access provider LIS a query for location.
> 
> I agree absolutely that the requesting LIS must be authenticated by the
> requested LIS. And, I think, the requesting LIS should also be able to
> trust the requested LIS.
> 
> I'm not sure how you would expect the target to control use of LIS-LIS
> communication. The target has no ability to communicate with the access
> provider LIS to express preferences, because there is no direct
> relationship. Or should the target tell the ISP LIS to relay a message to
> the access provider LIS, that it shouldn't talk to the ISP LIS? If the
> access provider isn't supposed to trust the ISP LIS, then that relayed
> message can't be trusted, either. I'm having a hard time understanding the
> idea that the target can control LIS-LIS.
> Barbara
> 
> >I never heard OBO being proposed as a mechanism to prevent SIP location
> conveyance. In my discussions with service providers, many would prefer
> not to ever do OBO for emergency services, because of potential liability
> if they get it wrong. Others agree, but are concerned that regulators in
> their countries will insist on the capability as part of a transition
> (when few end devices are deployed that support location), and that lack
> of a standard will make it more difficult to meet such a regulatory
> requirement.
> >
> >With that said, I don't give a flip if IETF does anything about OBO. I
> certainly won't be trying to fight for it if means weathering attacks,
> accusing me of wanting to damage the Internet. [But I do still want a LIS-
> LIS mechanism, which I assume is now completely separate from OBO?]
> >Barbara
> >
> Behalf Of Francois Menard
> 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. GA621
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Jun 2008 21:52:40 -0500

I would add that Open Source development is done out of the goodness of
the developer's hearts. Mr Menard if you care to sponsor us for our time
and the necessary equipment I am sure that we could provide an open
source LIS to LIS project.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Matt Lepinski
> Sent: Thursday, 26 June 2008 3:17 AM
> To: Francois Menard
> Cc: [email-masked]; Dawson, Martin
> >I would attempt to deploy HELD for LIS to LIS, but for as long as a
LIS
> in
> >However, I do not know of an open source implementation of  HELD, or
a
> LIS

---

From: Richard Barnes <[email-masked]>
Date: Thu, 26 Jun 2008 14:07:03 -0400

Marc,

I'm a little puzzled by these strong objections to OBO. For clarity, 
here's what I understand the "OBO" use case to mean:
-- The Target's access network operates an LS
-- An LR requests location from that LS
-- The LS returns location to the LR (subject to LS-local policy)

This seems exactly like the presence use case except for two things:
1. The Target doesn't explicitly PUBLISH his location, and
2. There's no automated mechanism right now for the Target to find the 
proper LS and send rules to it.

The first difference isn't a privacy risk; this is the same as for the 
LCP use case and the (LCP-based) dereference use case.  And in any case, 
the network can often access this information independent of the client.

The second difference isn't much of a privacy risk either, because there 
are non-automated policy channels.  There exist plenty of non-technical 
mechanisms by which a network and a subscriber can agree to privacy 
terms.  These mechanisms are employed regularly with regard to 
information much more sensitive than my current location (banking 
records, medical records, etc).  In particular, to the extent that the 
Target is a subscriber to the access network (LS operator), they already 
have a relationship that can be used to establish privacy rules.

If you're arguing that there should be a mechanism for the Target to 
specify policy for this "OBO LIS", please say so.  Otherwise, could you 
clarify what your concern is?

--Richard

Marc Linsner wrote:
> acknowledge/accept this fact, or change it’s charter.
> 
> -Marc-
> 
>

---

From: Marc Linsner <[email-masked]>
Date: Fri, 27 Jun 2008 09:21:53 -0400

Richard,

I believe you are missing of couple of my key points.

1) OBO forces a relationship between the access provider and application
provider.

2) You can't compare OBO to Presence.  In the presence model, the target
chooses his Presence provider.  The same cannot be said for choosing an
access provider.

-Marc-

On 6/26/08 2:07 PM, "Richard Barnes" <[email-masked]> wrote:

>> acknowledge/accept this fact, or change it¹s charter.
>> 
>> -Marc-
>> 
>>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 27 Jun 2008 10:02:52 -0400

Marc,

> 1) OBO forces a relationship between the access provider and application

I wouldn't use the word "force": OBO only works when there's a 
relationship between the access provider and the application provider. 
If there's not a relationship, it just doesn't work (since they can't 
authenticate).  In this sense, OBO fails safe, since location doesn't 
get transmitted when there's no relationship.

This doesn't mean that OBO doesn't have applicability on an Internet 
scale.  SSL only works when the server and the client have a 
relationship, but thousands (millions?) of SSL servers manage to have a 
relationship with billions of browsers.

> chooses his Presence provider.  The same cannot be said for choosing an

Surely, an endpoint chooses which networks he connects to, and accepts 
certain terms as a consequence?  Whenever I sign on to a commercial hot 
spot, I have to explicitly agree to terms of service (which could 
contain location terms for all I know).  This isn't as nice as if there 
were a way for my endpoint to automatically tell the network my 
preferences, but it's almost as seamless.  And both mechanisms, manual 
and automated, can implement the rule interface to an LS.

--Richard