> >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 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.
> >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.
>
> 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.
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.
> >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.
These are separate statements. This paragraph does not refer to possession model, but talks more generally about the purpose of routing-allowed.
>
> James
>
>
> >Cheers,
> >--Martin
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:jmpolk@cisco.com]
> > > Sent: Friday, 17 July 2009 3:23 PM
> > > To: Thomson, Martin; Brian Rosen; Alissa Cooper;
> > > Ray.Bellis@nominet.org.uk
> > > Cc: GEOPRIV
> > > Subject: RE: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-
> 00.txt
> > >
> > > 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.
> > > >
> > > > 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]
>
------------------------------------------------------------------------------------------------
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
