Re: [Sipping-emergency] proposed charter, new wg on emergency calling and routing

Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 27 September 2004 13:13 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 JAA27498 for <sipping-emergency-web-archive@ietf.org>; Mon, 27 Sep 2004 09:13:45 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBvRk-0005cM-HL for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 09:21:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBv7F-0003o6-18; Mon, 27 Sep 2004 09:00:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBuwf-0002fX-37 for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 08:49:33 -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 IAA26315 for <sipping-emergency@ietf.org>; Mon, 27 Sep 2004 08:49:31 -0400 (EDT)
Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBv4H-0005EV-Nz for sipping-emergency@ietf.org; Mon, 27 Sep 2004 08:57:26 -0400
Received: from razor.cs.columbia.edu (IDENT:qDfYMgtTOy2U+BFFlaJEqg6HgOjdXrTM@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8RCnRwG012763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 27 Sep 2004 08:49:27 -0400 (EDT)
Received: from [127.0.0.1] (IDENT:yRRvD7VxmvVjOOzo02R+Ohg4uEa+TqkV@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8RCnLYZ010804; Mon, 27 Sep 2004 08:49:21 -0400
Message-ID: <41580C50.9070105@cs.columbia.edu>
Date: Mon, 27 Sep 2004 08:49:20 -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] proposed charter, new wg on emergency calling and routing
References: <7927C67249E4AD43BC05B539AF0D129801AF41CD@stntexch04.cis.neustar.com>
In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF41CD@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.9.26.0
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: sipping-emergency@ietf.org, "'mankin@psg.com'" <mankin@psg.com>
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.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit

I'm glad to see some progress on this issue.

My concern is that the charter already specifies or biases the solution. 
I know Ted has a particular solution in mind, possibly influenced by his 
experience at his day job, but this is far from what most people who 
have been actively working in this area have been discussing. Thus, my 
concerns are primarily with the paragraphs below:


> Standards Track RFC describing a query protocol for Emergency Service
> Context
> lookup  by physical location.  Update, insert, and modification of the data
> associated
> with ERC's is out of scope for this work item.
>     (IRIS might be a candidate protocol here--it is a query only protocol
> for registry data,
>      which is one way to model the back end store mapping location to ERC).
> 
> BCP describing the call routing strategies for ip911.
>     (e.g.:  does an ERC have a sip: URI to talk to, or do we need to last
> mile via PSTN?)
> 
> BCP describing how to discover ERC capabilities.
>     (can a deaf person IM this center or can we route through a relay?)
> 
> Threats and security documentation
>     (mainly pointers, but the pointers need to be gathered).

I believe that the description misses a core requirement, namely the 
ability to administer the system in a fully decentralized manner that 
reflects the current administrative boundaries and delebation of 
responsibilities. It also must be international, i.e., it cannot just 
work for the US (or pick any other country) or require a US entity to 
manage the system.

It would have been nice to recognize that there has been work going on 
this area for several years, but maybe that's too much to ask.

Henning

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