Subject: [Geopriv] Geopriv L7 LCP: New Requirement

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Feb 2007 21:14:32 +0100

Hi all,

Otmar raised some interesting aspects as part of his review of 
<draft-ietf-geopriv-l7-lcp-ps-00.txt> that are very relevant for this 
working group since he raised a new requirement in context of the 
Geopriv L7 LCP work. He refers to the "on-behalf-of" functionality where 
a solution for HELD can be found in 
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-identity-extensions-00.txt. 

The basic requirement is quite simple and known to everyone: "A entity 
(other than the Target) asks on behalf of the Target for the location 
information information of the Target."

I don't recall that we ever discussed this requirement in the design 
team (because it was not raised) but Otmar thinks it is relevant.

Ciao
Hannes

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

e same
>>> LCP protocol, but uses different "identifiers" and security procedures.
>>>
>>> Leaving this issue open ("they need to cooperate somehow") is not doing
>>> us a favor here.
>>>       
>> Could you provide some text about what you want?
>>     
>
> The various wholesale scenarios are documented in section 8 of
> http://www.nena.org/media/files/08-505_20061221.pdf
>
> I just boils down to the fact that the LCP needs to work in
> a LIS-LIS setting as well. Then we have an "on behalf of" lookup
> using different identifiers as the key to location.
>
> Is there agreement in this WG that we need to address wholesale
> scenarios, including LIS-LIS communication (the "they need to
> cooperate somehow" bit from the draft) ?
>
> I certainly think we need to.
>
>   

Since this requirement was never proposed within the design team there 
was no chance to reach a conclusion on it.

Ciao
Hannes

> /ol

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 10 Feb 2007 15:24:09 -0500

I don't see the difference of this compared to passing a location- 
retrieving URI to the third party.

To ensure any kind of security, the target has to provide credentials  
to the third party - which is essentially what the randomized URI  
does. (You'd presumably want these credentials to be time-limited, too.)

Henning

On Feb 10, 2007, at 3:14 PM, Hannes Tschofenig wrote:

> <draft-ietf-geopriv-l7-lcp-ps-00.txt> that are very relevant for  
> this working group since he raised a new requirement in context of  
> the Geopriv L7 LCP work. He refers to the "on-behalf-of"  
> functionality where a solution for HELD can be found in http:// 
> tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-identity- 
> extensions-00.txt.
>
> The basic requirement is quite simple and known to everyone: "A  
> entity (other than the Target) asks on behalf of the Target for the  
> location information information of the Target."
>
> I don't recall that we ever discussed this requirement in the  
> design team (because it was not raised) but Otmar thinks it is  
> relevant.
>
> Ciao
> Hannes
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Feb 2007 21:40:29 +0100

Hi Henning,

some terminology first:
* Target -- RFC 3693
* Location Information Server (LIS) -- entity that knows the location of 
the Target
* OBO-Client -- entity that requests the location of the Target without 
being the Target itself.

If I understood the requirement correctly then it is
* applicable only if the OBO-Client is in the same network as the Target 
or has a relationship to it,
   This aspect is necessary since (a) the security issues are difficult 
to handle and (b) the identifier might not be resolvable outside this 
"realm".
* uses identifiers like the VCI/VPI (and not the URI)

Ciao
Hannes

Henning Schulzrinne wrote:
> I don't see the difference of this compared to passing a 
> location-retrieving URI to the third party.
>
>> Geopriv L7 LCP work. He refers to the "on-behalf-of" functionality 
>> where a solution for HELD can be found in

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 10 Feb 2007 15:45:33 -0500

Right. But 'having a relationship' with the network means very  
little. I have a relationship with Verizon DSL. Should I be able to  
get the addresses of all other Verizon DSL customers?

On Feb 10, 2007, at 3:40 PM, Hannes Tschofenig wrote:

> Hi Henning,
>
> some terminology first:
> * Target -- RFC 3693
> * Location Information Server (LIS) -- entity that knows the  
> location of the Target
> * OBO-Client -- entity that requests the location of the Target  
> without being the Target itself.
>
> * applicable only if the OBO-Client is in the same network as the  
> Target or has a relationship to it,
>   This aspect is necessary since (a) the security issues are  
> difficult to handle and (b) the identifier might not be resolvable  
> outside this "realm".

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Feb 2007 21:53:13 +0100

I agree that this is a fuzzy term.

I wonder whether we can make it a bit more precise.

Two conditions seem to be necessary for the mechanism to work:
* The OBO-Client needs to learn the identifier. For some identifiers 
that already requires being quite close to the Target.
* The OBO-Client needs to be authorized to perform the 
identifier-to-location information resolution step.

I think that the latter aspect is the restrictive part here.

Ciao
Hannes

Henning Schulzrinne wrote:
> Right. But 'having a relationship' with the network means very little. 
> I have a relationship with Verizon DSL. Should I be able to get the 
> addresses of all other Verizon DSL customers?
>
>> * Location Information Server (LIS) -- entity that knows the location 
>> of the Target

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 10 Feb 2007 17:14:34 -0600

I think that you guys really need to look at these networks and how they
are constructed in more detail. What Otmar is talking about is not OBO
in the same sense that it has been talked about in the past. It is LIS
to LIS communications because each LIS provides slightly different
information and you NEED information from both in order to be able to
determine location.

I can point you at several texts on this topic, the easiest one to start
with is http://www.nena.org/media/files/08-505_20061221.pdf

If you plan to look at this document it would also be worthwhile looking
at the requirements section in there as I don't believe that all of the
NENA location acquisition protocol requirements are currently addressed
in the LCP requirements draft either. The most obvious one that springs
to mind is the need for a quality of service response time parameter
DA-12.

Hannes, the terms and definitions section of this document is also quite
extensive and are the terms that and definitions that are now being used
widely through carrier and service provider groups. So they may also be
a good place to start.

Cheers
James 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Sunday, 11 February 2007 7:53 AM
> To: Henning Schulzrinne
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement
> 
little.
> >> * Location Information Server (LIS) -- entity that knows the
location
> >> * uses identifiers like the VCI/VPI (and not the URI)

------------------------------------------------------------------------------------------------
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: Otmar Lendl <[email-masked]>
Date: Mon, 12 Feb 2007 11:46:30 +0100

Henning, 

you have a different scenario in mind. The requirement stems from
the fact that some DSL rollouts separate the role of the ISP from
the role of the local loop provider.

The draft already mentiones this:

   Requirement L7-4: Layer 2 and Layer 3 Provider Relationship

      The design of the GEOPRIV Layer 7 Location Configuration Protocol
      MUST assume that there is a trust and business relationship
      between the L2 and the L3 provider.  The L3 provider operates the
      LIS and needs to obtain location information from the L2 provider
      since this one is closest to the end host.  If the L2 and L3
      provider for the same host are different entities, they cooperate
      for the purposes needed to determine end system locations.

The question here is whether that the proposed L7 LCP is also used to
implement "they cooperate for the purposes needed to determine end
system locations".

It's not that I as a customer can query for the location of all other
Verizon DSL customers, but for Earthlink to inquire at Verizon where
exactly one of their own wholesale customer is located.  (nb. I have
no idea whether earthlink and verizon have a resale relationship.)

/ol

-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Feb 2007 09:05:35 -0500

It all comes down to identification. We have focused on L2/L3  
identifiers so far. Asking "where is [email-masked]?" is much more  
closely related to SIMPLE, for example. Needless to say, this  
question seems to be equivalent to some random person asking the  
question, in that it is subject to privacy rules and possibly  
requires the consent of the target.

I'm not sure if, in your example, you intend Earthlink to provide an  
IP address or some NAS identifier or something else.

Obviously, there is also no necessity for the same protocol to be  
used for both the configuration application and the remote query. For  
a variety of reasons, such as privacy, consent, identifiers and  
security, one might even argue that this is not a good idea. We have  
been able to avoid the privacy policy discussion so far since we  
assumed that the querier was the target or that the target had, by  
handing out a token, given permission to the location recipient. Your  
example clearly violates that assumption.

Henning

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 12 Feb 2007 16:18:35 +0100

> requires the consent of the target.

If "[email-masked]" from above is a meant to be a SIP address,
then yes, we don't want to do that.

There are a number of IDs with which a L3 provider could ask
his L2 provider for the location of a specific customer, e.g.

* L2TP tunnel/channel ID
* ATM VCI/VPI
* Ethernet VLAN tag
* MPLS tag
* Radius username

I don't see the need for consent from the target. After all,
it's completely irrelevant for the broadband subscriber whether
his ISP has subcontracted the L2 connectivity to someone else.
All that matters to the user is that his provider's LIS can
provide an accurate response. 

The L2 provider needs to ensure that the interface he provides
to his customers (i.e. reseller) authenticates queries and only
provides informations to L3 providers about their respective
users.

> IP address or some NAS identifier or something else.

Let's walk this though again (this time using an Austrian Real World
example:

* Telekom Austia (TA) as the local incumbent operates a DSL
  infrastructure in Austria. They run DSLAMs and BRAS.

* Other ISPs, e.g. eTel resell the TA DSL solution.

* TA hands off customers to eTel using L2TP tunnels.

* The PPTP session which the customer sees is from his PC
  to a device from eTel (LNS) which does the PPP handshake
  and assigns the IP address (from eTel's pool).

* All the TA infrastructure is transparent for the customer, he
  doesn't even know that the DSLAM isn't run by eTel.

Thus:

* A LIS will have to be run by eTel to serve their own customers.

* eTel has (as of now) no chance to know from which of the TA
  lines a specific user is logging in. A user can use his
  username/password from *any* TA DSL line and will be forwarded
  to eTel equipment.

* The eTel LIS thus needs to query into the TA network on where
  this specific L2TP session comes from in order to give a
  correct answer. eTel could either use

  - L2TP tunnel/session identifiers or
  - Radius Authentication names

  to identify a specific session when querying TA's LIS.

  They can't use IP addresses as TA does not see the end-user's
  address: they just transport the PPP stream.

> used for both the configuration application and the remote query. 

That's a legitimate question.

We need that LIS-LIS protocol for 10 - 30 % of the European broadband
users. ASAP. In the sense of "at the same time as the endhost-LIS
protocol". I doubt we have the manpower here in this WG to tackle
two different protocols for LIS queries at the same time.

> For a variety of reasons, such as privacy, consent, identifiers and  

Sorry, but that assumption was misplaced.

Sometimes the simple and easy solution just is not enough.

/ol

---

From: <[email-masked]>
Date: Mon, 12 Feb 2007 10:45:17 -0500

The model described by Otmar herein is also the one we are contemplating. As such, LIS to LIS interaction is definitively a requirement for us.

I will add that the third party ISP and its wholesaler already have a business relationship and an interconnection agreement (for IP traffic handoff). As such, adding another protocol on top of may not raise more security or privacy concerns, including the explicit consent of the end user.

I'm also of the view that reusing protocols that can effectively fulfill the requirements is generally a good thing.

Thanks,

Guy Caron

-----Message d'origine-----
De : Otmar Lendl [mailto:[email-masked]] 
Envoyé : 12 février 2007 10:19
À : Henning Schulzrinne
Cc : GEOPRIV
Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement

* L2TP tunnel/channel ID
* ATM VCI/VPI
* Ethernet VLAN tag
* MPLS tag
* Radius username

Thus:

/ol

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 12 Feb 2007 15:39:23 -0500

We also have the wholesale DSL model that would require LIS to LIS communication. 

To start this process all over again to generate requirements for a protocol that can only be used for LIS to LIS communication, isn't workable. This process has taken far too long, as it is, and there's pressure to have a complete solution.

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.   

In the past, geopriv has also discussed locating objects such as hospital carts and weather balloons, which may have an RFID tag (so they can be located) but no IP stack. In this case, a doctor's PDA device in a hospital could be querying the central hospital locator database (let's call it a LIS), to determine the cart's location.

IMO, people need to get over the fact that they can't control how a protocol is used once it's released into the world. The desire to make this "L7" protocol so uni-purpose that it can't be used improperly, will generate a protocol that is almost useless, because it is so limited in its capabilities. 
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 10:45 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Thanks,

Guy Caron

-----Message d'origine-----
De : Otmar Lendl [mailto:[email-masked]]
Envoyé : 12 février 2007 10:19
À : Henning Schulzrinne
Cc : GEOPRIV
Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement

On 2007/02/12 15:02, Henning Schulzrinne <[email-masked]> wrote:
> closely related to SIMPLE, for example. Needless to say, this question 
> seems to be equivalent to some random person asking the question, in 
> that it is subject to privacy rules and possibly requires the consent 
> of the target.

If "[email-masked]" from above is a meant to be a SIP address, then yes, we don't want to do that.

There are a number of IDs with which a L3 provider could ask his L2 provider for the location of a specific customer, e.g.

* L2TP tunnel/channel ID
* ATM VCI/VPI
* Ethernet VLAN tag
* MPLS tag
* Radius username

I don't see the need for consent from the target. After all, it's completely irrelevant for the broadband subscriber whether his ISP has subcontracted the L2 connectivity to someone else.
All that matters to the user is that his provider's LIS can provide an accurate response. 

The L2 provider needs to ensure that the interface he provides to his customers (i.e. reseller) authenticates queries and only provides informations to L3 providers about their respective users.

Thus:

> 
> Obviously, there is also no necessity for the same protocol to be used 
> for both the configuration application and the remote query.

We need that LIS-LIS protocol for 10 - 30 % of the European broadband users. ASAP. In the sense of "at the same time as the endhost-LIS protocol". I doubt we have the manpower here in this WG to tackle two different protocols for LIS queries at the same time.

/ol

*****

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Feb 2007 14:44:43 -0500

Do DSL lines move?  In general, I don't think they do.  I did have  
one do that a couple of years ago when I tried to get service via a  
CLEC, but the ILEC put it back where they found it... coincidentally  
an hour after I filed a complaint with the state regulatory body.   
But in general, I think both the civic and geodetic location of the  
DSL line's service address is known, or should be known, at the time  
of provisioning the service.

And LIS to LIS is the same thing as LS to LS, which is already  
covered by the current specs.  I'm unclear what it is that is so  
special about OBO, but sending location objects from one location  
server to another is already possible the RFCs that are published today.

I don't have a problem with providing a mechanism to do what is being  
asked, so long as it doesn't seriously contort that protocol's main  
function.  But from what I can tell, what is being asked is already  
possible.

-andy

On Feb 12, 2007, at 3:39 PM, Stark, Barbara wrote:

> To start this process all over again to generate requirements for a  
> protocol that can only be used for LIS to LIS communication, isn't  
> workable. This process has taken far too long, as it is, and  
> there's pressure to have a complete solution.
>
> 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.
>
> In the past, geopriv has also discussed locating objects such as  
> hospital carts and weather balloons, which may have an RFID tag (so  
> they can be located) but no IP stack. In this case, a doctor's PDA  
> device in a hospital could be querying the central hospital locator  
> database (let's call it a LIS), to determine the cart's location.
>
> IMO, people need to get over the fact that they can't control how a  
> protocol is used once it's released into the world. The desire to  
> make this "L7" protocol so uni-purpose that it can't be used  
> improperly, will generate a protocol that is almost useless,  
> because it is so limited in its capabilities.
> Barbara
>
>
> The model described by Otmar herein is also the one we are  
> contemplating. As such, LIS to LIS interaction is definitively a  
> requirement for us.
>
> I will add that the third party ISP and its wholesaler already have  
> a business relationship and an interconnection agreement (for IP  
> traffic handoff). As such, adding another protocol on top of may  
> not raise more security or privacy concerns, including the explicit  
> consent of the end user.
>
> I'm also of the view that reusing protocols that can effectively  
> fulfill the requirements is generally a good thing.
>
> Thanks,
>
> Guy Caron
>
>> question
> There are a number of IDs with which a L3 provider could ask his L2  
> provider for the location of a specific customer, e.g.
>
> * L2TP tunnel/channel ID
> * ATM VCI/VPI
> * Ethernet VLAN tag
> * MPLS tag
> * Radius username
>
> I don't see the need for consent from the target. After all, it's  
> completely irrelevant for the broadband subscriber whether his ISP  
> has subcontracted the L2 connectivity to someone else.
> The L2 provider needs to ensure that the interface he provides to  
> his customers (i.e. reseller) authenticates queries and only  
> provides informations to L3 providers about their respective users.
>
>> used
> We need that LIS-LIS protocol for 10 - 30 % of the European  
> broadband users. ASAP. In the sense of "at the same time as the  
> endhost-LIS protocol". I doubt we have the manpower here in this WG  
> to tackle two different protocols for LIS queries at the same time.
>
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential,  
> proprietary, and/or privileged material. Any review,  
> retransmission, dissemination or other use of, or taking of any  
> action in reliance upon this information by persons or entities  
> other than the intended recipient is prohibited. If you received  
> this in error, please contact the sender and delete the material  
> from all computers. GA625
>
>
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 13 Feb 2007 15:01:15 -0500

I agree, that it's absolutely possible, through existing TLS mechanisms. 

While DSL lines don't (or shouldn't) move, the L2TP tunnel, or router port, where traffic for a given DSL customer comes into an ISP's network, does change. PPPoE authentication info isn't tied to a DSL line (I can use my login and password from anybody's bellsouth.net DSL line). So, the ISP can't assume, that just because they see traffic from a particular customer, that the customer's traffic is coming from his DSL line. The ISP needs to ask the access provider where that traffic physically originates from.

As a side note, I hope there's no expectation that we would calculate, derive, or measure geo locations for service addresses. My expectation is that we would only have a civic location. We certainly won't be going out and measuring, and I've heard it's a bad idea to create geo data based on a civic address. [Comment on "I think both the civic and geodetic location of the DSL line's service address is known".]
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 2:45 PM
To: Stark, Barbara
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

Do DSL lines move?  In general, I don't think they do.  I did have one do that a couple of years ago when I tried to get service via a CLEC, but the ILEC put it back where they found it... coincidentally  
an hour after I filed a complaint with the state regulatory body.   
But in general, I think both the civic and geodetic location of the DSL line's service address is known, or should be known, at the time of provisioning the service.

And LIS to LIS is the same thing as LS to LS, which is already covered by the current specs.  I'm unclear what it is that is so special about OBO, but sending location objects from one location server to another is already possible the RFCs that are published today.

I don't have a problem with providing a mechanism to do what is being asked, so long as it doesn't seriously contort that protocol's main function.  But from what I can tell, what is being asked is already possible.

-andy

*****

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Feb 2007 15:44:06 -0500

> I agree, that it's absolutely possible, through existing TLS  

Well, that and PIDF-LO and SIP.

> While DSL lines don't (or shouldn't) move, the L2TP tunnel, or  
> router port, where traffic for a given DSL customer comes into an  
> ISP's network, does change. PPPoE authentication info isn't tied to  
> a DSL line (I can use my login and password from anybody's  
> bellsouth.net DSL line). So, the ISP can't assume, that just  
> because they see traffic from a particular customer, that the  
> customer's traffic is coming from his DSL line. The ISP needs to  
> ask the access provider where that traffic physically originates from.

I was attempting to note that this information is static.  Regardless  
of how the traffic flows in the network, the location of the DSL end  
point remains the same.  Therefore, this information could be passed  
on the forms filled out in triplicate when the customer signs up.   
Even if this does not happen, some identifier relating to the  
customer has to be provisioned that can be used as a reference.

That being said, if you feel the information is dynamic and in need  
to a protocol so that it can be updated, I'll take your work for it.

> As a side note, I hope there's no expectation that we would  
> calculate, derive, or measure geo locations for service addresses.  
> My expectation is that we would only have a civic location. We  
> certainly won't be going out and measuring, and I've heard it's a  
> bad idea to create geo data based on a civic address. [Comment on  
> "I think both the civic and geodetic location of the DSL line's  
> service address is known".]

Ultimately, that is up to the applications you wish to support.   
Geodetic is better for targeting artillery.  Civic is better for  
dispatching emergency services.  I suspect you care more for the  
latter than the former.

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 14 Feb 2007 11:29:24 +0100

> to a protocol so that it can be updated, I'll take your work for it.

Andy,

the location of a DSL line ist static in the sense that once
a customer has logged in via that line, his location remains
the same.

What Barbara (and I) tried to explain is that DSL lines with
username/password based authentication are more similar to
dialup accounts than to leased lines. 

When a reseller of such an DSL service adds a new customer,
two things happen:

* the customer's line is connected to a DSLAM port
* a username/password pair is generated, communicated, and activated

There is *no* check in the system which restricts this username/password
pair to this specific DSL line.

The LIS of the ISP thus CANNOT operate like this:

1) Map the source IP address of the RELO/HELD query to the customer account.
2) Look up the address of that customer's DSL line.
3) Return that address.

This is just as misguided as using the customer's home address of a
dialup-user as the location. 

/ol

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Feb 2007 08:47:30 -0500

Well, nothing is foolproof.  The Cable Modem guys are stuck with using MAC
address of the cablemodem, but it is possible on some systems to take your
CM to your friends house and plug it in.  As long as (in most systems) you
are in the same CMTS area, it will not know that you moved it.

I had been under the assumption that the IP address correlated to a customer
which correlated to an address, but now that you point out that a
username/password is the key to the customer ID, it's obvious that won't
work.  What is needed is something akin to the cablemodem MAC address.  Is
there something?

For some time now, several of us have been suggesting that IP address is not
a good identifier for many networks.  Can it be that DSL is among the
networks where IP address cannot reasonably be used to determine location
from a LIS?  I would guess that there is something the client could get at,
which would be a good identifier.  Even if that were something tied to the
DSL modem, it wouldn't be much different than the cable systems.  Best, of
course, would be something that could be correlated to the DSLAM port.

Brian

> From: Otmar Lendl [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2007 5:29 AM
> To: Andrew Newton
> Cc: [email-masked]; Stark, Barbara; [email-masked]

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 14 Feb 2007 09:11:09 -0500

The IP address IS a good identifier. But it needs to be correlated back
to the service location through information that only the physical
access provider has. So the device queries the ISP's LIS (with IP
address as ID), and the ISP queries the access provider's LIS (using
L2TP tunnel, port and other IDs). The device cannot directly query the
access provider LIS, because of several reasons: (1) the device doesn't
have an ID that can be used to directly query the access provider; (2)
the access provider frequently isn't legally allowed to communicate with
the customer at anything above a transport layer; (3) the access
provider's LIS can't be located by the device.

Yes, the IP address does ultimately correlate to the DSLAM port, which
correlates to a circuit ID, to a service address, through the
aggregation point, through the ATM PVC, and through all the other points
traversed in the access and ISP networks. Between the ISP and the access
provider, our operation systems have all the information needed to do
this correlation. We've already looked at that, and we know it can be
done. But to do that correlation, the LISs must communicate. 

This is rather well described and documented in the NENA location TID,
Section 8. That TID is at
http://www.nena.org/media/files/08-505_20061221.pdf
This is the same TID that has the NENA requirements for an acquisition
protocol.

Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 8:48 AM
To: 'Otmar Lendl'; 'Andrew Newton'
Cc: [email-masked]; Stark, Barbara; [email-masked]
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Well, nothing is foolproof.  The Cable Modem guys are stuck with using
MAC address of the cablemodem, but it is possible on some systems to
take your CM to your friends house and plug it in.  As long as (in most
systems) you are in the same CMTS area, it will not know that you moved
it.

I had been under the assumption that the IP address correlated to a
customer which correlated to an address, but now that you point out that
a username/password is the key to the customer ID, it's obvious that
won't work.  What is needed is something akin to the cablemodem MAC
address.  Is there something?

For some time now, several of us have been suggesting that IP address is
not a good identifier for many networks.  Can it be that DSL is among
the networks where IP address cannot reasonably be used to determine
location from a LIS?  I would guess that there is something the client
could get at, which would be a good identifier.  Even if that were
something tied to the DSL modem, it wouldn't be much different than the
cable systems.  Best, of course, would be something that could be
correlated to the DSLAM port.

Brian

> > I was attempting to note that this information is static.  
> > Regardless of how the traffic flows in the network, the location of 
> > the DSL end point remains the same.  Therefore, this information 
> > could be passed on the forms filled out in triplicate when the
customer signs up.
> the location of a DSL line ist static in the sense that once a 
> customer has logged in via that line, his location remains the same.
> 
> username/password based authentication are more similar to dialup 
> accounts than to leased lines.
> 
> When a reseller of such an DSL service adds a new customer, two things

> happen:
> There is *no* check in the system which restricts this 
> username/password pair to this specific DSL line.
> 

*****

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Feb 2007 11:00:17 -0500

> dialup accounts than to leased lines.

Again, I'll take your word for it.  I certainly don't appreciate  
people telling me how my network should work.  But I do appreciate  
your description of the problem.

However, I still believe that OBO is unnecessary.  All the components  
to LIS to LIS have been in GEOPRIV from the beginning.  A LIS is just  
a special form of an LS.

-andy

---

From: <[email-masked]>
Date: Wed, 14 Feb 2007 11:12:16 -0500

Andrew,

<However, I still believe that OBO is unnecessary.  All the components to LIS to LIS have been in GEOPRIV from the beginning.  A LIS is just a special form of an LS.>

Is it your understanding that LIS to LIS and OBO within the context of this thread are one of the same?

I don't think they are.

If LIS to LIS is definitively covered by a geopriv document somewhere then, can this requirement (L7 MUST support LS-LS) be added to section 9?

Thanks,

Guy Caron
________________________________________
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 14 février 2007 11:00
À : Otmar Lendl
Cc : Stark, Barbara; Caron, Guy (A162859); [email-masked]; [email-masked]
Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement

Again, I'll take your word for it.  I certainly don't appreciate people telling me how my network should work.  But I do appreciate your description of the problem.

However, I still believe that OBO is unnecessary.  All the components to LIS to LIS have been in GEOPRIV from the beginning.  A LIS is just a special form of an LS.

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 14 Feb 2007 17:39:02 +0100

On 2007/02/14 17:02, Andrew Newton <[email-masked]> wrote:
> people telling me how my network should work.  

I don't claim that this is the way DSL networks should be built.

It's just a statement of facts on the ground. Geopriv won't change
the overall architecture of current DSL implementations. We just have
to deal with what has been built out there and there is no way we can
ignore millions of active DSL users.

> But I do appreciate your description of the problem.

You're welcome.

> to LIS to LIS have been in GEOPRIV from the beginning.  A LIS is just  

I have missed that. Could you elaborate and explain which protocol
should be used between the LIS of the ISP and the LIS of the DSL
wholeseller?

/ol

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Feb 2007 12:35:19 -0500

> of this thread are one of the same?

I don't think they are the same thing either, but that's not your  
requirement.  Your requirement is that you need to communicate the  
location of a subscriber from the DSL provider to the ISP.  What I'm  
stating is that you can already to that today.

> If LIS to LIS is definitively covered by a geopriv document  
> somewhere then, can this requirement (L7 MUST support LS-LS) be  
> added to section 9?

What is the point of putting a requirement in a document if the  
intent is not to do anything with it?

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 14 Feb 2007 12:58:13 -0500

> Your requirement is that you need to communicate the location of a
subscriber from the DSL provider to the ISP.  > What I'm stating is that
you can already to that today.

How? I'm not aware of a mechanism for doing that today.

I hope you don't still think that an ISP "knows" where a subscriber is,
on the basis of "this subscriber has an active session to the ISP
network; this subscriber has DSL service at XYZ civic location;
therefore, traffic from this subscriber must be originating from XYZ
civic location." We simply cannot make that final leap of faith. In
reality, the subscriber could have initiated the session from anywhere. 

When an IP address is assigned, the only way for an ISP to know where
the traffic for that IP address originates from is to launch a real-time
query to the access provider, with information about the
port/tunnel/etc. that the traffic is using to get to the ISP. I'm not
aware of any real-time query mechanism that will do this today.
Barbara

*****

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 Feb 2007 14:40:02 -0600

Brian,

I am completely gob-smacked by some of your assertions below.
You have been heavily involved in the work we have done in NENA is
arriving at both requirements and a series of possible solutions for DSL
networks. You are aware that location in these networks is dependent on
tracing identifier chains through the network. That at the chain starts
at the ISP with the IP address and works its way back through various
identifiers, which may include L2TP tunnel and session identifiers etc.
You have also seen the suggested mechanisms for passing this information
back from the ISP LIS to the RANP-LIS.

I agree with Barbara, in the DSL world the IP address is a good
identifier, but it is ultimately not the only identifier required to
provide location, it provides links to other identifier that ultimately
allow location to be determined. The issue is that some of these
intermediary identifier are dynamic, so you cannot simply provision
location against IP address or user-identifier in the LIS. 

The document Barbara and I have both posted links to now show how this
can be done. I would urge those that have not read it.

Cheers
James

> Sent: Thursday, 15 February 2007 12:48 AM
> Cc: [email-masked]; 'Stark, Barbara'; [email-masked]
MAC
> customer
> not
> from a LIS?  I would guess that there is something the client could
get
> at,
Regardless
> > There is *no* check in the system which restricts this
username/password

---

From: <[email-masked]>
Date: Wed, 14 Feb 2007 15:42:48 -0500

Andrew,

<Your requirement is that you need to communicate the  
location of a subscriber from the DSL provider to the ISP.>

I agree with you and it would go like this:

0) VEP discovers the targeted LIS based on IP address and finds the ISP LIS
1) VEP sends a request for location to ISP LIS with IP Address over L7-LAP
2) ISP LIS recognizes the IP address as being in its realm and performs DB lookup to find L2TP info + ASP LIS URL (in this use case)
3) ISP LIS sends a request for location to ASP LIS with L2TP info over L7-LAP
4) ASP LIS recognizes L2TP info + ISP LIS credentials and performs DB lookup to find LO
5) ASP LIS responds to ISP LIS with LO over L7-LAP which forwards to VEP over L7-LAP

Note: ASP stands for Access Service Provider, sometimes called Access Infrastructure Provider (AIP). It is the operator of the physical network (in this case, DSL).

< What is the point of putting a requirement in a document if the  
intent is not to do anything with it?>

If the above represents what you envision as well, and your position remains unchanged on this specific use case of LS-LS being already addressed by geopriv, therefore making it a requirement for all L2-LCPs and L7-LAPs to support it, then it may not be of value indeed.

I would appreciate if you could confirm that is the case.

Regards,

Guy Caron

-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 14 février 2007 12:35
À : Caron, Guy (A162859)
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 15:38:46 -0600

The acquisition protocol attribute that supports doing this is a client identity extension. RELO supports a form of it and HELD supports generic client ID extensions.

A subscriber is identified to the visited LIS by their source IP@. An ISP LIS may be able to determine the L2TP tunnel identifier from a DSL provider that this subscriber is associated with. In order to query the DSL infrastructure provider LIS, the ISP LIS has to be able to add this L2TP tunnel to the client identifier (the IP@ is no longer a usable correlator). The DSL provider LIS can then associate the L2TP tunnel ID to the user's civic address as Guy, Barbara, and Otmar have described.

Given the premise that nobody wants to define yet another acquisition protocol purely for the purpose of LIS-LIS communication, this requirement boils down to the need for the location request to be able to support other (typically access technology dependent) forms of client identifier than the IP address.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, 15 February 2007 7:43 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Andrew,

Regards,

Guy Caron

-----Message d'origine-----

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 15:40:47 -0600

> are in the same CMTS area, it will not know that you moved it.

Actually, since a ranging measurement is performed by the cable modem, location could be determined by having a map of the cable.  That's probably not all that feasible, but it IS possible.

MT

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Feb 2007 21:24:02 -0500

Just to make this a bit more concrete: The protocol-level requirement  
I see here is that the ISP needs to be able to issue a location query  
with some non-IP address, such as the port number) to the ISP LIS.  
(And there needs to be some kind of authentication between the two  
providers, but that's a relatively easy one.)

I think the requirements already address the need to accommodate  
identifiers other than IP addresses.

On Feb 14, 2007, at 9:11 AM, Stark, Barbara wrote:

> -

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Feb 2007 21:28:03 -0500

On Feb 14, 2007, at 4:38 PM, Dawson, Martin wrote:

> The acquisition protocol attribute that supports doing this is a  
> client identity extension. RELO supports a form of it and HELD  
> supports generic client ID extensions.

Amplification: RELO supports additional client ID extensions via IANA  
registration. (You'd presumably need to standardize the textual form  
since there are often many ways to render the same information, such  
as MAC addresses.)

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Feb 2007 21:39:20 -0500

> should be used between the LIS of the ISP and the LIS of the DSL

Ok.  I jumped the gun slightly.  Everything you need is almost an  
RFC.  The thing that still not an RFC is SIP location conveyance.   
(Yell at James Polk.)

If the ISP LIS needs location from the DSL LIS, it can simply do what  
anybody else could do... subscribe to it.  Use RFC 4119, SIP location  
conveyance.  The subscription URI would be pres:192.168.X.Y@dsl- 
wholeseller.example.com.  Or you can pick whatever identifier to use,  
it doesn't have to be the IP address.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Feb 2007 21:44:40 -0500

> How? I'm not aware of a mechanism for doing that today.

See my reply to Otmar.

> reality, the subscriber could have initiated the session from  

Actually, Otmar's description that this is similar to dial-up was  
very helpful.  This sounds reasonable.

> aware of any real-time query mechanism that will do this today.

Well, my original point is that DSL lines don't move.  And though  
this is similar to dial-up, just how many of your customers actually  
take their DSL modem over to their buddies house.  I doubt that every  
happens.  However, I do remember you putting forth some use case  
about mobile, wireless ethernet devices that hooked into the DSLAM.   
That seems to be a pretty compelling use case.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Feb 2007 21:54:37 -0500

On Feb 14, 2007, at 3:42 PM, [email-masked] wrote:
> 2) ISP LIS recognizes the IP address as being in its realm and  
> performs DB lookup to find L2TP info + ASP LIS URL (in this use case)

Well, I don't know what a VEP is, but this sounds right.  In steps 1  
and 3, the "sends request" is a subscription of a PIDF-LO using SIP.   
That's already possible with the RFCs and drafts that are well  
underway.  See my reply to Otmar.  This has nothing to do with "L7- 
LAP".  And please, stick to the agreed upon initials.  LAP vs. LCP is  
just splitting semantic hairs.

> If the above represents what you envision as well, and your  
> position remains unchanged on this specific use case of LS-LS being  
> already addressed by geopriv, therefore making it a requirement for  
> all L2-LCPs and L7-LAPs to support it, then it may not be of value  
> indeed.

I just read that sentence 3 times, and I'm still unsure of the reason  
for which you are asking my confirmation or denial.

-andy

---

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

There are systems available that significantly limit how much you can move
the CM and not be discovered.  Not all cable operators have such systems.  

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2007 4:41 PM
> To: Brian Rosen; Otmar Lendl; Andrew Newton
> Actually, since a ranging measurement is performed by the cable modem,
> location could be determined by having a map of the cable.  That's
> probably not all that feasible, but it IS possible.
> 
> MT
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 15 Feb 2007 04:11:48 -0600

Hi All,

I raised the issue in a previous email, about the LIS needing know how
quickly a requesting client needs a response to a location request.

This is important to a LIS because in some types of access, most notably
wireless access network, the LIS may have more than one location
determination mechanism available to it. Furthermore, it is common for
more accurate location techniques to take longer to yield a result, in
some cases this may take upwards of  15 seconds. Consequently, the LIS
needs to have a means of gauging which determination techniques are
appropriate to invoke for a specific location request.

The proposed new requirement is borrowed from the NENA document
http://www.nena.org/media/files/08-505_20061221.pdf

The location acquisition protocol shall allow the requesting device to
specify a response time requirement to the LIS when requesting location
information. The response time is expressed as the maximum time that the
requesting node is prepared to wait for location information. The LIS is
required to provide the most accurate location fix it can within the
specified response time. 

Cheers

James

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 15 Feb 2007 11:39:56 -0500

Interesting idea. I'm not sure it works for LIS to LIS, though I could
see it working for "true" OBO. The ID is the main problem. Frequently,
it's not a single ID that identifies the connection in question, to the
access provider. It's frequently not an IP address. Usually, it's a
combination of IDs that would be needed to uniquely identify the line,
and the combination to use will vary per access provider, and there may
be several variations within an access provider (as the access network
evolves, new users frequently are placed on newer platforms, and old
users are left alone). I think that to try to figure out some way to
support all the needed variations within a single URI would be really
difficult. Parameterizing the various IDs would be simpler.
Barbara

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 9:39 PM
To: Otmar Lendl
Cc: [email-masked]
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

		However, I still believe that OBO is unnecessary.  All
the components  

		to LIS to LIS have been in GEOPRIV from the beginning.
A LIS is just  

		a special form of an LS.

	I have missed that. Could you elaborate and explain which
protocol

	wholeseller?

Ok.  I jumped the gun slightly.  Everything you need is almost an RFC.
The thing that still not an RFC is SIP location conveyance.  (Yell at
James Polk.)

If the ISP LIS needs location from the DSL LIS, it can simply do what
anybody else could do... subscribe to it.  Use RFC 4119, SIP location
conveyance.  The subscription URI would be
pres:[email-masked].  Or you can pick whatever
identifier to use, it doesn't have to be the IP address.

-andy

*****

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Feb 2007 12:08:11 -0500

On Feb 15, 2007, at 11:39 AM, Stark, Barbara wrote:

> Interesting idea. I'm not sure it works for LIS to LIS, though I  
> could see it working for "true" OBO. The ID is the main problem.  
> Frequently, it's not a single ID that identifies the connection in  
> question, to the access provider. It's frequently not an IP  
> address. Usually, it's a combination of IDs that would be needed to  
> uniquely identify the line, and the combination to use will vary  
> per access provider, and there may be several variations within an  
> access provider (as the access network evolves, new users  
> frequently are placed on newer platforms, and old users are left  
> alone). I think that to try to figure out some way to support all  
> the needed variations within a single URI would be really  

Well, the formulation of the URI is up to you.  The user part doesn't  
have to be an IP address, or can be a combination of things.  That's  
completely up to you.  And multiple URIs may point to the same entity.

If what you are saying is that you cannot determine an identifier to  
use, then I'm afraid no protocol will solve your problem.

I'm also now concerned that the concept of OBO is not well defined.   
When originally presented to the working group, the OBO identifier  
was an IP address.  Now you are saying it usually is not.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 15 Feb 2007 12:50:10 -0500

The identifier(s) to use is very simple for an ISP LIS to determine.
It's not at all difficult to provide the ISP LIS with very specific
rules, based on how it interconnects with the access provider.

What is difficult, is figuring out a standard format for a URI user part
that would allow for all the variations in combinations of IDs that
exist, so that a standard format could be defined that would cover all
interconnection models. Section 8 of the NENA Location TID
(http://www.nena.org/media/files/08-505_20061221.pdf) provides 5
different examples of interconnection models, and the IDs that would
need to be used in each of these cases. In this document, scenario 1
uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 uses
2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP tunnel
ID (source and destination) and PPPoE session ID. These are just 5
possible examples, and should not be considered exhaustive.
Interconnection models are still evolving.

As for "defining" OBO, I agree that there's definitely confusion over
this term. I think we really need to distinguish between LIS to LIS
queries, and some external entity querying the (ISP) LIS for location of
an end device. In the 2nd case, I think IP address is probably all that
the querying entity has, that the ISP LIS would understand and be able
to use. LIS to LIS is somewhat different.
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 12:08 PM
To: Stark, Barbara
Cc: Otmar Lendl; [email-masked]
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

> see it working for "true" OBO. The ID is the main problem.
> question, to the access provider. It's frequently not an IP address. 
> Usually, it's a combination of IDs that would be needed to uniquely 
> identify the line, and the combination to use will vary per access 
> provider, and there may be several variations within an access 
> provider (as the access network evolves, new users frequently are 
> placed on newer platforms, and old users are left alone). I think that

> to try to figure out some way to support all the needed variations 
> within a single URI would be really difficult. Parameterizing the 
> various IDs would be simpler.
> Barbara

I'm also now concerned that the concept of OBO is not well defined.   
When originally presented to the working group, the OBO identifier was
an IP address.  Now you are saying it usually is not.

-andy

*****

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Feb 2007 13:33:20 -0500

Barbara,

> 
> What is difficult, is figuring out a standard format for a 
> URI user part that would allow for all the variations in 
> combinations of IDs that exist, so that a standard format 
> could be defined that would cover all interconnection models. 
> Section 8 of the NENA Location TID
> (http://www.nena.org/media/files/08-505_20061221.pdf) 
> provides 5 different examples of interconnection models, and 
> the IDs that would need to be used in each of these cases. In 
> this document, scenario 1 uses the IP address, scenario 2 
> uses NAS-ID and ATM PVC, scenario 3 uses
> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses 
> L2TP tunnel ID (source and destination) and PPPoE session ID. 
> These are just 5 possible examples, and should not be 
> considered exhaustive.

I don't understand the difficulty.  You are implying there is no
communication between the two entities involved in a wholesale relationship.
I envision that during the technical requirements discussion between these 2
entities at the inception of the relationship, there would be discussions by
the access provider along the lines of: "Btw, when you need to discover the
location of an end point, do a sip subscribe to:
[email-masked]"
I don't see the need for a global standard, in fact I see limitations by
attempting to create such standards along the line of your concern about
interconnection models are still evolving.

What am I missing?

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Feb 2007 15:51:25 -0500

> Interconnection models are still evolving.

Well, that's easily solved with a BCP for formulating URIs based on  
the ID.  You don't need a new protocol or to conflate the LCP  
protocol with this functionality.

-andy

---

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

To help clarify the meaning of OBO versus LIS-LIS communication, it is
probably best to define OBO and the concept of identity extension.

OBO - the act of directly requesting a target device's location or
location reference where the LIS provides the same treatment to the
request as if it came from the target itself. An OBO requires a trust
relationship to be established between the requestor and LIS.

Client identity extension - the addition of parameters to the location
request that can be used in addition to, or instead of, the target's IP
address. Examples of additional parameters are MAC address, unique
tunnel identity, and switch/port identity.

Client identity extension can be used in either a standard client=target
type request and it can be used in the case of an OBO. The particular
case of an OBO that is being discussed for the DSL scenario is one that
occurs between LIS' with one acting as the client and the client
identity extension including the L2TP tunnel identifier. The meaning of
OBO didn't change just because the client in this scenario is a LIS.

I don't see any need to consider anything other than the standard
location acquisition protocol for this. I think that question may be
more pertinent to the de-referencing scenario - which is not the same
use case as the one being discussed.

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 12:08 PM
To: Stark, Barbara
Cc: Otmar Lendl; [email-masked]
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

-andy

*****

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 16:04:08 -0600

I agree with Andy - I think you could come up with the same scheme for
identity communication; it's just a protocol after all.

I just don't see why you would suddenly want to use a different protocol
for this special case of an OBO. I don't see any value in that.

A lot of requirements have come up for location acquisition protocols -
request for location reference, request for signed location, nomination
of response time QoS, location assertion...

There is the potential for any or all of these functions to be relevant
in the LIS-LIS special OBO case. There's no point in redefining them in
another protocol.

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, 16 February 2007 7:51 AM
To: Stark, Barbara
Cc: [email-masked]; Otmar Lendl
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Feb 2007 20:49:53 -0500

> identity communication; it's just a protocol after all.

Which, btw, could be used with any of the LbyR protocols.  I mention  
SIP because it is closest to RFC.  But this could be easily applied  
to other any of the HTTP LbyR proposals.  In fact, this sounds like a  
great requirement to be added to the LbyR requirements.

> for this special case of an OBO. I don't see any value in that.

Suddenly?  What is so sudden about this?

But I do agree with OBO being the special case.  And the advantage of  
divorcing it from L7-LCP work is that it can then be applied more  
broadly, across environments that use different LCPs.  That would  
seem to be a tremendous benefit.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 20:06:02 -0600

I don't see the tremendous benefit - however, I'm excited that there's
some semblance of agreement.

What's the requirement you see for LbyR? Do you mean the ability to
support OBO?

There is a requirement for OBO to be able to be done. In what sense is
it not part of the "L7" acquisition protocol work?

Which "nearly RFC" are you referring to specifically?

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, 16 February 2007 12:50 PM
To: Dawson, Martin
Cc: Stark, Barbara; [email-masked]; Otmar Lendl
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 16 Feb 2007 11:16:29 +0100

> it doesn't have to be the IP address.

<irony>

Now I get it.

We don't need HELD or RELO at all. The end-host who wants to 
learn its location can use 4119, too:

Either

* Learn it's external IP address (via STUN)
* subscribe to pres:[email-masked]

or

* subscribe to pres:[email-masked]

We just need to tackle the LIS discovery issue.

</irony>

Is this what you were trying to say?

/ol

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Feb 2007 09:32:32 -0500

> Is this what you were trying to say?

Not at all.  When you quit with your standup comedy routine and  
reread the thread, you'll find you just conflated two issues.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 16 Feb 2007 10:04:39 -0500

I hate to break ranks, but if we could get the user part figured out
(and I do think we would need some standardization, even if it's just a
BCP), I kind of like this proposed solution. It has a certain simplicity
to it.

Since we've been pushing for these LISs to support LbyR, anyway, and
this is really just LbyR, I don't see it as being a different protocol,
yet again. This is a protocol we'd expect to be supported by a LIS in
any case. The only change is that the URI may require careful parsing by
the queried LIS, and the querier LIS needs to support LbyR queries in
both directions.

When I look at the functions in HELD (and RELO has a subset of these),
and think through which of those functions would I really need for
LIS-LIS or OBO, I come up with:
- ability to request reference -- not needed, since, as pointed out,
I've already got a perfectly good non-expiring reference; OBO querier or
LIS doesn't need to ask for references to hand off to others, it should
create its own references for that, as appropriate [aside: a
non-expiring reference and a "LCP" are rather equal in the privacy
debate from the OBO/LIS-LIS perspective.]
- ability to assert location -- not needed for OBO or LIS-LIS; only an
end device should be able to do this, if even that is allowed
- ability to provide rules/profile for privacy -- not needed for OBO or
LIS-LIS; only the device should be able to do this
- ability to sign location -- if this is part of PIDF-LO, then this is
independent of request mechanism
- ability to request that location be signed -- I think we can assume
that the location should be signed if it can be signed
- ability to specify how quickly a response is needed -- this would be
useful, but it may be possible to design around the issue
- have I missed anything?

Supporting URI formats other than SIP (e.g., HTTP) would still need to
be worked. But that format would be common to all LbyR usages.
This in no way removes the requirement for a device-to-LIS "LCP". I
haven't read that into the suggestion at all.

So, I think this idea warrants consideration.
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 3:51 PM
To: Stark, Barbara
Cc: [email-masked]; Otmar Lendl
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote:

> What is difficult, is figuring out a standard format for a URI user 
> part that would allow for all the variations in combinations of IDs 
> that exist, so that a standard format could be defined that would 
> cover all interconnection models. Section 8 of the NENA Location TID
> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP 
> tunnel ID (source and destination) and PPPoE session ID. These are 
> just 5 possible examples, and should not be considered exhaustive.

Well, that's easily solved with a BCP for formulating URIs based on the
ID.  You don't need a new protocol or to conflate the LCP protocol with
this functionality.

-andy

*****

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

---

From: <[email-masked]>
Date: Fri, 16 Feb 2007 16:16:51 -0500

I agree with Barbara and would also add : 

- ability to request geo and/or civic location

The "ability to specify how quickly a response is needed" would also be really helpful to us.

Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great!

Jérôme

-----Message d'origine-----
De : Stark, Barbara [mailto:[email-masked]] 
Envoyé : 16 février 2007 10:05
À : Andrew Newton
Cc : [email-masked]; Otmar Lendl
Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 3:51 PM
To: Stark, Barbara
Cc: [email-masked]; Otmar Lendl
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

-andy

*****

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Feb 2007 22:37:29 -0500

> BCP), I kind of like this proposed solution. It has a certain  

I'm not sure if this is along the lines you suggest, but

http://tools.ietf.org/wg/geopriv/draft-schulzrinne-geopriv- 
locationref-00.txt

investigated a SIP-based solution in this general space.

---

From: <[email-masked]>
Date: Wed, 21 Feb 2007 11:59:57 -0500

To add to my last post, I think something along the lines of draft-winterbottom-geopriv-held-identity-extensions would be more flexible and avoid the creation of yet another document. Since HELD, as mentioned in earlier posts, is also a prime choice to support richer location acquisition mechanisms (ex.: response time, location type preference, request for signing, location assertion, etc), the combination of the two seems to do the job quite nicely.

Jérôme

-----Message d'origine-----
De : Grenier, Jerome (6002687) 
Envoyé : 16 février 2007 16:17
À : 'Stark, Barbara'; Andrew Newton
Cc : [email-masked]; Otmar Lendl
Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement

Jérôme

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 3:51 PM
To: Stark, Barbara
Cc: [email-masked]; Otmar Lendl
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

-andy

*****