< draft-ietf-geopriv-policy-21.txt		draft-ietf-geopriv-policy-22.txt >
	GEOPRIV H. Schulzrinne, Ed.		GEOPRIV H. Schulzrinne, Ed.
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track H. Tschofenig, Ed.		Intended status: Standards Track H. Tschofenig, Ed.
	Expires: January 13, 2010 Nokia Siemens Networks		Expires: April 27, 2011 Nokia Siemens Networks
	J. Morris		J. Morris
	CDT		CDT
	J. Cuellar		J. Cuellar
	Siemens		Siemens
	J. Polk		J. Polk
	Cisco		Cisco
	July 12, 2009		October 24, 2010
	Geolocation Policy: A Document Format for Expressing Privacy Preferences		Geolocation Policy: A Document Format for Expressing Privacy Preferences
	for Location Information		for Location Information
	draft-ietf-geopriv-policy-21.txt		draft-ietf-geopriv-policy-22.txt
			Abstract
			This document defines an authorization policy language for
			controlling access to location information. It extends the Common
			Policy authorization framework to provide location-specific access
			control. More specifically, this document defines condition elements
			specific to location information in order to restrict access based on
			the current location of the Target. Furthermore, it offers location-
			specific transformation elements to reduce the granularity of the
			returned location information.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on April 27, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 13, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document defines an authorization policy language for		described in the Simplified BSD License.
	controlling access to location information. It extends the Common
	Policy authorization framework to provide location-specific access
	control. More specifically, this document defines condition elements
	specific to location information in order to restrict access based on
	the current location of the Target. Furthermore, it offers location-
	specific transformation elements to reduce the granularity of the
	returned location information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 9		3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Structure of Geolocation Authorization Documents . . . . . 9		3.1. Structure of Geolocation Authorization Documents . . . . . 8
	3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 9		3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 8
	4. Location-specific Conditions . . . . . . . . . . . . . . . . . 10		4. Location-specific Conditions . . . . . . . . . . . . . . . . . 9
	4.1. Geodetic Location Condition Profile . . . . . . . . . . . 10		4.1. Geodetic Location Condition Profile . . . . . . . . . . . 9
	4.2. Civic Location Condition Profile . . . . . . . . . . . . . 11		4.2. Civic Location Condition Profile . . . . . . . . . . . . . 10
	5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 13		6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 13		6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 12
	6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 13		6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 12
	6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 13		6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 12
	6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 14		6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13
	6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 14		6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13
	6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 15		6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14
	6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 16		6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.1. Rule Example with Civic Location Condition . . . . . . . . 18		7.1. Rule Example with Civic Location Condition . . . . . . . . 18
	7.2. Rule Example with Geodetic Location Condition . . . . . . 19		7.2. Rule Example with Geodetic Location Condition . . . . . . 19
	7.3. Rule Example with Civic and Geodetic Location Condition . 19		7.3. Rule Example with Civic and Geodetic Location Condition . 19
	7.4. Rule Example with Location-based Transformations . . . . . 20		7.4. Rule Example with Location-based Transformations . . . . . 20
	8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 22		7.5. Location Obfuscation Example . . . . . . . . . . . . . . . 22
	9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 23		8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 26
	10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25		9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 27
	10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 25		10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 25		10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 29
	10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 25		10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 25		10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 29
	10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 25		10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 25		10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 29
	10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 25		10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 29
	10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26		10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 29
	10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 26		10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 30
			10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 30
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	11.1. Geolocation Policy XML Schema Registration . . . . . . . . 27		11.1. Geolocation Policy XML Schema Registration . . . . . . . . 31
	11.2. Geolocation Policy Namespace Registration . . . . . . . . 27		11.2. Geolocation Policy Namespace Registration . . . . . . . . 31
	11.3. Geolocation Policy Location Profile Registry . . . . . . . 28		11.3. Geolocation Policy Location Profile Registry . . . . . . . 32
	11.4. Basic Location Profile XML Schema Registration . . . . . . 28		11.4. Basic Location Profile XML Schema Registration . . . . . . 32
	11.5. Basic Location Profile Namespace Registration . . . . . . 29		11.5. Basic Location Profile Namespace Registration . . . . . . 33
	11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 29		11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 33
	12. Internationalization Considerations . . . . . . . . . . . . . 31		12. Internationalization Considerations . . . . . . . . . . . . . 35
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 32		13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 34		14.1. Normative References . . . . . . . . . . . . . . . . . . . 38
	14.2. Informative References . . . . . . . . . . . . . . . . . . 34		14.2. Informative References . . . . . . . . . . . . . . . . . . 38
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	Location information needs to be protected against unauthorized		Location information needs to be protected against unauthorized
	access to preserve the privacy of humans. In RFC 3693 [RFC3693], a		access to preserve the privacy of humans. In RFC 3693 [RFC3693], a
	protocol-independent model for access to geographic information is		protocol-independent model for access to geographic information is
	defined. The model includes a Location Generator (LG) that		defined. The model includes a Location Generator (LG) that
	determines location information, a Location Server (LS) that		determines location information, a Location Server (LS) that
	authorizes access to location information, a Location Recipient (LR)		authorizes access to location information, a Location Recipient (LR)
	that requests and receives location information, and a Rule Maker		that requests and receives location information, and a Rule Maker
	skipping to change at page 16, line 49 ¶		skipping to change at page 15, line 49 ¶
	This profile uses the token 'geodetic-transformation' and refers only		This profile uses the token 'geodetic-transformation' and refers only
	to the Coordinate Reference System (CRS) WGS 84		to the Coordinate Reference System (CRS) WGS 84
	(urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic		(urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic
	location transformations to be specified by means of the <provide-		location transformations to be specified by means of the <provide-
	geo> element that may restrict the returned geodetic location		geo> element that may restrict the returned geodetic location
	information based on the value provided in the 'radius' attribute.		information based on the value provided in the 'radius' attribute.
	The value of the 'radius' attribute expresses the radius in meters.		The value of the 'radius' attribute expresses the radius in meters.
	The schema of the <provide-geo> element is defined in Section 8.		The schema of the <provide-geo> element is defined in Section 8.
	For each rule in the policy specification containing a <provide-geo>		The algorithm proceeds in 6 steps. The first two steps are
	element, the LS chooses a circle with a radius F given by the		independent of the measured position to be obscured. Those two steps
	'radius' attribute of the <provide-geo> element. The center of the		should be run only once or rather seldom (for every region and
	circle is chosen randomly, under the constraint that the circle MUST		desired uncertainty). The steps are:
	contain the Target's location, which may be a point or another
	location shape. In response to queries matching this rule, the LS
	MUST return a shape containing this circle; while the returned shape
	may change from one query to another, the chosen circle remains
	constant as long as the Target's location (whether a point or a
	region) remains completely within the circle. An LS may, for
	example, store the location of the center or compute it based on a
	hash function that includes the target's identity. If the Target's
	location moves within the chosen circle, the LS MAY choose a new
	random center point, but when the Target's location moves outside the
	chosen circle, the LS SHOULD choose a new random center point.
	The above-described procedure aims to satisfy the following design		1. Choose a geodesic projection with Cartesian coordinates and a
	goals:		surface you want to cover. The maximal distortion of the map may
			not be too much (see notes below).
	1. The circle returned must contain the actual location of the		2. Given uncertainty "d", choose a grid of so called "landmarks" at
	Target.		a distance (maximal) d of each other.
	2. In general, no point in the circle must be more likely than		3. Given a measured location M=(m,n) in the surface, calculate its 4
	others to contain the Target.		closest landmarks on the grid, with coordinates: SE=(b,l),
			SW=(b,r), NE=(t,l), NW=(t,r). Thus l<=m<r and b<=n<t. See notes
			below.
	3. Repeated queries must not reveal the likely location of the		4. Let x=(m-l)/(r-l) and y=(n-b)/(t-b)
	Target.
			x and y are thus the local coordinates of the point M in the
			small grid square that contains it. 0<=x,y<1.
			5. Let P = 0.2887 (=sqrt(3)/6) and q = 0.7113 (=1-p), determine
			which of the following 8 cases holds:
			C1. x < p and y < p
			C2. p <= x < q and y < x and y < 1-x
			C3. q <= x and y < p
			C4. p <= y < q and x <= y and y < 1-x
			C5. p <= y < q and y < x and 1-x <= y
			C6. x < p and q <= y
			C7. p <= x < q and x <= y and 1-x <= y
			C8. q <= x and q <= y
			6. Depending on the case, let C (=Center) be
			C1: SW
			C2: SW or SE
			C3: SE
			C4: SW or NW
			C5: SE or NE
			C6: NW
			C7: NW or NE
			C8: NE
			Return the circle with center C and radius d.
			Notes:
			Regarding Step 1:
			The scale of a map is the ratio of a distance on (a straight line)
			on the map to the corresponding air distance on the ground. For
			maps covering larger areas, a map projection from a sphere (or
			ellipsoid) to the plane will introduce distortion and the scale of
			the map is not constant. Also, note that the real distance on the
			ground is taken along great circles, which may not correspond to
			straight lines in the map, depending on the projection used. Let
			us measure the (length) distortion of the map as the quotient
			between the maximal and the minimal scales in the map. The
			distortion MUST be below 1.5. (The minimum distortion is 1.0: If
			the region of the map is small, then the scale may be taken as a
			constant over the whole map).
			Regarding Step3:
			SW is mnemonic for south-west, b for bottom, l for left
			(SW=(l,b)), etc, but the directions of the geodesic projection may
			be arbitrary, and thus SW may be not south-west of M but it will
			be left and below M *on the map*.
	7. Examples		7. Examples
	This section provides a few examples for authorization rules using		This section provides a few examples for authorization rules using
	the extensions defined in this document.		the extensions defined in this document.
	7.1. Rule Example with Civic Location Condition		7.1. Rule Example with Civic Location Condition
	This example illustrates a single rule that employs the civic		This example illustrates a single rule that employs the civic
	location condition. It matches if the current location of the Target		location condition. It matches if the current location of the Target
	skipping to change at page 22, line 5 ¶		skipping to change at page 22, line 5 ¶
	<rule id="AA56ia9">		<rule id="AA56ia9">
	<conditions/>		<conditions/>
	<actions/>		<actions/>
	<transformations>		<transformations>
	<gp:provide-location/>		<gp:provide-location/>
	</transformations>		</transformations>
	</rule>		</rule>
	</ruleset>		</ruleset>
			7.5. Location Obfuscation Example
			Suppose you want a to obscure positions in the continental USA.
			Step 1:
			First you choose a geodesic projection. If you are measuring
			location as latitude and longitude, a natural choice is to take a
			rectangular projection. One latitudinal degree corresponds
			approximately to 110.6 kilometers, while a good approximation of a
			longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where
			pi is approximately 3.1415, and M is the Earth's average
			meridional radius, approximately 6,367.5 km. For instance, one
			longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km,
			while the formula given offers an estimation of 96.24, which is
			good for our purposes.
			We will set up a grid not only for the continental US, but for the
			whole earth between latitudes 25 and 50 degrees, and thus will
			cover also the Mediterranean, South Europe, Japan and the north of
			China. As will be seen below, the grid distortion (for not too
			large grids in this region) is approx cos(25)/cos(50), which is
			1.4099.
			As origin of our grid, we choose the point at latitude 25 degrees
			and longitude 0 (Greenwich). The latitude 25 degrees is chosen to
			be just south of Florida and thus south of the continental US.
			(On the south hemisphere the origin should be north of the region
			to be covered; if the region crosses the Equator, the origin
			should be on the Equator. In his way it is guaranteed that the
			latitudinal degree has largest distance at the latitude of the
			origin).
			At 25 degrees one degree in east-west direction corresponds approx
			to (pi/180)*M*cos(25) = 100.72 km.
			The same procedure, basically, produces grids for
			* 45 degrees south to 45 degrees north Tropics and subtropics
			* 25 to 50 degrees (both north or south) Continental US
			* 35 to 55 degrees (both north or south) South and Central Europe
			* 45 to 60 degrees (both north or south) Central and North Europe
			* 55 to 65 degrees (both north or south) Scandinavia
			* 60 to 70 degrees (both north or south)
			Since we do not want to often change grid system (this would leak
			more information about obscured locations when they are repeatedly
			visited), the algorithm should prefer to use the grids discussed
			above, with origin at the Greenwich meridian and at latitudes o=0,
			o=25, o=35, o=45, 0=55, and o=60 degrees (north) or at latitudes
			o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the minus to
			indicate "south").
			Our choice for the continental USA is o=25.
			For locations close to the poles, a different projection should be
			used (not discussed here).
			Step 2:
			To construct the grid points, we start with our chosen origin and
			place the along the main axes (NS and EW) grid points at a
			distance d of each other.
			We will now construct a grid for a desired uncertainty of d =
			100km. At our origin, 100 km correspond roughly to d1 = 100/
			100.72 = 0.993 degrees on east-west direction and to d2 = 100/
			110.6 = 0.904 degrees in north-south direction.
			The (i,j)-point in the grid (i and j are integers) has longitude
			d1*i and latitude 25+d2*j, measured in degrees. More generally,
			if the grid has origin at coordinates (0,o), measured in degrees,
			the (i,j)-point in the grid has coordinates (longitude = d1*i,
			latitude = o+d2*j). The grid has almost no distorsion at the
			latitude of the origin, but it has as we go further away from it.
			The distance between two points in the grid at 25 degrees latitude
			is indeed approx 100 km, but just above the Canadian border, on
			the 50th degree, it is 0.993*(pi/180)*M*cos(50) = 70.92km. Thus,
			the grid distortion is 100/70.92 = 1.41, which is acceptable
			(<1.5). (On north-south direction the grid has roughly no
			distortion, the vertical distance between two neighboring grid
			points is approximately 100 km).
			Step 3:
			Now suppose you measure a position at M, with longitude -105 (the
			minus sign is used to denote 105 degrees *west*; without minus,
			the point is in China, 105 degrees east) and latitude 40 degrees
			(just north of Denver, CO). The point M is 105 degrees west and
			15 degrees north of our origin (which has longitude 0 and latitude
			25).
			Let "floor" be the function that returns the largest integer
			smaller or equal to a floating point number. To calculate SW, the
			closest point of the grid on the south-west of M=(m,n), we
			calculate
			i= floor(m/d1) = floor(-105/0.993) = -106
			j= floor(n-o/d2) = floor(15/0.904) = 16
			Those are the indexes of SW on the grid. The coordinates of SW
			are then: (d1*i, 25+d2*j) = (-105.242, 39.467).
			Thus:
			l=d1*floor(m/d1) = -105.243
			r=l+d1 = -105.243+0.993 = -104.250
			b=o+d2*floor(n-o/d2) = 39.467
			t=b+d2 = 39.467+0.904 = 40.371
			These are the formulas for l,r,b, and t in the general case of
			Cartesian projections based on latitude and longitude.
			Step 4:
			Calculate x and y, the local coordinates of the point M in the
			small grid square that contains it. This is easy:
			x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245
			y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590
			Step 5:
			First compare x with p (0.2887) and (0.7113). x is smaller than p.
			Therefore, only cases 1,4 or 6 could hold.
			Also compare y with p (0.2887) and (0.7113). y is between them: p
			<= y < q. Thus, we must be in case 4. To check, compare y (0.59)
			with x (0.245) and 1-x. y is larger than x and smaller than 1-x.
			We are in case C4 (p <= y < q and x <= y and y < 1-x).
			Step 6:
			Now we choose either SW or NW as the center of the circle.
			The obscured location is the Circle with radius 100 km and center
			in SW (coordinates: -105.243, 39.467), or NW (coordinates:
			-105.243, 40.371).
	8. XML Schema for Basic Location Profiles		8. XML Schema for Basic Location Profiles
	This section defines the location profiles used as child elements of		This section defines the location profiles used as child elements of
	the transformation element.		the transformation element.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:basic-location-profiles"		targetNamespace="urn:ietf:params:xml:ns:basic-location-profiles"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	skipping to change at page 34, line 48 ¶		skipping to change at page 38, line 48 ¶
	[I-D.thomson-geopriv-geo-shape]		[I-D.thomson-geopriv-geo-shape]
	Thomson, M., "Geodetic Shapes for the Representation of		Thomson, M., "Geodetic Shapes for the Representation of
	Uncertainty in PIDF-LO",		Uncertainty in PIDF-LO",
	draft-thomson-geopriv-geo-shape-03 (work in progress),		draft-thomson-geopriv-geo-shape-03 (work in progress),
	December 2006.		December 2006.
	[I-D.thomson-geopriv-uncertainty]		[I-D.thomson-geopriv-uncertainty]
	Thomson, M. and J. Winterbottom, "Representation of		Thomson, M. and J. Winterbottom, "Representation of
	Uncertainty and Confidence in PIDF-LO",		Uncertainty and Confidence in PIDF-LO",
	draft-thomson-geopriv-uncertainty-03 (work in progress),		draft-thomson-geopriv-uncertainty-05 (work in progress),
	June 2009.		May 2010.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for		[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
	Presence and Instant Messaging", RFC 2778, February 2000.		Presence and Instant Messaging", RFC 2778, February 2000.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	skipping to change at page 36, line 31 ¶		skipping to change at page 40, line 31 ¶
	detailed review in November 2006. Richard Barnes gave a detailed		detailed review in November 2006. Richard Barnes gave a detailed
	review in February 2008.		review in February 2008.
	This document uses text from [I-D.thomson-geopriv-geo-shape].		This document uses text from [I-D.thomson-geopriv-geo-shape].
	Therefore, we would like to thank Martin Thomson for his work in		Therefore, we would like to thank Martin Thomson for his work in
	[I-D.thomson-geopriv-geo-shape]. We would also like to thank Martin		[I-D.thomson-geopriv-geo-shape]. We would also like to thank Martin
	Thomson, Matt Lepinski and Richard Barnes for their comments		Thomson, Matt Lepinski and Richard Barnes for their comments
	regarding the geodetic location transformation procedure. Richard		regarding the geodetic location transformation procedure. Richard
	provided us with a detailed text proposal.		provided us with a detailed text proposal.
			Robert Sparks, Martin Thomson, and Warren Kumari deserve thanks for
			their input on the location obfuscation discussion. Robert
			implemented various versions of the algorithm in the graphical
			language "Processing" and thereby helped us tremendously to
			understand problems with the previously illustrated algorithm.
	We would like to thank Dan Romascanu, Yoshiko Chong and Jari		We would like to thank Dan Romascanu, Yoshiko Chong and Jari
	Urpalainen for their last call comments.		Urpalainen for their last call comments.
	Finally, we would like to thank the following individuals for their		Finally, we would like to thank the following individuals for their
	feedback as part of the IESG, GenArt, and SecDir review: Jari Arkko,		feedback as part of the IESG, GenArt, and SecDir review: Jari Arkko,
	Eric Gray, Russ Housley, Carl Reed, Martin Thomson, Lisa Dusseault,		Eric Gray, Russ Housley, Carl Reed, Martin Thomson, Lisa Dusseault,
	Chris Newman, Jon Peterson, Sam Hartman, Cullen Jennings, Tim Polk,		Chris Newman, Jon Peterson, Sam Hartman, Cullen Jennings, Tim Polk,
	and Brian Rosen.		and Brian Rosen.
	Authors' Addresses		Authors' Addresses
End of changes. 18 change blocks.
	99 lines changed or deleted		300 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/