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

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Mon, 11 October 2004 21:32 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 RAA00950 for <sipping-emergency-web-archive@ietf.org>; Mon, 11 Oct 2004 17:32:11 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7wm-0005gY-DQ for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 17:43:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH7Zj-0003nk-FR; Mon, 11 Oct 2004 17:19:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH71l-0001Kd-0u for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 16:44:18 -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 QAA22542 for <sipping-emergency@ietf.org>; Mon, 11 Oct 2004 16:44:14 -0400 (EDT)
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7CM-0002wQ-Cn for sipping-emergency@ietf.org; Mon, 11 Oct 2004 16:55:14 -0400
Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9BKi8pl016960; Mon, 11 Oct 2004 16:44:08 -0400 (EDT)
Message-ID: <416AF07D.3020008@dynamicsoft.com>
Date: Mon, 11 Oct 2004 16:43:41 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
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="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
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: 5d7a7e767f20255fce80fa0b77fb2433
Content-Transfer-Encoding: 7bit

Sounds good to me.

-Jonathan R.

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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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