That would be a good clarification. Thanks Alissa.
From: Alissa Cooper [mailto:acooper@cdt.org]
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
On Jul 16, 2009, at 9:41 PM, 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.
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:alice@example.com" 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:alice@example.com", 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
------------------------------------------------------------------------------------------------
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]
------------------------------------------------------------------------------------------------ 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] |
