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

Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 11 October 2004 17:59 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 NAA27930 for <sipping-emergency-web-archive@ietf.org>; Mon, 11 Oct 2004 13:59:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4cj-0004zW-UG for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 14:10:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4LN-0001No-MS; Mon, 11 Oct 2004 13:52:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4JV-0000xw-GO for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 13:50:25 -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 NAA26990 for <sipping-emergency@ietf.org>; Mon, 11 Oct 2004 13:50:23 -0400 (EDT)
Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4U1-0004me-PE for sipping-emergency@ietf.org; Mon, 11 Oct 2004 14:01:21 -0400
Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9BHnbuu019375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Oct 2004 13:49:43 -0400 (EDT)
Message-ID: <416AC7AC.5010304@cs.columbia.edu>
Date: Mon, 11 Oct 2004 13:49:32 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Subject: Re: [Sipping-emergency] New revision of proposed ECRIT charter
References: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com>
In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.10.0
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0'
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: 7bit
Cc: sipping-emergency@ietf.org
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: 287c806b254c6353fcb09ee0e53bbc5e
Content-Transfer-Encoding: 7bit

Looks good to me, seconding the comments made by others.

Peterson, Jon wrote:
> 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