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