< draft-winterbottom-ecrit-priv-loc-01.txt		draft-winterbottom-ecrit-priv-loc-02.txt >
	ECRIT J. Winterbottom		ECRIT J. Winterbottom
	Internet-Draft CommScope		Internet-Draft CommScope
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: January 17, 2013 Nokia Siemens Networks		Expires: April 19, 2013 Nokia Siemens Networks
	L. Liess		L. Liess
	Deutsche Telekom		Deutsche Telekom
	July 16, 2012		October 16, 2012
	Out of Jurisdiction Emergency Routing		Out of Jurisdiction Emergency Routing
	draft-winterbottom-ecrit-priv-loc-01.txt		draft-winterbottom-ecrit-priv-loc-02.txt
	Abstract		Abstract
	Some countries and regions require location information be		Some countries and regions require location information be
	constrained to emergency service applications and do not permit		constrained to emergency service applications and do not permit
	location information to traverse the end-point at all. This document		location information to traverse the end-point at all. This document
	describes the requirements of these countries and provides a solution		describes the requirements of these countries and provides a solution
	based on an extension to the HELD location protocol.		based on an extension to the HELD location protocol.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 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."
	This Internet-Draft will expire on January 17, 2013.		This Internet-Draft will expire on April 19, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 18 ¶		skipping to change at page 2, line 18 ¶
	Table of Contents		Table of Contents
	1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3		1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5		3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5
	4. Key Observations . . . . . . . . . . . . . . . . . . . . . . . 6		4. Key Observations . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Available Building Blocks . . . . . . . . . . . . . . . . . . 7		5. Available Building Blocks . . . . . . . . . . . . . . . . . . 7
	6. The Missing Link . . . . . . . . . . . . . . . . . . . . . . . 8		6. The Missing Link . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Domain Breakdown . . . . . . . . . . . . . . . . . . . . . 10		6.2. Domain Breakdown . . . . . . . . . . . . . . . . . . . . . 10
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11		7. HELD Extensions to Support Emergency Routing Information . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7.1. HELD Schema Extension . . . . . . . . . . . . . . . . . . 12
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 12		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . . 13		10.1. URN sub-namespace registration for
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		'urn:ietf:params:xml:ns:geopriv:held:eri' . . . . . . . . 14
			10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15
			11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
			12.2. Informative References . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction and Motivation		1. Introduction and Motivation
	The Internet emergency calling architecture specified in		The Internet emergency calling architecture specified in
	[I-D.ietf-ecrit-phonebcp] describes two main models for emergency		[I-D.ietf-ecrit-phonebcp] describes two main models for emergency
	call processing. The first is a device-centric model, where a device		call processing. The first is a device-centric model, where a device
	obtains location information using a location configuration protocol,		obtains location information using a location configuration protocol,
	such a HELD [RFC5985], and then proceeds to determine the address of		such a HELD [RFC5985], and then proceeds to determine the address of
	the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1		the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1
	shows this model in a simplified form.		shows this model in a simplified form.
	skipping to change at page 11, line 41 ¶		skipping to change at page 11, line 41 ¶
	| | +-------------+ |		| | +-------------+ |
	| | |		| | |
	| | +-----------+ |		| | +-----------+ |
	| +--(7)-locReq(Auth)--+ | |		| +--(7)-locReq(Auth)--+ | |
	| | ESRP/PSAP |<--(6)-Call(locURI)-+		| | ESRP/PSAP |<--(6)-Call(locURI)-+
	+---(8)-locResp(Loc)--->| |		+---(8)-locResp(Loc)--->| |
	+-----------+		+-----------+
	Figure 5: Emergency Call Domains		Figure 5: Emergency Call Domains
	7. Privacy Considerations		7. HELD Extensions to Support Emergency Routing Information
	[[TBD.]]		Figure 4 describes the enhancements needed to support the new calling
			model. Since the VSP has no means of determining if the LIS in the
			access network supports this modified calling model or not, there is
			no need to modify the syntax of locationRequest message sent to the
			LIS. The location request MUST include a responseTime of
			emergencyRouting to ensure that the LIS provides a response to the
			VSP as quickly as possible. When using IP related information
			identify the UA to the LIS then the identify information MUST be
			expressed using the IP flow representation specified in
			[I-D.ietf-geopriv-flow-identity]. This approach ensures that any
			issues caused by address translation entities in the path can be
			mitigated as far as possible. It also supports the LIS returning a
			location allowing invocation of the standard switch-centric calling
			procedures. A new optional "emergencyRoutingInformation" element is
			added to the locationResponse message containing the relevant
			destination URLs.
	8. Security Considerations		The list of destination URLs provided in the
			"emergencyRoutingInformation" element MUST conform to the same
			contraints as the service URLs returned in the LoST [RFC5222] in the
			findServiceResponse. For clarity these constraints are repreated
			here:
			1. The URLs MUST be absolute URLs
			2. The ordering of the URLs has no particular significance
			3. Each URL scheme MUST only appear at most once
			4. It is permissible to include both secured and regular versions of
			a protocol
			7.1. HELD Schema Extension
			This section describes the schema extension to HELD.
			<?xml version="1.0"?>
			<xs:schema
			targetNamespace="urn:ietf:params:xml:ns:geopriv:held:eri"
			xmlns:xs="http://www.w3.org/2001/XMLSchema"
			xmlns:eri="urn:ietf:params:xml:ns:geopriv:held:eri"
			xmlns:xml="http://www.w3.org/XML/1998/namespace"
			elementFormDefault="qualified" attributeFormDefault="unqualified">
			<xs:element name="emergencyRoutingInformation" type="eri:eriType"/>
			<xs:complexType name="eriType">
			<xs:complexContent>
			<xs:restriction base="xs:anyType">
			<xs:sequence>
			<xs:element name="uri" type="xs:anyURI"
			maxOccurs="unbounded"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:anyAttribute namespace="##any" processContents="lax"/>
			</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
			</xs:schema>
			7.2. Examples
			Figure 6 illustrates a <locationRequest> example that contains IP
			flow information in the request.
			<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
			responseTime="emergencyRouting">
			<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
			layer4="tcp" layer3="ipv4">
			<src>
			<address>192.168.1.1</address>
			<port>1024</port>
			</src>
			<dst>
			<address>10.0.0.1</address>
			<port>80</port>
			</dst>
			</flow>
			</locationRequest>
			Figure 6: Example Location Request.
			Figure 7 illustrates the <locationResponse> message containing two
			location URIs: a HTTPS and a SIP URI. Additionally, the response
			contains routing information.
			<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
			<locationUriSet expires="2006-01-01T13:00:00.0Z">
			<locationURI>
			https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
			</locationURI>
			<locationURI>
			sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
			</locationURI>
			</locationUriSet>
			<emergencyRoutingInformation
			xmlns="urn:ietf:params:xml:ns:geopriv:held:eri">
			<uri>sip:nypd@example.com</uri>
			<uri>sips:nypd@example.com</uri>
			<uri>xmpp:nypd@example.com</uri>
			</emergencyRoutingInformation>
			</locationResponse>
			Figure 7: Example Location Response
			8. Privacy Considerations
	[[TBD.]]		[[TBD.]]
	9. IANA Considerations		9. Security Considerations
	[[TBD.]]		[[TBD.]]
	10. Acknowledgements		10. IANA Considerations
			10.1. URN sub-namespace registration for
			'urn:ietf:params:xml:ns:geopriv:held:eri'
			This document calls for IANA to register a new XML namespace, as per
			the guidelines in [RFC3688].
			URI: urn:ietf:params:xml:ns:geopriv:held:eri
			Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org),
			James Winterbottom (james.winterbottom@commscope.com).
			XML:
			BEGIN
			<?xml version="1.0"?>
			<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
			"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
			<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
			<head>
			<title>HELD Emergency Routing Information Extensions</title>
			</head>
			<body>
			<h1>Additional Element for HELD Emergency Routing Information</h1>
			<h2>urn:ietf:params:xml:ns:geopriv:held:eri</h2>
			[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
			with the RFC number for this specification.]]
			<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
			</body>
			</html>
			END
			10.2. XML Schema Registration
			This section registers an XML schema as per the procedures in
			[RFC3688].
			URI: urn:ietf:params:xml:schema:geopriv:held:eri
			Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org),
			James Winterbottom (james.Winterbottom@commscope.com).
			The XML for this schema can be found as the entirety of
			Section 7.1 of this document.
			11. Acknowledgements
	We would like to thank Wilfried Lange for sharing his views with us.		We would like to thank Wilfried Lange for sharing his views with us.
	We would also like to thank Bruno Chatras for his review comments.		We would also like to thank Bruno Chatras for his review comments.
	11. References		12. References
			12.1. Normative References
	11.1. Normative References
	[I-D.ietf-ecrit-phonebcp]		[I-D.ietf-ecrit-phonebcp]
	Rosen, B. and J. Polk, "Best Current Practice for		Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in support of Emergency Calling",		Communications Services in support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-20 (work in progress),		draft-ietf-ecrit-phonebcp-20 (work in progress),
	September 2011.		September 2011.
	[I-D.ietf-geopriv-deref-protocol]		[I-D.ietf-geopriv-deref-protocol]
	Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.		Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.
	Thomson, "A Location Dereferencing Protocol Using HELD",		Thomson, "A Location Dereferencing Protocol Using HELD",
	draft-ietf-geopriv-deref-protocol-07 (work in progress),		draft-ietf-geopriv-deref-protocol-07 (work in progress),
	July 2012.		July 2012.
			[I-D.ietf-geopriv-flow-identity]
			Bellis, R., "Flow Identity Extension for HELD",
			draft-ietf-geopriv-flow-identity-00 (work in progress),
			September 2012.
	[I-D.ietf-geopriv-res-gw-lis-discovery]		[I-D.ietf-geopriv-res-gw-lis-discovery]
	Thomson, M. and R. Bellis, "Location Information Server		Thomson, M. and R. Bellis, "Location Information Server
	(LIS) Discovery using IP address and Reverse DNS",		(LIS) Discovery using IP address and Reverse DNS",
	draft-ietf-geopriv-res-gw-lis-discovery-03 (work in		draft-ietf-geopriv-res-gw-lis-discovery-04 (work in
	progress), March 2012.		progress), September 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
			January 2004.
	[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.		[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
	Tschofenig, "LoST: A Location-to-Service Translation		Tschofenig, "LoST: A Location-to-Service Translation
	Protocol", RFC 5222, August 2008.		Protocol", RFC 5222, August 2008.
	[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
	Location Configuration Protocol: Problem Statement and		Location Configuration Protocol: Problem Statement and
	Requirements", RFC 5687, March 2010.		Requirements", RFC 5687, March 2010.
	[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",		[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
	RFC 5985, September 2010.		RFC 5985, September 2010.
	skipping to change at page 13, line 15 ¶		skipping to change at page 17, line 10 ¶
	September 2010.		September 2010.
	[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.		[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
	Barnes, "Use of Device Identity in HTTP-Enabled Location		Barnes, "Use of Device Identity in HTTP-Enabled Location
	Delivery (HELD)", RFC 6155, March 2011.		Delivery (HELD)", RFC 6155, March 2011.
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,		[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet		"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, December 2011.		Multimedia", RFC 6443, December 2011.
	11.2. Informative References		12.2. Informative References
	[I-D.ietf-ecrit-rough-loc]		[I-D.ietf-ecrit-rough-loc]
	Barnes, R. and M. Lepinski, "Using Imprecise Location for		Barnes, R. and M. Lepinski, "Using Imprecise Location for
	Emergency Context Resolution",		Emergency Context Resolution",
	draft-ietf-ecrit-rough-loc-04 (work in progress),		draft-ietf-ecrit-rough-loc-05 (work in progress),
	March 2011.		July 2012.
	[I-D.ietf-ecrit-trustworthy-location]		[I-D.ietf-ecrit-trustworthy-location]
	Tschofenig, H., Schulzrinne, H., and B. Aboba,		Tschofenig, H., Schulzrinne, H., and B. Aboba,
	"Trustworthy Location Information",		"Trustworthy Location Information",
	draft-ietf-ecrit-trustworthy-location-03 (work in		draft-ietf-ecrit-trustworthy-location-03 (work in
	progress), April 2012.		progress), April 2012.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
End of changes. 16 change blocks.
	25 lines changed or deleted		190 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/