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

["James M. Polk" <[e-mail]>]

At 01:46 AM 7/17/2009, Thomson, Martin wrote:
>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.

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.
>
>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.


>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


>Cheers,
>--Martin
>
> > -----Original Message-----
> > From: James M. Polk [mailto:[e-mail]]
> > Sent: Friday, 17 July 2009 3:23 PM
> > To: Thomson, Martin; Brian Rosen; Alissa Cooper;
> > [e-mail]
> > 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:[e-mail]" 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:[e-mail]", 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]