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/