Subject: [Geopriv] I-D Action:draft-ietf-geopriv-arch-00.txt

From: [email-masked]
Date: Sun, 12 Jul 2009 19:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title           : An Architecture for Location and Location Privacy in Internet Applications
	Author(s)       : R. Barnes, et al.
	Filename        : draft-ietf-geopriv-arch-00.txt
	Pages           : 42
	Date            : 2009-07-09

Location-based services (such as navigation applications, emergency
services, management of equipment in the field) need geographic
location information about Internet hosts, their users, and other
related entities.  These applications need to securely gather and
transfer location information for location services, and at the same
time protect the privacy of the individuals involved.  This document
describes an architecture for privacy-preserving location-based
services in the Internet, focusing on authorization, security, and
privacy requirements for the data formats and protocols used by these
services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-arch-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 13 Jul 2009 10:05:34 -0400

What was formerly lo-sec has been submitted as geopriv-arch. The  
document contains tons of changes based on the feedback received  
before and during the last meeting. A few things to look out for:

* We got rid of the notion of LR as "ultimate" recipient. Now LR  
describes any entity that receives location.

* The protocol labels are gone.

* Location configuration is called out explicitly. LIS is defined as a  
special case of LG that only provides a Target with its own location.

* Section 4 is probably going to come out or get significantly re- 
worked in an upcoming version.

* We're still working on adding a section that discusses discrepancies  
and/or missing terminology between geopriv-arch and 3693 (it's not in  
this version).

Alissa

Begin forwarded message:

> From: [email-masked]
> Date: July 12, 2009 10:30:01 PM EDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] I-D Action:draft-ietf-geopriv-arch-00.txt
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 Jul 2009 12:21:52 -0500

A couple of comments in general

firstly, there are more than 5 authors listed, which is not 
acceptable to the RFC-Editor any longer.

more in-line below

At 09:05 AM 7/13/2009, Alissa Cooper wrote:
>before and during the last meeting.

yet the acknowledgements section only says the design team was behind 
the effort.

>A few things to look out for:
>

err, this is yet another definition change in the grand scheme of Geopriv...

so, a LIS is an LCP server, and what is the destination of 
subscriptions for dereferences - but only by the target itself, not 
dereferences by other entities?

hmmm

This is confusing at best, and at worst - others outside of this WG 
will not understand this arch at all because of this.

Please see comments on the SIPCORE list as proof of this (made to the 
list, but not by me)

>>         Title           : An Architecture for Location and 
>> Location Privacy
>>in Internet Applications
>Content-Type: text/plain<BR>Content-ID: 
>&lt;[email-masked]&gt;<BR><BR>
>
>

---

From: [email-masked]
Date: Tue, 14 Jul 2009 09:35:52 +0100

> dereferences by other entities?

I'm not happy with this either.

What are the motives for this change?  It seems to me that generically a 
"LIS" is widely taken to mean anything that implements HELD (or similar?) 
regardless of who is requesting the location and to restrict the 
terminology now seems rather odd.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: [email-masked]
Date: Tue, 14 Jul 2009 20:07:15 +0100

> The notion of a LIS in the role that provides a Target with its own 
> location seems to be supported in the rest of our existing geopriv 
> documents (lis-discovery, lbyr-requirements, held, l7-lcp-ps). Can you 
> provide references that instead point to LIS as a dereference server 
> that responds to any LR's request?

I am not concerned with LbyR dereferencing, I'm concerned with (what was 
called) LIS-to-LIS and also (more importantly) third party queries where 
the Target is not directly involved.

Ray

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 14 Jul 2009 14:53:00 -0400

James, Ray,

The last time we were discussing lo-sec, it was obvious that some  
clarity was needed about a single entity performing multiple Geopriv  
roles. Throughout the new version of the document, we've tried to make  
that clear, both by stating it explicitly ("It is not uncommon for the  
same entity to perform both the LG and LS roles, or both the LR and LS  
roles." in section 2), and by consistently referring to "the entity  
acting as L_" or the "the entity performing the role of L_".

This holds true for LIS as much as any other Geopriv role. Nothing  
prevents an entity acting as a LIS from also acting as an LS. Perhaps  
my one-sentence description was more confusing/objectionable than the  
text itself. From section 3.2.2:

> 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, 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 [8]. Several such protocols have  
> been developed within Geopriv [9][10][11][12].
>  By definition, a LIS needs only to 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.
The notion of a LIS in the role that provides a Target with its own  
location seems to be supported in the rest of our existing geopriv  
documents (lis-discovery, lbyr-requirements, held, l7-lcp-ps). Can you  
provide references that instead point to LIS as a dereference server  
that responds to any LR's request?
Also, we will get authors/acknowledgements squared away in a  
subsequent draft.
Alissa
On Jul 14, 2009, at 4:35 AM, [email-masked] wrote:

> What are the motives for this change?  It seems to me that  
> generically a "LIS" is widely taken to mean anything that implements  
> HELD (or similar?) regardless of who is requesting the location and  
> to restrict the terminology now seems rather odd.
>
> Ray
>
> --

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 14 Jul 2009 16:59:23 -0500

Hi Alissa,

Please take a look at http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-03 that was accepted as a working group item in March of last year.

This document is all about a LIS also providing a dereference service for location URIs.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Alissa Cooper
Sent: Tue 7/14/2009 1:53 PM
To: [email-masked]; James M. Polk
Cc: GEOPRIV
Subject: Re: [Geopriv] Fwd:  I-D Action:draft-ietf-geopriv-arch-00.txt
 
James, Ray,

------------------------------------------------------------------------------------------------
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: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 22:11:52 -0500

At 01:53 PM 7/14/2009, Alissa Cooper wrote:
>roles.

I agree that a single entity can perform multiple roles - but that's 
the opposite of what you're suggesting here; as you're changing the 
same function and definition of the entity based on who's asking for 
the same information -- which is what I object to.

>Throughout the new version of the document, we've tried to make

again - that's the opposite of what's happening here.

What you are saying is that a LIS is the dereference server and 
destination of a location URI from the target *only*.

If a 3rd party wants that same target's PIDF-LO using the _same_ 
location URI it is no longer contacting the LIS, it is contacting a 
Location Server.

This is nuts.

LISs should be used for 1 purpose, as should Location Servers.

A LIS should be used to provide LI to a Target via an LCP.

Location Servers are location inserters (i.e., the SIP UA or Proxy 
that inserts location into the SIP request).

We need to have another singular purpose term defined as the 
destination of the location URI, call it a Dereference Server (DS) 
which provides PIDF-LOs from Location Recipients that were given a 
location URI from or of a target.

This means everything is clearly singular in

>documents (lis-discovery, lbyr-requirements, held, l7-lcp-ps).

"...the rest of our existing geopriv documents..."

These are all HELD originated and HELD only documents.  Surely 
Geopriv has produced more documents that just about HELD, hasn't it?

If so, then this quote isn't so accurate, is it?

BTW - which of these documents define how HELD returns a PIDF-LO in a response?

>Can you  provide references that instead point to LIS as a 
>dereference server

Can you?

A LIS has always been our least defined entity.

As suggested above, why get into a discussion about an acronym (LIS) 
that does a function that accurately describes what we're talking 
about just fine (i.e., Dereference Server (DS)).

This would solve all our problems and minimize or eliminate 
everyone's confusion.

>Also, we will get authors/acknowledgements squared away in 
>a  subsequent draft.

yeah -- and the 2 chairs are part of that author team... so who's 
running this document (as a matter of process)?

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 23:24:57 -0500

At 04:59 PM 7/14/2009, Winterbottom, James wrote:
>Hi Alissa,
>
>Please take a look at 
>http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-03 
>that was accepted as a working group item in March of last year.

this is 16 months old and there isn't an updated version on the tools 
page for geopriv?

how are we wg members supposed to keep up with docs that are this old?

>service for location URIs.

so a HELD doc (that's this old) defines how a general Geopriv entity 
is to be defined.

ummmm-k

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 16 Jul 2009 01:50:27 -0500

James,

Version -00 (or -01) of this document, which was the combined result of work from JamesW, Henning, Hannes and myself was accepted.  Since then, the WG item was blocked (I don't know why) and we've had a few more revisions.

This is on the tools page and -03 is the current and active version.  I don't see why there would be a problem.  It's not old, it's just that we've not needed to update it.

--Martin

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Thursday, 16 July 2009 2:25 PM
> To: Winterbottom, James; Alissa Cooper; [email-masked]
> Cc: GEOPRIV
> > > > >* Location configuration is called out explicitly. LIS is
> defined
> > > as a

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 16 Jul 2009 10:22:54 -0400

I was asking about other docs because the conception of what a LIS is  
has to come from somewhere, and I wanted to know what comes to  
people's minds when they think of it. Deref was useful in that respect.

On the LIS point, a simple way to solve this could be to define LIS as  
follows (unless there's another document out there that directly  
contradicts this definition), in 3.2.3 of geopriv-arch:

"A LIS provides location URIs to LRs."

And then the discussion of the LIS in 3.2.2 could be taken out.

This doesn't address the issue of dereferencing, but does it get the  
job done on defining a LIS?

Alissa

---

From: [email-masked]
Date: Thu, 16 Jul 2009 15:39:41 +0100

> people's minds when they think of it. Deref was useful in that respect.

To me a LIS is any server that provides location information, and more 
specifically one that implements HELD.

That is irrespective of whether the input query is a Location URI (which 
needs dereferencing) or a parameterized HELD request containing the 
various extensions.

> job done on defining a LIS?

This seems somewhat better, yes.

kind regards,

Ray

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Jul 2009 13:53:01 -0500

and here's the rub...

3 consecutive active WG participants give 3 different answers with 3 
consecutive messages to the Geopriv list 8 years after the WG was formed.

(sarcastically) that's brilliant!

Alissa says LISes give location URIs out.

Ray says LISes give LI out.

Brian says LISes give LOs and location URIs out.

these are THREE different behaviors folks.

LI has zero identity, therefore LISes cannot give out PIDF-LOs (so 
they are not dereference servers).

If LISes only gave out location URIs, then that makes a Proxy that 
inserts location a LIS, which I don't believe anyone agrees with (but 
I could be wrong, there might be one or two that believe this).

Brian says LISes give everything out, except LI (i.e., that has no 
identity associated).

We need a single entity defined and labelled that location URIs point 
to, that provides PIDF-LOs when a LR subscribes to it to get that 
PIDF-LO of a Target (and I don't care whether it's the target itself 
or a 3rd party that's subscribing - a dereference transaction is a 
dereference transaction).

This makes this a specific purpose entity within the Geopriv 
Architecture - and I believe it ought to be called what it does, a 
Dereference Server (DS).

James

At 11:10 AM 7/16/2009, Brian Rosen wrote:
>Generally, we call things that deliver location values as well as URIs to be
>LISses.
>
>Brian
>
> > Behalf Of Alissa Cooper
> > Sent: Thursday, July 16, 2009 10:23 AM
> > To: James M. Polk; [email-masked]
> > Cc: GEOPRIV

---

From: [email-masked]
Date: Thu, 16 Jul 2009 21:24:11 +0100

> (sarcastically) that's brilliant!

To be fair, I'm relatively new here ('75 will be my sixth IETF) and I'm 
still suffering from acronym overload :(

My answer wasn't intended to be restrictive, but it is the case I'm most 
familiar with because it's the one we need for VoIP ES location in the UK. 
 We don't have LbyR URIs, we just have a URI that points to a HELD server 
and then we send the appropriate identity extensions.  We get back a 
PIDF-LO.

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 16 Jul 2009 12:10:29 -0400

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 16 Jul 2009 16:46:43 -0500

I agree - and I don't think the fact that different folk emphasise
different aspects of the LIS when they describe what it means to them is
actually an indication of poor understanding or agreement.

I'd say that a LIS is a server that provides a location value or
reference to a target device or to a third party by, for example,
dereference.

A LIS may be devolved into two components - the LS which is responsible
for serving the location requests (e.g. target query and third party
dereference) and the LG which is responsible for determining/generating
the actual location information. The IETF only defines the protocols
applicable to the LS component (that I'm aware of).

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Friday, 17 July 2009 2:10 AM
To: 'Alissa Cooper'; 'James M. Polk'; [email-masked]
Cc: 'GEOPRIV'
Subject: Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-00.txt

Generally, we call things that deliver location values as well as URIs
to be
LISses.

Brian

> >> text itself. >From section 3.2.2:
> >>
> >>> > err, this is yet another definition change in the grand scheme
of
> >>> Geopriv...

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Jul 2009 17:36:22 -0500

>Generally, we call things that deliver location values as well as URIs to be

I thought so too, until I was mercilessly corrected on the SIPCORE 
list by Martin -- to the point of him saying:

         "It's becoming more and more apparent that you (James) don't 
understand
         how location by reference is deployed. "

Add this to Alissa's bullet about the changes to the 
draft-ietf-geopriv-arch-00 ID from the original loc-sec-05 stating 
the LIS was used to dereference a PIDF-LO, but only if it is the 
target that's doing the dereferencing.

color me confused (still)

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 16 Jul 2009 20:41:47 -0500

Let me explain my understanding of this.  Perhaps it will help some people who are having trouble with the concepts, the design choices and how GEOPRIV translates into reality.

My belief is that the content of this essay is consistent with what is in the architecture document, with the caveat that I haven't yet thoroughly reviewed the latest version.  I don't believe that there is any need to fundamentally alter that document, although clarification might be helpful on some points.

==Roles

The 5 roles in GEOPRIV - LG, LS, LR, Target and RM - are logical.  These 5 roles are also sufficient to describe the entire model.

  LG creates/determines/makes location.
  LS provides/serves location.
  LR accepts/requests location.
  Target is the subject (this is a passive role)
  RM controls how an LS provides/serves location.

An entity might assume any one of these roles, depending on what it is that they are doing.

There are other terms for entities, but these are either more specific definitions (LIS), or they relate to actual physical actors (Device, Person).  These terms are not necessary to describe the model, but they are somewhat helpful in relating that model to reality - something that we inevitably have to do if this is ever going to be of any use to anyone.

==The LIS

The term LIS is a specialized, just as LCP is.  Describing the LCP case in terms of these roles is simple:

  Location configuration is necessary when a device is unable to determine its own location.  A server in the network fills this function.  This server is named LIS.  The LIS assumes the role of LG when generating location information.  For this purpose, the Device assumes the role of Target (c.f. HELD Sec3).  

  The LIS then assumes the role of LS and the Device assumes the role of LR when the LIS provides the Device with its location.  The RM role in this exchange is rather abstract; the LS allows access to location based on the LCP policy, a necessary exception.

In this sense, the architecture document doesn't _need_ to talk about the LIS; but then it wouldn't be particularly relevant if it didn't deal with this very important case and the special circumstances surrounding it (LCP policy, etc).

BTW, Alissa: I your definition of LIS isn't complete.  Deriving as it does from draft-winterbottom-geopriv-deref-protocol it doesn't consider all cases.

==Dereference

Dereference isn't special in any way.  It doesn't need special terms beyond the basic set of 5 roles.  The HELD deference draft uses LIS, because it relates the dereference operation back to the LCP case; it doesn't need to, but relevance is again aided by relating this to reality.

==LI versus LO

You'll note that I haven't distinguished between LI and LO in these descriptions.  That's intentional; it's somewhat more complicated.

A location object binds identity to location, that's its purpose.  But this is also a function performed by protocols, leading to the current tension.

One form of binding is performed in HELD and DHCP through the identity that is implicitly carried in the request.  When making an LCP request, the requester is fairly certain of what they're asking for without needing to consult the LO.  The protocol semantics are clear: they are requesting their own location.

DHCP only provides LI, therefore it is unaffected.  HELD provides a LO, or at least appears to, and thus we are led to the problem we're discussing both here and in SIPCORE.

Now, I don't see this is a problem.  I just see this as a case where domains intersect.  But you have to think it through carefully and thoroughly.  One problem that we're having is that identity is perceived as being absolute, which is false.  This shouldn't be a revolutionary concept in this forum, where the prevalent form of identity - the IP address - is well understood to be relative.  The understanding of what 192.0.2.75 means varies depending on where you stand.  Or, to take more extreme cases, the meaning of 10.0.2.3 or 127.0.0.1.

But I digress.  Even in the context of an LCP, the specific identity used in the exchange between Device and LIS is not absolute.  The Device might think "me", "ab:cd:ef:12:34:56" or maybe "192.168.1.3"; the LIS might think "ab:cd:ef:12:34:56" or "192.0.2.75".  Neither thinks "sip:[email-masked]" except in rare circumstances.

Thus, in constructing a LO, the LIS can only use whatever identity it uses for location determination.  (It doesn't do this for other reasons, but it could.)  Whatever this identity is, it would be rare for that identity to be useful in another domain, say...SIP.

In order for the identity in the LO to be meaningful in another domain, a binding needs to be performed between an identity in that domain and the identity in the LO, or between the identity and the location information contained therein.  A Device might do that, knowing as it does that this location object relates to itself.  Knowing it's own identity, the Device can construct a new LO with a new binding.

(In doing so, the Device might be considered an LG, but I think that the distinction isn't helpful; something for the draft authors to consider perhaps...)

==Privacy of Identity

HELD prohibits (or recommends against) the inclusion of identity information.  That's to ensure that when a location URI is dereferenced it does not provide information that is either inaccurate or prohibited by any RM.  On the one hand, it can't provide identity that is useful in another domain, because it can't ensure it's veracity.  More importantly, it doesn't want to for privacy reasons.

No means is provided for an RM to grant permission to disclose identity.  Therefore, the LIS does not.  If the LIS did so, this would limit where a location URI could be used.  A user could not provide a location URI to just provide their location; because if they did so, aspects of their identity would also be revealed.

For instance, I might want to interact with a location-based alerting (c.f. early-warning) application without revealing my identity.  Aside from things that I inadvertently reveal (such as the IP of my proxy) the only information that the application requires is my location.  The application certainly does not need to know that I am "sip:[email-masked]", or my Device has a MAC address of "01:23:45:67:78".  Even location might be obscured to the level that I consider appropriate.

I hope that this is helpful.  I hope that this (and more appropriately, the architecture document) goes some way to achieving two important goals: a consistent model to work from, and everyone understanding that model.  I believe we're almost there on both counts, despite recent evidence to the contrary.

Cheers,
Martin

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 17 Jul 2009 00:23:00 -0500

ok - this isn't a bad explanation so far, but it is mostly in 
relation to looking at the world as if HELD were the LCP responder 
and the LG/LS dereferencing to get a PIDF-LO. This doesn't hold to be 
true in other protocols that aren't designed to function in this holistic way.

Take the case previous to HELD, which is DHCP and SIP.

DHCP is the LCP, providing LCI to a client, the target.

Now with LI, the target can build a PIDF-LO (making it an LG -- which 
is in 3693, so draft authors do not need to consider that 
scenario).  If the LG is also an LS providing LO towards an LR.

John Elwell's principle confusion is that in the SIP architecture 
(there are UAs, proxies, redirect server, registrars and gateways), a 
UA can be a Geopriv LS. A proxy that inserts location into that same 
SIP request towards the LR is an LS (and probably an LG), and if the 
LR receives a location URI, it dereferences that location URI to get 
the target's PIDF-LO from a 3rd party server in the network that's 
not a proxy or a UA -- which is also an LS.

Having an LS be used in terms of 3 different roles within the SIP 
arch is confusing "in reality".

The rub of all this is the Geopriv and SIP entity architectures do 
not map 1 for 1, and that is confusing (without putting a number on 
it) some in the SIP focused world.

I'm going to work with John to see if my writing of Conveyance has 
contributed to that confusion, or if this it is distilled as best as 
can be done.

To date - I've reduced the term confusion by creating a new SIP 
specific term called a Location Inserter (with no acronym because LI 
wouldn't work here), which can be either a UAC or proxy.

I might define another SIP specific term called a Dereference Server 
(DS) which is subscribed to by an LR using a location URI as the 
R-URI.  If I go down this route, this would nearly or completely 
eliminate the use of the term Location Server within 
Conveyance.  This would also reduce confusion to SIP folks.

James

At 08:41 PM 7/16/2009, Thomson, Martin wrote:
>Let me explain my understanding of this.  Perhaps it will help some 
>people who are having trouble with the concepts, the design choices 
>and how GEOPRIV translates into reality.
>
>My belief is that the content of this essay is consistent with what 
>is in the architecture document, with the caveat that I haven't yet 
>thoroughly reviewed the latest version.  I don't believe that there 
>is any need to fundamentally alter that document, although 
>clarification might be helpful on some points.
>
>==Roles
>
>The 5 roles in GEOPRIV - LG, LS, LR, Target and RM - are 
>logical.  These 5 roles are also sufficient to describe the entire model.
>
>There are other terms for entities, but these are either more 
>specific definitions (LIS), or they relate to actual physical actors 
>(Device, Person).  These terms are not necessary to describe the 
>model, but they are somewhat helpful in relating that model to 
>reality - something that we inevitably have to do if this is ever 
>going to be of any use to anyone.
>
>==The LIS
>
>   Location configuration is necessary when a device is unable to 
> determine its own location.  A server in the network fills this 
> function.  This server is named LIS.  The LIS assumes the role of 
> LG when generating location information.  For this purpose, the 
> Device assumes the role of Target (c.f. HELD Sec3).
>
>   The LIS then assumes the role of LS and the Device assumes the 
> role of LR when the LIS provides the Device with its location.  The 
> RM role in this exchange is rather abstract; the LS allows access 
> to location based on the LCP policy, a necessary exception.
>
>In this sense, the architecture document doesn't _need_ to talk 
>about the LIS; but then it wouldn't be particularly relevant if it 
>didn't deal with this very important case and the special 
>circumstances surrounding it (LCP policy, etc).
>
>BTW, Alissa: I your definition of LIS isn't complete.  Deriving as 
>it does from draft-winterbottom-geopriv-deref-protocol it doesn't 
>consider all cases.
>
>==Dereference
>
>Dereference isn't special in any way.  It doesn't need special terms 
>beyond the basic set of 5 roles.  The HELD deference draft uses LIS, 
>because it relates the dereference operation back to the LCP case; 
>it doesn't need to, but relevance is again aided by relating this to reality.
>
>==LI versus LO
>
>You'll note that I haven't distinguished between LI and LO in these 
>descriptions.  That's intentional; it's somewhat more complicated.
>
>A location object binds identity to location, that's its 
>purpose.  But this is also a function performed by protocols, 
>leading to the current tension.
>
>One form of binding is performed in HELD and DHCP through the 
>identity that is implicitly carried in the request.  When making an 
>LCP request, the requester is fairly certain of what they're asking 
>for without needing to consult the LO.  The protocol semantics are 
>clear: they are requesting their own location.
>
>DHCP only provides LI, therefore it is unaffected.  HELD provides a 
>LO, or at least appears to, and thus we are led to the problem we're 
>discussing both here and in SIPCORE.
>
>Now, I don't see this is a problem.  I just see this as a case where 
>domains intersect.  But you have to think it through carefully and 
>thoroughly.  One problem that we're having is that identity is 
>perceived as being absolute, which is false.  This shouldn't be a 
>revolutionary concept in this forum, where the prevalent form of 
>identity - the IP address - is well understood to be relative.  The 
>understanding of what 192.0.2.75 means varies depending on where you 
>stand.  Or, to take more extreme cases, the meaning of 10.0.2.3 or 127.0.0.1.
>
>But I digress.  Even in the context of an LCP, the specific identity 
>used in the exchange between Device and LIS is not absolute.  The 
>Device might think "me", "ab:cd:ef:12:34:56" or maybe "192.168.1.3"; 
>the LIS might think "ab:cd:ef:12:34:56" or "192.0.2.75".  Neither 
>thinks "sip:[email-masked]" except in rare circumstances.
>
>Thus, in constructing a LO, the LIS can only use whatever identity 
>it uses for location determination.  (It doesn't do this for other 
>reasons, but it could.)  Whatever this identity is, it would be rare 
>for that identity to be useful in another domain, say...SIP.
>
>In order for the identity in the LO to be meaningful in another 
>domain, a binding needs to be performed between an identity in that 
>domain and the identity in the LO, or between the identity and the 
>location information contained therein.  A Device might do that, 
>knowing as it does that this location object relates to 
>itself.  Knowing it's own identity, the Device can construct a new 
>LO with a new binding.
>
>(In doing so, the Device might be considered an LG, but I think that 
>the distinction isn't helpful; something for the draft authors to 
>consider perhaps...)
>
>==Privacy of Identity
>
>HELD prohibits (or recommends against) the inclusion of identity 
>information.  That's to ensure that when a location URI is 
>dereferenced it does not provide information that is either 
>inaccurate or prohibited by any RM.  On the one hand, it can't 
>provide identity that is useful in another domain, because it can't 
>ensure it's veracity.  More importantly, it doesn't want to for 
>privacy reasons.
>
>No means is provided for an RM to grant permission to disclose 
>identity.  Therefore, the LIS does not.  If the LIS did so, this 
>would limit where a location URI could be used.  A user could not 
>provide a location URI to just provide their location; because if 
>they did so, aspects of their identity would also be revealed.
>
>For instance, I might want to interact with a location-based 
>alerting (c.f. early-warning) application without revealing my 
>identity.  Aside from things that I inadvertently reveal (such as 
>the IP of my proxy) the only information that the application 
>requires is my location.  The application certainly does not need to 
>know that I am "sip:[email-masked]", or my Device has a MAC 
>address of "01:23:45:67:78".  Even location might be obscured to the 
>level that I consider appropriate.
>
>
>I hope that this is helpful.  I hope that this (and more 
>appropriately, the architecture document) goes some way to achieving 
>two important goals: a consistent model to work from, and everyone 
>understanding that model.  I believe we're almost there on both 
>counts, despite recent evidence to the contrary.
>
>Cheers,
>Martin
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 17 Jul 2009 01:46:44 -0500

It's an interesting problem, and I can sympathize.

I have no problem with you creating terms for your context.  As long as they are clearly defined and aid in improving the readability of the document.

It might help to provide some text relating those to the GEOPRIV model to assist the GEOPRIV-literate in analysing your document.  You can do this in the definition of your terms.

To add to my previous email:

==SIP conveyance

From a GEOPRIV perspective, SIP conveyance operates in three modes: by value, by reference with possession, by reference with access control.

By value provision of location information includes a location object.  Each SIP entity in the signalling path becomes an LR as they receive the LO, then an LS as they forward it on.  The UAC, as the originator of the flow and the entity that inserts the LO (the UAC is the only valid "Inserter" in this context) is either a RM directly, or acts with permission of a RM.  By allowing insertion, the RM implicitly gives permission for all entities on the signalling path to forward the LO as part of their usual processing.

By reference provision of location information does not inherently include location information in the signalling; therefore, entities on the signalling path do not assume either LR or LS role until one attempts to dereference the URI.

However, when the possession model for location by reference is used, access (if not permission) is granted to all entities on the path.

Explicit permission is required if SIP entity wishes to use the LO for routing purposes.  The explicit routing-allowed indicator is used for this purpose.  (draft-ietf-geopriv-sip-lo-retransmission covers this case better than I can.)

Cheers,
--Martin

> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, 17 July 2009 3:23 PM
> To: Thomson, Martin; Brian Rosen; Alissa Cooper;
> [email-masked]
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-00.txt
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 17 Jul 2009 16:05:53 -0500

At 01:46 AM 7/17/2009, Thomson, Martin wrote:
>I have no problem with you creating terms for your context.  As long 
>as they are clearly defined and aid in improving the readability of 
>the document.

I'm pretty amazed you say this - and am equally please, because I 
believe this can definitely bridge the gap between the two models to 
help give clarity when one doesn't completely understand both.

>It might help to provide some text relating those to the GEOPRIV 
>model to assist the GEOPRIV-literate in analysing your document.

This is a good idea, but I cannot at the moment know that I'll hit 
the right balance in the first try - without additional text.  If 
this is to be done in the definitions section, which is fine BTW, 
what do you suggest I put there? This will help give me direction 
that you won't be opposed to in my first try. (I'm tired of having to 
rev over and over again because we didn't see eye-to-eye when we 
thought we did in fewer words (i.e., talking passed each other 
without knowing it)

>You can do this in the definition of your terms.
>
> From a GEOPRIV perspective, SIP conveyance operates in three modes: 
> by value, by reference with possession, by reference with access control.
>
>By value provision of location information includes a location 
>object.  Each SIP entity in the signalling path becomes an LR as 
>they receive the LO, then an LS as they forward it on.  The UAC, as 
>the originator of the flow and the entity that inserts the LO (the 
>UAC is the only valid "Inserter" in this context) is either a RM 
>directly, or acts with permission of a RM.  By allowing insertion, 
>the RM implicitly gives permission for all entities on the 
>signalling path to forward the LO as part of their usual processing.

this gets more complicated when considering a B2BUA inserting an LO 
into a SIP request, but in general, this is a good/quick overview of 
Conveyance.

>By reference provision of location information does not inherently 
>include location information in the signalling; therefore, entities 
>on the signalling path do not assume either LR or LS role until one 
>attempts to dereference the URI.
>
>However, when the possession model for location by reference is 
>used, access (if not permission) is granted to all entities on the path.

I'm not sure I'd completely agree with this, as I don't believe the 
LR will ever know if it is using a possession or authorization model 
until it does or doesn't get challanged by the Dereferencing server, 
given that there is no indication in the locationValue or 
routing-allowed parameter that either model is in use.'

Remember, the routing-allowed just means that a SIP server can ask 
for the dereference, it doesn't mean the dereference server grants the request.

>Explicit permission is required if SIP entity wishes to use the LO 
>for routing purposes.  The explicit routing-allowed indicator is 
>used for this purpose.  (draft-ietf-geopriv-sip-lo-retransmission 
>covers this case better than I can.)

see above, as I do not believe routing-allowed means "possession 
model". Case in point, if the PIDF-LO is in the SIP request, and the 
routing-allowed parameter is "no", all the LRs in the signaling path 
(i.e., all the SIP servers that understand location are LRs) possess 
the location of the target, but don't have permission or 
authorization to view the location.

James

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 19 Jul 2009 15:51:10 -0400

This is helpful. I don't think the sentence in geopriv-arch that  
kicked off this discussion was really that far off from what you  
suggest. The original sentence:
"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 potential edit:
"The process of providing a Target with its own location is known  
within Geopriv as Location Configuration, and the server in an access  
network that provides such location is often described as a Location  
Information Server (LIS). The LIS assumes the role of LG when  
generating location information, and the role of LS when providing it."
I agree that we should note the role of a LIS in this document, but it  
doesn't warrant an extensive discussion.

Alissa

On Jul 16, 2009, at 9:41 PM, Thomson, Martin wrote:

> The 5 roles in GEOPRIV - LG, LS, LR, Target and RM - are logical.   
> These 5 roles are also sufficient to describe the entire model.
>
> function.  This server is named LIS.  The LIS assumes the role of LG  
> when generating location information.  For this purpose, the Device  
> assumes the role of Target (c.f. HELD Sec3).
>
>  The LIS then assumes the role of LS and the Device assumes the role  
> of LR when the LIS provides the Device with its location.  The RM  
> role in this exchange is rather abstract; the LS allows access to  
> location based on the LCP policy, a necessary exception.
>
> A location object binds identity to location, that's its purpose.   
> But this is also a function performed by protocols, leading to the  
> current tension.
>
> knowing as it does that this location object relates to itself.   
> Knowing it's own identity, the Device can construct a new LO with a  
> new binding.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 19 Jul 2009 19:55:20 -0500

That would be a good clarification.  Thanks Alissa.

From: Alissa Cooper [mailto:[email-masked]] 
Sent: Monday, 20 July 2009 5:51 AM
To: Thomson, Martin
Cc: GEOPRIV
Subject: Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-00.txt

This is helpful. I don't think the sentence in geopriv-arch that kicked off this discussion was really that far off from what you suggest. The original sentence:

"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 potential edit:

"The process of providing a Target with its own location is known within Geopriv as Location Configuration, and the server in an access network that provides such location is often described as a Location Information Server (LIS). The LIS assumes the role of LG when generating location information, and the role of LS when providing it."

I agree that we should note the role of a LIS in this document, but it doesn't warrant an extensive discussion.

Alissa

==Roles

==The LIS

==Dereference

==LI versus LO

==Privacy of Identity

Cheers,
Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 19 Jul 2009 20:05:21 -0500

> thought we did in fewer words (i.e., talking passed each other

You suggested these two terms:

Inserter: the signalling entity that creates or adds to the Geolocation header.  If location information is included in the message by value, this entity assumes the GEOPRIV role of Location Server (LS) by doing so.

(Location) Dereference Server: the entity that serves a location URI.  This entity assumes the GEOPRIV role of Location Server (LS).

That's my interpretation in a few words as I can manage.
 
> for the dereference, it doesn't mean the dereference server grants the

Indeed, that is correct, but this is necessary for the complete analysis.  When dealing with possession model URIs, knowledge of the URI is all the information necessary to access location information.  It does not matter if the SIP intermediary is aware of this or not, but it is an important consideration.

> authorization to view the location.

These are separate statements.  This paragraph does not refer to possession model, but talks more generally about the purpose of routing-allowed.

> > > >An entity might assume any one of these roles, depending on what
> it
> > > >is that they are doing.
> > > >
> > > >it doesn't need to, but relevance is again aided by relating this
> to
> > > reality.
> > > >
> > > >==LI versus LO
> > > >
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >[mf2]
> > >
> >

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 20 Jul 2009 14:56:59 -0500

At 02:51 PM 7/19/2009, Alissa Cooper wrote:
>(LIS)."A potential edit:
>within Geopriv as Location Configuration, and the server in an 
>access network that provides such location is often described as a 
>Location Information Server (LIS). The LIS assumes the role of LG 
>when generating location information, and the role of LS when 
>providing it."I agree that we should note the role of a LIS in this 
>document, but it doesn't warrant an extensive discussion.

the not-so-splitting-of-hairs difference in this definition from what 
RFC3693 defines is that the LG is the first entity that creates or 
builds a PIDF-LO.  The LIS does this for HELD, but for no other 
protocol, and a couple of other protocols existed prior to HELD 
existing, so this doesn't really address what the LIS does for DHCP 
for example, or LLDP-MED.  There is no PIDF-LO in either one of those 
protocols, so this isn't a clean fit (calling the LIS an LG, except 
in the case of HELD).

My point is that HELD is not yet an RFC, and this group has produced 
2 standards track RFCs for DHCP, i.e., the protocol that the LIS 
isn't defined as an LG because it doesn't build/create a PIDF-LO.

I believe geopriv-arch-00's proposal is misaligned now with RFC 3693, 
regardless of how many in this WG believe HELD is the one true 
protocol for this WG (which is how it appears more and more believe).

Further - what I commented on in my original email was the fact that 
the author team (not necessarily you Alissa) took in on as a non-WG 
consensus change control act to change the architecture (that the LIS 
dereferences a PIDF-LO, where the 3rd party does not use a LIS to 
dereference a PIDF-LO, where no distinction is made whether this is a 
HELD based PIDF-LO or a SIP based PIDF-LO) -- but as a group of 
authors, felt the authors were in charge of change control over a WG 
item, which -- according to IETF process, you are not to make changes 
that aren't decided by the WG, and consistent with existing WG RFCs.

This is not consistent with WG (PS) RFCs and was not discussed by the whole WG.

James

>>specific definitions (LIS), or they relate to actual physical 
>>actors (Device, Person).  These terms are not necessary to describe 
>>the model, but they are somewhat helpful in relating that model to 
>> role of LR when the LIS provides the Device with its 
>> location.  The RM role in this exchange is rather abstract; the LS 
>> allows access to location based on the LCP policy, a necessary exception.
>>
>>Dereference isn't special in any way.  It doesn't need special 
>>terms beyond the basic set of 5 roles.  The HELD deference draft 
>>uses LIS, because it relates the dereference operation back to the 
>>LCP case; it doesn't need to, but relevance is again aided by 
>>relating this to reality.
>>
>>==LI versus LO
>>
>>LO, or at least appears to, and thus we are led to the problem 
>>we're discussing both here and in SIPCORE.
>>
>>Now, I don't see this is a problem.  I just see this as a case 
>>where domains intersect.  But you have to think it through 
>>carefully and thoroughly.  One problem that we're having is that 
>>identity is perceived as being absolute, which is false.  This 
>>shouldn't be a revolutionary concept in this forum, where the 
>>prevalent form of identity - the IP address - is well understood to 
>>be relative.  The understanding of what 192.0.2.75 means varies 
>>depending on where you stand.  Or, to take more extreme cases, the 
>>meaning of 10.0.2.3 or 127.0.0.1.
>>
>>But I digress.  Even in the context of an LCP, the specific 
>>identity used in the exchange between Device and LIS is not 
>>absolute.  The Device might think "me", "ab:cd:ef:12:34:56" or 
>>maybe "192.168.1.3"; the LIS might think "ab:cd:ef:12:34:56" or 
>>"192.0.2.75".  Neither thinks 
>>"sip:<mailto:[email-masked]>[email-masked]" except in rare circumstances.
>>
>>reasons, but it could.)  Whatever this identity is, it would be 
>>rare for that identity to be useful in another domain, say...SIP.
>>
>>(In doing so, the Device might be considered an LG, but I think 
>>that the distinction isn't helpful; something for the draft authors 
>>to consider perhaps...)
>>
>>==Privacy of Identity
>>
>>requires is my location.  The application certainly does not need 
>>to know that I am 
>>"sip:<mailto:[email-masked]>[email-masked]", or my Device has 
>>a MAC address of "01:23:45:67:78".  Even location might be obscured 
>>to the level that I consider appropriate.
>>
>>
>>appropriately, the architecture document) goes some way to 
>>achieving two important goals: a consistent model to work from, and 
>>everyone understanding that model.  I believe we're almost there on 
>>both counts, despite recent evidence to the contrary.
>>
>>Cheers,
>>Martin
>>

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Jul 2009 16:37:08 -0500

At 08:05 PM 7/19/2009, Thomson, Martin wrote:
>Inserter: the signalling entity that creates or adds to the 
>Geolocation header.  If location information is included in the 
>message by value, this entity assumes the GEOPRIV role of Location 
>Server (LS) by doing so.
>
>(Location) Dereference Server: the entity that serves a location 
>URI.  This entity assumes the GEOPRIV role of Location Server (LS).

ok - cool, I can run with that. I believe this will directly clear up 
John Elwell's  (and others) confusion about the many forms of Geopriv 
entity roles.

I have a more meta question that's a hole in the above "inserter" role though:

         what is the role of the SIP server that inserts a location URI of
         the Target?

that's gotta be defined somewhere.  I believe this entity is also an 
LS, because it is a location aware entity that is sighting (put aside 
the fact that you hate that word) the target. This "act of sighting" 
is location awareness - ergo an entity role within Geopriv 
architecture. This entity would _not_, however, be an LG (that's 
saved for LO creators, which this entity does not do).

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 27 Jul 2009 01:33:15 -0500

I was wondering when this would come up.  I don't think that it's strictly an LS, because it doesn't necessarily provide a LO.  All it does is possibly enable the later acquisition of an LO.  If we look at possession model, it's much closer to an LS than with authorization - where the actual LS might reject a request for the LO.

In the end, I don't think that it's overly important.  By labelling it an LS, all the LS responsibilities go along with that and that could be helpful.  I can't think of any reason not to simply label it as an LS.

--Martin