--- 1/draft-ietf-ecrit-unauthenticated-access-09.txt 2014-08-12 03:14:31.289764443 -0700 +++ 2/draft-ietf-ecrit-unauthenticated-access-10.txt 2014-08-12 03:14:31.337765574 -0700 @@ -1,26 +1,26 @@ ECRIT H. Schulzrinne Internet-Draft Columbia University 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 - Nokia + H. Tschofenig D. Kroeselberg Siemens - July 3, 2014 + August 12, 2014 Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices - draft-ietf-ecrit-unauthenticated-access-09.txt + draft-ietf-ecrit-unauthenticated-access-10.txt Abstract This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network. Status of This Memo @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -159,26 +159,20 @@ help may, for example, be in a NAA and NASP situation, as explained in more detail in Figure 1. Depending on local policy and regulations, it may not be possible to place emergency calls in the NAA case. Unless local regulations require user identification, it should always be possible to place calls in the NASP case, with 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 caller place an emergency call in the ZBP case. We discuss each case 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 this document is already available in the PSTN. Consequently, there is real-world experience available and not all of it is positive. 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 countries. This causes overload situations at PSAPs, which is considered harmful to the overall availability and reliability of emergency services. As an example, Federal Office of Communications (OFCOM, @@ -584,26 +578,27 @@ Figure 5: Architectural Overview Note: Figure 5 does not indicate who operates the ESRP and the LoST server. Various deployment options exist. 5.1. End Host Profile 5.1.1. LoST Server Discovery 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 - The end host MUST discover the ESRP using the LoST protocol - [RFC5222]. + The end host MUST discover the ESRP using the LoST protocol [RFC5222] + unless a ESRP has been provisioned using other means. 5.1.3. Location Determination and Location Configuration 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 of [RFC6881] regarding the interaction between the device and the LIS applies to this document. The SIP UA in the end host MUST attach available location information in a PIDF-LO [RFC4119] when making an emergency call. When @@ -906,20 +901,24 @@ We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT meeting. Furthermore, we would like to thank Martin Thomson and Bernard Aboba for their detailed document review in preparation of the 81st IETF 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 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 This document does not require actions by IANA. 10. References 10.1. Normative References [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, @@ -1025,23 +1024,22 @@ Research in Motion UK Ltd 200 Bath Road Slough, Berks SL1 3XE UK Phone: +44 1753 667099 Email: smccann@rim.com URI: http://www.rim.com Gabor Bajko - Nokia - Email: Gabor.Bajko@nokia.com + Email: gaborbajko@gmail.com Hannes Tschofenig Hall in Tirol 6060 Austria Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Dirk Kroeselberg Siemens Germany