draft-ietf-ecrit-unauthenticated-access-09.txt		draft-ietf-ecrit-unauthenticated-access-10.txt
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track S. McCann		Intended status: Standards Track S. McCann
	Expires: January 4, 2015 Research in Motion UK Ltd		Expires: February 13, 2015 Research in Motion UK Ltd
	G. Bajko		G. Bajko
	Nokia
	H. Tschofenig		H. Tschofenig
	D. Kroeselberg		D. Kroeselberg
	Siemens		Siemens
	July 3, 2014		August 12, 2014
	Extensions to the Emergency Services Architecture for dealing with		Extensions to the Emergency Services Architecture for dealing with
	Unauthenticated and Unauthorized Devices		Unauthenticated and Unauthorized Devices
	draft-ietf-ecrit-unauthenticated-access-09.txt		draft-ietf-ecrit-unauthenticated-access-10.txt
	Abstract		Abstract
	This document provides a problem statement, introduces terminology		This document provides a problem statement, introduces terminology
	and describes an extension for the base IETF emergency services		and describes an extension for the base IETF emergency services
	architecture to address cases where an emergency caller is not		architecture to address cases where an emergency caller is not
	authenticated, has no identifiable service provider, or has no		authenticated, has no identifiable service provider, or has no
	remaining credit with which to pay for access to the network.		remaining credit with which to pay for access to the network.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 4, 2015.		This Internet-Draft will expire on February 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 4, line 31		skipping to change at page 4, line 31
	help may, for example, be in a NAA and NASP situation, as explained		help may, for example, be in a NAA and NASP situation, as explained
	in more detail in Figure 1. Depending on local policy and		in more detail in Figure 1. Depending on local policy and
	regulations, it may not be possible to place emergency calls in the		regulations, it may not be possible to place emergency calls in the
	NAA case. Unless local regulations require user identification, it		NAA case. Unless local regulations require user identification, it
	should always be possible to place calls in the NASP case, with		should always be possible to place calls in the NASP case, with
	minimal impact on the ISP. Unless the ESN requires that all calls		minimal impact on the ISP. Unless the ESN requires that all calls
	traverse a known set of VSPs, it is technically possible to let a		traverse a known set of VSPs, it is technically possible to let a
	caller place an emergency call in the ZBP case. We discuss each case		caller place an emergency call in the ZBP case. We discuss each case
	in more details in Section 3.		in more details in Section 3.
	Note: At the time of writing there is no regulation in place that
	demands the functionality described in this memo. SDOs have started
	their work on this subject in a proactive fashion in the anticipation
	that national regulation will demand it for a subset of network
	environments.
	As mentioned in the abstract some of the functionality provided in		As mentioned in the abstract some of the functionality provided in
	this document is already available in the PSTN. Consequently, there		this document is already available in the PSTN. Consequently, there
	is real-world experience available and not all of it is positive.		is real-world experience available and not all of it is positive.
	For example, the functionality of SIM-less calls in today's cellular		For example, the functionality of SIM-less calls in today's cellular
	system has lead to a fair amount of hoax or test calls in certain		system has lead to a fair amount of hoax or test calls in certain
	countries. This causes overload situations at PSAPs, which is		countries. This causes overload situations at PSAPs, which is
	considered harmful to the overall availability and reliability of		considered harmful to the overall availability and reliability of
	emergency services.		emergency services.
	As an example, Federal Office of Communications (OFCOM,		As an example, Federal Office of Communications (OFCOM,
	skipping to change at page 14, line 10		skipping to change at page 14, line 10
	Figure 5: Architectural Overview		Figure 5: Architectural Overview
	Note: Figure 5 does not indicate who operates the ESRP and the LoST		Note: Figure 5 does not indicate who operates the ESRP and the LoST
	server. Various deployment options exist.		server. Various deployment options exist.
	5.1. End Host Profile		5.1. End Host Profile
	5.1.1. LoST Server Discovery		5.1.1. LoST Server Discovery
	The end host MUST discover a LoST server [RFC5222] using DHCP		The end host MUST discover a LoST server [RFC5222] using DHCP
	[RFC5223].		[RFC5223] unless a LoST server has been provisioned using other
			means.
	5.1.2. ESRP Discovery		5.1.2. ESRP Discovery
	The end host MUST discover the ESRP using the LoST protocol		The end host MUST discover the ESRP using the LoST protocol [RFC5222]
	[RFC5222].		unless a ESRP has been provisioned using other means.
	5.1.3. Location Determination and Location Configuration		5.1.3. Location Determination and Location Configuration
	The end host MUST support location acquisition and the LCPs described		The end host MUST support location acquisition and the LCPs described
	in Section 6.5 of [RFC6881]. The description in Section 6.5 and 6.6		in Section 6.5 of [RFC6881]. The description in Section 6.5 and 6.6
	of [RFC6881] regarding the interaction between the device and the LIS		of [RFC6881] regarding the interaction between the device and the LIS
	applies to this document.		applies to this document.
	The SIP UA in the end host MUST attach available location information		The SIP UA in the end host MUST attach available location information
	in a PIDF-LO [RFC4119] when making an emergency call. When		in a PIDF-LO [RFC4119] when making an emergency call. When
	skipping to change at page 21, line 5		skipping to change at page 21, line 5
	We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc		We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc
	Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT		Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT
	meeting.		meeting.
	Furthermore, we would like to thank Martin Thomson and Bernard Aboba		Furthermore, we would like to thank Martin Thomson and Bernard Aboba
	for their detailed document review in preparation of the 81st IETF		for their detailed document review in preparation of the 81st IETF
	meeting. Alexey Melnikov was the General Area (Gen-Art) reviewer. A		meeting. Alexey Melnikov was the General Area (Gen-Art) reviewer. A
	number of changes to the document had been made in response to the AD		number of changes to the document had been made in response to the AD
	review by Richard Barnes.		review by Richard Barnes.
			We would also like to thank review comments from various IESG
			members, including Stephen Farrell, Barry Leiba, Pete Resnick,
			Spencer Dawkins, Joel Jaeggli, and Ted Lemon.
	9. IANA Considerations		9. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for		[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
	Emergency and Other Well-Known Services", RFC 5031,		Emergency and Other Well-Known Services", RFC 5031,
	skipping to change at page 23, line 35		skipping to change at page 23, line 35
	Research in Motion UK Ltd		Research in Motion UK Ltd
	200 Bath Road		200 Bath Road
	Slough, Berks SL1 3XE		Slough, Berks SL1 3XE
	UK		UK
	Phone: +44 1753 667099		Phone: +44 1753 667099
	Email: smccann@rim.com		Email: smccann@rim.com
	URI: http://www.rim.com		URI: http://www.rim.com
	Gabor Bajko		Gabor Bajko
	Nokia
	Email: Gabor.Bajko@nokia.com		Email: gaborbajko@gmail.com
	Hannes Tschofenig		Hannes Tschofenig
	Hall in Tirol 6060		Hall in Tirol 6060
	Austria		Austria
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Dirk Kroeselberg		Dirk Kroeselberg
	Siemens		Siemens
	Germany		Germany
End of changes. 11 change blocks.
	16 lines changed or deleted		14 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/