Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-lbyr-requirements-05

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 4 Jan 2009 20:16:01 -0600

Hi Hannes,

Except as noted, I agree with the sentiments of the review.

> I wonder why you use the term "location server" instead of "Location
> Information Server".
> In
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-08.txt
> we have used the term LIS instead of LS.
> There was a long discussion about this topic and we agreed to use that
> term. For now, I did not make any changes regarding the LIS vs. LS
> aspect.

In the context of an LCP, LIS has been adopted, but LS is most applicable to this context, since it most frequently discusses the interactions between LR and LS.

> FROM:
> 
>    Location-by-Value (LbyV):  The mechanism of representing location
>       either in configuration or conveyance protocols, (i.e., the
> actual
>       included location value).
> 
> TO:
> 
>    Location-by-Value (LbyV):  Location information in the format of a
> PIDF-LO
>       (or related encoding)
>
> FROM:
> 
>    Location-by-Reference (LbyR):  The mechanism of representing
> location
>       by means of a location URI for use in either a location
>       configuration, conveyance, or dereferencing protocol, and which
>       refers to a fully specified location.
> 
> TO:
> 
>    Location-by-Reference (LbyR):  A location URI pointing to location
> information

I think that these suggestions miss the point.  When we talk about by value and by reference, it's the action of conveyance that is the subject of the discussion.  These changes focus instead on the format.  However, we already have names for those things: Location Object and Location URI.

> FROM:
> 
>    Location Dereference Protocol:  A protocol which is used by a client
>       to query a location dereference server, based on location URI
>       input and which returns location information.
> 
> TO:
> 
>    Location Dereference Protocol:  A protocol that is used by a client
>       to query a location server, based on the location URI
>       input and which returns location information.

Removing the redundant term "location dereference server" in favour of LS is good.
 
> 
> FROM:
> 
>                     +-----------+  Geopriv      +-----------+
>                     |           |  Location     | Location  |
>                     |    LIS    +---------------+ Recipient |
>                     |           |  Dereference  |           |
>                     +-+---+-----+  Protocol (3) +----+------+
>                      *    |                        --
>          Rulemaker  *     | Geopriv              --
>          Policy    *      | Location           --
>          Exchange *       | Configuration    --
>             (1b) *        | Protocol       --
>                 *         | (1a)         --      Geopriv
>                *          |            --        Using Protocol
>      + - - - -*- - - - - -|- - - -+  --          (e.g., SIP)
>      |+------+----+ +-----+-----+ |--            (2)
>       | Rulemaker | | Target /  |--
>      ||  / owner  | | End Host  + |
>       |           | |           |
>      |+-----------+ +-----------+ |
> 
>      |       User of Target       |
>      + - - - - - - - - - - - - - -+
> 
> 
> To make this figure more generic I would also add a box that talks
> about
> the Rulemaker being outside the Target.
> Additionally, I would only use the term "Rulemaker" instead of
> "Rulemaker / owner" because I don't really understand what owner in
> this
> context means.

I agree.  I don’t think that this is a major change, but it's a useful one.  I've often drawn the triumvirate: device/target, user and rule maker.  These often collapse into singularity, but aren't necessarily the same in the model, or in reality for that matter.

> FROM:
> 
>    1. Access control authorization model:  ...
> 
>    2. Possession authorization model:  ...
> 
> TO:
> 
>    1. Access control authorization model:  Access to the location URI
> is
>       limited by policy.  In this model it is assumed that the
> rulemaker
> 
>       provides authorization policies to the LIS and these policies
>       are attached to a location URI and control the dereferencing
> process.
> 
>    2. Possession authorization model:  The possession authorization
>       model is described as not having policies associated to the
> location
>       URI >>apart<< from only possessing the location
>       URI itself.  In this case, possession implies authorization.
>       Access to the location URI is limited by distribution only.
>       Whoever possesses the location URI has the ability to dereference
>       it.  Possession authorization models may be used within specified
>       domains only, or might be used across wide open public networks.
 
(Implied word "apart" added above.)

I think that the non-point on where possession can be used (either in public or in private) can be removed.

In the authorization model, the use of LIS (as opposed to LS) doesn't matter much.  Both could be regarded as correct, but in the context of the proposed sentence, the term LIS seems more correct.  However, this is only with respect to a narrow use case; an entity could request a location URI of a non-LIS (in some respects, a presence AoR could be regarded as an authorization model location URI).  LS would be more correct.

> I wonder whether we could delete requirement C4 or reword it a bit:
> 
> FROM:
> 
>    C4. Location Information Masking:  The location URI form MUST,
>       through randomization and uniqueness, ensure that any location
>       specific information embedded within the location URI itself is
>       kept obscure during location configuration.
> 
>       Motivation: It is important to keep any location information
>       masked from a casual observing node.
> 
> TO:
> 
>    C4. Location Information Masking:  The location URI MUST,
>       through randomization and uniqueness, ensure that the location
>       URI does not contain location information specific components.
> 
>       Motivation: It is important to keep any location information
>       masked from a casual observing node.

The problem is that randomization and uniqueness do not relate to the goal that states that the location URI does not reveal location information.

There are several goals at work here:

 - No embedded location information - necessary for authorization model only.  Possession of the URI should not reveal any location information to an unauthorized recipient.  Two ways to achieve this: encrypt the information, or don't include it.  I think that this is the requirement you actually want here.

 - Randomness - possession model.  A location URI should not be easily guessable.  C9.

 - Uniqueness - all models.  Not really all that useful a property, but as a consequence of the randomness, there is a potential for collisions that must be dealt with.  I think that this is a consequence of that, so it's really not worth mentioning.

> FROM:
> 
>    C5. User Identity Protection:  ...
> 
> TO:
> 
>    C5. User Identity Protection:  The location URI MUST NOT contain
>       information that identifies the user or device. Examples include
>       phone extensions, badge numbers, first or last names.
> 
>       Motivation: It is important to protect caller identity or contact
>       address from being included in the form of the location URI
> itself
>       when it is generated.

This is the first use of the word "caller".  Suggest "target" instead.

> I don't quite understand C10.
> 
> 
>    C10.  Location URI Optional:  In the case of user-provided
>       authorization policies, where anonymous or non-guessable location
>       URIs are not warranted, the location configuration protocol MAY
>       support optional location URI forms.
> 
>       Motivation: Users don't always have such strict privacy
>       requirements, but may opt to specify their own location URI, or
>       components thereof.

If you are proposing to remove this, then I agree.  For the sake of your enlightenment (which might be a bit too positive a word), there was a feature in one of the original HELD proposals way back that allowed for a user to specify what the presentity URI was to be in the document.  This is probably along those lines: allow the requester to specify their preferred URI.

> I would delete C11 as the location configuration protocol cannot really
> tell the authorization model the Target / Rulemaker is going to apply.
> I
> could get a Location URI and then upload it to a presence server. The
> presence server could operate based on my authorization policies. The
> initial LbyR would follow a possession model but the entire system
> would
> still be an authorization model.
> 
>    C11.  Location URI Authorization Model:  The location configuration
>       protocol SHOULD indicate whether the requested location URI
>       conforms to the access control authorization model or the
>       possession authorization model.
> 
>       Motivation: Downstream dereference clients and servers need to
>       know whether a location URI provided by the location
> configuration
>       protocol conforms to an access control authorization model or a
>       possession authorization model.

Disagree entirely.  When you get a URI, the policy that applies to the dereference of that URI needs to be known (explicitly or otherwise).  The cost of failure to do this is that a possession model location URI could be published on the assumption that it follows authorization model.

I think that you've confused the role of the presence server in this example.  If the presence server is handing a location URI out, then that's up to the presence server policy.

If the presence server is dereferencing, then handing out location objects... Then you have a new location by reference arrangement where the presence AoR is your location URI and the presence server is a location server.
 
> D2 is phrased incorrectly. I guess what you would like to say is that
> the lifetime of the location URI that is being provided via the
> Location
> Configuration Protocol should also be made available to the Location
> Recipient so that he knows how long derefencing is possible. This is
> not
> really a requirement for the Location Dereferencing Protocol but rather
> to the Location Conveyance protocol that passes the LbyR (and
> potentially the lifetime around) unless you suggest that the location
> URI should already indicate the lifetime as a URI parameter.

Is this requirement for conveyance useful?  It certainly hasn't been considered yet.

> FROM:
> 
> 	     A location URI, regardless of its construction, if public,
> by itself,
>    implies no safeguard against anyone being able to dereference and
> get
>    the location.  The method of constructing the location URI form to
>    include randomization along with encryption does help prevent some
>    potential pattern guessing.  In the case of one time use location
>    URIs, (referred to as a pawn ticket), the argument can be made that
>    possession implies permission, and location URIs that are public are
>    protected only by privacy rules enforced at the dereference server.
> 
>    TO:
> 
>    The method of constructing the location URI  to
>    include randomized components helps to prevent adversaries from
>    obtaining location information without ever retrieving a location
> URI.
>    In the possession model, a location URI, regardless of its
> construction,
>    if made publically available, implies no safeguard against anyone
> being able to
>    dereference and get the location. Care has to be paid when
> distribution such
>    a location URI to the trusted location recipients. When this aspect
> is of concern then
>    the authorization model has to be chosen. Even in this model care
> has
> to be
>    taken on how to construct the authroization policies to ensure that
> only those
>    parties have access to location information that are considered
> trustworthy enough
>    to enforce the basic rule set that is attached to location
> information in a PIDF-LO
>    document.

This last sentence is a bit of a truism, and doesn't add a lot to what is already a very long paragraph.  The form above suggests three paragraphs to me.  1: benefits of random component; 2: risks in public disclosure of a possession model location URI; 3: risks in authorization model.  The discussion on the third point aren't necessary - the difficultly in constructing a good policy should be self-evident.

> Ciao
> Hannes

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 5 Jan 2009 12:53:42 +0200

Hi Martin, 

>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-08.tx
>> t we have used the term LIS instead of LS.
>In the context of an LCP, LIS has been adopted, but LS is most 
>applicable to this context, since it most frequently discusses 
>the interactions between LR and LS.

In some sense you are right. 

The interaction regarding the LCP is surely between the LIS and the Target. 
The interaction for dereferencing is more generic. 

So, I don't know what todo. 

>I think that these suggestions miss the point.  When we talk 
>about by value and by reference, it's the action of conveyance 
>that is the subject of the discussion.  These changes focus 
>instead on the format.  However, we already have names for 
>those things: Location Object and Location URI.
>

OK. 

>> about the Rulemaker being outside the Target.
>> this context means.
>I agree.  I don't think that this is a major change, but it's 
>a useful one.  I've often drawn the triumvirate: 
>device/target, user and rule maker.  These often collapse into 
>singularity, but aren't necessarily the same in the model, or 
>in reality for that matter.
>
>> FROM:
>> 
>I think that the non-point on where possession can be used 
>(either in public or in private) can be removed.
>
>In the authorization model, the use of LIS (as opposed to LS) 
>doesn't matter much.  Both could be regarded as correct, but 
>in the context of the proposed sentence, the term LIS seems 
>more correct.  However, this is only with respect to a narrow 
>use case; an entity could request a location URI of a non-LIS 
>(in some respects, a presence AoR could be regarded as an 
>authorization model location URI).  LS would be more correct.

Maybe we could add this indication. 

>The problem is that randomization and uniqueness do not relate 
>to the goal that states that the location URI does not reveal 
>location information.

But isn't the definition of Location URI already indicating that it is not
location? 

> - No embedded location information - necessary for 
>authorization model only.  Possession of the URI should not 
>reveal any location information to an unauthorized recipient.  
>Two ways to achieve this: encrypt the information, or don't 
>include it.  I think that this is the requirement you actually 
>want here.
>
> - Uniqueness - all models.  Not really all that useful a 
>property, but as a consequence of the randomness, there is a 
>potential for collisions that must be dealt with.  I think 
>that this is a consequence of that, so it's really not worth 
>mentioning.
>
>> FROM:
>> 

Sounds good 

>If you are proposing to remove this, then I agree.  For the 
>sake of your enlightenment (which might be a bit too positive 
>a word), there was a feature in one of the original HELD 
>proposals way back that allowed for a user to specify what the 
>presentity URI was to be in the document.  This is probably 
>along those lines: allow the requester to specify their preferred URI.

To me, this rather sounds that the Target selects the value of the URI
instead of the server. This does not sound like a good idea to me. 

>
>> I would delete C11 as the location configuration protocol cannot 
>> really tell the authorization model the Target / Rulemaker 
>is going to apply.
>> I
>> would still be an authorization model.
>> 
>Disagree entirely.  When you get a URI, the policy that 
>applies to the dereference of that URI needs to be known 
>(explicitly or otherwise).  The cost of failure to do this is 
>that a possession model location URI could be published on the 
>assumption that it follows authorization model.
>
>I think that you've confused the role of the presence server 
>in this example.  If the presence server is handing a location 
>URI out, then that's up to the presence server policy.
>
>If the presence server is dereferencing, then handing out 
>location objects... Then you have a new location by reference 
>arrangement where the presence AoR is your location URI and 
>the presence server is a location server.

Maybe I should phrase it differently: 

When I use HELD to obtain a Location URI and forward that URI to you then do
you know whether the URI is going to be used in an authorization or in a
possession model?

You don't know. This requirement says that you should tell the difference. 
We don't have that functionality and I don't recall that anyone proposed to
have such a model. 

In HTTP, when you get a URL you don't know either whether you would be
allowed to access it or whether you will get challenged.

Does this make sense now? 

>> Location Configuration Protocol should also be made available to the 
>> Location Recipient so that he knows how long derefencing is 
>possible. 
>> This is not really a requirement for the Location Dereferencing 
>> Protocol but rather to the Location Conveyance protocol that passes 
>> the LbyR (and potentially the lifetime around) unless you 
>suggest that 
>> the location URI should already indicate the lifetime as a URI 
>> parameter.
>

Maybe. Following the HTTP model - you don't get to know how long to the URL
will be "resolvable" either. 

>
>> FROM:
>> 
>> 	     A location URI, regardless of its construction, if 
>public, by 
>> itself,
>> has to be
>This last sentence is a bit of a truism, and doesn't add a lot 
>to what is already a very long paragraph.  The form above 
>suggests three paragraphs to me.  1: benefits of random 
>component; 2: risks in public disclosure of a possession model 
>location URI; 3: risks in authorization model.  The discussion 
>on the third point aren't necessary - the difficultly in 
>constructing a good policy should be self-evident.

Ok. 

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 5 Jan 2009 17:43:56 -0600

Hi Hannes,

> So, I don't know what todo.

Let me propose a new diagram then.  This might help with the other comments as well.

--
         +---------+--------+   Location    +-----------+
         |         |        |  Dereference  | Location  |
         |   LIS   -   LS   +---------------+ Recipient |
         |         |        |   Protocol    |           |
         +----+----+--------+      (3)      +-----+-----+
              |         `.                        |
              |    Policy `.                      |
Location      |    Exchange `.                    |
Configuration |      (*)      |        Location   |
Protocol      |          +----+----+   Conveyance |
  (1)         |          |  Rule   |   Protocol   ;
              |          |  Maker  |     (2)     /
        +-----+----+     +---------+           ,'
        |          |                       _,-'
        |  Target  +----------------------'
        |          |
        +----------+

     Figure 1: Location Reference Entities and Interactions

Figure 1 shows the assumed communication model for both a layer 7
location configuration protocol and a location dereference protocol.

1. The Target (a Device) uses a Location Configuration Protocol to
   acquire a location reference from a LIS, which acts as (or is able
   to access) an LS.

   In the case where the Target is also a Rule Maker, the location
   configuration protocol can be used to convey policy information.
   In the case where possession of a location URI is the only required
   form of authorization (see below [[a reference-able section number
   would be of a huge help here...]]), a policy is implied whereby any
   requester is granted access to location information.  This does not
   preclude other means of providing authorization policies.

   A Target could also acquire a location URI from the LS directly
   using alternative means.

2. The Target conveys the location URI to the Location Recipient
   (interface out of scope).

3. The Location Recipient dereferences the location URI to acquire
   location information from the LS.

   The LS controls access to location information based on the policy
   provided by the Rule Maker.
--

> But isn't the definition of Location URI already indicating that it is

Not really.  It's not a necessary attribute of the URI.  Of course, there isn't really many good reasons to expose location information in this way, but it doesn't prevent it from being valid.

Keep in mind that Alex's geo: URI is a location URI in one sense.  It just doesn't require a protocol to dereference.

>>...

No kidding ;)  Of course, we usually choose an AoR/email address; by the same token, a more or less permanent possession model location URI might be a reasonable candidate for user selection.

> Does this make sense now?

Yes, thanks, it took me a while to latch on to your point.  The use cases are different for LCP and conveyance.  

For the LCP case, the Target needs to know.  That determines how they distribute the information.   (Note: it could be a function of how you ask, not necessarily an explicit indication in the response - the effect is the same.)

After conveyance, I agree that knowing what sort of URI this is becomes less useful.  However, that only holds true if we either prevent retransmission or we have an explicit indication on whether retransmission is allowed.  Knowing the type of URI could be used to advise LR behaviour.  If the LR knows that a URI follows the authorization model, then the LR can freely distribute a URI.
 
> >> Location Recipient so that he knows how long derefencing is
...
> will be "resolvable" either.

I'll follow up with the sip-conveyance authors.

Just for my benefit:  I'm not sure whether I understand your HTTP model - are you talking about an HTTP conveyance protocol that I'm not aware of?

Cheers,
Martin

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 6 Jan 2009 20:42:49 +0200

Hi Martin, 

>> >applicable to this context, since it most frequently discusses the 
>> >interactions between LR and LS.
>> 
>Figure 1 shows the assumed communication model for both a 
>layer 7 location configuration protocol and a location 
>dereference protocol.
>

Sounds good

>
>> But isn't the definition of Location URI already indicating 
>that it is 
>> not location?
>
>Not really.  It's not a necessary attribute of the URI.  Of 
>course, there isn't really many good reasons to expose 
>location information in this way, but it doesn't prevent it 
>from being valid.
>
>Keep in mind that Alex's geo: URI is a location URI in one 
>sense.  It just doesn't require a protocol to dereference.

Well. For me a Location URI is a pointer to location that needs to be
dereferenced to obtain location information. 

Using a URI to encode location information so that it isn't a pointer
anymore and does not need to be de-referenced to obtain location doesn't
really satisfy my understanding of a location URI. 

Why would you want to dereference a location URI that has location already
encoded in the URI? E.g., a data: URI. This for example is a data: URI
encoding of the example shown in
http://held-location.sourceforge.net/held_js/pidflo.html. In your definition
of location URI this would be a URI but nobody would dereference it since it
already describes the location. If one does this then it should be treated
like a ordinary location object -- it is just encoded a bit differently. 

data:text/html;charset=utf-8,<%3Fxml version%3D"1.0"
encoding%3D"UTF-8"%3F>%0D%0A  <presence
xmlns%3D"urn%3Aietf%3Aparams%3Axml%3Ans%3Apidf"%0D%0A
xmlns%3Agp%3D"urn%3Aietf%3Aparams%3Axml%3Ans%3Apidf%3Ageopriv10"%0D%0A
xmlns%3Agml%3D"http%3A%2F%2Fwww.opengis.net%2Fgml"%0D%0A
xmlns%3Ags%3D"http%3A%2F%2Fwww.opengis.net%2Fpidflo%2F1.0"%0D%0A
entity%3D"pres%3Apaul%40somecell.example.com">%0D%0A    <tuple
id%3D"arcband">%0D%0A      <status>%0D%0A        <gp%3Ageopriv>%0D%0A
<gp%3Alocation-info>%0D%0A               <gml%3APolygon
srsName%3D"urn%3Aogc%3Adef%3Acrs%3AEPSG%3A%3A4326">%0D%0A
<gml%3Aexterior>%0D%0A                   <gml%3ALinearRing>%0D%0A
<gml%3AposList>%0D%0A                       -33.856625 151.215906 -33.856299
151.215343%0D%0A                       -33.856326 151.214731 -33.857533
151.214495%0D%0A                       -33.857720 151.214613 -33.857369
151.215375%0D%0A                       -33.856625 151.215906%0D%0A
<%2Fgml%3AposList>%0D%0A                   <%2Fgml%3ALinearRing>%0D%0A
<%2Fgml%3Aexterior>%0D%0A               <%2Fgml%3APolygon>%0D%0A
<%2Fgp%3Alocation-info>%0D%0A          <gp%3Ausage-rules%2F>%0D%0A
<method>TA-NMR<%2Fmethod>%0D%0A        <%2Fgp%3Ageopriv>%0D%0A
<%2Fstatus>%0D%0A
<timestamp>2007-06-22T20%3A57%3A29Z<%2Ftimestamp>%0D%0A    <%2Ftuple>%0D%0A
<%2Fpresence>

>No kidding ;)  Of course, we usually choose an AoR/email 
>address; by the same token, a more or less permanent 
>possession model location URI might be a reasonable candidate 
>for user selection.

But we are talking about the LCP here -- the interface between the Target
and the LIS. Here again it is important to say that we are talking about the
LIS and not a generic location server where you might very well select your
own identity. 

>> When I use HELD to obtain a Location URI and forward that URI to you 
>> then do you know whether the URI is going to be used in an 
>> authorization or in a possession model?
>> 
>> We don't have that functionality and I don't recall that anyone 
>> proposed to have such a model.
>>
>Yes, thanks, it took me a while to latch on to your point.  
>The use cases are different for LCP and conveyance.  
>
>For the LCP case, the Target needs to know.  That determines 
>how they distribute the information.   (Note: it could be a 
>function of how you ask, not necessarily an explicit 
>indication in the response - the effect is the same.)
>
>After conveyance, I agree that knowing what sort of URI this 
>is becomes less useful.  However, that only holds true if we 
>either prevent retransmission or we have an explicit 
>indication on whether retransmission is allowed.  Knowing the 
>type of URI could be used to advise LR behaviour.  If the LR 
>knows that a URI follows the authorization model, then the LR 
>can freely distribute a URI.

Didn't we discuss this issue in the past already and folks did not want to
attach meta-data (like policies, lifetime, etc.) to the URI. Maybe we could
re-think that decision since, I believe, that you are saying that we should
always attach the basic policies -- regardless whether it is LbyR or LbyV.

This would mean for SIP location conveyance, for example, you convey an
object like the following one (as XML encoding):

<?xml version="1.0" encoding="UTF-8"?>
<LbyR>
    <locationUriSet expires="2007-05-24T13:00:00">
        <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
        <locationURI>sip:[email-masked]
</locationURI>
    </locationUriSet>
    <usage-rules>
        <retransmission-allowed>false</retransmission-allowed>
        <retention-expiry>2007-05-25T12:35:02+10:00 </retention-expiry>
    </usage-rules>
</LbyR>

>> >> Location Configuration Protocol should also be made available to 
>> >> the Location Recipient so that he knows how long derefencing is
>> >possible.
>...
>> >
>> >Is this requirement for conveyance useful?  It certainly 
>hasn't been 
>> >considered yet.
>> 
>> Maybe. Following the HTTP model - you don't get to know how long to 
>> the URL will be "resolvable" either.
>
>Just for my benefit:  I'm not sure whether I understand your 
>HTTP model - are you talking about an HTTP conveyance protocol 
>that I'm not aware of?

Think about HTTP without any relationship to our work. 
Just plain HTTP. 

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Jan 2009 18:24:54 -0600

Hi Hannes,

I think that we've resolve the actual problems with the document to my satisfaction.  I tend to agree with all you've said, with minor philosophical reservations, but nothing of substance; certainly nothing that needs action.

I'd like to clarify the reasoning behind the decision not to include metadata for location URIs.  The decision is sound, but I don't think that the decision has been captured effectively, not to mention the rationale.

The first issue is retransmission of URI information.  When a SIP UA receives a location URI, it does not necessarily know whether it is permitted to share this information (outside of the standard signalling path).  The impact of sharing a location URI that is protected by an authorization policy is probably minimal.  On the other hand, if possession is used to imply authorization, then sharing is bad.

For retransmission, the easiest solution prevents sharing altogether.  This makes the most sense to me.  Of course, if the Geolocation header is used for indirect publish, this exception will need to be noted there.

The second issue is expiry of URIs.  On this point the choice to use an explicit indication or not is trickier.  With an explicit indication, a UA would not waste time dereferencing an expired URI.  It would be able to quickly identify when location information is not available.  Of course, you have to weigh this (small) benefit and the probability of it being needed against the cost of the parameter and the hindrance it causes.

On expiry, no metadata, although this isn't as clear cut.

Do my conclusions sound reasonable to you?

Martin

p.s. header parameters would be sufficient, that XML looks a little much for SIP.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Jan 2009 19:45:04 -0600

Hannes

Conveyance will not modify itself such that the newly created 
Geolocation header carries a location URI that looks like your XML 
example below.  This is too much for a SIP header, therefore it would 
have to be a message body-part (within the SIP request).

Besides, this is missing the point of having a location URI in the 
first place - for SIP proxies (those that are *not* B2BUAs or SBCs) 
to add location into a SIP request.  Making this information part of 
a message body prevents that requirements from being fulfilled.

If you really want to go down this path, I'll gladly take out 
location URIs from the Geolocation header, and replace the whole 
solution with "location MUST be carried as a message body part as a 
PIDF-LO", given that turning the XML that's below into a PIDF would 
be a fairy easy task (taking maybe 1 or 2 minutes).

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Jan 2009 19:56:20 -0600

Hi James,

As I outlined in my response to the email, I don't think that this is necessary either.  My suggestion is that conveyance pre-empt problems by:

 - stating that location URIs MUST NOT be retransmitted or forwarded by the UAS unless necessary for signalling.

 - noting that location URIs can expire, but that no explicit indication of when they do so is provided.

These were the elements of metadata that were the subject of discussion.  Of course, if more than the above were required, nothing would prevent them from being added as header parameters.  I just don't think that is necessary for now.

By the way, I find your anthropomorphism of a document interesting :)

M

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 7 January 2009 12:45 PM
> To: Hannes Tschofenig; Thomson, Martin; Tschofenig, Hannes (NSN -
> FI/Espoo); 'ext Robert Sparks'; 'GEOPRIV'
> Subject: Location URI as an object now? (was Re: [Geopriv] WGLC: draft-
> ietf-geopriv-lbyr-requirements-05)
> 
> Hannes
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Jan 2009 22:22:49 -0600

At 07:56 PM 1/6/2009, Thomson, Martin wrote:
>Hi James,
>
>As I outlined in my response to the email, I don't think that this 
>is necessary either.

ok, but I'm not fond of the additional restrictions you want to go 
into Conveyance.

>My suggestion is that conveyance pre-empt problems by:
>
>  - stating that location URIs MUST NOT be retransmitted or 
> forwarded by the UAS unless necessary for signalling.

"MUST NOT"? Where did this requirement come from, given that what 
you're suggesting is cross transaction awareness within a UA, which 
is something Conveyance currently avoids.

>  - noting that location URIs can expire, but that no explicit 
> indication of when they do so is provided.

Conveyance currently does not have any text wrt URIs ability to 
expire. Why does this need to be added, given that Conveyance will 
then need to define what this actually is, and probably means getting 
into an explanation of authorization vs. possession models to give 
proper context to the whole expiry discussion.

That's convoluting more into Conveyance than it should have in it.

>These were the elements of metadata that were the subject of discussion.

this might be a concern or topic of interest to HELD, but not Conveyance...

>Of course, if more than the above were required, nothing would 
>prevent them from being added as header parameters.  I just don't 
>think that is necessary for now.
>

what new description did I give Conveyance that resulted in this reaction?

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Jan 2009 23:18:12 -0600

Hi James,

Inline...

> Sent: Wednesday, 7 January 2009 3:23 PM
> To: Thomson, Martin; Hannes Tschofenig; Tschofenig, Hannes (NSN -
> FI/Espoo); ext Robert Sparks; GEOPRIV
> Subject: RE: Location URI as an object now? (was Re: [Geopriv] WGLC:
> draft-ietf-geopriv-lbyr-requirements-05)
> 

If you have a URI where possession implies authorization, if the UAS were to pass that on to his buddies, then you have a privacy concern.  You don't need to get into the details of different usage models.  All I'm suggesting is that conveyance make it clear even the URI must be treated as private data.  One sentence in section 7:

   This document requires that SIP entities sending or receiving
   location MUST obey such instructions.  The contents of the Geolocation header, including the URI, is private information and SIP entities MUST NOT forward this information to entities outside of what is necessary for normal SIP routing procedures.

Yes, this goes beyond what is necessary for basic interoperability.  This is not talking about a SIP stack, but about the application that uses that stack.  That's all about protecting the ---PRIV.

> That's convoluting more into Conveyance than it should have in it.

I'd not be concerned if conveyance didn't discuss URI expiry.
 
> what new description did I give Conveyance that resulted in this

"Conveyance will not modify itself" seems to imply anthropomorphic properties.  The alternative is self-modification, which is much scarier.  On the other hand, given the age of this document, perhaps that shouldn't be so surprising...

MT

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 7 Jan 2009 09:57:14 +0200

I just wrote the example in XML to figure out whether I correctly understood
Martin. 
The content can obviously be encoded in a non-XML fashion. 

Ciao
Hannes

>Sent: 07 January, 2009 03:45
>To: Hannes Tschofenig; 'Thomson, Martin'; Tschofenig, Hannes 
>(NSN - FI/Espoo); 'ext Robert Sparks'; 'GEOPRIV'
>Subject: Location URI as an object now? (was Re: [Geopriv] 
>WGLC: draft-ietf-geopriv-lbyr-requirements-05)
>
>Hannes
>
>Geolocation header carries a location URI that looks like your 
>XML example below.  This is too much for a SIP header, 
>therefore it would have to be a message body-part (within the 
>SIP request).
>
>Besides, this is missing the point of having a location URI in 
>the first place - for SIP proxies (those that are *not* B2BUAs 
>or SBCs) to add location into a SIP request.  Making this 
>information part of a message body prevents that requirements 
>from being fulfilled.
>
>location URIs from the Geolocation header, and replace the 
>whole solution with "location MUST be carried as a message 
>body part as a PIDF-LO", given that turning the XML that's 
>below into a PIDF would be a fairy easy task (taking maybe 1 
>or 2 minutes).
>
>James
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 7 Jan 2009 09:58:30 +0200

If this is the way to go then the requirement in Roger's document has to be
re-worded a bit.  

>From: Thomson, Martin [mailto:[email-masked]] 
>Sent: 07 January, 2009 03:56
>To: James M. Polk; Hannes Tschofenig; Tschofenig, Hannes (NSN 
>- FI/Espoo); ext Robert Sparks; GEOPRIV
>Subject: RE: Location URI as an object now? (was Re: [Geopriv] 
>As I outlined in my response to the email, I don't think that 
>this is necessary either.  My suggestion is that conveyance 
>pre-empt problems by:
>
>These were the elements of metadata that were the subject of 
>discussion.  Of course, if more than the above were required, 
>nothing would prevent them from being added as header 
>parameters.  I just don't think that is necessary for now.
>
>> first place - for SIP proxies (those that are *not* B2BUAs 
>or SBCs) to 
>> add location into a SIP request.  Making this information part of a 
>> message body prevents that requirements from being fulfilled.
>> 
>> If you really want to go down this path, I'll gladly take 
>out location 
>> URIs from the Geolocation header, and replace the whole 
>solution with 
>> "location MUST be carried as a message body part as a 
>PIDF-LO", given 
>> that turning the XML that's below into a PIDF would be a fairy easy 
>> task (taking maybe 1 or 2 minutes).
>> 
>> James
>> 
>> ><?xml version="1.0" encoding="UTF-8"?> <LbyR>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 7 Jan 2009 10:02:34 +0200

>discussion.

James, this has nothing todo with HELD. Instead it is a rather generic
question that came up with one of the requirements Roger had in his
document. The same issue would be applicable to
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-
03.txt

For example, there you also have a field "Valid-For" that fits into one part
of the requirements. The other part is whether the Location Recipient
actually knows this information as well. 

Ciao
Hannes

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 8 Jan 2009 17:26:11 -0800

Hannes:
Thank you for your extensive review and comments.  Wow, the changes,
most of which I've either agreed with (or not objected to), will
certainly pare down the remaining list of requirements.  I have provided
responses and some remarks inline [RSM], and will also respond to some
of the comments made subsequent to this message.

Of course, a diff btwn a revised version and -05 will help folks see the
impact.

-roger.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tschofenig, 
> Hannes (NSN - FI/Espoo)
> Sent: Friday, December 26, 2008 12:39 PM
> To: ext Robert Sparks; GEOPRIV
> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-lbyr-requirements-05
> 
> Hi Roger,
> Hi Robert, 
> 
> I re-read the document and I have a few minor text suggestions: 
> 
> I wonder why you use the term "location server" instead of 
> "Location Information Server". 
> In
> There was a long discussion about this topic and we agreed to 
> use that term. For now, I did not make any changes regarding 
> the LIS vs. LS aspect. 

[RSM]  I agree this is troubling. It has been for a long time,
especially since the presence architecture (RFC3693) uses LS that
interacts with a Rule Maker, and the lcp-ps doesn't (no Rule Maker).  I
think the later diagram provided by Martin will fix most of these
concerns.

>       either in configuration or conveyance protocols, (i.e., 
> the actual
>    Location-by-Value (LbyV):  Location information in the 
> format of a PIDF-LO
>       (or related encoding) 

[RSM] agreed

> 
> FROM:
> 
>    Location-by-Reference (LbyR):  The mechanism of 
> representing location
>    Location-by-Reference (LbyR):  A location URI pointing to 
> location information 
> 

[RSM] no objection

>       input and which returns location information.

[RSM] agreed

> 
> FROM:
> 
>    Location URI:  An identifier which serves as a pointer to 
> a location
>       record on a remote host (e.g., LIS).  Used within an 
> Location-by-
>       Reference mechanism, a location URI is provided by a location
>       configuration server, and is used as input by a dereference
>       protocol to retrieve location from a dereference server.
> 
> TO:
> 
>    Location URI:  An identifier that serves as a pointer to a location
>       information. A location URI is provided by a location
>       server, and is later used as input by a dereference
>       protocol to retrieve location information.
> 

[RSM] agree mostly - and would certainly agree for this document, since
there still is, what I'd argue is a valid use case for having a location
URI with inherent location (e.g., non PRIV related).  Suggest rewording
to: 

    Location URI:  As defined within this document, an identifier that
serves as a pointer to a location
       information. A location URI is provided by a location
       server, and is later used as input by a dereference
       protocol to retrieve location information.

> To make this figure more generic I would also add a box that 
> talks about the Rulemaker being outside the Target. 
> Additionally, I would only use the term "Rulemaker" instead 
> of "Rulemaker / owner" because I don't really understand what 
> owner in this context means. 
> 

[RSM] The Rulemaker here is drawn outside the Target (is within the
"user of the target" box).  This may become moot, given Martin's updated
diagram.

> 
> FROM:
> 
>    (1a).  Target requests reference from server; and receives back, a
>    location URI in server response
> 
>    (1b).  Rulemaker policy is consulted (interface out of scope)
> 
>    (2).  Target conveys reference to recipient (out of scope)
> 
>    (3).  Recipient dereferences location URI, by a choice of methods,
>    including a request/response (e.g., HTTP) or publish/subscription
>    (e.g., SIP SUBSCRIBE/NOTIFY)
> 
> TO:
> 
> 
>    (1a).  Target requests reference from the location server; 
> and receives back, a
>    location URI in the location server response message
> 
>    (1b).  Rulemaker policy is consulted (interface out of scope)
> 
>    (2).  Target conveys reference to location recipient (out of scope)
> 
>    (3).  Recipient dereferences location URI, for example 
> using HTTP or SIP
> 

[RSM] Agree

> 
> FROM:
> 
>    An example scenario of how this might work, is where the Target
>    obtains a location URI in the form of a subscription URI 
> (e.g., a SIP
>    URI) via HELD (a Geopriv layer 7 location configuration protocol).
> 
> TO:
> 
> 
>    An example scenario of how this might work, is where the Target
>    obtains a location URI in the form of a subscription URI 
> (e.g., a SIP
>    URI) via a location configuration protocol.
> 

[RSM] Agree

> 
> 
> 
> I would delete the following paragraph as the same 
> information is also presented further below: 
> 
>    Because a location URI is a pointer to the Target's location, it is
>    important that it be constructed in such a way that it does not
>    unintentionally reveal any usable information about the Target it
>    represents.  For example, it is important to prevent 
> adversaries from
>    obtaining any information that may be revealed about a Target by
>    direct examination of the location URI itself, (e.g., names,
>    identifiers, etc.), some determinable pattern or syntax (e.g.,
>    sequence of numbers), or guessable codes (e.g., weak encryption).
>    Therefore, each location URI must be constructed with security
>    safeguards in mind.
> 
> 

[RSM] Agree

> 
> FROM:
> 
>    1. Access control authorization model:  Access to the 
> location URI is
>       limited by policy.  In this case, the Rule Maker 
> (owner/Target) is
>       able to provide authorization policies to the LIS during this
>       stage, or through some other parallel mechanism (e.g., interface
>       1b., Figure 1.).  Policies are attached to a location 
> URI through
>       an (undisclosed) mechanism.
> 
>       model is described as having no authentication and/or
>       authorization requirement aside from only possessing 
> the location
>    1. Access control authorization model:  Access to the 
> location URI is
>       limited by policy.  In this model it is assumed that 
> the rulemaker
> 
>       are attached to a location URI and control the 
> dereferencing process.
> 
>       model is described as not having policies associated to 
> the location
>       URI  from only possessing the location

[RSM] agree with one minor correction: 
s/from/aside from/1 as in the original, "...aside from only possessing
the location URI itself."
(I don't think you meant to leave out "aside")

> FROM:
> 
> 
> It is important to protect the actual location information from
>    an intermediate node (despite the fact that in the possession model
>    there would be nothing to prevent an interceptor from seeking to
>    dereference the location URI). 
> 
> TO:
> 
> It is important to protect the actual location information from
>    an intermediate node.
> 
> The statement you made is not correct as the protocol for 
> conveying the reference could experience confidentiality protection. 
> 

[RSM] Agree

> 
> Obfuscating the location URI
>    safeguards against the undetected stripping off of what would
>    otherwise be evident location information, since it forces a
>    dereference operation by the location dereference server, an
>    important step for the purpose of providing statistics, 
> audit trails,
>    and general logging for many different kinds of location based
>    services.
> 
> Not sure what exactly that means. 
> 

[RSM] This text was a result of a long discussion thread (some time ago)
- and related to C4 - as to having to do with whether the location URI
revealed any domain, user, or device specific information.  The idea was
to make it look bland, uninteresting, and generic, so that it's location
would be to some degree, undectable.

> 
> Each of these two general protocols has
>    multiple specific protocol implementations.  Location configuration
>    protocols include, HELD, DHCP, and LLDP-MED, whereas 
> current location
>    dereferencing protocols include HELD Deref, HTTP GET, and SIP
>    SUBSCRIBE/NOTIFY.  
> 
> It would be useful to provide references to all these 
> protocols. The other alternative is to delete the sentence.
> 

[RSM] I'm in favor of a deletion, as suggested.

> 
> I would delete the following sentence: 
> 
> Because each of these specific protocol
>    implementations has its own unique client and server interactions,
>    the requirements here are not intended to state what a client or
>    server is expected to do, but rather which requirements must be met
>    separately by any location configuration protocol or location
>    dereference protocol, for the purposes of using a location URI.
> 

[RSM] I don't object to the deletion of it.

> 
> FROM:
> 
>    C1. Location URI support:  The configuration protocol MUST 
> support a
>       location reference in URI form.
> 
>       Motivation: It is helpful to have a consistent form of 
> key for the
>       LbyR mechanism.
> 
>  
> TO:
> 
>    C1. Location URI support:  The location configuration 
> protocol MUST support a
>       location reference in URI form. 
> 
>       Motivation: A standardized location reference mechanism 
> increases interoperability. 
> 

[RSM] Agree with change.

>       masked from a casual observing node.

[RSM] I agree with the change, and would just as soon keep C4 around,
since it may be possible to adhere to C5, but still reveal more info
than necessary here, such as sequential numbering, etc. 

> 
> FROM:
> 
>    C5. User Identity Protection:  The location URI MUST NOT 
> contain any
>       user identifying information that identifies the user, device or
>       address of record, (e.g., which includes phone extensions, badge
>       numbers, first or last names, etc.), within the URI form.
> 
>       address from being included in the form of the location 
> URI itself
>       when it is generated.
> 
> TO:
> 
>       address from being included in the form of the location 
> URI itself
>       when it is generated.
> 

[RSM] Agree.

> 
> C7 is the same as C2. Hence, delete C7. 
> 
>    C7. Validity Interval Indication:  A location 
> configuration protocol
>       MUST provide an indication of the location URI validity interval
>       (i.e., expiry time) when present.
> 
>       Motivation: It is important to be able to determine how long a
>       location URI is to remain useful for, and when it must be
>       refreshed.
> 

[RSM] No objection.

>    
> 
> I would phrase this requirement a bit differently:
> 
> FROM:
> 
>    C8. Location only:  The location URI MUST NOT point to any
>       information about the Target other than it's location.
> 
>       Motivation: A user should have the option to control how much
>       information is revealed about them.  This provides that 
> control by
>       not forcing the inclusion of other information with location,
>       (e.g., to not include any identification information in the
>       location URI.)
> 
> TO:
> 
>    C8. Selective disclosure:  The location configuration protocol
>       MUST provide a mechanism to control what information is being 
>       disclosed about the Target. 
> 
> 
>       Motivation: The rulemaker has to be in control of how 
> much information 
>       is revealed during the dereferencing step as part of 
> the privacy features. 
> 

[RSM] Agree. This is much better, thanks.

> 
> FROM:
> 
>  C9. Location URI Not guessable:  Where location URIs are used
>       publicly, any location URI MUST be constructed using 
> properties of
>       uniqueness and cryptographically random sequences so that it is
>       not guessable.  (Note that the number of bits depends to some
>       extent on the number of active location URIs that might exist at
>       the one time; 128-bit is most likely enough for the near term.)
> 
>       Motivation: Location URIs need to guard against any 
> observing node
>       or individual stripping off meaningful information about the
>       Target.
> 
> TO: 
> 
>    C9. Location URI Not guessable:  As a default, the 
> location configuration 
>       protocol MUST return location URIs that are random and 
> unique throughout 
>       the indicated lifetime. A location URI with 128-bits of 
> randomness
> 
>       is RECOMMENDED. 
> 
>       Motivation: Location URIs should be constructed in such 
> a way that
> 
>       an adversary cannot guess them and dereference them 
> without having
> 
>       ever obtained them from the Target. 
> 

[RSM] No objection.

>       requirements, but may opt to specify their own location URI, or

[RSM] This is the case where a location URI might not be an "LbyR, or
dereferencable location URI", that is, those use cases (mentioned above)
that justify the deployment of a location URI with embedded location.

> 
> I would delete C11 as the location configuration protocol 
> cannot really tell the authorization model the Target / 
> Rulemaker is going to apply. I could get a Location URI and 
> then upload it to a presence server. The presence server 
> could operate based on my authorization policies. The initial 
> LbyR would follow a possession model but the entire system 

[RSM] I don't object too much here, but only based on what we can agree
to with regard to including metadata along with a location URI.

> 
> C12 is the same as C7 and C2. hence, I suggest to delete C12. 
> 
> 
>    C12.  Location URI Lifetime:  A location URI SHOULD have an
>       associated expiration lifetime (i.e., validity 
> interval), and MUST
>       have an validity interval if used with the possession
>       authorization model.
> 
>       Motivation: If a location URI is unintentionally 
> leaked, then the
>       amount of time that the reference can be potentially used by an
>       unknown attacker (or, casual observer) needs to be limited.
> 

[RSM] I don't object.

> 
> D2 is phrased incorrectly. I guess what you would like to say 
> is that the lifetime of the location URI that is being 
> provided via the Location Configuration Protocol should also 
> be made available to the Location Recipient so that he knows 
> how long derefencing is possible. This is not really a 
> requirement for the Location Dereferencing Protocol but 
> rather to the Location Conveyance protocol that passes the 
> LbyR (and potentially the lifetime around) unless you suggest 
> that the location URI should already indicate the lifetime as 
> a URI parameter. 
> 
> In any case, D2 should be deleted. 
> 
>    D2. Validity Interval Indication:  A location dereference protocol
>       MUST provide an indication of the location URI validity interval
>       (i.e., expiry time) when present.
> 
>       Motivation: It is important to be able to determine how long a
>       location URI is to remain useful for, and what time it will no
>       longer be usable.
> 

[RSM] I don't object.

> D6 is essentially the same as D2. Delete D6.
> 
>    D6. Validity Interval Indication:  A dereference protocol MUST
>       provide an indication of the location URI validity 
> interval (i.e.,
>       expiry time) when present.
> 
>       Motivation: It is important to be able to determine how long a
>       location URI is to remain useful for, and when it must be
>       refreshed.
> 

[RSM] I won't object, just so long as conveyance takes up the cause.

> I suggest to delete D7 since this is not in control of the 
> Location Dereferencing Protocol to decide about the style of the URI. 
> Instead, it is the Location Server that controls this aspect 
> when crafting the location URI and this is already covered in 
> the previous requirements. 
> 
>    D7. Location URI anonymized:  Any location URI whose 
> dereference will
>       not be subject to authentication and access control MUST be
>       anonymized.
> 
>       Motivation: The dereference protocol must define an anonymized
>       format for location URIs.  This format must identify the desired
>       location information via a random token with at least 
> 128 bits of
>       entropy (rather than some kind of explicit identifier, 
> such as an
>       IP address).
> 

[RSM] Agree to the delete.

> Same as D7, delete. 
> 
>    D8. Location Information Masking:  The location URI form MUST,
>       kept obscure during location URI dereferencing.
> 
>       masked from a casual observing node, requiring instead 
> a discrete
>       dereference operation in order to return location information.
> 

[RSM] I don't object, but do think C4 (the equivalent req for LCP)
should be retained.

> 
> I wonder whether this requirement makes sense as we are 
> stating requirements for the protocol and not for the 
> correctness of the implementation. In some sense you are 
> asking the implementation to actually enforce the 
> authorization policies the rulemaker has uploaded.
> I think a solution document should say that in the Security 
> Considerations section but that's about it. 
> 
> My suggestion: delete it 
> 
>    D9. Location Privacy:  The location dereference protocol 
> MUST support
>       the application of privacy rules to the dissemination of a
>       requested location object.
> 
>       Motivation: The dereference server must obey all provisioned
>       privacy rules that apply to a requested location object.
> 

[RSM] yeah, I know - this has been the struggle here.  Don't oppose it's
deletion.

> 
> FrOM:
> 
>    D10.  Location Confidentiality:  The dereference protocol MUST
>       support encryption of messages sent between the location
>       dereference client and the location dereference server, and MAY
>       alternatively provide messaging unencrypted.
> 
>       Motivation: Environmental and local configuration policy will
>       guide the requirement for encryption for certain 
> transactions.  In
>       some cases, encryption may be the rule, in others, it may be
>       acceptable to send and receive messages without encryption.
> 
> TO:
> 
>    D10.  Location Confidentiality:  The location dereference 
> protocol MUST
>       support confidentiality protection of messages sent between the 
> 	  Location Recipient and the location server.
> 
>       Motivation: The location URI indicates what type of 
> security protocol 
> 	  has to be provided. An example is a location URI 
> using a HTTPS URI scheme.
> 

[RSM] Agree.
	  
> regarding D11: When dereferencing takes place and the client 
> authentication is demanded then the authorization can 
> implicitly be inferred. I would delete this requirement as it 
> does not get the Location Recipient too far to know what 
> authorization model is being applied. If you consider the 
> HTTP environment then you will notice that there you see what 
> authorization model is being applied when you try to access 
> the resource being a URL and you are being challenged. 
> 
>  
>     D11.  Location URI Authorization Model:  The location dereference
>       Motivation: Downstream dereference clients need to know 
> whether a
>       location URI provided by the location configuration protocol
>       conforms to an access control authorization model or a 
> possession
>       authorization model in order to save time processing dereference
>       attempts.
> 

[RSM] yep.  I don't object to deleting D11.

> public, by itself,
>    implies no safeguard against anyone being able to 
> dereference and get
>    obtaining location information without ever retrieving a 
> location URI.  
>    if made publically available, implies no safeguard against 
> anyone being able to 
>    a location URI to the trusted location recipients. When 
> this aspect is of concern then 
>    the authorization model has to be chosen. Even in this 
> model care has to be 
>    taken on how to construct the authroization policies to 
> ensure that only those 
>    parties have access to location information that are 
> considered trustworthy enough 

[RSM] accept text change.
  
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of ext Robert Sparks
> >Sent: 05 December, 2008 17:53
> >To: GEOPRIV
> >Subject: [Geopriv] WGLC: draft-ietf-geopriv-lbyr-requirements-05
> >
> >This is a GEOPRIV Working Group Last Call for comments on
> >draft-ietf-geopriv-lbyr-requirements-05
> >(http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lbyr-re
> >quirements-05.txt
> >)
> >
> >Please send your comments no later than Friday Dec 19, 2008.
> >
> >RjS

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 8 Jan 2009 17:31:07 -0800

Hannes/Martin:
(this msg. is a follow-up in addition to prior responses based on
Hannes' review of -05)

Here's what I see as to the current proposals on the table and my take
on each:
1. new diagram (as provided inline) to eliminate some confusion btwn
LS/LIS/RM, [ok]
2. changes to text under diagram, except as noted next, [ok]
3. seek clarification of the statement (in same figure text), "A Target
could also acquire a location URI from the LS directly using alternative
means."  An example would probably make clearer.
4. location URI with self-evident location (inherent location).  While I
agree with the below sentiment that some use cases may exist for this,
and should be described (maybe in a different draft?) - I don't think
such a thing is an example of LbyR location URI.  An LbyR, by definition
is a reference, and therefore needs to be dereferenced.

-roger.

> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 06, 2009 10:43 AM
> To: 'Thomson, Martin'; Tschofenig, Hannes (NSN - FI/Espoo); 
> 'ext Robert Sparks'; 'GEOPRIV'
> >> The interaction regarding the LCP is surely between the 
> LIS and the 
> >> Target.
> >Not really.  It's not a necessary attribute of the URI.  Of course, 
> >there isn't really many good reasons to expose location 
> information in 
> >this way, but it doesn't prevent it from being valid.
> >
> sense.  It 
> >just doesn't require a protocol to dereference.
> 
> Well. For me a Location URI is a pointer to location that 
> needs to be dereferenced to obtain location information. 
> 
> Using a URI to encode location information so that it isn't a 
> pointer anymore and does not need to be de-referenced to 
> obtain location doesn't really satisfy my understanding of a 
> location URI. 
> 
> Why would you want to dereference a location URI that has 
> location already encoded in the URI? E.g., a data: URI. This 
> for example is a data: URI encoding of the example shown in 
> http://held-location.sourceforge.net/held_js/pidflo.html. In 
> your definition of location URI this would be a URI but 
> nobody would dereference it since it already describes the 
> location. If one does this then it should be treated like a 
> ordinary location object -- it is just encoded a bit differently. 
> 
> >No kidding ;)  Of course, we usually choose an AoR/email address; by 
> >the same token, a more or less permanent possession model 
> location URI 
> >might be a reasonable candidate for user selection.
> 
> But we are talking about the LCP here -- the interface 
> between the Target and the LIS. Here again it is important to 
> say that we are talking about the LIS and not a generic 
> location server where you might very well select your own identity. 
> 
> 
> >
> >
> is becomes 
> >less useful.  However, that only holds true if we either prevent 
> >retransmission or we have an explicit indication on whether 
> >retransmission is allowed.  Knowing the type of URI could be used to 
> >advise LR behaviour.  If the LR knows that a URI follows the 
> >authorization model, then the LR can freely distribute a URI.
> 
> Didn't we discuss this issue in the past already and folks 
> did not want to attach meta-data (like policies, lifetime, 
> etc.) to the URI. Maybe we could re-think that decision 
> since, I believe, that you are saying that we should always 
> attach the basic policies -- regardless whether it is LbyR or LbyV.
> 
> This would mean for SIP location conveyance, for example, you 
> convey an object like the following one (as XML encoding):
> 
> HTTP model 
> >- are you talking about an HTTP conveyance protocol that I'm 
> not aware 
> >of?
> 
> >This message is for the designated recipient only and may contain 
> >privileged, proprietary, or otherwise private information.
> immediately 
> >and delete the original.  Any unauthorized use of this email is 
> >prohibited.

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 8 Jan 2009 17:34:06 -0800

Does anyone have a suggested text block change, if so?

I wouldn't agree that a location URI needs to be an object, but based on
the lbyr-requirements paring, it does seem like conveyance needs to step
up with some additional requirement.

-roger.

> Sent: Tuesday, January 06, 2009 11:59 PM
> To: 'Thomson, Martin'; 'James M. Polk'; Tschofenig, Hannes 
> Subject: Re: [Geopriv] Location URI as an object now? (was 
> Re: WGLC:draft-ietf-geopriv-lbyr-requirements-05)
> 
> If this is the way to go then the requirement in Roger's 
> document has to be re-worded a bit.  
> 
> >As I outlined in my response to the email, I don't think 
> that this is 
> >necessary either.  My suggestion is that conveyance pre-empt 
> problems 
> >by:
> >
> >discussion.  Of course, if more than the above were 
> required, nothing 
> >would prevent them from being added as header parameters.  I 
> just don't 
> >> >This would mean for SIP location conveyance, for example, 
> you convey
> >> an

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Jan 2009 20:39:16 -0600

Hi Roger,

On 3 - the only example I can think of is acquisition of a presence AoR.  If that AoR was to be used for location information, it could be regarded as a location URI.

On 4 - I agree.  In any case, an attempt to add text on this would likely be confusing.

Cheers,
Martin

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Friday, 9 January 2009 12:31 PM
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-lbyr-requirements-05
> 
> Hannes/Martin:
> CONFIDENTIALITY NOTICE: The information contained in this message may
> be privileged and/or confidential. If you are not the intended
> recipient, or responsible for delivering this message to the intended
> recipient, any review, forwarding, dissemination, distribution or
> copying of this communication or any attachment(s) is strictly
> prohibited. If you have received this message in error, please notify
> the sender immediately, and delete it and all attachments from your
> computer and network.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 9 Jan 2009 12:58:29 +0200

Thanks, Roger. 

I agree with your clarifications.  

>From: ext Roger Marshall [mailto:[email-masked]] 
>Sent: 09 January, 2009 03:26
>To: Tschofenig, Hannes (NSN - FI/Espoo); ext Robert Sparks; GEOPRIV
>Thank you for your extensive review and comments.  Wow, the 
>changes, most of which I've either agreed with (or not 
>objected to), will certainly pare down the remaining list of 
>requirements.  I have provided responses and some remarks 
>inline [RSM], and will also respond to some of the comments 
>made subsequent to this message.
>
>Of course, a diff btwn a revised version and -05 will help 
>folks see the impact.
>
>-roger.
>
>
>Hannes (NSN 
>> - FI/Espoo)
>especially since the presence architecture (RFC3693) uses LS 
>that interacts with a Rule Maker, and the lcp-ps doesn't (no 
>Rule Maker).  I think the later diagram provided by Martin 
>will fix most of these concerns.
>
>> 
>> 
>> FROM:
>> 
>format of a 
>CONFIDENTIALITY NOTICE: The information contained in this 
>message may be privileged and/or confidential. If you are not 
>the intended recipient, or responsible for delivering this 
>message to the intended recipient, any review, forwarding, 
>dissemination, distribution or copying of this communication 
>or any attachment(s) is strictly prohibited. If you have 
>received this message in error, please notify the sender 
>immediately, and delete it and all attachments from your 
>computer and network.
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jan 2009 13:27:46 -0600

Hi folks -

Can you help Roger close this so we can put this document down?

RjS

On Jan 8, 2009, at 7:34 PM, Roger Marshall wrote:

> CONFIDENTIALITY NOTICE: The information contained in this message  
> may be privileged and/or confidential. If you are not the intended  
> recipient, or responsible for delivering this message to the  
> intended recipient, any review, forwarding, dissemination,  
> distribution or copying of this communication or any attachment(s)  
> is strictly prohibited. If you have received this message in error,  
> please notify the sender immediately, and delete it and all  
> attachments from your computer and network.

---

From: TSG <[email-masked]>
Date: Tue, 13 Jan 2009 11:38:53 -0800

> Can you help Roger close this so we can put this document down?

Depends on what the GeoPRIV controls are used for.
>> up with some additional requirement.
Anything that is part of a data-message stream that is intended to be 
able to be reviewed by a Court would need an evidence-grade object 
management practice generated for it.
> ------------------------------------------------------------------------
>
>
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM
>
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Jan 2009 17:02:08 -0600

Hi Robert,

The location by reference requirements specifically excludes the conveyance protocol.  I'm happy to continue that.

My suggestion is to ignore my little suggestion.  Treat it as a comment on SIP conveyance.

Cheers,
Martin

> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, 14 January 2009 6:28 AM
> To: Roger Marshall
> Cc: Hannes Tschofenig; Thomson, Martin; James M. Polk; Tschofenig,
> Hannes (NSN - FI/Espoo); GEOPRIV
> Subject: Re: [Geopriv] Location URI as an object now? (was Re:
> WGLC:draft-ietf-geopriv-lbyr-requirements-05)
> 
> Hi folks -
>

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 13 Jan 2009 15:13:41 -0800

I've got no objection with Martin's suggestion.

-roger. 

> Sent: Tuesday, January 13, 2009 3:02 PM
> To: Robert Sparks; Roger Marshall
> Cc: Hannes Tschofenig; James M. Polk; Tschofenig, Hannes (NSN 
> - FI/Espoo); GEOPRIV
> Subject: RE: [Geopriv] Location URI as an object now? (was 
> The location by reference requirements specifically excludes 
> the conveyance protocol.  I'm happy to continue that.
> 
> > > I wouldn't agree that a location URI needs to be an object, but 
> > > based on the lbyr-requirements paring, it does seem like 
> conveyance 
> > > needs to step up with some additional requirement.
> > >
> > > -roger.
> > >
> > >> To: 'Thomson, Martin'; 'James M. Polk'; Tschofenig, 
> Hannes (NSN - 
> > >>> By the way, I find your anthropomorphism of a document 
> interesting 
> > >>> :)
> > >>>
> > >>> M
> > >>>
> > >>>> Subject: Location URI as an object now? (was Re: 
> [Geopriv] WGLC:
> > >>>> draft-
> therefore
> > >>> it would
> > >>>>>        <retention-expiry>2007-05-25T12:35:02+10:00 
> </retention-
> > >>>> expiry>
> > >>>>>    </usage-rules>
> > >>>>> </LbyR>
> > >>>>
> > >>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Jan 2009 01:20:35 +0100

On this list it will not be treated as a comment on sip-location-conveyance.

If you want it to be such, you will need to make it to the sip list.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Thomson, Martin
> Sent: Tuesday, January 13, 2009 11:02 PM
> Cc: GEOPRIV; Tschofenig, Hannes (NSN - FI/Espoo); James M. Polk

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Jan 2009 18:22:02 -0600

Yessir.

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, 14 January 2009 11:21 AM
> To: Thomson, Martin; Robert Sparks; Roger Marshall
> Re:WGLC:draft-ietf-geopriv-lbyr-requirements-05)
>