draft-ietf-ecrit-phonebcp-17.txt   draft-ietf-ecrit-phonebcp-18.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: September 29, 2011 Cisco Systems Expires: January 29, 2012 Cisco Systems
March 28, 2011 July 28, 2011
Best Current Practice for Communications Services in support of Best Current Practice for Communications Services in support of
Emergency Calling Emergency Calling
draft-ietf-ecrit-phonebcp-17 draft-ietf-ecrit-phonebcp-18
Abstract Abstract
The IETF and other standards organization have efforts targeted at The IETF and other standards organization have efforts targeted at
standardizing various aspects of placing emergency calls on IP standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices, networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency networks and services should use such standards to make emergency
calls. calls.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 29, 2011. This Internet-Draft will expire on January 29, 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
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 4 3. Overview of how emergency calls are placed . . . . . . . . . . 4
4. Which devices and services should support emergency calls . . 5 4. Which devices and services should support emergency calls . . 5
5. Identifying an emergency call . . . . . . . . . . . . . . . . 5 5. Identifying an emergency call . . . . . . . . . . . . . . . . 5
6. Location and its role in an emergency call . . . . . . . . . . 6 6. Location and its role in an emergency call . . . . . . . . . . 6
6.1. Types of location information . . . . . . . . . . . . . . 6 6.1. Types of location information . . . . . . . . . . . . . . 6
6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7
6.2.1. User-entered location information . . . . . . . . . . 7 6.2.1. User-entered location information . . . . . . . . . . 7
6.2.2. Access network "wire database" location information . 7 6.2.2. Access network "wire database" location information . 7
6.2.3. End-system measured location information . . . . . . . 7 6.2.3. End-system measured location information . . . . . . . 8
6.2.4. Network-measured location information . . . . . . . . 8 6.2.4. Network-measured location information . . . . . . . . 8
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8
6.4. Location and references to location . . . . . . . . . . . 9 6.4. Location and references to location . . . . . . . . . . . 9
6.5. End system location configuration . . . . . . . . . . . . 9 6.5. End system location configuration . . . . . . . . . . . . 9
6.6. When location should be configured . . . . . . . . . . . . 10 6.6. When location should be configured . . . . . . . . . . . . 10
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11 6.7. Conveying location . . . . . . . . . . . . . . . . . . . . 11
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12
6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13
6.12. Other location considerations . . . . . . . . . . . . . . 13 6.12. Other location considerations . . . . . . . . . . . . . . 13
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. SIP signaling requirements for User Agents . . . . . . . . 15 9.2. SIP signaling requirements for User Agents . . . . . . . . 15
9.3. SIP signaling requirements for proxy servers . . . . . . . 16 9.3. SIP signaling requirements for proxy servers . . . . . . . 16
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21 17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21
17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21 17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21
19.2. Informative References . . . . . . . . . . . . . . . . . . 24 19.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Terminology 1. Terminology
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].
This document uses terms from [RFC3261], [RFC5012] and This document uses terms from [RFC3261], [RFC5012] and
[I-D.ietf-ecrit-framework]. [I-D.ietf-ecrit-framework].
2. Introduction 2. Introduction
This document describes how access networks, Session Initiation This document describes how access networks, Session Initiation
Protocol [RFC3261] user agents, proxy servers and Public Safety Protocol [RFC3261] user agents, proxy servers and Public Safety
Access Points (PSAPs) support emergency calling, as outlined in Access Points (PSAPs) support emergency calling, as outlined in
[I-D.ietf-ecrit-framework], which is designed to complement the [I-D.ietf-ecrit-framework], which is designed to complement the
present document in section headings, numbering and content. This present document in section headings, numbering and content.
BCP succinctly describes the requirements of end devices and Understanding [I-D.ietf-ecrit-framework] is necessary to understand
applications (requirements prefaced by "ED-"), access networks this document. This BCP succinctly describes the requirements of end
(including enterprise access networks) (requirements prefaced by devices and applications (requirements prefaced by "ED-"), access
"AN-"), service providers (requirements prefaced by "SP-") and PSAPs networks (including enterprise access networks) (requirements
to achieve globally interoperable emergency calling on the Internet. prefaced by "AN-"), service providers (requirements prefaced by
"SP-") and PSAPs to achieve globally interoperable emergency calling
on the Internet.
This document also defines requirements for "Intermediate" devices This document also defines requirements for "Intermediate" devices
which exist between end devices or applications and the access which exist between end devices or applications and the access
network. For example, a home router is an "Intermediate" device. network. For example, a home router is an "Intermediate" device.
Reporting location on an emergency call (see Section 6) may depend on Reporting location on an emergency call (see Section 6) may depend on
the ability of such intermediate devices to meet the requirements the ability of such intermediate devices to meet the requirements
prefaced by "INT-". prefaced by "INT-".
Other organizations, such as the North American Emergency Number
Association (NENA), define the PSAP interface. NENA's documents
reference this document.
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
An emergency call can be distinguished (Section 5) from any other An emergency call can be distinguished (Section 5) from any other
call by a unique Service URN [RFC5031], which is placed in the call call by a unique Service URN [RFC5031], which is placed in the call
set-up signaling when a home or visited emergency dial string is set-up signaling when a home or visited emergency dial string is
detected. Because emergency services are local to specific detected. Because emergency services are local to specific
geographic regions, a caller must obtain his location (Section 6) geographic regions, a caller must obtain his location (Section 6)
prior to making emergency calls. To get this location, either a form prior to making emergency calls. To get this location, either a form
of measuring (e.g., GPS) (Section 6.2.3) device location in the of measuring (e.g., GPS) (Section 6.2.3) device location in the
endpoint is deployed, or the endpoint is configured (Section 6.5) endpoint is deployed, or the endpoint is configured (Section 6.5)
skipping to change at page 6, line 29 skipping to change at page 6, line 34
Handling location for emergency calling usually involves several Handling location for emergency calling usually involves several
steps to process and multiple elements are involved. In Internet steps to process and multiple elements are involved. In Internet
emergency calling, where the endpoint is located is "determined" emergency calling, where the endpoint is located is "determined"
using a variety of measurement or wiretracing methods. Endpoints can using a variety of measurement or wiretracing methods. Endpoints can
be "configured" with their own location by the access network. In be "configured" with their own location by the access network. In
some circumstances, a proxy server can insert location into the some circumstances, a proxy server can insert location into the
signaling on behalf of the endpoint. The location is "mapped" to the signaling on behalf of the endpoint. The location is "mapped" to the
URI to send the call to, and the location is "conveyed" to the PSAP URI to send the call to, and the location is "conveyed" to the PSAP
(and other elements) in the signaling. Likewise, we employ Location (and other elements) in the signaling. Likewise, we employ Location
Configuration Protocols, the Location-to-Service Mapping Protocol, Configuration Protocols (LCPs), the Location-to-Service Mapping
and Location Conveyance Protocols for these functions. The Location- Protocol, and Location Conveyance Protocols for these functions. The
to-Service Translation protocol [RFC5222] is the Location Mapping Location-to-Service Translation protocol [RFC5222] is the Location
Protocol defined by the IETF. Mapping Protocol defined by the IETF.
6.1. Types of location information 6.1. Types of location information
There are several forms of location. All IETF location configuration There are several forms of location. All IETF location configuration
and location conveyance protocols support both civic and geospatial and location conveyance protocols support both civic and geospatial
(geo) forms. The civic forms include both postal and jurisdictional (geo) forms. The civic forms include both postal and jurisdictional
fields. A cell tower/sector can be represented as a point (geo or fields. A cell tower/sector can be represented as a point (geo or
civic) or polygon. Other forms of location representation MUST be civic) or polygon. Other forms of location representation MUST be
mapped into either a geo or civic for use in emergency calls. mapped into either a geo or civic for use in emergency calls.
skipping to change at page 8, line 15 skipping to change at page 8, line 20
ED-17/INT-9/AN-9 Devices that support endpoint measuring of location ED-17/INT-9/AN-9 Devices that support endpoint measuring of location
MUST have at least a coarse location capability (typically <1km MUST have at least a coarse location capability (typically <1km
accuracy) for routing of calls. The location mechanism MAY be a accuracy) for routing of calls. The location mechanism MAY be a
service provided by the access network. service provided by the access network.
6.2.4. Network-measured location information 6.2.4. Network-measured location information
AN-10 Access networks MAY provide network-measured location AN-10 Access networks MAY provide network-measured location
determination. Wireless access networks that do not supply network determination. Wireless access networks that do not supply network
measured location MUST require that all devices connected to the measured location MUST require that all devices or intermediate
network have end-system measured location. Uncertainty and devices connected to the network have end-system measured location.
confidence may be specified by local regulation. Where not Uncertainty and confidence may be specified by local regulation.
specified, uncertainty of less than 100 meters with 95% confidence is Where not specified, uncertainty of less than 100 meters with 95%
RECOMMENDED for dispatch location. confidence is RECOMMENDED for dispatch location.
AN-11 Access networks that provide network measured location MUST AN-11 Access networks that provide network measured location MUST
have at least a coarse location (typically <1km when not location have at least a coarse location (typically <1km when not location
hiding) capability at all times for routing of calls. hiding) capability at all times for routing of calls.
AN-12 Access networks with range of <10 meters (e.g. personal area AN-12 Access networks with range of <10 meters (e.g. personal area
networks such as Bluetooth MUST provide a location to mobile devices networks such as Bluetooth MUST provide a location to mobile devices
connected to them. The location provided SHOULD be that reported by connected to them. The location provided SHOULD be that reported by
the upstream access network unless a more accurate mechanism is the upstream access network unless a more accurate mechanism is
available. available.
skipping to change at page 9, line 23 skipping to change at page 9, line 27
ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration
Protocol (DHCP) location options [RFC4776], [RFC3825] and HTTP Protocol (DHCP) location options [RFC4776], [RFC3825] and HTTP
Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a
specific access network interface for which location configuration specific access network interface for which location configuration
mechanisms such as Link Layer Discovery Protocol - Media Endpoint mechanisms such as Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device
SHOULD support the additional respective access network specific SHOULD support the additional respective access network specific
location configuration mechanism. location configuration mechanism.
AN-13/INT-14 The access network MUST support either DHCP location
options or HELD. The access network SHOULD support other location
configuration technologies that are specific to the type of access
network.
AN-14/INT-15 Where a router is employed between a LAN and WAN in a AN-14/INT-15 Where a router is employed between a LAN and WAN in a
small (less than approximately 650 square meters) area, the router small (less than approximately 650 square meters) area, the router
MUST be transparent to the location provided by the WAN to the LAN. MUST be transparent to the location provided by the WAN to the LAN.
This may mean the router must obtain location as a client from the This may mean the router must obtain location as a client from the
WAN, and supply an LCP server to the LAN with the location it WAN, and supply an LCP server to the LAN with the location it
obtains. Where the area is larger, the LAN MUST have a location obtains. Where the area is larger, the LAN MUST have a location
configuration mechanism satisfying the requirements of this document. configuration mechanism satisfying the requirements of this document.
ED-22/INT-16 Endpoints SHOULD try all LCPs supported by the device in ED-22/INT-16 Endpoints SHOULD try all LCPs supported by the device in
any order or in parallel. The first one that succeeds in supplying any order or in parallel. The first one that succeeds in supplying
skipping to change at page 11, line 16 skipping to change at page 11, line 16
might indicate having moved, for example when it changes access might indicate having moved, for example when it changes access
points, the device SHOULD refresh its location. points, the device SHOULD refresh its location.
ED-32/INT-26/AN-18 It is RECOMMENDED that location determination not ED-32/INT-26/AN-18 It is RECOMMENDED that location determination not
take longer than 250 ms to obtain routing location and systems SHOULD take longer than 250 ms to obtain routing location and systems SHOULD
be designed such that the typical response is under 100 ms. However, be designed such that the typical response is under 100 ms. However,
as much as 3 seconds to obtain routing location MAY be tolerated if as much as 3 seconds to obtain routing location MAY be tolerated if
location accuracy can be substantially improved over what can be location accuracy can be substantially improved over what can be
obtained in 250 ms. obtained in 250 ms.
6.7. Conveying location in SIP 6.7. Conveying location
ED-33/SP-15 Location sent between SIP elements MUST be conveyed using ED-33/SP-15 Location sent between SIP elements MUST be conveyed using
[I-D.ietf-sipcore-location-conveyance]. [I-D.ietf-sipcore-location-conveyance].
6.8. Location updates 6.8. Location updates
ED-34/AN-19 Where the absolute location or the accuracy of location ED-34/AN-19 Where the absolute location or the accuracy of location
of the endpoint may change between the time the call is received at of the endpoint may change between the time the call is received at
the PSAP and the time dispatch is completed, location update the PSAP and the time dispatch is completed, location update
mechanisms MUST be implemented and used. mechanisms MUST be implemented and used.
skipping to change at page 13, line 36 skipping to change at page 13, line 36
implementing DHCP for location configuration SHOULD use [RFC3118], implementing DHCP for location configuration SHOULD use [RFC3118],
although the difficulty in providing appropriate credentials is although the difficulty in providing appropriate credentials is
significant. significant.
ED-47 If S/MIME is used, the INVITE message MUST provide enough ED-47 If S/MIME is used, the INVITE message MUST provide enough
information unencrypted for intermediate proxies to route the call information unencrypted for intermediate proxies to route the call
based on the location information included. This would include the based on the location information included. This would include the
Geolocation header, and any bodies containing location information. Geolocation header, and any bodies containing location information.
Use of S/MIME with emergency calls is NOT RECOMMENDED. Use of S/MIME with emergency calls is NOT RECOMMENDED.
ED-48/SP-24 Either TLS or IPSEC [RFC3986] MUST be used to protect ED-48/SP-24 Either TLS or IPsec [RFC3986] MUST be used to protect
location (but see Section 9.1). location (but see Section 9.1).
7. LIS and LoST Discovery 7. LIS and LoST Discovery
ED-49 Endpoints MUST support one or more mechanisms that allow them ED-49 Endpoints MUST support one or more mechanisms that allow them
to determine their public IP address, for example, STUN [RFC5389]. to determine their public IP address, for example, STUN [RFC5389].
ED-50 Endpoints MUST support LIS discovery as described in [RFC5986], ED-50 Endpoints MUST support LIS discovery as described in [RFC5986],
and the LoST discovery as described in [RFC5223]. and the LoST discovery as described in [RFC5223].
skipping to change at page 18, line 15 skipping to change at page 18, line 15
11. Mid-call behavior 11. Mid-call behavior
ED-65/SP-37 During the course of an emergency call, devices and ED-65/SP-37 During the course of an emergency call, devices and
proxies MUST initiate a call transfer upon receipt of REFER request proxies MUST initiate a call transfer upon receipt of REFER request
within the dialog with method=INVITE and the Referred-by header field within the dialog with method=INVITE and the Referred-by header field
[RFC3515] in that request. [RFC3515] in that request.
12. Call termination 12. Call termination
ED-66 There can be a case where the session signaling path is lost, ED-66 Normal [RFC3261] procedures for termination MUST be used for
the PSAP terminates the call but the user agent does not receive the termination of the call.
BYE. The PSAP would not receive the ACK and may initiate a call
back. If an incoming call is received from the domain of the PSAP,
the device MUST alert for the (new) incoming call. The domain of an
incoming call can only be determined from the From header, which is
not reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From header field would be a DoS attack.
13. Disabling of features 13. Disabling of features
ED-67/SP-38 User Agents and proxies MUST disable features that will ED-67/SP-38 User Agents and proxies MUST disable features that will
interrupt an ongoing emergency call, such as: interrupt an ongoing emergency call, such as:
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Hold o Hold
o Outbound Call Blocking o Outbound Call Blocking
skipping to change at page 20, line 45 skipping to change at page 20, line 39
a random amount of time (in perhaps a 30 minute period, sufficient a random amount of time (in perhaps a 30 minute period, sufficient
for any avalanche restart to complete) and then test. for any avalanche restart to complete) and then test.
ED-83 PSAPs MAY refuse repeated requests for test from the same ED-83 PSAPs MAY refuse repeated requests for test from the same
device in a short period of time. Any refusal is signaled with a 486 device in a short period of time. Any refusal is signaled with a 486
or 488 response. or 488 response.
16. Security Considerations 16. Security Considerations
Security considerations for emergency calling have been documented in Security considerations for emergency calling have been documented in
[RFC5069], and [I-D.ietf-geopriv-arch]. [RFC5069], and [I-D.ietf-geopriv-arch]. This document suggests that
security (TLS or IPsec) be used hop by hop on a SIP call to protect
location information, identity, etc. It also suggests that if the
attempt to create a security association fails, the call be retried
without the security. It's more important to get an emergency call
through than to protect the data; indeed, in many jurisdictions
privacy is explicitly waived when making emergency calls. Placing a
call without security may reveal user information, including
location. The alternative - failing the call if security cannot be
established, is considered unacceptable.
17. IANA Considerations 17. IANA Considerations
This document registers service URNs in the Service URN Labels This document registers service URNs in the Service URN Labels
registry per [RFC5031] for testing. registry per [RFC5031] for testing.
17.1. test service urn 17.1. test service urn
A new entry in the URN Service Label registry is added. The new A new entry in the URN Service Label registry is added. The new
service is "test", the reference is this document, and the service is "test", the reference is this document, and the
description is "self test". description is "self test".
17.2. 'test' Subregistry 17.2. 'test' Subregistry
A new Subregistry is created, the "'test' Sub-Service. The A new Subregistry is created, the "'test' Sub-Service. The
registration process is Expert review by ECRIT working group, its registration process is Expert Review per [RFC5226]. The expert
successor, or, in their absence, the IESG. The Reference is this review should consider The Reference is this document. The initial
document. The initial content of the subregistry is: content of the subregistry is:
Service Reference Description Service Reference Description
-------------------------------------------------------------------- --------------------------------------------------------------------
test.sos [this document] test for sos test.sos [this document] test for sos
test.sos.ambulance [this document] test for sos.ambulance test.sos.ambulance [this document] test for sos.ambulance
test.sos.animal-control [this document] test for sos.animal-control test.sos.animal-control [this document] test for sos.animal-control
test.sos.fire [this document] test for sos.fire test.sos.fire [this document] test for sos.fire
test.sos.gas [this document] test for sos.gas test.sos.gas [this document] test for sos.gas
test.sos.marine [this document] test for sos.marine test.sos.marine [this document] test for sos.marine
test.sos.mountain [this document] test for sos.mountain test.sos.mountain [this document] test for sos.mountain
skipping to change at page 22, line 13 skipping to change at page 22, line 16
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Sivachelvan, C., Venna, N., Jones, P., Stratton, N., Sivachelvan, C., Venna, N., Jones, P., Stratton, N.,
Roychowdhury, A., and K. Hedayat, "An Extension to the Roychowdhury, A., and K. Hedayat, "An Extension to the
Session Description Protocol (SDP) for Media Loopback", Session Description Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-15 (work in progress), draft-ietf-mmusic-media-loopback-15 (work in progress),
March 2011. March 2011.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-06 (work in draft-ietf-sipcore-location-conveyance-08 (work in
progress), February 2011. progress), May 2011.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[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.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
skipping to change at page 24, line 19 skipping to change at page 24, line 23
[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.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223, Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008. August 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
 End of changes. 19 change blocks. 
44 lines changed or deleted 52 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/