Subject: [Geopriv] Next Steps for draft-ietf-geopriv-l7-lcp-ps

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Apr 2007 14:38:16 +0200

Hi all,

I am currently working on the update of draft-ietf-geopriv-l7-lcp-ps.
Since I was not able to attend the IETF#68 GEOPRIV WG meeting and hence 
I need to rely on the meeting minutes or a short summary.
Here are my questions:

- Document structure?

OK to remove
 * VPN Considerations
?

OK to move
 * Location-by-Reference and Location Subscriptions
into Roger's doc?

OK to move
 * Preventing Faked Location based DoS Attacks
 * Security Considerations
to a separate security document?

- Terminology of "Location Information Server (LIS)"

Fall back to RFC3693's "Location Server (LS)"

- Operational Considerations

What should we do?

- Requirements Section

Two items:
   LIS-to-LIS & On-behalf-of
   Need for a Quality of Service response time parameter

Move to Roger's doc?

- Location-by-Reference

Move requirements to draft-marshall-geopriv-lbyr-requirements-00.txt ?

YES? NO?

Ciao
Hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 6 Apr 2007 09:05:15 -0400

See inline for my opinions

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, April 06, 2007 8:38 AM
> To: GEOPRIV
> Subject: [Geopriv] Next Steps for draft-ietf-geopriv-l7-lcp-ps
> 
> Hi all,
> 
I don't think so.  I think they are a significant factor in L7 LCP.
>  * Location-by-Reference and Location Subscriptions
Yes

> to a separate security document?
Yes

> Fall back to RFC3693's "Location Server (LS)"
I'd prefer LIS

> - Operational Considerations
Send text

>    LIS-to-LIS & On-behalf-of
Separate docs

>    Need for a Quality of Service response time parameter
Requires more discussion I think

> Move to Roger's doc?
No, I don't think it has anything to do with LbyR
> Move requirements to draft-marshall-geopriv-lbyr-requirements-00.txt ?
Yes

Brian

---

From: Richard Barnes <[email-masked]>
Date: Fri, 06 Apr 2007 09:57:58 -0400

Hannes,
Responses inline.
--RB

> I need to rely on the meeting minutes or a short summary.
Yes.

> * Location-by-Reference and Location Subscriptions
Yes.

> to a separate security document?
Yes.  (I'll have a draft out Real Soon Now.)

> Fall back to RFC3693's "Location Server (LS)"

Either this, or need a definition of an LIS.  I tend to agree with the 
former (change to LS).  The LIS referred to in the document fits into 
the LS picture in Section 4 of RFC 3693; the LCP use case is special 
only in that the LS is assumed to have access to an LG that can do 
positioning and the L

>   LIS-to-LIS & On-behalf-of
Should have a separate BCP on this, as it's just a specific usage of 
existing mechanisms.

>   Need for a Quality of Service response time parameter
Don't see this as necessary in the base spec, perhaps an extension.  But 
I'm open to discussion.

> Move requirements to draft-marshall-geopriv-lbyr-requirements-00.txt ?

Yes.

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Fri, 6 Apr 2007 08:27:47 -0600

Only one comment:

In the geospatial/GIS/cadastral worlds, LIS = Land Information System. It is 
definitely tough to find a TLA that does not conflict with another TLA!

Carl

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>; "'GEOPRIV'" 
<[email-masked]>
Sent: Friday, April 06, 2007 7:05 AM
Subject: RE: [Geopriv] Next Steps for draft-ietf-geopriv-l7-lcp-ps

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 06 Apr 2007 17:19:12 +0200

Hi Brian 

-------- Original-Nachricht --------
Datum: Fri, 6 Apr 2007 09:05:15 -0400
Von: "Brian Rosen" <[email-masked]>
An: "\'Hannes Tschofenig\'" <[email-masked]>, "\'GEOPRIV\'" <[email-masked]>
Betreff: RE: [Geopriv] Next Steps for draft-ietf-geopriv-l7-lcp-ps

> I don't think so.  I think they are a significant factor in L7 LCP.

The current text would probably better belong to a solution document rather than in a requirements doc. 

I can put a requirement in there that the solution document has to describe that aspect. 

> > Fall back to RFC3693's "Location Server (LS)"

I put LS into the document since it is much easier for me. I don't need to define a new term. 

> > - Operational Considerations

Well, let's see whether our Operations and Management Area Director has time for that. 

> No, I don't think it has anything to do with LbyR

It was meant to be used as a parameter of the dereferencing protocol. 

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 6 Apr 2007 11:26:03 -0400

>> I don't think so.  I think they are a significant factor in L7 LCP.

Agree with Hannes. So far, the only real solution that has been  
proposed is "Contact the LIS on your physical network, preferably  
before you set up the VPN and don't use the VPN-provided IP address."

> The current text would probably better belong to a solution  
> document rather than in a requirements doc.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 6 Apr 2007 11:49:53 -0400

I am okay with something like this as a requirement.  I think some text
describing the problem, and thus the need for this requirement is
appropriate in the document.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, April 06, 2007 11:26 AM
> To: Hannes Tschofenig
> Cc: Brian Rosen; [email-masked]
> Subject: Re: [Geopriv] Next Steps for draft-ietf-geopriv-l7-lcp-ps
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 6 Apr 2007 11:51:23 -0400

> It was meant to be used as a parameter of the dereferencing protocol.
If we accept the requirement to support response time, then it is a
requirement on the L7 LCP as well as the LbyR dereference.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 6 Apr 2007 13:01:54 -0500

I agree with Brian here.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Saturday, 7 April 2007 1:51 AM
> To: 'Hannes Tschofenig'; [email-masked]
> Subject: RE: RE: [Geopriv] Next Steps for draft-ietf-geopriv-l7-lcp-ps
> 

------------------------------------------------------------------------------------------------
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: "Roger Marshall" <[email-masked]>
Date: Fri, 6 Apr 2007 13:29:12 -0700

Please see [my comments], inline. 

>Sent: Friday, April 06, 2007 8:19 AM
>To: Brian Rosen; [email-masked]
>Subject: Re: RE: [Geopriv] Next Steps for draft-ietf-geopriv-l7-lcp-ps
>
>Hi Brian 
>
>
>> > Since I was not able to attend the IETF#68 GEOPRIV WG meeting and 
>> > hence I need to rely on the meeting minutes or a short summary.
>> > Here are my questions:
>> > 
>> > - Document structure?
>> > 
>> > OK to remove
>> >  * VPN Considerations
>> > ?

[RM - I agree that they should be moved to a different doc.]

...
>don't need to define a new term. 

[RM - I'd prefer <LS> in IETF docs.  If disagree, then need explanation
of differences between an IETF LS & an IETF LIS - if there is no
significant difference, then we don't need two terms for the same
thing.]

...
>Hannes

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 6 Apr 2007 15:45:32 -0500

I guess I see a LIS as being unequivocally tied to the access network. I
see the LS as described in 3693 as being tied to the Target and that no
association with the access network is required or implied.
To my mind this is a pretty significant difference.

Cheers
James

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Saturday, 7 April 2007 6:29 AM
> To: Hannes Tschofenig; Brian Rosen; [email-masked]
> The information contained in this message may be privileged and/or
> confidential. If you are not the intended recipient, or responsible
for
> delivering this message to the intended recipient, any review,
forwarding,
> dissemination, distribution or copying of this communication or any
> attachment(s) is strictly prohibited. If you have received this
message in
> error, please so notify the sender immediately, and delete it and all
> attachments from your computer and network.
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 08 Apr 2007 17:58:31 +0200

I believe that this specific deployment consideration is visible from 
the rest of the document. I could add a sentence to the terminology 
section regarding this aspect. Unfortunately, the problem then starts 
when it comes to the definition of access networks.

Ciao
Hannes

Winterbottom, James wrote:
>>> Subject: Re: RE: [Geopriv] Next Steps for
>>>       
> draft-ietf-geopriv-l7-lcp-ps
>   
>>> Hi Brian
>>>
>>>
>>>>> I am currently working on the update of
>>>>>           
>>> draft-ietf-geopriv-l7-lcp-ps.
>>>       
>> [RM - I'd prefer <LS> in IETF docs.  If disagree, then need
>>     
> explanation
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 8 Apr 2007 12:39:37 -0500

Hi Hannes,

My point is that this is a fundamental difference not a simple
"terminology" thing. So yes, I agree that the definition of access
network needs to be clear and that it is different in different
configurations but that is the reality of the beast. I think that saying
something along the lines of the LIS can be considered as an anonymous
LS associated with the IP domain in which the end-point is physically
attached, is probably sufficient.

Cheers
James

> Sent: Monday, 9 April 2007 1:59 AM
> To: Winterbottom, James
> Cc: Roger Marshall; Brian Rosen; [email-masked]
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 08 Apr 2007 19:47:36 +0200

Hi James,

I agree that this is a big difference when you compare the concept of a 
server being in the access and another one that isn't. However, RFC 3693 
is so generic on this issue that you cannot argue whether one or the 
other is meant. For example, consider the SIP Location Conveyance 
document. Obviously, the use case there for attaching a reference to a 
location object is useful in those cases where the SIP proxy is in the 
access network. In that document no new terminology is created either.

Ciao
Hannes

 Winterbottom, James wrote:
>>> I guess I see a LIS as being unequivocally tied to the access
>>>       
> network. I
>   
>>> see the LS as described in 3693 as being tied to the Target and that
>>>       
> no
>   
>>>> Subject: RE: RE: [Geopriv] Next Steps for
>>>>         
>>>>>>> Since I was not able to attend the IETF#68 GEOPRIV WG meeting
>>>>>>>               
> and
>   
>>>>>> I don't think so.  I think they are a significant factor in L7
>>>>>>             
> LCP.
>   
>>>> error, please so notify the sender immediately, and delete it and
>>>>         
> all
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 8 Apr 2007 13:49:38 -0500

Hi Hannes,

RFC-3693 provides the following definition:
"Access Provider (AP):
         The domain that provides the initial network access or other
         data communications services essential for the operation of
         communications functions of the Device or computer equipment in
         which the Device operates.  Often, the AP -- which will be a
         wireless carrier, an Internet Service Provider, or an internal
         corporate network -- contains the LG."

I think that this is sufficient in so far as a LIS is an LS coupled with
the LG.

Cheers
James

> Sent: Monday, 9 April 2007 3:48 AM
> To: Winterbottom, James

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 08 Apr 2007 21:03:51 +0200

Hi James,

you would like to define the term LIS as a device where the Location 
Server is located in the Access Provider's domain and contains a 
Location Generator (with the terms "Location Server", "Access Provider" 
and "Location Generator" from RFC 3693).

Ciao
Hannes

Winterbottom, James wrote:
>> I agree that this is a big difference when you compare the concept of
>>     
> a
>   
>> server being in the access and another one that isn't. However, RFC
>>     
> 3693
>   
>>> configurations but that is the reality of the beast. I think that
>>>       
> saying
>   
>>> something along the lines of the LIS can be considered as an
>>>       
> anonymous
>   
>>> LS associated with the IP domain in which the end-point is
>>>       
> physically
>   
>>>> I believe that this specific deployment consideration is visible
>>>>         
> from
>   
>>>> section regarding this aspect. Unfortunately, the problem then
>>>>         
> starts
>   
>>>>> see the LS as described in 3693 as being tied to the Target and
>>>>>           
> that
>   
>>> no
>>>
>>>       
>>>>>>> Betreff: RE: [Geopriv] Next Steps for
>>>>>>>               
>>>>>>>>> hence I need to rely on the meeting minutes or a short
>>>>>>>>>                   
> summary.
>   
>>>>>>>>> Here are my questions:
>>>>>>>>>
>>>>>>>>> - Document structure?
>>>>>>>>>
>>>>>>>>> OK to remove
>>>>>>>>>  * VPN Considerations
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>> The information contained in this message may be privileged
>>>>>>             
> and/or
>   
>>>>>> confidential. If you are not the intended recipient, or
>>>>>>             
> responsible
>   
>>>>>>             
>>>>> for
>>>>>
>>>>>
>>>>>           
>>>>>> dissemination, distribution or copying of this communication or
>>>>>>             
> any
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 8 Apr 2007 14:36:03 -0500

Yes.

> Sent: Monday, 9 April 2007 5:04 AM
> To: Winterbottom, James

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 08 Apr 2007 22:28:56 +0200

Hi all,

James W. suggested to use the following definition for LIS:

"
Location Information Server (LIS):

A LIS is a device located in the Access Provider's domain that consists 
of a Location Server and a Location Generator.
The terms "Location Server", "Access Provider" and "Location Generator" 
are taken from RFC 3693.
"

What do other people think about using this term in 
<draft-ietf-geopriv-l7-lcp-ps>?

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 08 Apr 2007 15:54:21 -0500

Is the LIS the very first element that creates a PIDF-LO?

If not, it's not appropriate to call the LIS an LG.

At 03:28 PM 4/8/2007, Hannes Tschofenig wrote:
>A LIS is a device located in the Access Provider's domain that 
>consists of a Location Server and a Location Generator.
>The terms "Location Server", "Access Provider" and "Location 
>Generator" are taken from RFC 3693.
>"
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 08 Apr 2007 23:50:01 +0200

I would say so. I, however, recall cases being mentioned where the 
Target has a GPS device but uploads the PIDF-LO to the LIS to get it 
signed (or to retrieve a location-by-reference to this location 
information).

Since the discussion around security is still ongoing I don't know 
whether any of this is going to turn into anything.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 08 Apr 2007 21:51:55 -0500

Hannes

Are you saying the only PIDF-LO that's transmitted is a signed one 
*and* that the PIDF-LO is first created by the LIS (unless there is a 
GPS in the endpoint)?

I think you are mixing terms here (LIS and LS, which are not the same)...

A target that creates and transmits a PIDF-LO consists of both a 
Location Server and a Location Generator, but this target is not a LIS.

At 04:50 PM 4/8/2007, Hannes Tschofenig wrote:
>signed (or to retrieve a location-by-reference to this location information).
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 09 Apr 2007 13:30:46 +0200

Hi James,

In response to your question:

"

I responded with a "YES, BUT..."

The "BUT" refers to discussions we had on the list related to location 
signing and a proposal from my side to replace location signing with a 
location-by-reference concept.

As usual there is no clear answer to your question. For the current 
version of the document I would, however, argue that a clear "YES" is 
appropriate (since the document does not talk about location signing and 
location-by-reference anymore.

Ciao
Hannes

 > >>>consists oFrom [email-masked] Mon Apr 09 07:31:09 2007
Date: Mon, 09 Apr 2007 13:30:46 +0200
From: Hannes Tschofenig <[email-masked]>
To: "James M. Polk" <[email-masked]>
Subject: Re: [Geopriv] Definition of LIS
Cc: [email-masked]

Hi James,

In response to your question:

"

I responded with a "YES, BUT..."

The "BUT" refers to discussions we had on the list related to location 
signing and a proposal from my side to replace location signing with a 
location-by-reference concept.

As usual there is no clear answer to your question. For the current 
version of the document I would, however, argue that a clear "YES" is 
appropriate (since the document does not talk about location signing and 
location-by-reference anymore.

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Mon, 9 Apr 2007 13:38:26 -0400

I don't like the definition being given.  It, and this thread, seem  
to be hung up on the LG.  An LG and an LS have always been able to co- 
exist on the same hardware and even in the same software.  That is  
nothing new.

My understanding has always been that a LIS is a special type of LS  
in relation to the access network it serves, and that the important  
distinction is that a LIS can authenticate/authorize based on access  
network identifiers because of its special relationship with the  
access network.

-andy

On Apr 9, 2007, at 7:30 AM, Hannes Tschofenig wrote:

> The "BUT" refers to discussions we had on the list related to  
> location signing and a proposal from my side to replace location  
> signing with a location-by-reference concept.
>
> version of the document I would, however, argue that a clear "YES"  
> is appropriate (since the document does not talk about location  
> signing and location-by-reference anymore.
>
> Ciao
> Hannes
>
> > Hannes
> >

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 9 Apr 2007 13:45:13 -0400

I'm also uncomfortable with the LG association. We've used LIS to
identify servers in ISP and access networks, where devices query an ISP
LIS, which can query an access network LIS. It's not clear to me what
sort of LG capability the ISP LIS can really be said to have.
Barbara 

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, April 09, 2007 1:38 PM
To: GEOPRIV WG
Subject: Re: [Geopriv] Definition of LIS

I don't like the definition being given.  It, and this thread, seem to
be hung up on the LG.  An LG and an LS have always been able to co-
exist on the same hardware and even in the same software.  That is
nothing new.

My understanding has always been that a LIS is a special type of LS in
relation to the access network it serves, and that the important
distinction is that a LIS can authenticate/authorize based on access
network identifiers because of its special relationship with the access
network.

-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: "Stuard, Doug" <[email-masked]>
Date: Mon, 9 Apr 2007 16:08:45 -0400

I see a LIS as a general case, i.e., a location server without
necessarily having an associated LG.  An Access LIS would be equivalent
to the LS as defined in RFC 3963, as it would always be associated with
(or include) an LG function. The ISP or other higher level LIS would be
the repository of the LO or URI to which queries would be addressed and
where rules would be applied.

Doug

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Monday, April 09, 2007 1:45 PM
> To: Andrew Newton; GEOPRIV WG
> Subject: RE: [Geopriv] Definition of LIS
> 
access
> > The "BUT" refers to discussions we had on the list related to
location
> 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: "James M. Polk" <[email-masked]>
Date: Mon, 09 Apr 2007 16:36:27 -0500

Hannes

[I was on the flight to the SDO meeting during others answers to what 
you wrote below, but I want to be clear how I believe in this regard]

Then we are in disagreement.

Any LIS is an instance of a LS (Location Server), just as a SIP B2BUA 
is an instance of a SIP Proxy server. You can have A without B, but 
you cannot have B without A.

I strongly believe the 3693 description of a target being a Location 
Generator as a distinct possibility, and in fact a probability, from 
Geopriv's point of view.

What you answer below with is a scenario in which neither DHCP or 
LLDP-MED can deliver LCI to a target and have that target create a 
PIDF-LO from that LCI itself.  This inability you want is wrong in my 
view, and contrary to what Geopriv developed from its beginnings.

James

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Apr 2007 03:13:48 +0200

I actually have two questions in this context:

* Shouldn't the "SIP Location Conveyance" document define this term and 
use it in it's document?

* Is it actually true that the LS will always have an LG attached to it? 
Typically, the LS will just talk to some network technology specific LGs 
anyway.

Now, I would define the LIS as:

"

A LIS is a Location Server located in the Access Provider's domain that
is either co-located with a Location Generator (LG) or has access to one or multiple LGs.
The terms "Location Server", "Access Provider" and "Location
Generator" are taken from RFC 3693.

"

Ciao
Hannes

Stuard, Doug wrote:
>> identify servers in ISP and access networks, where devices query an
>>     
> ISP
>   
>>> signing and a proposal from my side to replace location signing with
>>>       
> a
>   
>>>> *and* that the PIDF-LO is first created by the LIS (unless there
>>>>         
>>> is a
>>>       
>>>> GPS in the endpoint)?
>>>>
>>>>> I would say so. I, however, recall cases being mentioned where
>>>>>           
> the
>   
>>>>> Target has a GPS device but uploads the PIDF-LO to the LIS to
>>>>>           
>>> get it
>>>       
>>>>> signed (or to retrieve a location-by-reference to this
>>>>>           
>>>> location information).
>>>>         
>>>>> Since the discussion around security is still ongoing I don't
>>>>>           
> know
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Apr 2007 08:29:56 -0500

At 08:13 PM 4/9/2007, Hannes Tschofenig wrote:
>* Shouldn't the "SIP Location Conveyance" document define this term 
>and use it in it's document?

with my Conveyance author hat off = nooooo...!

Why would this (a LIS) be defined in a SIP spec (that talks about SIP 
user agents and SIP servers)?

A LIS (if this exists as "an entity") would be a SIP UA - and not a 
SIP server - and that is covered in the Conveyance doc by talking 
about SIP UAs.

>* Is it actually true that the LS will always have an LG attached to 
>it? Typically, the LS will just talk to some network technology 
>specific LGs anyway.
>