Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

From: "Marc Linsner" <[email-masked]>
Date: Wed, 14 Feb 2007 17:34:20 -0500

Barbara, 

> 
> Furthermore, people have expressed the belief in other venues (other 
> than the IETF) that legislative and/or regulatory bodies in some 
> countries may require true "On Behalf Of"
> querying by a VPC (VoIP Position Center), when an emergency call 
> arrives without a location. It's believed that this could make for a 
> smoother transition from non-location-capable to location-capable 
> devices. That should be the job of that national entity to legislate 
> this (or not), and not of the IETF to simply prevent it (by refusing 
> to allow a protocol to support this function). Furthermore, it should 
> be the job of these same national legislative/regulatory bodies to 
> determine and police privacy
> laws/regulations, and not the IETF.   
> 

1) The IETF is very interested in maintaining the current Internet
architecture as these attributes directly contribute to the Internet's
success.  The attributes I'm referring to include the separation of
application from the network.  Of particular concern to your proposal is to
create an application that requires low layer information from the far side
of the Internet as implementation experience tells us that limits are
created when doing such.  It appears some accept these limitations, it
appears some aspire for these limitations.

2) The GeoPriv work group is charged with protecting the privacy and
security of an Internet user's location information.  When highly sensitive
information is passed around 'On Behalf Of', it raises large concerns to the
GeoPriv community.

3) Regulators will make rules, regulators are not capable of inventing
technology.  Regulators will do what they do regardless of what the IETF
does.

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 Feb 2007 16:57:43 -0600

Marc,

Your statements demonstrate a clear misinterpretation of the problem in
so far as the way in which Barbara, Guy, Otmar and others are trying to
stating it.
 
A user is asking the ISP, "Where am I?"
He has the right do this, doesn't he?

Has he granted the ISP permission therefore to have his location?
Of course he has, because he is expecting the ISP to know.

The ISP doesn't know where the user is, but the ISP does know who to
ask.
The thing the ISP is going to ask does know where the User is, but
doesn't call the user by that name. This is fact, and it is NOT OBO as
has been described with relation to a proxy requesting location
on-behalf-of an end-point that is not location capable. It is describing
how a location request can be proxied to a node that actually knows
where location is. Indeed, the LIS to LIS mechanisms is no more OBO than
the DHCP server requesting location from a wiremap database because a
DHCP client has requested one of the location options.

The LIS to LIS requirement is similar to other relay concepts that the
IETF readily endorses when they are proposed. This is NO DIFFERENT to
the DHCP relay concept on which a number of existing proposals are
heavily dependent. 

In fact, DHCP relay is a very analogy, since the relay agent essentially
uses the same protocol but adds additional identifiers to provide the
DHCP server with additional information.

Cheers
James

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Thursday, 15 February 2007 9:34 AM
> To: 'Stark, Barbara'
> Cc: 'GEOPRIV WG'
> Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement
> 
> Barbara,
> 
> >
> application from the network.  Of particular concern to your proposal
is
> to
> information is passed around 'On Behalf Of', it raises large concerns
to
> the

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 17:21:14 -0600

Just in case James is interpreting your comments too specifically, Marc,
I'll respond from the general perspective.

"On-behalf-of", as I think we all understand, means that an entity other
than the target device is querying the LIS for the target location. This
means the LIS is explicitly identifying the target by some identifier
(including IP@ as a possibility) as opposed to using the source IP@ of
the requestor to identify the target.

A key scenario for this is where the target device does not have native
location capability itself (e.g. a legacy regular phone form factor VoIP
handset that can't speak an acquisition protocol). The applicability of
this scenario is really limited to the situation where the entity that
controls the application also controls the access network. This may be
because it's one entity that owns the whole plot or because an
independent trust relationship exists between multiple entities who,
between them, own the whole plot. An example is an enterprise switched
Ethernet network with an IP PABX, legacy VoIP handsets, and their own
LIS. Another example is a DSL provider that provides an on-net VoIP
service (not nomadic to third party access) for their DSL providers. As
such, none of these are really pure Internet services model scenarios.
In both these cases, it is reasonable and secure - and should be
uncontentious - that the call servers can query the LIS on-behalf-of the
legacy devices.

Barbara was highlighting that regulators, who are often unsympathetic,
will require DSL/VoIP provider as mentioned in the above scenario to
provide full location capability according E911 requirements. They won't
care if there is a problem with getting updates into an existing
population of clients. For this carrier, the OBO mechanism is both
technically possible and reliably implementable. Since an OBO type
request requires strong trust coupling between the requestor and the LIS
- which would involve the use of authentication/authorizatin mechanisms,
trusted networks and the like, it's not really a generic Internet use
case. However, it's still are real one for the acquisition protocol to
accommodate.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Thursday, 15 February 2007 9:58 AM
To: Marc Linsner; Stark, Barbara
Cc: GEOPRIV WG
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Marc,

Cheers
James

is
to
> technology.  Regulators will do what they do regardless of what the
IETF

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Feb 2007 23:34:11 -0500

The attraction of OBO is the ability to provide accurate location before we
upgrade the endpoints.  I really, truly hope that it would not be used as an
excuse to not upgrade the networks.

The downside of OBO is that there are commonly occurring circumstances that
result in WRONG location.  Not just no location, wrong location, and no one
knows it until they respond.  VPN NATed IP addresses that appear to be good
is an example (such as a teleworker to a mediums sized enterprise that are
on the same carrier's network).  

In some countries, that may be a fatal problem: it's not failure or mistake
or something like that, you know for sure that some number of cases will
fail bad.  The liability of that is probably too much to handle unless the
government specifically exempts the carriers from the liability.

The IETF won't like this kind of problem when the solution is relatively
straightforward (upgrade to new protocols).  If OBO was relatively
foolproof, or failed "safe" (no location), it's probably a worthwhile
tradeoff.  If the use case is "greater good", it's probably a win.  However,
that is probably not the case.

Oh, and James, the endpoint/user is NOT asking it's carrier to do this.  As
we usually understand it, it's not subject to any kind of user control or
sanction, it's something the carrier does to get things like emergency call
to work better.  I shudder to think of the privacy implications of doing it
in some other circumstances.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2007 6:21 PM
> To: Winterbottom, James; Marc Linsner; Stark, Barbara
> Cc: GEOPRIV WG

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 23:26:59 -0600

The VPN corner case isn't OBO-specific. Any acquisition protocol working over layer 3+ has this issue. The issue is that the LIS may think that the device is actually inside the physical network rather than just joining it virtually. The fear that you're raising is that it may incorrectly associate a location with that device. The solution is that the LIS must be able to detect that the device with the presented IP@ is actually coming through a VPN tunnel. A LIS should respond that it can't provide a location in this case (and that's regardless of whether the request came directly from the device or by OBO). Ultimately it would be preferable that the location client on devices are designed to only discover a LIS via the physical network connections - however it would be naïve for a LIS implementation to assume this safeguard was in place.

Similarly, any NAT situation where the device is on the opposite side of the NAT from the LIS will result in a single location being associated with the outgoing IP@ of that NAT. For homes and small businesses this is OK. For really large businesses, where the granularity of the location information on the user side of the NAT is relevant, there should be a LIS on the user side. This consideration, also, is independent of whether either LIS is queried OBO or direct.

Finally, I think OBO is an excellent incremental feature. It's not the network upgrade that's being deferred as you suggest. It's the end-devices that need updating. A LIS should be able to accept both OBO requests, from authorized clients, and device-direct requests from within its area of coverage. A call server that knows how to do an OBO, should also be able to cope with getting an LO or location reference in the call signalling as well.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 15 February 2007 3:34 PM
To: Dawson, Martin; Winterbottom, James; 'Marc Linsner'; 'Stark, Barbara'
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 15 Feb 2007 01:12:28 -0600

Brian,

Perhaps you can help me with what the privacy implication is here,
because it isn't obvious to me. Some one can ask the RANP-LIS (and this
would be a few systems with a trust relationship with the RANP) where
does L2TP tunnel session 555 terminate?

Now since the tunnel runs between the ISP and the RANP, that limits who
can actually know what the tunnel association is anyway.

Perhaps you can elaborate on:

a) how this is a significant personal violation of privacy
b) how it can be done outside of the scope of the RANP or ISP
c) how you can provide the types of services we have discussed both on
the list here and in NENA without a LIS to LIS configuration.

On the latter point you were asked in NENA repeatedly to come up with an
alternative and you consistently declined to do so. So provide a firm
alternative or concede that LIS to LIS is required.

Cheers
James

> The attraction of OBO is the ability to provide accurate location
before
> we
> upgrade the endpoints.  I really, truly hope that it would not be used
as
> an
> result in WRONG location.  Not just no location, wrong location, and
no
> one
> Oh, and James, the endpoint/user is NOT asking it's carrier to do
this.
> As
> to work better.  I shudder to think of the privacy implications of
doing
> it
> > > create an application that requires low layer information from the
far
> > > side
> > > technology.  Regulators will do what they do regardless of what
the
> --
> > ----------------------
> --
> > ----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Feb 2007 11:16:26 -0500

Actually no.  With the single exception of a hardware VPN box that creates
the tunnel before the endpoint even boots, you DON'T have the same problem.
The problem occurs when the first time location is added is at emergency
call time.  If you do it at boot time, you are okay.  You can even detect
the problem (IP address at boot <> IP address at call time).  The endpoint
can often (but not always) bypass the tunnel to ask for location.

A broadband carrier LIS can't determine if a device is attached virtually to
its network, so it can't respond in a correct manner with OBO.

The problems with OBO on large enterprise are too numerous to list.  I think
we can agree "Just don't do that" is the appropriate answer.

Finally, if a carrier that implemented OBO also implemented, at the same
time, a real LCP, and it checked for the presence of an LO before it added
one, then we would get what we wanted.  I fear they won't do this.  Of
course my liability issue would then rain upon them (the device could have
reported the correct location, because it was upgraded, but the network
didn't provide good location to the device, it insisted the network new
better).  That would be exactly the case in a teleworker to a small business
via a VPN on the same carrier network if the phone implemented the LCPs.

Brian

> Sent: Thursday, February 15, 2007 12:27 AM
> To: Brian Rosen; Winterbottom, James; Marc Linsner; Stark, Barbara
> Cc: GEOPRIV WG
> The VPN corner case isn't OBO-specific. Any acquisition protocol working
> over layer 3+ has this issue. The issue is that the LIS may think that the
> device is actually inside the physical network rather than just joining it
> virtually. The fear that you're raising is that it may incorrectly
> associate a location with that device. The solution is that the LIS must
> be able to detect that the device with the presented IP@ is actually
> coming through a VPN tunnel. A LIS should respond that it can't provide a
> location in this case (and that's regardless of whether the request came
> directly from the device or by OBO). Ultimately it would be preferable
> that the location client on devices are designed to only discover a LIS
> via the physical network connections - however it would be naïve for a LIS
> implementation to assume this safeguard was in place.
> 
> Similarly, any NAT situation where the device is on the opposite side of
> the NAT from the LIS will result in a single location being associated
> with the outgoing IP@ of that NAT. For homes and small businesses this is
> OK. For really large businesses, where the granularity of the location
> information on the user side of the NAT is relevant, there should be a LIS
> on the user side. This consideration, also, is independent of whether
> either LIS is queried OBO or direct.
> 
> Finally, I think OBO is an excellent incremental feature. It's not the
> network upgrade that's being deferred as you suggest. It's the end-devices
> that need updating. A LIS should be able to accept both OBO requests, from
> authorized clients, and device-direct requests from within its area of
> coverage. A call server that knows how to do an OBO, should also be able
> to cope with getting an LO or location reference in the call signalling as
> well.
> 
> Cheers,
> Martin
>

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Feb 2007 11:26:21 -0500

James, Martin,

No, I understand completely.  For your convenience, I will copy Barbara's
statement (which happens to be the very first line of my message):

"Furthermore, people have expressed the belief in other venues (other than
the IETF) that legislative and/or regulatory bodies in some countries may
require true "On Behalf Of" querying by a VPC (VoIP Position Center), when
an emergency call arrives without a location."

Unless you have changed the definition of 'VPC', I am characterizing this as
quite different from a wholesale relationship between an ISP and access
provider.

-Marc-

> Just in case James is interpreting your comments too 
> specifically, Marc, I'll respond from the general perspective.
> 
> "On-behalf-of", as I think we all understand, means that an 
> entity other than the target device is querying the LIS for 
> the target location. This means the LIS is explicitly 
> identifying the target by some identifier (including IP@ as a 
> possibility) as opposed to using the source IP@ of the 
> requestor to identify the target.
> 
> A key scenario for this is where the target device does not 
> have native location capability itself (e.g. a legacy regular 
> phone form factor VoIP handset that can't speak an 
> acquisition protocol). The applicability of this scenario is 
> really limited to the situation where the entity that 
> controls the application also controls the access network. 
> This may be because it's one entity that owns the whole plot 
> or because an independent trust relationship exists between 
> multiple entities who, between them, own the whole plot. An 
> example is an enterprise switched Ethernet network with an IP 
> PABX, legacy VoIP handsets, and their own LIS. Another 
> example is a DSL provider that provides an on-net VoIP 
> service (not nomadic to third party access) for their DSL 
> providers. As such, none of these are really pure Internet 
> services model scenarios.
> In both these cases, it is reasonable and secure - and should 
> be uncontentious - that the call servers can query the LIS 
> on-behalf-of the legacy devices.
> 
> Barbara was highlighting that regulators, who are often 
> unsympathetic, will require DSL/VoIP provider as mentioned in 
> the above scenario to provide full location capability 
> according E911 requirements. They won't care if there is a 
> problem with getting updates into an existing population of 
> clients. For this carrier, the OBO mechanism is both 
> technically possible and reliably implementable. Since an OBO 
> type request requires strong trust coupling between the 
> requestor and the LIS
> - which would involve the use of authentication/authorizatin 
> mechanisms, trusted networks and the like, it's not really a 
> generic Internet use case. However, it's still are real one 
> for the acquisition protocol to accommodate.
> 
> Cheers,
> Martin
> 
> Your statements demonstrate a clear misinterpretation of the 
> problem in so far as the way in which Barbara, Guy, Otmar and 
> others are trying to stating it.
>  
> The ISP doesn't know where the user is, but the ISP does know 
> who to ask.
> The thing the ISP is going to ask does know where the User 
> is, but doesn't call the user by that name. This is fact, and 
> it is NOT OBO as has been described with relation to a proxy 
> requesting location on-behalf-of an end-point that is not 
> location capable. It is describing how a location request can 
> be proxied to a node that actually knows where location is. 
> Indeed, the LIS to LIS mechanisms is no more OBO than the 
> DHCP server requesting location from a wiremap database 
> because a DHCP client has requested one of the location options.
> 
> The LIS to LIS requirement is similar to other relay concepts 
> that the IETF readily endorses when they are proposed. This 
> is NO DIFFERENT to the DHCP relay concept on which a number 
> of existing proposals are heavily dependent. 
> 
> In fact, DHCP relay is a very analogy, since the relay agent 
> essentially uses the same protocol but adds additional 
> identifiers to provide the DHCP server with additional information.
> 
> Cheers
> James
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > > determine and police privacy laws/regulations, and not the IETF.
> > >
> > 
> > create an application that requires low layer information 
> from the far
> > side

---

From: <[email-masked]>
Date: Thu, 15 Feb 2007 12:40:04 -0500

Brian,

<... and it checked for the presence of an LO before it added one, then we would get what we wanted>

This seems relatively easy logic to implement at the location recipient (with OBO):

1) If LO is present in the SIP message coming from the VoIP End Point (VEP), use it;
2) If not, look for it and insert it.

<I fear they won't do this>

I would implement this if the trustworthiness of the VEP-provided LO could be verified (linking to the signature discussion). If it isn't, I would drop it and use the one I trust.

Guy Caron

-----Message d'origine-----
De : Brian Rosen [mailto:[email-masked]] 
Envoyé : 15 février 2007 11:16
À : 'Dawson, Martin'; 'Winterbottom, James'; 'Marc Linsner'; 'Stark, Barbara'
Cc : 'GEOPRIV WG'
Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 15:42:09 -0600

OK, I'll define VPC and see if I can find anything sinister in it...

VPC - the entity that translates location information into an emergency
route in response to a request from a call server and which caches the
location and call-related information pending a query from the ALI for
that call.

It does some other things - as well - but I don't see how the above or
any of the other things preclude a VPC instance from having a trust
relationship with the access network.

In order to perform the OBO, the VPC would have to have been conveyed
(via the V2 interface) the IP@ or some other meaningful network
identifier. This can only work in the special case of the VPC being able
to make anything of this identifier by sufficient contextual knowledge
and relationship with the access network.

None of which I see as offering any special cause for privacy concern
compared to, for example, the call server performing the OBO in the
situation of a trust relationship or, indeed, the same situation between
an ISP and a DSL infrastructure provider.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, 16 February 2007 3:26 AM
To: Winterbottom, James; Dawson, Martin
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

James, Martin,

No, I understand completely.  For your convenience, I will copy
Barbara's
statement (which happens to be the very first line of my message):

"Furthermore, people have expressed the belief in other venues (other
than
the IETF) that legislative and/or regulatory bodies in some countries
may
require true "On Behalf Of" querying by a VPC (VoIP Position Center),
when
an emergency call arrives without a location."

Unless you have changed the definition of 'VPC', I am characterizing
this as
quite different from a wholesale relationship between an ISP and access
provider.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 15:59:26 -0600

OK - so I think the specific special case you're referring to is

* User attaches to enterprise via a VPN tunnel (from arbitrary unknown location)

* User utilizes enterprise's VoIP service which happens to be a carrier provided virtual PABX enterprise service

* Carrier call-server performs an OBO based on the user's enterprise assigned, VPN tunnel end-point, IP@

* The LIS that the call-server makes the OBO to is also provided by the carrier and has no visibility into the enterprise network topology

Is that the situation? You'll have to be clear if we're to be sure we're not talking at cross purposes.

Again, I'm saying that the problem here is not specifically because an OBO was used. The problem is that the LIS being used is not adequate to the task. If the same subscriber did a LIS discovery over the VPN and found the same LIS and did a direct request for location by value or by reference, the LIS would come up with the same location as it did for the OBO.

Saying that the device could have avoided the OBO by getting the location from an alternative LIS in its physical network is true, but it doesn't address the root cause which is the use of a LIS that cannot properly detect and determine the necessary granularity within the serving network in question.

There are many ways for end-customers to extend their network in ways which are not transparent to the service provider. The "Pringle can scenario" could be the watchword for this. Digital cordless phones with one mile range in the POTS domain are the analog (no pun intended). Any carrier who offers a hosted VoIP service which includes a hosted LIS function needs to make it clear to the customer that their location capability is limited to attributing a single location to their subscribers. If the customer needs better granularity, then the customer needs to look at hosting their own LIS function.

Ruling OBO out in all cases of a distributed enterprise is overly extreme. For example, an enterprise-hosted VoIP server with an enterprise hosted LIS can quite reliably provide OBO-based functionality because it can access the necessary internal network details. It can even do that when the enterprise is multi-site and the sites are interconnected via VPN tunnels. Again, in the specific case that you're referring to - where the user is connecting from an unknown location via a VPN - the LIS has to be able to detect and determine that location is unknown in this case.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 16 February 2007 3:16 AM
To: Dawson, Martin; Winterbottom, James; 'Marc Linsner'; 'Stark, Barbara'
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Feb 2007 23:09:57 -0500

Nope, that is not the scenario I had in mind, but see below.

My scenario is that a teleworker has a VPN tunnel open to his enterprise,
but also has a variety of services he subscribes to himself, say, a VoIP
service offered by his broadband carrier.

He places an emergency call, which works fine, but the address the call
sever sees is the IP address of the enterprise, and not his carrier assigned
IP address of his residence.

His endpoint would correctly determine his location, if it was done before
he creates the tunnel, or the softclient understands to explicitly go around
the tunnel to obtain location.  OBO could not. 

Of course, it also doesn't work if he places the call through any kind of
enterprise telephony system where the enterprise VoIP carrier tries to use
OBO.  Again, it would work if the system used the endpoint to obtain
location, which is your scenario.

It is OBO that does not work, because the endpoint has effective strategies
to get around the problem, but the OBO agent does not.  Trying to determine
location from the middle of the network doesn't work.

Brian

> Sent: Thursday, February 15, 2007 4:59 PM
> * The LIS that the call-server makes the OBO to is also provided by the
> carrier and has no visibility into the enterprise network topology
> 
> Again, I'm saying that the problem here is not specifically because an OBO
> was used. The problem is that the LIS being used is not adequate to the
> task. If the same subscriber did a LIS discovery over the VPN and found
> the same LIS and did a direct request for location by value or by
> reference, the LIS would come up with the same location as it did for the
> OBO.
> 
> Saying that the device could have avoided the OBO by getting the location
> from an alternative LIS in its physical network is true, but it doesn't
> address the root cause which is the use of a LIS that cannot properly
> detect and determine the necessary granularity within the serving network
> in question.
> 
> There are many ways for end-customers to extend their network in ways
> which are not transparent to the service provider. The "Pringle can
> scenario" could be the watchword for this. Digital cordless phones with
> one mile range in the POTS domain are the analog (no pun intended). Any
> carrier who offers a hosted VoIP service which includes a hosted LIS
> function needs to make it clear to the customer that their location
> capability is limited to attributing a single location to their
> subscribers. If the customer needs better granularity, then the customer
> needs to look at hosting their own LIS function.
> 
> Ruling OBO out in all cases of a distributed enterprise is overly extreme.
> For example, an enterprise-hosted VoIP server with an enterprise hosted
> LIS can quite reliably provide OBO-based functionality because it can
> access the necessary internal network details. It can even do that when
> the enterprise is multi-site and the sites are interconnected via VPN
> tunnels. Again, in the specific case that you're referring to - where the
> user is connecting from an unknown location via a VPN - the LIS has to be
> able to detect and determine that location is unknown in this case.
> 
> Cheers,
> Martin
> 
> mechanisms,
> essentially

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 23:09:13 -0600

You have to be more explicit in your scenario Brian.

Which LIS is the hypothetical VoIP service doing an OBO query to?

It doesn't feel like your scenario hangs together at the moment. The independent VoIP service call-server, which has no relationship with the enterprise and, therefore, no relationship with the LIS in the enterprise, is not going to be able to do any OBO queries to that LIS in the first place. So it won't be able to get to the point of considering the caller's location is at the enterprise.

Generally speaking, OBO can't be applied to a generic Internet service that has no relationship with the access.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 16 February 2007 3:10 PM
To: Dawson, Martin; Winterbottom, James; 'Marc Linsner'; 'Stark, Barbara'
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Brian