Subject: Re: [Geopriv] LCP & Arch....

From: Alissa Cooper <[email-masked]>
Date: Sat, 10 Oct 2009 20:55:14 +0100

To try to close the loop on this:

The text we had in -arch before was:
> The process of providing a Target with its own location is known  
> within Geopriv as Location Configuration, and the LG that provides  
> such location is often described as a Location Information Server  
> (LIS). Protocols used exclusively to communicate location from a LIS  
> to a Target are known as Location Configuration Protocols.

Based on your suggestion below and the terminology used throughout the  
rest of the document, here's what I'm thinking:
The process of providing a Target with its own location is known  
within Geopriv as Location Configuration, and the LG that provides  
such location is often described as a Location Information Server  
(LIS).  A location configuration protocol (LCP) is one mechanism that  
can be used by a Target to discover its own location from a LIS.  The  
LCP provides functions in the way it obtains, transports and delivers  
location requests and responses between the LIS and the Target such  
that the LIS can trust that the location requests and responses  
handled via the LCP are in fact from/to the Target.

Alissa

On Sep 18, 2009, at 9:23 PM, Marc Linsner wrote:

> Alissa,
>
> My recent tack of attempting to change the use of "LCP Policy" is  
> due to
> it's overloaded use.  LCP was 'allowed' by the GeoPriv community  
> because it
> provides a basic feature.  It guarantees a posture to the Rulemaker  
> policy
> engine about a request for location - it's the target.  DHCP  
> guarantees the
> request is from the target and will deliver the LCI to the target  
> via the
> layer 2 mechanisms it utilizes.  Baseline HELD performs the same  
> function
> using 3-way handshaking and the return routability of IP.  Neither  
> of these
> mechanisms usurps the Rulemaker Policy engine from doing it's thing.
>
> It has long been the belief within the GeoPriv community that a  
> target has
> the unalienable right to it's own location information, but that is  
> no more
> than the opinion of this group of engineers.  Upon implementation of  
> the
> tools GeoPriv delivers, the *real* 'Rulemaker' will decide.
>
> Example: A target could request DHCP option 123/99 within a discover  
> packet
> and the Rulemaker policy can be to NOT deliver the LCI in the DHCP  
> offer.
> Or, the Rulemaker can return an LCI with only City, State  
> information.  The
> same holds true with baseline HELD.  Hence, the LCP functioned as  
> designed,
> the Rulemaker made the final decision.
>
> The policy is actually associated with a target discovering it's own
> location, not the protocol label that carried the location request.   
> Hence
> the term "LCP Policy" is a misnomer.
>
> On to your question, my suggestion would be:
>
> "A location configuration protocol (LCP) is one mechanism that can  
> be used
> by a target to discover it's own location from a LS/LIS.  The LCP  
> provides
> functions in the way it captures, delivers, and transports location
> requests/responses to/from the LS/LIS such that the LS/LIS can trust  
> that
> the location requests delivered via the LCP are in fact from/to the  
> target."
>
>
>> Assuming the blank gets filled in, I think we all have the same
>> understanding of what an LCP policy is: it's an authorization policy
>> that only allows Targets to obtain their own locations. Depending on
>> how you fill in the blank, this might create the slightly confusing
>> situation where a LIS implements HELD identity extensions (and thus
>> cannot be considered to be using an LCP) but follows the LCP policy
>> (because it is provisioned with a policy that only allows it to
>> provide Targets with their own locations). This confusion may or may
>> not be surmountable by clarifying the text in held-identity.
>
> The heartburn I have from this paragraph is that HELD identity  
> extensions
> does not offer any of the characteristics of an LCP.  A location  
> request
> received by a LS/LIS via HELD identity extensions must perform the
> authentication and posturing of the request prior to making a policy
> decision.  These two functions (authentication and posturing) are
> pre-delivered by an LCP in a trustable manner such that the LS/LIS  
> doesn't
> have to perform them.  HELD identity extensions can not deliver that  
> LCP
> function, hence my request to scrub LCP from that document.
>
> I hope this is understandable and helps,
>
> -Marc-
>
>
>
>
> On 9/18/09 1:39 PM, "Alissa Cooper" <[email-masked]> wrote:
>
>> Ok. So coming back around to how we characterize "LCP" and "LCP
>> policy" in geopriv-arch:
>>
>> Let's discuss LCPs separately from LCP policy, because they are
>> distinct.
>>
>> It sounds like what you are wanting is a description of LCP that goes
>> something like: "A location configuration protocol is a protocol that
>> provides Targets with their own locations and relies on ___________  
>> to
>> authenticate those Targets." How would you fill in the blank?
>>
>> Assuming the blank gets filled in, I think we all have the same
>> understanding of what an LCP policy is: it's an authorization policy
>> that only allows Targets to obtain their own locations. Depending on
>> how you fill in the blank, this might create the slightly confusing
>> situation where a LIS implements HELD identity extensions (and thus
>> cannot be considered to be using an LCP) but follows the LCP policy
>> (because it is provisioned with a policy that only allows it to
>> provide Targets with their own locations). This confusion may or may
>> not be surmountable by clarifying the text in held-identity.
>>
>> On Sep 17, 2009, at 12:25 PM, Marc Linsner wrote:
>>
>>> Nothing prevents changes to the authorization policy when utilizing
>>> the DHCP
>>> mechanism.  The LIS function decides authorization, DHC simply
>>> provides
>>> authentication.  Until now, everyone has assumed a TDIL policy is
>>> utilized
>>> with the DHCP mechanism, but there is nothing inherent in the
>>> protocols that
>>> would lockdown the policy.  That would be an implementation choice.
>>>
>>> -Marc-
>>>
>>>
>>> On 9/17/09 12:13 PM, "Alissa Cooper" <[email-masked]> wrote:
>>>
>>>> Agreed on all these points, except the idea that there's a Rule  
>>>> Maker
>>>> in DHCP location configuration. If the policy is not changeable,  
>>>> what
>>>> is the use of claiming that there is a Rule Maker?
>>>>
>>>> On Sep 17, 2009, at 11:59 AM, Marc Linsner wrote:
>>>>
>>>>> Alissa,
>>>>>
>>>>> I don't believe you are comparing use cases, you are comparing
>>>>> mechanisms.
>>>>>
>>>>> The use cases are more simple.
>>>>>
>>>>> 1) A target discovering it's location (TDIL)
>>>>> 2) Third party discovering someone else's location
>>>>>
>>>>> more in-line.......
>>>>>
>>>>> -Marc-
>>>>>
>>>>>
>>>>> On 9/17/09 10:20 AM, "Alissa Cooper" <[email-masked]> wrote:
>>>>>
>>>>>> Before we get back to the terminology question that Marc has  
>>>>>> raised
>>>>>> regarding LCP, it might be useful to map out the use cases we are
>>>>>> discussing to see where the real differences are. I have made an
>>>>>> attempt below based on the recent discussions -- are these the
>>>>>> distinctions that we should be making?
>>>>>>
>>>>>>
>>>>>> In the rough process for an LS providing location to an LR, the  
>>>>>> LS:
>>>>>>
>>>>>> 1. Authenticates the LR.
>>>>>> 2. Checks whether the LR is authorized to receive the location it
>>>>>> requested.
>>>>>> 3. Provides the location if the LR is authorized.
>>>>>>
>>>>>> I think we have four basic use cases that we've been comparing.
>>>>>>
>>>>>> I. In DHCP, the steps above are as follows:
>>>>> This mechanism can only fulfill use case #1
>>>>>>
>>>>>> 1. Authentication: based on DHC
>>>>>> 2. Authorization: implicit because LR is the Target
>>>>> Authorization: Rulemaker: well-known TDIL policy
>>>>>
>>>>>> 3. Provide LI (per 3825 or 4776) or location URI pointing to LO
>>>>>> (per
>>>>>> dhcp-lbyr-uri)
>>>>>>
>>>>>> II. In the base HELD protocol, the steps are:
>>>>> This mechanism can only fulfill use case #1
>>>>>>
>>>>>> 1. Authentication: return-routeability of IP address
>>>>>> 2. Authorization: based on Rule Maker rules (which may be
>>>>>> equivalent
>>>>>> to the "LCP policy" of only providing a Target with its own
>>>>>> location,
>>>>>> or may forbid even that for certain Targets, per Martin's email
>>>>>> [1]/
>>>>>> held section 9.3)
>>>>> Authorization: Rulemaker policy (most cases = well-known TDIL
>>>>> policy)
>>>>>
>>>>>> 3. Provide LO or location URI pointing to LO
>>>>>>
>>>>>> III. For a Target using a HELD identity extension to obtain its  
>>>>>> own
>>>>>> location, the steps are:
>>>>>>
>>>>>> 1. Authentication: required, but we can't mandate anything  
>>>>>> detailed
>>>>>> since it depends on the identifier presented (per Richard's email
>>>>>> [2])
>>>>> Authentication: Required, regardless how difficult
>>>>>> 2. Authorization: based on Rule Maker rules (which may be
>>>>>> equivalent
>>>>>> to the "LCP policy" of only providing a Target with its own
>>>>>> location,
>>>>>> or may forbid even that for certain Targets, per Martin's email
>>>>>> [1]/
>>>>>> held section 9.3)
>>>>> Authorization: Rulemaker policy
>>>>>> 3. Provide LO or location URI pointing to LO
>>>>>>
>>>>>> IV. For an LR using a HELD identity extension to obtain some  
>>>>>> other
>>>>>> Target's location, the steps are:
>>>>>>
>>>>>> 1. Authentication: required, but we can't mandate anything  
>>>>>> detailed
>>>>>> since it depends on the identifier presented (per Richard's email
>>>>>> [2])
>>>>> Authentication: Required, regardless how difficult
>>>>>> 2. Authorization: based on Rule Maker rules
>>>>> Authorization: Rulemaker policy
>>>>>> 3. Provide LO or location URI pointing to LO
>>>>>>
>>>>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/
>>>>>> msg07874.html
>>>>>> [2] http://www.ietf.org/mail-archive/web/geopriv/current/
>>>>>> msg07880.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 17, 2009, at 8:21 AM, Marc Linsner wrote:
>>>>>>
>>>>>>> Martin,
>>>>>>>
>>>>>>> We still have a disconnect.
>>>>>>>
>>>>>>> LCP is one mechanism that assists the function whereby a  
>>>>>>> ‘targets
>>>>>>> discovers it location’ (TDIL)
>>>>>>> The LCP mechanism is specific to the action of the communication
>>>>>>> protocol ensuring the requester of location is the target.  That
>>>>>>> is/
>>>>>>> was the agreed to definition by the GeoPriv community.
>>>>>>> Identity Extensions does not/can not employ the LCP mechanism.
>>>>>>> The policy you want is the ‘TDIL policy’.
>>>>>>>
>>>>>>> I suggest you divorce the term LCP from the Identity Extensions
>>>>>>> draft.  I earlier suggested that LCP be mentioned in the draft
>>>>>>> as a
>>>>>>> comparison such to draw functional parallels.  Now I’m wondering
>>>>>>> if
>>>>>>> that’s even necessary.
>>>>>>>
>>>>>>> -Marc-
>>>>>>>
>>>>>>>
>>>>>>> On 9/16/09 8:05 PM, "Thomson, Martin"  
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I wouldn’t go so far to label LCP as an aberration (more  
>>>>>>>> below),
>>>>>>>> but I agree with the basic message.
>>>>>>>>
>>>>>>>> I hope that HELD makes Marc’s point absolutely clear:
>>>>>>>>
>>>>>>>> The LIS MUST
>>>>>>>> verify that the client is the target of the returned location,
>>>>>>>> i.e.,
>>>>>>>> the LIS MUST NOT provide location to other entities than the
>>>>>>>> target.
>>>>>>>> Note that this is a necessary, but not sufficient criterion for
>>>>>>>> authorization.  A LIS MAY deny requests according to any local
>>>>>>>> policy.
>>>>>>>>
>>>>>>>> There is no such ‘right’.  Besides, we’re not in any position  
>>>>>>>> to
>>>>>>>> assign any ‘rights’.
>>>>>>>>
>>>>>>>> I think that the concept of ‘LCP policy’ is a good way to  
>>>>>>>> address
>>>>>>>> these concerns.  This actually provides a way that we can treat
>>>>>>>> an
>>>>>>>> LCP as part of the architecture.
>>>>>>>>
>>>>>>>> This is the policy under which we imagine that a LCP server  
>>>>>>>> might
>>>>>>>> operate.  LCP has all of the functions that are required
>>>>>>>> (requester
>>>>>>>> authentication, privacy protections, rule makers, etc…), it’s
>>>>>>>> just
>>>>>>>> that most of these are hard-coded.  However, we need to be
>>>>>>>> absolutely clear when we are making statements that depend on
>>>>>>>> this
>>>>>>>> policy.
>>>>>>>>
>>>>>>>> And like Marc says, we should never assume that this policy
>>>>>>>> exists;
>>>>>>>> that wouldn’t be right.
>>>>>>>>
>>>>>>>> --Martin
>>>>>>>>
>>>>>>>>
>>>>>>>> From: [email-masked] [mailto:geopriv-
>>>>>>>> [email-masked]] On
>>>>>>>> Behalf Of Marc Linsner
>>>>>>>> Sent: Thursday, 17 September 2009 6:52 AM
>>>>>>>> To: GEOPRIV
>>>>>>>> Subject: [Geopriv] LCP & Arch....
>>>>>>>>
>>>>>>>> To add more to my rant about LCP on the interim meeting call
>>>>>>>> yesterday.....
>>>>>>>>
>>>>>>>> LCP is an aberration of the GeoPriv architecture.  Early on,  
>>>>>>>> the
>>>>>>>> GeoPriv work group agreed to allow LCP based on the fact the
>>>>>>>> underlying communication protocol would ensure the LCI provided
>>>>>>>> belonged to the recipient.  Hence, no work required at the LS/ 
>>>>>>>> LIS
>>>>>>>> to verify that the requester is the target.  It was never  
>>>>>>>> agreed
>>>>>>>> that LCP was a ‘function’ that GeoPriv would provide, but LCP  
>>>>>>>> is
>>>>>>>> simply an aberration that shares the baggage associated with  
>>>>>>>> the
>>>>>>>> GeoPriv Privacy architecture with a communication protocol that
>>>>>>>> can
>>>>>>>> provide the guarantees as described.
>>>>>>>>
>>>>>>>> Hence, we have created 2 LCP solutions, DHCP and (baseline)  
>>>>>>>> HELD.
>>>>>>>> Both these mechanisms protect the privacy of the location  
>>>>>>>> data as
>>>>>>>> they guarantee that the target is the recipient.  Any mechanism
>>>>>>>> where the communication protocol cannot provide this guarantee
>>>>>>>> MUST
>>>>>>>> be considered ‘not an LCP’ and follow the whole GeoPriv  
>>>>>>>> privacy/
>>>>>>>> security architecture (policy set by rulemaker, enforced by LS/
>>>>>>>> LIS,
>>>>>>>> etc.).
>>>>>>>>
>>>>>>>> My hope is to dispel the myth that LCP is a ‘right’ that target
>>>>>>>> has
>>>>>>>> to gain access to it’s own location data and GeoPriv must  
>>>>>>>> deliver
>>>>>>>> on this ‘right’ at all costs.  The overall privacy/security
>>>>>>>> architecture must still be followed when a target is  
>>>>>>>> discovering
>>>>>>>> it’s own location (trust relationships, identity verification,
>>>>>>>> rule-
>>>>>>>> based policy, etc.).
>>>>>>>>
>>>>>>>> -Marc-
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> --
>>>>>>>> --
>>>>>>>> --------------------
>>>>>>>> This message is for the designated recipient only and may
>>>>>>>> contain privileged, proprietary, or otherwise private
>>>>>>>> information.
>>>>>>>> If you have received it in error, please notify the sender
>>>>>>>> immediately and delete the original.  Any unauthorized use of
>>>>>>>> this email is prohibited.
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> --
>>>>>>>> --
>>>>>>>> --------------------
>>>>>>>> [mf2]
>>>>>>> _______________________________________________
>>>>>>> Geopriv mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Geopriv mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>
>

---

From: Marc Linsner <[email-masked]>
Date: Mon, 12 Oct 2009 08:24:32 -0400

I obviously agree.... :^)

-Marc-

On 10/10/09 3:55 PM, "Alissa Cooper" <[email-masked]> wrote:

>>>>>>>> Œtargets
>>>>>>>> discovers it location¹ (TDIL)
>>>>>>>> The policy you want is the ŒTDIL policy¹.
>>>>>>>> 
>>>>>>>> comparison such to draw functional parallels.  Now I¹m wondering
>>>>>>>> if
>>>>>>>> that¹s even necessary.
>>>>>>>> 
>>>>>>>> -Marc-
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> I wouldn¹t go so far to label LCP as an aberration (more
>>>>>>>>> below),
>>>>>>>>> I hope that HELD makes Marc¹s point absolutely clear:
>>>>>>>>> 
>>>>>>>>> The LIS MUST
>>>>>>>>> There is no such Œright¹.  Besides, we¹re not in any position
>>>>>>>>> to
>>>>>>>>> assign any Œrights¹.
>>>>>>>>> 
>>>>>>>>> I think that the concept of ŒLCP policy¹ is a good way to
>>>>>>>>> address
>>>>>>>>> authentication, privacy protections, rule makers, etcŠ), it¹s
>>>>>>>>> just
>>>>>>>>> that wouldn¹t be right.
>>>>>>>>> that LCP was a Œfunction¹ that GeoPriv would provide, but LCP
>>>>>>>>> is
>>>>>>>>> be considered Œnot an LCP¹ and follow the whole GeoPriv
>>>>>>>>> privacy/
>>>>>>>>> My hope is to dispel the myth that LCP is a Œright¹ that target
>>>>>>>>> has
>>>>>>>>> to gain access to it¹s own location data and GeoPriv must
>>>>>>>>> deliver
>>>>>>>>> on this Œright¹ at all costs.  The overall privacy/security
>>>>>>>>> it¹s own location (trust relationships, identity verification,
>>>>>>>>> rule-
>>>>>>>>> based policy, etc.).
>>>>>>>>> 
>>>>>>>>> -Marc-
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 12 Oct 2009 18:14:12 -0500

Looks good.

Pedantic question: Isn't this LS, not LG?

From my understanding of the model, the LG never provides location to another.  In some cases, the LIS necessarily only acts as LS and the actual LG can be elsewhere.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Marc Linsner
> Sent: Monday, 12 October 2009 11:25 PM
> To: Alissa Cooper
> Cc: GEOPRIV
> Subject: Re: [Geopriv] LCP & Arch....
> 
> >>>>>>>>> -------------------------------------------------------------
> ---------
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --------------------
> >>>>>>>>> -------------------------------------------------------------
> ---------
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --------------------
> >>>>>>>>> [mf2]

------------------------------------------------------------------------------------------------
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: Alissa Cooper <[email-masked]>
Date: Tue, 20 Oct 2009 08:59:20 +0100

I realized that I had previously proposed an edit to this same section  
for a different reason (http://www.ietf.org/mail-archive/web/geopriv/current/msg07828.html 
), and those changes are not reflected in the suggested text below.  
So, putting it all together, here is what I think we have:

3.2.2. Location Configuration

   Some performing the Location Generator role are designed only to
   provide Targets with their own locations (as opposed to distributing
   a Target's location to others).  The process of providing a Target
   with its own location is known within Geopriv as Location
   Configuration. The term Location Information Server (LIS) is often  
used
   to describe the entity that performs this function (although a LIS  
may also
   perform other functions, such as providing a Target's location to  
other entities).  A Location Configuration Protocol (LCP) is one  
mechanism that can be used by a Target to discover its own location  
from a LIS.  The LCP provides functions in the way it obtains,  
transports and delivers
location requests and responses between the LIS and the Target such  
that the LIS can trust that the location requests and responses
handled via the LCP are in fact from/to the Target.  Several LCPs have  
been developed within Geopriv [9][10][11][12].

   A LIS whose sole purpose is to perform Location Configuration need  
only follow a simple privacy-preserving
   policy: transmit a Target's location only to the Target itself.  This
   is known as the "LCP policy."

   Importantly, if an LS is also serving in the role of LG and it has
   not been provisioned with Privacy Rules for a particular Target, it
   MUST follow the LCP policy, whether it is a LIS or not.  In the
   positioning phase, an entity serving the roles of both LG and LS that
   has not received Privacy Rules must follow this policy.  The same is
   true for any LS in the distribution phase.

I think this makes it clear that a LIS can serve the role of LG or of  
LS.

Alissa

On Oct 13, 2009, at 12:14 AM, Thomson, Martin wrote:

> From my understanding of the model, the LG never provides location  
> to another.  In some cases, the LIS necessarily only acts as LS and  
> the actual LG can be elsewhere.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Oct 2009 06:50:59 +0800

Hi Alissa,

This looks good, except that I think that my comment was mostly addressed at the first sentence.  I'd prefer:

   Some performing the Location _Server_ role are designed only to
   provide Targets with their own locations (as opposed to
   distributing a Target's location to others). ...

Reason: I'm a nasty pedant.

Or: The Location Server is the only role that provides location to any other entity.  Consider the possibility that the entity providing location information did not generate it.

(nit: The first paragraph could be three, given that it makes three distinct statements.)

--Martin

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Tuesday, 20 October 2009 6:59 PM
> To: Thomson, Martin
> Cc: Marc Linsner; GEOPRIV
> for a different reason (http://www.ietf.org/mail-
> archive/web/geopriv/current/msg07828.html

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Oct 2009 06:33:33 +0100

I don't think it's true that an LS is the only entity that provides  
location to any other entity, because an LS has to obtain location  
somehow, and it does that by receiving location from an LG. The  
definition of LG in geopriv-arch is explicit about this.

I also think I read the first paragraph differently. It doesn't say  
that a LIS performs the LG role. It also doesn't say that a LIS  
performs the LS role. It's a server in an access network that can  
perform either role, or neither role. We discussed this before and  
reached that conclusion: http://www.ietf.org/mail-archive/web/geopriv/current/msg07579.html

On Oct 20, 2009, at 11:50 PM, Thomson, Martin wrote:

> Hi Alissa,
>
> This looks good, except that I think that my comment was mostly  
> addressed at the first sentence.  I'd prefer:
>
> Or: The Location Server is the only role that provides location to  
> any other entity.  Consider the possibility that the entity  
> providing location information did not generate it.
>
>> distributing

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 22 Oct 2009 06:14:58 +0800

The entity in the LS role must have also acquired location some time previous.  It does this either by assuming the LG role (as we imagine a LIS), or by assuming the LR role.

That is, a LIS might be an LG, but it might also just be an LR.

I think that the mail you referred to supports this conclusion:

  "The LIS assumes the role of LG when generating location information, and the role of LS when providing it."

My main point is that providing location is a function of the LS role and the discussion on location configuration mainly focuses on that act.

--Martin

> Sent: Wednesday, 21 October 2009 4:34 PM
> To: Thomson, Martin
> reached that conclusion: http://www.ietf.org/mail-
> archive/web/geopriv/current/msg07579.html
>