draft-ietf-geopriv-dhcp-lbyr-uri-option-13.txt		draft-ietf-geopriv-dhcp-lbyr-uri-option-14.txt
	Network WG James Polk		Network WG James Polk
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Proposed Standard Mar 10, 2012		Intended status: Proposed Standard Mar 12, 2012
	Expires: Sept 10, 2012		Expires: Sept 12, 2012
	Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6		Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6
	Option for a Location Uniform Resource Identifier (URI)		Option for a Location Uniform Resource Identifier (URI)
	draft-ietf-geopriv-dhcp-lbyr-uri-option-13		draft-ietf-geopriv-dhcp-lbyr-uri-option-14
	Abstract		Abstract
	This document creates a Dynamic Host Configuration Protocol (DHCP)		This document creates a Dynamic Host Configuration Protocol (DHCP)
	Option for transmitting a client's geolocation Uniform Resource		Option for transmitting a client's geolocation Uniform Resource
	Identifier (URI). This Location URI can then be dereferenced in a		Identifier (URI). This Location URI can then be dereferenced in a
	separate transaction by the client or sent to another entity and		separate transaction by the client or sent to another entity and
	dereferenced to learn physically where the client is located.		dereferenced to learn physically where the client is located.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	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."
	This Internet-Draft will expire on September 10, 2012.		This Internet-Draft will expire on September 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4		2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4
	2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5		2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5
	2.3. LocationURI Format for both IPv4 and IPv6 . . . . . . . 5		2.3. LocationURI Format for both IPv4 and IPv6 . . . . . . . 5
	3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 6		3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 6
	3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8		3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8
	3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8		3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8
	3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9		3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	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)
	skipping to change at page 6, line 22		skipping to change at page 6, line 22
	the Location Target resides. The LuriValue of		the Location Target resides. The LuriValue of
	LuriType=1 is always represented in UTF-8.		LuriType=1 is always represented in UTF-8.
	LuriType=2 Valid-For - The time, in seconds, this URI is to be		LuriType=2 Valid-For - The time, in seconds, this URI is to be
	considered Valid for dereferencing. The timer		considered Valid for dereferencing. The timer
	associated with this LuriType starts upon receipt of		associated with this LuriType starts upon receipt of
	this Option by the client. The LuriValue of LuriType=2		this Option by the client. The LuriValue of LuriType=2
	is always represented as a four-byte unsigned integer.		is always represented as a four-byte unsigned integer.
	The Valid-For (LuriType=2) indicates how long, in seconds, the		The Valid-For (LuriType=2) indicates how long, in seconds, the
	client is to consider this location URI (LuriType=1) valid. The		client is to consider this location URI (LuriType=1) valid.
	choice of the Valid-For value is a policy decision for the operator		Applications MUST NOT make use of a location URI after it becomes
	of the DHCP server. Like location URIs themselves, it can be		invalid (i.e., after the Valid-For timer expires).
	statically configured on the DHCP server or provisioned dynamically
	(via an out-of-band exchange with a Location Information Server) as
	requests for location URIs are received.
	The Valid-For time is used only at the application layer, as an		The choice of the Valid-For value is a policy decision for the
			operator of the DHCP server. Like location URIs themselves, it can
			be statically configured on the DHCP server or provisioned
			dynamically (via an out-of-band exchange with a Location Information
			Server) as requests for location URIs are received.
			The Valid-For timer is used only at the application layer, as an
	indication of when the URI can be used to access location. It is		indication of when the URI can be used to access location. It is
	independent of the DHCP list time, and in no way related to the DHCP		independent of the DHCP lease timer, and in no way related to the
	state machine. Clients MUST NOT trigger an automatic DHCP refresh		DHCP state machine. Clients MUST NOT trigger an automatic DHCP
	on expiry of the Valid-For timer; rather, they should follow normal		refresh on expiry of the Valid-For timer; rather, they should follow
	DHCP mechanics.		normal DCHP mechanics.
			Server operators should consider the relation between the Valid-For
			time and the lease time. Clients typically request a lease refresh
			when half the lease time is up. If the Valid-For time is less than
			the typical refresh rate (i.e., half the lease time), then for the
			remaining interval, clients will run the risk of not having a usable
			location URI for applications. If the Valid-For time is less than
			half the typical refresh rate, it is a near certainty clients will
			not have a usable location URI for the interval between the
			Valid-For time and the typical refresh time for applications.
			For example, if a lease is set to 24 hours, the typical refresh
			request is set to initiate at the 12 hour mark. If the Valid-For
			timer is set to less than 24 hours, but more than 12 hours (in this
			example), the client might not be refreshed at the 12 hour mark and
			runs the risk of not have a location URI for applications that
			request it. If, on the other hand, the Valid-For timer is less than
			12 hours (in this example, which is before a typical client would
			ask for a refresh, applications will be without a usable location
			URI until the full refresh has been received.
			It should be expected that clients will overwrite any previous
			Option values when receiving a new instance of that Option number.
	The Valid-For (LuriType=2) offers no meaningful information without		The Valid-For (LuriType=2) offers no meaningful information without
	an accompanying Location URI (LuriType=1), therefore a Valid-For		an accompanying Location URI (LuriType=1), therefore a Valid-For
	(LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).		(LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
	The Valid-For (LuriType=2) is not mandated for use by this document.		The Valid-For (LuriType=2) is not mandated for use by this document.
	However, its presence MUST NOT cause any error in handling the		However, its presence MUST NOT cause any error in handling the
	location URI (i.e., if not understood, it MUST be ignored).		location URI (i.e., if not understood, it MUST be ignored).
	This Option format is highly extensible. Additional LuriType types		This Option format is highly extensible. Additional LuriType types
	skipping to change at page 12, line 37		skipping to change at page 13, line 11
	"Geopriv Requirements", RFC 3693, February 2004		"Geopriv Requirements", RFC 3693, February 2004
	[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
	Configuration Information", RFC 3825, July 2004		Configuration Information", RFC 3825, July 2004
	[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
	[RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of		[RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of
	'retransmission-allowed' for SIP Location Conveyance",		'retransmission-allowed' for SIP Location Conveyance",
	August 2009		August 2009
	[RFC5808] R. Marshall, "Requirements for a Location-by-Reference		[RFC5808] R. Marshall, "Requirements for a Location-by-Reference
	Mechanism", RFC 5808, May 2010		Mechanism", RFC 5808, May 2010
	[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.		[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
	Thomson, M. Dawson, "A Location Dereferencing Protocol Using		Thomson, M. Dawson, "A Location Dereferencing Protocol Using
	HELD", "work in progress", October 2011		HELD", "work in progress", October 2011
End of changes. 8 change blocks.
	18 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/