RE: [Sipping-emergency] New revision of proposed ECRIT charter

Roger Marshall <RMarshall@seattle.telecomsys.com> Fri, 15 October 2004 17:50 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 NAA24221 for <sipping-emergency-web-archive@ietf.org>; Fri, 15 Oct 2004 13:50:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWPU-0005P2-KB for sipping-emergency-web-archive@ietf.org; Fri, 15 Oct 2004 14:02:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWD0-0000cs-R0; Fri, 15 Oct 2004 13:49:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWB5-0000Ht-Uh for sipping-emergency@megatron.ietf.org; Fri, 15 Oct 2004 13:47:44 -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 NAA24006 for <sipping-emergency@ietf.org>; Fri, 15 Oct 2004 13:47:42 -0400 (EDT)
Received: from [206.173.41.176] (helo=sea-mailsweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWMU-0005KD-JJ for sipping-emergency@ietf.org; Fri, 15 Oct 2004 13:59:31 -0400
Received: from sea-exchange-1.xypoint.com (unverified [10.32.12.12]) by sea-mailsweep-1.telecomsys.com (Content Technologies SMTPRS 4.3.14) with ESMTP id <T6ca89b7c330a20001fc98@sea-mailsweep-1.telecomsys.com>; Fri, 15 Oct 2004 10:47:10 -0700
Received: by sea-exchange-1.telecomsys.com with Internet Mail Service (5.5.2656.59) id <4RC2PL5H>; Fri, 15 Oct 2004 10:47:22 -0700
Message-ID: <8C837214C95C864C9F34F3635C2A6575CE35AA@SEA-EXCHVS-2.telecomsys.com>
From: Roger Marshall <RMarshall@seattle.telecomsys.com>
To: "Peterson, Jon" <jon.peterson@neustar.biz>, sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter
Date: Fri, 15 Oct 2004 10:47:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
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: 944ecb6e61f753561f559a497458fb4f

Looks fine to me, whith amendments as suggested by others.

Roger Marshall
TCS

-----Original Message-----
From: sipping-emergency-bounces@ietf.org
[mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Sunday, October 10, 2004 11:01 PM
To: sipping-emergency@ietf.org
Subject: [Sipping-emergency] New revision of proposed ECRIT charter


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

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