>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.
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
>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:<mailto:alice@example.com>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:<mailto:alice@example.com>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]
>
>
>
>
>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
