Location Configuration Extensions for Policy Management
RFC 7199

Note: This ballot was opened for revision 04 and is now closed.

(Jari Arkko) Discuss

Discuss (2011-12-15 for -** No value found for 'p.get_dochistory.rev' **)
I will probably clear this after some discussion in the IESG tonight, and let Stephen hold his Discuss (item #5 in particular).

However, I am concerned that the document provides an authorization-by-possession model for clients to access their policies, delivers the policy URLs in the same DHCP and XML structures as other location URLs, and also acknowledges that there is a legitimate need for other entities to access policies:

   This document does not describe
   how policy might be provided to entities other than for location
   configuration, for example, in responses to dereferencing requests
   [I-D.ietf-geopriv-deref-protocol] or requests from third parties
   [RFC6155].

I predict that policy URLs will be leaked, intentionally, to those who need them, and that this will lead to security issues down the road. Is there something that we could do about this?

(Robert Sparks) (was Discuss, Yes) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2011-12-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please consider the review of Tobias Gondrom <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03926.html>. I will defer to the expertise of the Security ADs to consider whether the issues he points out are worthy of DISCUSSion, but I have not seen a public reply to his message.

[Updated to add:]
I note from the writeup that there are no implementations of this. I also note that geopriv-policy is given as an example of what might be used as a policy document in addition to the others. Is my suspicion correct that, in fact, down the road geopriv-policy will be the *predominant* use of this URI? If so, is it not worth holding this document until that one is completed? I suspect it will end up a lot shorter if it could talk in terms of an actual GEOPRIV policy document and use the others only as examples. (I see no need to hold a DISCUSS position on this, as I think there is no harm in publishing this first, but I would like to hear from the authors/chair/WG as to what the reasoning was.)

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-12-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I concur with the DISCUSS position of Stephen Farrell.

Why does this specification use the term "Internet host" instead of the term "Target" from RFC 3693? Consistency across this suite of documents would be good.

It would be helpful to cite RFC 3693 and RFC 5808 in Section 2.

In Section 4.1, the schema references "urn:ietf:params:xml:ns:geopriv:held:policy" but that namespace is never used in the schema definition.

In the examples, it would be helpful to point to the specifications that define the various data structures (i.e., the "urn:ietf:params:xml:ns:geopriv:held", "urn:ietf:params:xml:ns:common-policy", and "urn:ietf:params:xml:ns:geolocation-policy" namespaces).

The second block of XML in Section 5.3 never defines the gp: prefix (i.e., you need to add xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy" to the root <ruleset/> element).

(Sean Turner) No Objection

Comment (2011-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I'm with Stephen and Jari on this one and definitely support Stephen's discuss.  This really feels like security through obscurity, but if I let you see mine then you can be me for while.