ECRIT Working Group James Polk
Internet-Draft Cisco Systems
Expires: August 27th, 2006 Feb 27th, 2006
Analyzing ECRIT Mapping of a Location to an
Emergency URI for Emergency Calling
draft-polk-ecrit-mapping-events-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Emergency calling is a localized event, requiring a caller to place
an specially identified local emergency call to a Public Safety
Answering Point (PSAP), while including the location of the caller
in that signaling. The function of routing the set-up messaging to
the appropriate PSAP is performed by a mapping function that binds a
given location with one or more PSAP SIP(S)-URIs. This function is
done by the ECRIT mapping protocol. This document analyzes when the
ECRIT mapping protocol function can occur, and what general
components are involved in that mapping.
Polk Expires August 27th, 2006 [Page 1]
Internet-Draft ECRIT Mapping Events Feb 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Message Flow Assumptions and Rules Outlined . . . . . . . . . 3
3. Mapping Scenarios Outlined . . . . . . . . . . . . . . . . . 5
3.1 Scenario #1 - Alice Needs Configuration Data . . . . . . . 5
3.2 Scenario #2 - Alice Invokes Early ECRIT Mapping . . . . . 6
3.2.1 Scenario #2a - DHCP Requested ECRIT Mapping . . . . . . . 6
3.2.2 Scenario #2b - SIP REGISTER Requested ECRIT Mapping . . . 7
3.3 Scenario #3 - Message Flow to PSAP without Early ECRIT
Mapping . 9
4. Can Failures of the ECRIT Mapping Function Fail Call Attempts 10
4.1 Reactive ECRIT Mapping Function After Failure . . . . . . . 11
4.2 ESRP Reacts ECRIT Mapping Failure . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative References . . . . . . . . . . . . . . . . . . 14
8.2 Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
1. Introduction
Emergency calling is a highly localized event, dependent on the
location of the caller, and the caller's ability to input an
emergency address, most often this is the calling digits, of the
emergency call center. This is highly localized because the first
responders that that will render aid to the caller will also be
local to the caller. In IP, with its decomposed nature of call
control separated from access infrastructure, routing entities
requiring knowledge of the location of the caller is more
challenging, because there may not be a relationship between the
call control organization and the access infrastructure
organization. The calling device, here a Session Initiation
Protocol (SIP) User Agent (UA), needs to learn its location from the
network and include that information in the emergency call signaling
to ensure the call set-up messages have the information necessary to
route them to the PSAP. There needs to be a mechanism to take the
location of the caller and map that location to a emergency address.
Compounding this problem is that generally useful national emergency
dialstrings are not granular enough to address the specific PSAP
that serves a caller's location, which is a byproduct of IP
networks: one address gets to one location.
The ECRIT Mapping mechanism takes a given location of a device, for
example a SIP user agent (UA), and returns the appropriate PSAP URI
for that device to use if it initiates a call for emergency help
Polk Expires August 27th, 2006 [Page 2]
Internet-Draft ECRIT Mapping Events Feb 2006
[ID-ECRIT-REQS]. The mapping mechanism hinges on knowing, or being
given, a location to perform a mapping function against. How a
device learns its location is not specified here, but can be from a
number of means, including:
- Manual configuration
- Internal GPS measurement
- Lower layer triangulation, then informing the UA of its position
- Layer 2 interaction with network attachment point (i.e. LLDP-MED
or 802.11)
- A Layer 7 protocol (i.e. HELD or LCP, etc)
- DHCP (for geo [RFC3825] or civic [ID-CIVIC])
The latter appears likely to be the most common non-cellular means
of an endpoint learning its location.
The PSAP community really wants (demands?) the freshest mapping data
possible when a user calls for help. Thus, a working model was
envisioned in which the caller, while their call set-up signaling
was being routed through the network with the user's location in the
set-up message, would have a really smart device understand that
this is an emergency call, and perform the mapping to the
appropriate PSAP.
A question was raised sometime after this model was envisioned that
if this mapping function was only performed during the call and
failed, for whatever reason, would the call set-up fail. Most
agree, this would be a bad thing.
Therefore, some folks went off and started working on ideas about
when this mapping really was needed, knowing it was needed at some
point.
This document focuses on when that mapping can occur.
2. Message Flow Assumptions and Rules Outlined
This section starts by generalizing when "mapping" can occur.
Through this, it is assumed that
- SIP is the signaling protocol for call set-up.
- Location is included in the SIP Request either by-value or
by-reference
- SIP messages are well formed
Polk Expires August 27th, 2006 [Page 3]
Internet-Draft ECRIT Mapping Events Feb 2006
- there are value layer 3 routes between all components in any
message flow shown
- All URIs within this document use the SIP or SIPS-URI scheme, this
includes anywhere there are PSAP-URI or SIP(S)-URI indications
written
This document will put together rough message flows involving a
number of well known components foreseen in emergency calling
infrastructures, but without any IP routers, Ethernet switches or
other lower layer nodes.
The devices included in message flows are:
- Alice and her UA
- DHCP Server
- SIP Registrar
- SIP Proxy Server
- ECRIT Mapping Server
- Emergency Services Routing Proxy (ESRP)
- PSAP and all that goes with it
** NOTE - Not all components will be in every message flow, and in
fact, rarely will all the above list be in the same
message flow. That would make the flow too crowded for
the point being made in that subsection.
An ESRP is a special instance of a SIP server, be that a SIP Proxy,
Session Border Controller (SBC) or Back-to-Back-User-Agent (B2BUA),
that understands:
a) the concept of location within a SIP message, and
b) recognizes calls by their emergency identifier
("urn:services:sos" as specified in [ID-SOS], and
c) to perform a mapping function, regardless of the fact that a SIP
Request may have a valid PSAP-URI as a Request-URI
Ultimately, we're after this message flow:
Alice PSAP
[M1] INVITE (sos & location)
-------------------------->
[M2] 200 OK
<--------------------------
[M3] ACK
-------------------------->
Polk Expires August 27th, 2006 [Page 4]
Internet-Draft ECRIT Mapping Events Feb 2006
Media Session Established
<=========================>
Figure 1. Basic Message Flow
Then first responders would be racing to Alice's location to help
her. Unfortunately, calling a IP-enabled PSAP isn't that easy, as
there are a few more components in the network that are necessary,
some in certain situations, some in other situations. The rest of
this section will be building the network out between Alice and her
appropriate PSAP, to place this call above.
We will see that Alice needs to certain configuration information,
but this can be from at least two different types of sources. The
general configuration server message flow will be shown in Section
3.1.
We will see that these two configuration servers can communicate
with a location-to-PSAP-URI mapping server, i.e. an ECRIT mapping
server. Here we show a DHCP server and a SIP Registrar server.
Message flows will be shown for either case in Section 3.2
We know that Alice will almost certainly require communicating with
an ESRP server prior to her messages being routed to the PSAP. This
message flow will be shown in Section 3.3.
Finally, we will show how Alice will get her configuration
information, and likely still have to communicate through a first
hop proxy server prior to communicating with an ESRP, and on to the
PSAP. This message flow will be shown in Section 3.4.
3. Mapping Scenarios Outlined
Here we have 4 message flow scenarios with one of them having two
parts. These build on each other, more or less, so if a piece isn't
shown in a later scenario, assume it was covered in an earlier
scenario. These are *NOT* exactly how the message flows will exist
on the wires/radios between a user agent and the PSAP. This are
basic models so readers can focus on where ECRIT mapping
functionality can take place in a flow.
3.1 Scenario #1 - Alice Needs Configuration Data
Figure 1 above showed the perfect world scenario in which Alice knew
everything she needed to route her emergency call set-up to the
right PSAP with the first message. That was shown with a 'wink',
because everyone should know it isn't that easy. First of all,
Alice's UA needs configuration information. Why do we show this
seemingly mundane message flow, because ECRIT mapping can exist, or
be requested here.
Polk Expires August 27th, 2006 [Page 5]
Internet-Draft ECRIT Mapping Events Feb 2006
Alice Configuration Server PSAP
Configuration Data Request
-------------------------->
Configuration Data Reply
<--------------------------
Call set-up (sos & location included)
<---------------------------------------------------->
Emergency Call Established
<====================================================>
Figure 2. Basic Message Flow with Config Server Included
Alice, when she requests and receives her local configuration
information to communicate using IP, and when she does the
equivalent booting her SIP processes in the UA, can request a ECRIT
mapping be done. Sections 3.2.1 and 3.2.2 show two different
possibilities of this, based on the model show in Figure 2 above.
3.2 Scenario #2 - Alice Invokes Early ECRIT Mapping
Here we show Alice requesting that one of her configuration servers,
via a configuration protocol, invokes an ECRIT mapping procedure to
provide Alice with the most current PSAP URI at the this time. Two
protocols will be shown here: DHCP and SIP. Of course there are
other protocols that can be used, such as an HTTP query from Alice
once she has her device on-line, or another protocol, perhaps at
layer 2 via an extension to either IEEE's 802.11 or TIA's LLDP-MED.
3.2.1 Scenario #2a - DHCP Requested ECRIT Mapping
Figure 3a shows Alice's UA at initial boot time, sending out a DHCP
DISCOVER message to learn her IP address, default gateway, subnet
mask, and other basic configuration information to just communicate
over IP. It is conceivable that this is the first point that an
ECRIT mapping can be requested. Alice's DHCP client can send out a
request to her DHCP Server to do this ECRIT mapping. This DHCP
Option is documented here [ID-DHC-URI] as one of the URIs that can
be requested of the DHCP Server. In fact, a secondary PSAP-URI can
be requested within this same DHCP Option. That effort is still in
Internet Draft form.
Alice DHCP Server Registrar Mapping Server
[M1] DHCP DISCOVER (IP add, Subnet, Default GW, etc)
---------------->
[M2] DHCP OFFER
<----------------
[M3] DHCP REQUEST or INFORM (Location, PSAP-URI)
---------------->
Polk Expires August 27th, 2006 [Page 6]
Internet-Draft ECRIT Mapping Events Feb 2006
[M4] ECRIT Protocol Query (contains Location)
----------------------------------------->
[M5] ECRIT Protocol Response (contains PSAP-URI)
<-----------------------------------------
[M6] DHCP ACK (contains location & PSAP-URI)
<----------------
Emergency Call set-up initiated
-----------..........------------.....-->
Figure 3a. ECRIT Mapping Performed by DHCP Server
Essentially, the DHCP client requests this PSAP-URI from the DHCP
Server in a DHCP REQUEST or INFORM message (in message [M3]). The
DHCP Server can then using the ECRIT mapping protocol to query the
backend mapping server for this SIP(S)-URI (in message [M4]). This
communication can be secured using whatever mechanisms are available
or specified between the DHCP Server and the Mapping Server to
protect the information from eavesdroppers or anyone messing with
the data. This document can be used to review this fact of these
models as well, but that is not the intent at this time.
Upon reception of the ECRIT mapping response (in message [M5]), the
DHCP server can respond to Alice's client in a DHCP ACK message (in
message [M6]). At this point, Alice's UA has a PSAP SIP(S)-URI,
though, unless Alice calls for help immediately, the information
will be considered 'old' from the PSAP community. This does not
make the information bad, just less reliable.
3.2.2 Scenario #2b - SIP REGISTER Requested ECRIT Mapping
The second means of transferring configuration information to
Alice's UA is during the SIP processes boot time. In SIP, this is
accomplished with a SIP REGISTER Request message [RFC3261].
Included in Figure 3b is the DHCP messages, but without DHCP doing
the ECRIT mapping function.
It is important to understand that Alice's UA could have tried to
learn this PSAP URI from DHCP, but the DHCP ACK message did not
return an answer. The DHCP protocol ignores requests for Options
the Server does not understand [RFC2131]. As a result, Alice's SIP
processes should know this, based on its upgraded code, and
requested the information at the SIP layer as a backup.
Polk Expires August 27th, 2006 [Page 7]
Internet-Draft ECRIT Mapping Events Feb 2006
Alice DHCP Server Registrar Mapping Server
[M1] DHCP DISCOVER (IP add, Subnet, Default GW, etc)
---------------->
[M2] DHCP OFFER
<----------------
[M3] DHCP REQUEST or INFORM (Location)
---------------->
[M4] DHCP ACK
<----------------
[M5] REGISTER (PIDF-LO)
------------------------------------->
[M6] ECRIT Protocol Query (contains Location)
------------------->
[M7] ECRIT Protocol Response (contains PSAP-URI)
<-------------------
[M8] 200 OK (PSAP URI)
<-------------------------------------
Emergency Call set-up initiated
-----------..........------------.....-->
Figure 3b. Basic Message Flow with Config Server Included
After Alice's UA requests [M3] and receives location [M4] from her
DHCP server, and perhaps after it doesn't receive a PSAP URI in
DHCP, Figure 3b shows her UA transmitting a SIP REGISTER Request
message to her Registrar server [M5] [ID-L7-MAP]. If she wants her
PSAP URI, she'll need to include a PIDF-LO of her location
[RFC4119], and request that the Registrar server perform an ECRIT
mapping function [M6]. A positive response to this request, with
PSAP-URI will be a 200 OK response message [M8].
At this point *or* just as it was true after receiving has a PSAP
SIP(S)-URI though DHCP, unless Alice calls for help immediately, the
information will also be considered 'old' as far as the PSAP
community is concerned. This also does not make the information
bad, just less reliable.
NOTE - this message flow could be reduced by not including the DHCP
messages if Alice's UA were manually configured with
location, or location was learned from either an internal GPS
measurements, or a non-IP communication such as something a
cellular network or 802.11 WiFi communication. The focus of
the flow in Figure 3b is on SIP requesting the PSAP URI at
device registration time.
UA configuration, perhaps bound by local regulation, would handle
what to do if a UA were to initiate an ECRIT mapping function at
Polk Expires August 27th, 2006 [Page 8]
Internet-Draft ECRIT Mapping Events Feb 2006
DHCP and via a SIP REGISTER (or SUBSCRIBE) Request, and receive more
than one answer, perhaps one per protocol attempted.
Perhaps someone should write up a UA Device configuration document
specifying what a UA needs to be able to do, at a minimum, with this
and many other situations (wink).
3.3 Scenario #3 - Message Flow to PSAP without Early ECRIT Mapping
Figure 4. is a bit of a step backwards, because there is no early
ECRIT mapping performed, but this is the current basic ECRIT message
flow model, with the liberty taken to include DHCP to learn
location. Either the device requested a PSAP URI in the DHCP INFORM
(in [M3]) and didn't get it in the response DHCP ACK (in [M4]), or
the device did not request for early ECRIT mapping to performed.
This scenario also omits using SIP REGISTER to invoke the ECRIT
mapping query (all from Section 3.2).
Alice DHCP ESRP Mapping Server PSAP
[M1] DHCP DISCOVER (IP add, etc)
---------->
[M2] DHCP OFFER
<---------
[M3] DHCP REQUEST or INFORM (Location)
---------->
[M4] DHCP ACK (includes location)
<---------
[M5] INVITE (sos, PIDF-LO)
--------------------->
[M6] ECRIT Query
----------------->
[M7] ECRIT Response
<-----------------
[M8] INVITE (Request-URI to PSAP)
-------------------------------------->
[M9] 200 OK
<--------------------------------------------------------------
[M10] ACK
-------------------------------------------------------------->
Session Established
<=============================================================>
Figure 4. Basic Message Flow without Early ECRIT Mapping
Messages 1-4 are normal DHCP messages. [M3] includes a request for
the UA's location. [M4] includes the UA's location in the DHCP ACK
Polk Expires August 27th, 2006 [Page 9]
Internet-Draft ECRIT Mapping Events Feb 2006
message.
Message [M5] is Alice calling for emergency help. Her UA
understands this is an emergency call, so it sets the Request-URI
appropriately to urn:services:sos and includes the PIDF-LO either
by-value in a message body or by-reference in a SIP Location header
[ID-SIP-LOC]. This message is routed to an ESRP, which recognizes
it as an emergency request, and invokes a ECRIT mapping query to the
Emergency Mapping Server (in message [M6]). The ECRIT response is
in message [M7]. The ESRP modifies the INVITE through normal SIP
procedures outlined in [RFC3261], plus replaces the Request-URI
field of urn:services:sos with the PSAP-URI, likely a SIPS-URI.
This message retains the Location information of Alice's UA. [M9]
and [M10] compete this simplistic call set-up and the emergency call
is established between Alice and the PSAP.
A choice in this message flow that has not been discussed, but can
be brought up here, is whether or not the ESRP will become dialog
stateful in this call? If so, a Record-Route header is inserted in
[M8], and [M9] is destined for the ESRP, which sends the 200 OK to
Alice in a different [M10]. Her ACK would not be until [M11], and
it will go to the ESRP, which will pass this message along in a new
[M12].
4. Can Failures of the ECRIT Mapping Function Fail Call Attempts
Given the scenarios outlined in Section 3.3, and reviewing the
scenarios in Section 3.2 (other imagining others not shown, but like
DHCP and SIP, but with other mechanisms or protocols involved), it
appears prudent to discuss what to do if there is an ECRIT mapping
failure here:
Alice DHCP ESRP Mapping Server PSAP
[M1] DHCP DISCOVER (IP add, etc)
---------->
[M2] DHCP OFFER
<---------
[M3] DHCP REQUEST or INFORM (Location)
---------->
[M4] DHCP ACK (includes location)
<---------
[M5] INVITE (sos, PIDF-LO)
--------------------->
[M6] ECRIT Query
----------------->
[M7] ECRIT Response FAILS
<-----------------
?
Polk Expires August 27th, 2006 [Page 10]
Internet-Draft ECRIT Mapping Events Feb 2006
Figure 6. ECRIT Mapping Failure During Call Establishment
What happens if an ESRP receives a failure indication in message
[M7]? Or if it doesn't receive any reply, regardless of the number
of retries?
What happens to this emergency call if there has not been an early
ECRIT mapping function performed?
Would this be the next message in the flow above?
Alice DHCP ESRP Mapping Server PSAP
[M1] DHCP DISCOVER (IP add, etc)
---------->
[M2] DHCP OFFER
<---------
[M3] DHCP REQUEST or INFORM (Option 123, URI Option)
---------->
[M4] DHCP ACK
<---------
[M5] INVITE (sos, PIDF-LO)
--------------------->
[M6] ECRIT Protocol
----------------->
[M7] Map Failure
<-----------------
[M8] 4XX (New Mapping Failure)
<-----------------------
[M9] ACK
--------------------->
Figure 7. ECRIT Mapping Failure During Call Establishment
If Alice's UA received this new 4XX Mapping Failure response, how
would it react?
4.1 Reactive ECRIT Mapping Function After Failure
It appears likely that in order to get to a PSAP, Alice will need to
traverse a ESRP somewhere. Current thinking is that the PSAP will
not trust any request it receives unless it receives it from a
trusted ESRP. This document does not hope to define that trust
relationship establishment. But this would likely go a long way
towards DOS attacks to a raw/direct PSAP-URI. With this thinking in
mind, this likely cannot be the subsequent message flow to Figures 6
and 7:
Polk Expires August 27th, 2006 [Page 11]
Internet-Draft ECRIT Mapping Events Feb 2006
Alice DHCP ESRP Mapping Server PSAP
[M1] DHCP DISCOVER (IP add, etc)
---------->
[M2] DHCP OFFER
<---------
[M3] DHCP REQUEST or INFORM (Location)
---------->
[M4] DHCP ACK
<---------
[M5] INVITE (sos, PIDF-LO)
--------------------->
[M6] ECRIT Protocol
----------------->
[M7] Map Failure
<-----------------
[M8] 4XX (New Mapping Failure)
<-----------------------
[M9] ACK
--------------------->
[M10] DHCP REQUEST or INFORM (Location, URI)
---------->
[M11] ECRIT Protocol Query (contains Location)
------------------------------>
[M12] ECRIT Protocol Response (contains PSAP-URI)
------------------------------>
[M13] DHCP ACK
<---------
[M14] INVITE (Request-URI of DHCP learned PSAP URI)
-------------------------------------------------------------->
[M15] 200 OK (after PSAP questions if this is an attack
because this message didn't come from an ESRP)
<-------------------------------------------------------------
[M16] ACK
-------------------------------------------------------------->
Session Established
<=============================================================>
Figure 8. Reactive Mapping Failure and Recovery
Messages 1-9 are identical to Figure 7. Figure 8 shows that Alice's
UA, upon receiving the new 4XX (Mapping Failure) response message
querying for a fallback ECRIT mapping function. Message 10-13 are
identical from those shown in Section 3.2. Another protocol could
have been used here, such as SIP REGISTER (Section 3.2) for
Polk Expires August 27th, 2006 [Page 12]
Internet-Draft ECRIT Mapping Events Feb 2006
instance. The point is that in this case, Alice waits for a failure
to make her own query to a server that can make an ECRIT Mapping
query for her. Perhaps she can do this ECRIT query on her own, but
why wouldn't she have done this already?
This scenario in Figure 8 appears to be a inefficient, and prone to
failure for the reason stated above, the PSAP will likely treat any
inbound request with a high degree of skepticism if it does not come
from an ESRP (which failed its ECRIT map).
4.2 ESRP Reacts ECRIT Mapping Failure
It appears that a more successful scenario is shown in Figure 9, in
which Alice's UA request for an early ECRIT mapping be done (in
message [M3]), here showing via DHCP, but it could be any protocol
with this functionality. The key to this message flow verses
previous flows, and the one that bring the whole idea of early ECRIT
mapping together in case of a mapping failure at the ESRP, is that
the ESRP has the fallback map in the SIP INVITE. It doesn't have to
generate a new failure message to Alice's UA to have her react to
this event. Her UA has already accounted for this as a possibility.
Message [M7] contains the early ECRIT mapping in a loose route
header, to be used in case the ESRP mapping fails.
Alice DHCP ESRP Mapping Server PSAP
[M1] DHCP DISCOVER (IP add, etc)
---------->
[M2] DHCP OFFER
<---------
[M3] DHCP REQUEST or INFORM (Location, URI)
---------->
[M4] ECRIT Protocol Query (contains Location)
------------------------------>
[M5] ECRIT Protocol Response (contains PSAP-URI)
------------------------------>
[M6] DHCP ACK
<---------
[M7] INVITE (sos, PIDF-LO & early Mapping URI)
--------------------->
[M6] ECRIT Protocol
----------------->
[M7] Map Failure
<-----------------
[M8] INVITE (fallback of Route header)
-------------------------------------->
Polk Expires August 27th, 2006 [Page 13]
Internet-Draft ECRIT Mapping Events Feb 2006
[M9] 200 OK
<--------------------------------------------------------------
[M10] ACK
-------------------------------------------------------------->
Session Established
<=============================================================>
Figure 9. ECRIT Mapping Failure and Recovery During Call
Establishment
Once message [M7 returns with a mapping failure indication, or
doesn't return any indication (a timeout condition), the ESRP will
use what's in the SIP Route header and route message based on that
header field. The ESRP may choose to remove the Route header and
place header field contents with in the INVITE's Request-URI. This
would remove downstream elements from any point of confusion, even
though standard practice in SIP is to route based on the contents of
the top entry in the (loose) Route header. This document does not
make that recommendation, as that ought to be addressed elsewhere.
5. IANA Considerations
This document makes no request of the IANA.
Note to RFC Editor: in the process assigning numbers and building
IANA registries prior to publication, this section will have served
its purpose. It may therefore be removed upon publication as an
RFC.
6. Security Considerations
This document outlines message flows and has no normative text. The
only normative reference is to the ECRIT WG Requirements ID. Other
documents with normative text defining the ECRIT mapping protocol,
as well as DHCP and SIP address how those protocols needs to address
the security considerations.
7. Acknowledgements
Your name here
8. References
8.1 Normative References
[ID-ECRIT-REQS] H. Schulzrinne, R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-04.txt, "work in progress",
January 2006
Polk Expires August 27th, 2006 [Page 14]
Internet-Draft ECRIT Mapping Events Feb 2006
8.2 Informative References
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
progress", January 2006
[ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-00, "work in
progress", January 2006
[ID-DHC-URI] J. Polk, "A Dynamic Host Configuration Protocol Option
for Requesting and Receiving Uniform Resource Identifiers",
draft-polk-dhc-uri-02.txt, "work in progress", October 2005
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-
sip-location-conveyance-01.txt, "work in progress", June
2005
[ID-L7-MAP] J. Polk, " ECRIT Mapping During Session Initiation
Protocol Registration",
draft-polk-ecrit-mapping-during-registration-00, "work in
progress", February 2006
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Fax: none
Email: jmpolk@cisco.com
Polk Expires August 27th, 2006 [Page 15]
Internet-Draft ECRIT Mapping Events Feb 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk Expires August 27th, 2006 [Page 16]