[Sipping-emergency] New revision of proposed ECRIT charter

"Peterson, Jon" <jon.peterson@neustar.biz> Mon, 11 October 2004 06:03 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22431 for <sipping-emergency-web-archive@ietf.org>; Mon, 11 Oct 2004 02:03:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGtRz-00086x-Ei for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 02:14:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGtG0-0007oF-GY; Mon, 11 Oct 2004 02:02:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGtFO-0007Tc-Ck for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 02:01:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20040 for <sipping-emergency@ietf.org>; Mon, 11 Oct 2004 02:01:25 -0400 (EDT)
Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGtPr-00084m-Lm for sipping-emergency@ietf.org; Mon, 11 Oct 2004 02:12:15 -0400
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9B60sPm010547 for <sipping-emergency@ietf.org>; Mon, 11 Oct 2004 06:00:55 GMT
Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id <T32L38M8>; Mon, 11 Oct 2004 02:00:54 -0400
Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: sipping-emergency@ietf.org
Date: Mon, 11 Oct 2004 02:00:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="ISO-8859-1"
X-Spam-Score: 0.8 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Subject: [Sipping-emergency] New revision of proposed ECRIT charter
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: sipping-emergency.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e

All,

Here's a new version of the ECRIT charter for your consideration, that
attempts to incorporate the discussion over the past couple of weeks.

Any further issues?

Jon Peterson
NeuStar, Inc.

---

Emergency Context  Resolution with Internet Technologies (ECRIT)

Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor: TBD

Working Group Chairs:  TBD

In a number of areas the public switched telephone network (PSTN)
has been configured to recognize an explicitly specified number (commonly
one that is short and easily memorized) as a call for emergency services.  
These numbers (e.g. 911, 112) relate to an emergency service context and
depend
on a broad, regional configuration of service contact methods and a
geographically
constrained context of service delivery.  These calls are intended to be
delivered to
special call  centers equipped to manage emergency response. Successful
delivery
of an emergency service call within those systems requires both an
association of
the physical location of the originator with  an appropriate emergency
service
center and call routing to deliver the call to the center.

Calls placed using Internet technologies do not use the same systems to
achieve those goals, and the common use of overlay networks and tunnels
(either as VPNs or for mobility) makes meeting them more challenging.  There
are, however, Internet technologies available to describe location and to
manage call routing.  This working group will describe when these may be
appropriate
and how they may be used.   Explicitly outside the scope of this group
is the question of pre-emption or prioritization of emergency services
traffic. This group is considering emergency services calls which might be
made by
any user of the PSTN or Internet, as opposed to government or military
services that may impose very different authentication  and routing
requirements.

The group will show how the availability of location data and call routing
information
at different steps in  session setup would enable communication between a
user
and a relevant emergency response center. Though the term "call routing" is
used in this
document, it should be understood that some of the mechanisms which 
will be described might be used to enable other types of media 
streams. Video and text messaging, for example, might be used to request
emergency services.

While this group anticipates a close working relationship with NENA, any
solution
presented must be useful regardless of jurisdiction, and it must be possible
to
use without a single, central authority.  Further, it must be possible for
multiple
delegations within a jurisdiction to be handled independently, as call
routing
for specific emergency types may be indepdent.

Deliverables:

Informational RFC containing terminology definitions and the requirements.

A BCP describing how to identify a session set-up request is to an emergency
response center.

A BCP describing strategies for associating session originators with 
physical locations.

A BCP or Standards Track RFC describing how to route an emergency call
based on location information.  Either within that document or as a separate
document, a description of how error conditions are returned to the session
originator and how to test for error conditions without activating an
emergency
response.  Privacy concerns related to that testing must be addressed
in this document set.

A BCP describing how to discover the media stream types an ERC supports.

An Informational document describing the threats and security
considerations.


_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency