draft-ietf-geopriv-dhcp-lbyr-uri-option-02.txt		draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt
	Geopriv WG James Polk		Geopriv WG James Polk
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: Dec 17, 2008 June 17, 2008		Intended status: Standards Track (PS) Nov 3, 2008
	Intended status: Standards Track (PS)		Expires: May 3, 2009
	Dynamic Host Configuration Protocol (DHCP) Option for a		Dynamic Host Configuration Protocol (DHCP) Option for a
	Location Uniform Resource Identifier (URI)		Location Uniform Resource Identifier (URI)
	draft-ietf-geopriv-dhcp-lbyr-uri-option-02		draft-ietf-geopriv-dhcp-lbyr-uri-option-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on Dec 17, 2008.		This Internet-Draft will expire on May 3, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document creates a Dynamic Host Configuration Protocol (DHCP)		This document creates a Dynamic Host Configuration Protocol (DHCP)
	Option for the Location Uniform Resource Identifier (URI) of an		Option for the downloading of a Uniform Resource Identifier (URI)
	endpoint. For example, an endpoint can be a Session Initiation		pointing to the geolocation record of an endpoint. This URI, called
	Protocol (SIP) User Agent (i.e., a phone). This Location-URI can be		a Location-by-Reference (LbyR), points to a record on a location
	included in a UA's signaling messages to inform other nodes of that		server which tracks the geolocation of the endpoint. Once
	entity's geographic location, once the URI is dereferenced by a		downloaded by an endpoint, this LbyR can be forwarded to another
	Location Recipient.		entity, to be dereferenced if this entity wants to learn the
			geolocation of the sender endpoint.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4		2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4
	2.1. Elements of the Location Configuration Information . . 5		2.1. Elements of the Location Configuration Information . . 5
	3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5		3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5
	3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7		3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7
	3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7		3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7
	3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7		3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . 10		Intellectual Property and Copyright Statements . . . . . . . . . 11
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	This document creates a Dynamic Host Configuration Protocol (DHCP)		This document creates a Dynamic Host Configuration Protocol (DHCP)
	Option for delivery of a client's Location Uniform Resource		Option for the downloading of a Uniform Resource Identifier (URI)
	Identifier (URI). For example, a client can be a Session Initiation		pointing to the geolocation record of an endpoint. A client, for
	Protocol (SIP) User Agent (UA) [RFC3261] (i.e., a Phone). This		example, can be a Session Initiation Protocol (SIP) User Agent (UA)
	Location-URI can be included in a UA's signaling messages		[RFC3261] (i.e., a Phone). This URI, called a
	[ID-SIP-LOC] to inform remote devices (i.e., other phones or servers		Location-by-Reference (LbyR), points to a record on a location
	or applications) of that UA's geographic location. This is an		server [ID-LBYR-REQ] which tracks the geolocation of the endpoint
	indirect means of passing a Location Target's location to another		(through means not defined in this document). The LbyR record
	entity, called a dereference (of a URI). In other words, if an		stores the Geolocation of a Location Target. Once downloaded by an
	entity has the Location URI, it can access the location record at		endpoint (the target in this case), this LbyR can be forwarded to
	the server the URI points to, if the requestor has permission to		another entity, using SIP as defined in [ID-SIP-LOC], to be
	access it there. Where the location record is will likely be an		dereferenced if this second entity wants to learn the geolocation of
	entity called a Location Information Server (LIS) [ID-LBYR-REQ],		the Location Target.
	which stores the locations of many Location Targets, which has the
	ability to challenge each dereference request by whatever means it
	is capable of, thus providing additive security properties to
	location revelation.
	A Location Recipient is a device that has received location from		The act of dereferencing location is explained in [ID-SIP-CON],
	another entity. If this location is delivered by a URI, the URI has		which demonstrates how a possessor of a LbyR subscribes to a
	to be dereferenced by the Location Recipient to learn the remote		Location Server to attain the location of the Target. If the
	device's geographic location. Dereferencing can be done in SIP by		dereferencer has permission, defined in [ID-GEO-POL], the location
	use of the SUBSCRIBE/NOTIFY Methods [RFC3265] to either a sip:,		of the target will be returned to the Location Seeker. The Location
	sips: or pres: scheme URI. Each of these URI schemes are IANA		Server will grant permission to location inquires based on the rules
	registered in Section 5 of this document as valid for use by this		established by a Rule Holder [RFC3693]. Therefore, the Location
			Server has the ability to challenge any location seeker's request,
			thus providing additive security properties to location revelation.
	Option.		Option.
	Endpoints will require their geographic location for a growing		Endpoints will require their geographic location for a growing
	number of services. A popular use-case currently is for emergency		number of services. A popular use-case currently is for emergency
	services, in which SIP requires its location to be placed in a SIP		services, in which SIP requires its location to be placed in a SIP
	INVITE request [ID-SIP-LOC] towards a public safety answering point		INVITE request [ID-SIP-LOC] towards a public safety answering point
	(PSAP), i.e., an emergency response center. The reason for this is		(PSAP), i.e., an emergency response center. The reason for this is
	twofold:		twofold:
	o An emergency services SIP request must be routed/retargeted to the		o An emergency services SIP request must be routed/retargeted to the
	skipping to change at page 5, line 16		skipping to change at page 5, line 16
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code XXX | Option Length | Valid-For |		| Code XXX | Option Length | Valid-For |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Location-URI |		| Location-URI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ .... \		/ .... \
	\ .... /		\ .... /
			/ .... \
			\ .... /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Location-URI (cont'd) +		| Location-URI (cont'd) +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.1. Elements of the Location Configuration Information		2.1. Elements of the Location Configuration Information
	Code XXX: The code for this DHCP option.		Code XXX: The code for this DHCP option.
	Option Length: The length of this option variable.		Option Length: The length of this option variable.
	skipping to change at page 6, line 25		skipping to change at page 6, line 26
	example, Location URIs such as		example, Location URIs such as
	sips:34LKJH534663J54@example.com		sips:34LKJH534663J54@example.com
	should be done, providing no identity information, rather than a		should be done, providing no identity information, rather than a
	Location-URI such as this		Location-URI such as this
	sips:aliceisinatlanta@example.com		sips:aliceisinatlanta@example.com
	This Option is for only communications between a DHCP client and a		This Option is for only communications between a DHCP client and a
	DHCP server. It may be solicited (requested) by the client, or it		DHCP server. It can be solicited (requested) by the client, or it
	may be pushed by the server without a request for it. DHCP Options		can be pushed by the server without a request for it. DHCP Options
	not understood are ignored. A DHCP server might or might not have		not understood are ignored. A DHCP server might or might not have
	the location of a client, therefore direct knowledge of a		the location of a client, therefore direct knowledge of a
	Location-URI within the server. If a server does not have a		Location-URI within the server. If a server does not have a
	client's location, a communication path (or request) to a LIS would		client's location, a communication path (or request) to a LIS would
	be necessary.		be necessary.
	The LIS function, which is logical, is what creates the URI. The		The LIS function, which is logical, is what creates the LbyR. The
	coordination between the logical entity of a DHCP server and the		coordination between the logical entity of a DHCP server and the
	logical entity of a LIS as to which circuit-ID gets which		logical entity of a LIS as to which circuit-ID gets which
	Location-URI is not done via DHCP, therefore it is not defined		Location-URI is not done via DHCP, therefore it is not defined
	here. Further, any location revelation rules and policies a user		here. Further, any location revelation rules and policies a user
	has regarding the treatment of their actual location, and who can		has regarding the treatment of their actual location, and who can
	access (what precision of) their location will be done with other		access (what precision of) their location will be done with other
	than DHCP, and likely will be done before anything other than		than DHCP, and likely will be done before anything other than
	default authentication and authorization permissions are used when a		default authentication and authorization permissions are used when a
	Location Seeker, as defined in RFC 3693, requests a for a Target's		Location Seeker, as defined in RFC 3693, requests a for a Target's
	location.		location.
			Differentiating clients is done via client identifiers. Therefore,
			in many implementations, each client can be assigned unique LbyRs,
			though this is not mandatory.
	Any dereferencing of a client's Location-URI would not involve DHCP		Any dereferencing of a client's Location-URI would not involve DHCP
	either, but more likely by an application layer protocol such as		either, but more likely by an application layer protocol such as
	SIP, through a subscription to the Location-URI on the LIS. The LIS		SIP, through a subscription to the Location-URI on the LIS. The LIS
	would also handle all authentication and authorization of location		would also handle all authentication and authorization of location
	requests, which is also not performed with DHCP, therefore not		requests, which is also not performed with DHCP, therefore not
	defined here.		defined here.
	In the case of residential gateways being DHCP servers, they usually		In the case of residential gateways being DHCP servers, they usually
	perform as DHCP clients in a hierarchical fashion up into a service		perform as DHCP clients in a hierarchical fashion up into a service
	provider's network DHCP server(s), or learn what information to		provider's network DHCP server(s), or learn what information to
	skipping to change at page 10, line 22		skipping to change at page 10, line 25
	[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific		[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
	Event Notification", RFC 3265, June 2002.		Event Notification", RFC 3265, June 2002.
	[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic		[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
	Host Configuration Protocol (DHCPv4)", RFC 3396, November		Host Configuration Protocol (DHCPv4)", RFC 3396, November
	2002		2002
	7.2. Informative References		7.2. Informative References
	[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance",		[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance",
	draft-ietf-sip-location-conveyance-10.txt, "work in		draft-ietf-sip-location-conveyance-11.txt, "work in
	[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host		[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
	Configuration Protocol Option for Coordinate-based Location		Configuration Protocol Option for Coordinate-based Location
	[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol		[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
	(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration		(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
	Information ", RFC 4776, November 2006		Information ", RFC 4776, November 2006
	[ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference		[ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference
	Mechanism", draft-ietf-geopriv-lbyr-requirements-02.txt,		Mechanism", draft-ietf-geopriv-lbyr-requirements-04.txt,
	"work in progress", Feb 08		"work in progress", Nov 08
	[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,		[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
	"Geopriv Requirements", RFC 3693, February 2004		"Geopriv Requirements", RFC 3693, February 2004
			[ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.
			Polk, "Geolocation Policy: A Document Format for Expressing
			Privacy Preferences for Location Information", "work in
	Authors' Address		Authors' Address
	James Polk		James Polk
	3913 Treemont Circle		3913 Treemont Circle
	Colleyville, Texas 76034		Colleyville, Texas 76034
	USA		USA
	EMail: jmpolk@cisco.com		EMail: jmpolk@cisco.com
	Full Copyright Statement		Full Copyright Statement
End of changes. 14 change blocks.
	40 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/