Subject: [Geopriv] WGLC reminder

From: Alissa Cooper <[email-masked]>
Date: Fri, 8 Apr 2011 06:35:57 +0100

We have WGLCs open for draft-ietf-geopriv-deref-protocol-02 and draft- 
ietf-geopriv-policy-uri-00 until next Tuesday, April 12. Please send  
your comments to the appropriate threads (even if you're just giving a  
thumbs-up). Thus far there have been no responses.

Thanks
Alissa

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Apr 2011 17:28:56 +0800

I think that both documents are ready.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Alissa Cooper [[email-masked]]
Sent: Friday, April 08, 2011 12:35 AM
To: [email-masked]
Subject: [Geopriv] WGLC reminder

Thanks
Alissa

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 08:28:54 -0400

<hat type="individual" />

I agree.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 11 Apr 2011 07:11:01 +0800

Likewise.

On 2011-04-08 at 22:28:54, Richard L. Barnes wrote:
> > From: [email-masked] [[email-masked]] On Behalf
> Of
> > Alissa Cooper [[email-masked]]

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 11 Apr 2011 15:09:11 -0700

I say that they're ready to go.

-roger marshall.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alissa Cooper
Sent: Thursday, April 07, 2011 10:36 PM
To: [email-masked]
Subject: [Geopriv] WGLC reminder

Thanks
Alissa

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: Adam Roach <[email-masked]>
Date: Thu, 28 Apr 2011 16:58:31 -0500

On 4/8/11 12:35 AM, Alissa Cooper wrote:
> We have WGLCs open for draft-ietf-geopriv-deref-protocol-02 and 
> draft-ietf-geopriv-policy-uri-00 until next Tuesday, April 12. Please 
> send your comments to the appropriate threads (even if you're just 
> giving a thumbs-up). Thus far there have been no responses. 

Although I'm not following GEOPRIV (and so don't know if there are 
relevant threads to comment on), Richard asked me to perform a review of 
this document.  I'm doing this in kind of a hurry, so please excuse the 
fact that my comments are mostly in the order I encountered them when 
reading through the document.

The first thing that I notice is that the document rather tightly scopes 
policy URIs to being HTTP-only. I'm not suggesting that this document 
should go about defining other mechanisms; but it probably should leave 
the door open for future documents to do so without redefining key 
terms. (For example, if there were a good reason to use SIP to deliver 
policy information in the future, we should be able to do so without 
having to change the definition of "Policy URI.")

Specifically, I would suggest re-crafting section 3 to read more like:

    A policy URI is a URI that identifies a policy resource that
    contains the authorization policy for a linked location resource.
    Access to the location resource is governed by the contents of
    the authorization policy. This document defines the behavior of
    clients and servers using HTTP [RFC2616] policy URIs.

    A policy URI identifies a resource that a Rule Maker can use to
    inspect and install policy documents that tell a Location Server
    how it should protect the associated location resource.

This would also have minor impacts elsewhere in the document so that 
statements specific to the HTTP usage were qualified to indicate that 
the statements are specific to the HTTP usage (e.g. changing the title 
of section 3.1 to "HTTP Policy URI Usage").

On a separate topic, I note that the document implies that multiple 
clients are capable of updating the document via PUT and DELETE 
operations, but without mentioning the use of etags. This can cause 
races in the multi-client case (client A GETs the policy, appends a 
rule; client B PUTs a set of rules; and then client A PUTs his modified 
policy in place, overwriting B's policy). I believe the document needs 
to address this case by mentioning etags as a means for avoiding races. 
I would suggest that we even go so far as to require servers to return 
Etag header fields for all HTTP Policy URIs, so as to ensure that 
clients can use this mechanism. (This has impacts on the examples in 
section 5.3: add an "ETag" to the 200, and an "If-Match" to the PUT).

[Minor editorial nit in the first paragraph of section 3.2: I believe 
"different to" is a uniquely British usage, while "different from" is 
used in all English dialects]

Section 3.2 states: "A HELD-specific extension also allows a requester 
to specifically ask for a policy URI." I think this needs a citation 
(e.g., "See section 4.1").

Section 4.1 claims 'A policy URI MUST use the "http:" or "http:" 
scheme...'  I suspect that one of those should be "https," but the more 
relevant comment here is that this seems an unnecessary restriction. As 
I mentioned above, I think it would be short-sighted to close the door 
to using other protocols in the future. I suggest that we instead define 
clear behavior if the client does not understand the URI scheme (e.g., 
it is treated the same as if there were no URI present). What would be 
really nice would be adding an attribute to the "requestPolicyUri" 
element that indicated the preferred URI scheme. For example:

<requestPolicyUri scheme="https"/>

(The same comments apply to section 4.2, minus the bit about 
requestPolicyUri).

/a

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Apr 2011 09:11:34 +0800

Thanks for the input Adam,

I agree on the generalization.

On 2011-04-29 at 07:58:31, Adam Roach wrote:
> operations, but without mentioning the use of etags. 

Updating the examples is good, maybe even pointing out that conditional requests are the safest way to update resources.  In practice there is probably only one client updating the resource, so I expect that anything more than this would be overkill.

> scheme...'  I suspect that one of those should be "https," but the 
> more relevant comment here is that this seems an unnecessary 
> restriction. As I mentioned above, I think it would be short-sighted 
> to close the door to using other protocols in the future. I suggest 
> that we instead define clear behavior if the client does not 
> understand the URI scheme (e.g., it is treated the same as if there 
> were no URI present). What would be really nice would be adding an 
> attribute to the "requestPolicyUri"

This is the right idea, but I don't think that a request parameter is going to help.  It would be unlikely that a server is able to support a new policy URI scheme because a client asks for that scheme.  Instead, we can simply suggest that the server provide a policy URI for every scheme that it supports.  The client can then pick the one that suits it best.

Note that for DHCP, this implies the need for some changes to draft-ietf-geopriv-lbyr-uri-option.  I'll have to follow up on that separately.

--Martin

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Apr 2011 21:47:28 -0500

On 4/28/11 8:11 PM, Thomson, Martin wrote:
>
>> What would be really nice would be adding an

Yep, that works too.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Apr 2011 23:56:11 -0500

> This is the right idea, but I don't think that a request parameter is going to help.  It would be unlikely that a server is able to support a new policy URI scheme because a client asks for that sc…

After thinking about this a bit, there is a possibility that the server 
is having to allocate specific resources on a per-protocol basis, in 
which case you'd want the ability for the client to hint at a preferred 
protocol (so as to avoid unnecessary allocation of resources for 
unwanted protocols).

But I don't really have a strong opinion on the issue -- it's just 
another point worth considering.

/a

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Apr 2011 13:07:14 +0800

On 2011-04-29 at 14:56:11, Adam Roach wrote:
> > This is the right idea, but I don't think that a request parameter 
> > is
> going to help.  It would be unlikely that a server is able to support 
> a new policy URI scheme because a client asks for that scheme.  
> Instead, we can simply suggest that the server provide a policy URI 
> for every scheme that it supports.  The client can then pick the one 
> that suits it best.
> 
> After thinking about this a bit, there is a possibility that the 
> server is having to allocate specific resources on a per-protocol 
> basis, in which case you'd want the ability for the client to hint at 
> a preferred protocol (so as to avoid unnecessary allocation of 
> resources for unwanted protocols).

I'm inclined to classify this as an optimization.  So three reasons not to add the parameter:
 1. laziness
 2. it's probably not too much extra load to create a resource for most types of resources, especially if you optimize for the case where the resource isn't accessed
 3. DHCP won't have any hinting

If another editor manages to overcome #1, then I'm OK with having the hint.

--Martin

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Apr 2011 08:08:49 -0500

>   3. DHCP won't have any hinting

Fair enough.

/a