Carrying Location Objects in RADIUS and Diameter
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, geopriv mailing list <email@example.com>, geopriv chair <firstname.lastname@example.org> Subject: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard The IESG has approved the following document: - 'Carrying Location Objects in RADIUS and Diameter ' <draft-ietf-geopriv-radius-lo-24.txt> as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-24.txt
Technical Summary This document specifies RADIUS attributes for conveying access network location information, in both civic and geospatial location formats, along with access network ownership. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed throughout, for various scenarios of location information function within AAA. WG Summary The WG reached solid consensus to advance this document after a number of iterations. The WG had initial hesitation about taking on the work, because the RFC 4119 pidf_lo object could not be used within RADIUS attribute size constraints. The WG concerns were met with an eventual functional compromise, providing a mandated attribute with the pidf_lo policy markers, and opaque attributes pointing to the geopriv location formats developed for DHCP which had constraints similar to RADIUS. This document is a Critical Requirement for 3GPP. Both the GSM Association and the ITU have specified Operator Namespace Tokens for use in this protocol. (The document has customers). Document Quality The protocol was reviewed in depth by both the GEOPRIV and RADEXT Working Groups. RADEXT's formal issues list was cleared. GEOPRIV and RADEXT had some overlapping issues, especially location information design, and scenario evaluation. The conclusion that location- aware AAA systems need to be able to implement the formats and processing found in the GEOPRIV documents was very useful, because it meant that GEOPRIV did not have to intercept or anticipate any enhancements of the RADIUS data model. The document is especially careful in projecting GEOPRIV's paranoia towards exposing location information. Section 8.3 contains a detailed review against the previously defined requirements related to this, and the Security Considerations details the use of security services RADIUS provides as the using protocol to meet requirements.