Skip to main content

Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-07

Discuss


Yes

(Robert Sparks)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stephen Farrell)
(Stewart Bryant)
(Wesley Eddy)

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

Jari Arkko Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2011-12-15) Unknown
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 Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2011-12-13) Unknown
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.)
Peter Saint-Andre Former IESG member
No Objection
No Objection (2011-12-13) Unknown
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).
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2011-12-15) Unknown
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.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2012-09-20 for -05) Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown