From sipping-emergency-bounces@ietf.org Thu Sep 23 11:04:29 2004 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 LAA20752 for ; Thu, 23 Sep 2004 11:04:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVFu-0001Tg-Ie for sipping-emergency-web-archive@ietf.org; Thu, 23 Sep 2004 11:11:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUsb-0001CG-2m; Thu, 23 Sep 2004 10:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUqs-0000Vz-L1 for sipping-emergency@megatron.ietf.org; Thu, 23 Sep 2004 10:45:42 -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 KAA18882 for ; Thu, 23 Sep 2004 10:45:39 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAUxc-0000st-NP for sipping-emergency@ietf.org; Thu, 23 Sep 2004 10:52:44 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8NEj3M15430 for ; Thu, 23 Sep 2004 10:45:03 -0400 (EDT) Received: from [47.130.16.114] (acart03q.ca.nortel.com [47.130.16.114]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNP27B7; Thu, 23 Sep 2004 10:45:03 -0400 Message-ID: <4152E16B.9080902@nortelnetworks.com> Date: Thu, 23 Sep 2004 10:44:59 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping-emergency@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] test X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Checking to see if I'm still subscribed. I haven't seen anything from this list for months. Tom Taylor _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 05:33:21 2004 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 FAA15242 for ; Mon, 27 Sep 2004 05:33:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBs0Q-0001kF-Ig for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 05:41:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBrpO-0008TL-B8; Mon, 27 Sep 2004 05:29:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBraJ-0007K9-Nf for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 05:14:15 -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 FAA14529 for ; Mon, 27 Sep 2004 05:14:13 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBrhu-0001Us-ET for sipping-emergency@ietf.org; Mon, 27 Sep 2004 05:22:06 -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 i8R9DiPm009771; Mon, 27 Sep 2004 09:13:44 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 05:13:44 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41CD@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: sipping-emergency@ietf.org Date: Mon, 27 Sep 2004 05:13:34 -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 X-Mailman-Approved-At: Mon, 27 Sep 2004 05:29:49 -0400 Cc: "'mankin@psg.com'" Subject: [Sipping-emergency] proposed charter, new wg on emergency calling and routing X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Greetings SIPPING-emergency folk, Allison and I are considering the following proposal from Ted Hardie for a new working group in the Transport Area focusing on emergency call routing. We'd like some feedback from SIPPING-emergency subscribers about the overall propriety of this endeavor and, in particular, the charter text and deliverables attached below. Personally, I think there is a lot of valuable work that we could do in this area, and it is work that currently we ignore at our own hazard. While defining e911 for the Internet as a whole is most likely beyond our collective powers, there are chunks of this problem that really are our responsibility, and we need to address them as best we can. Jon Peterson NeuStar, Inc. ---- Emergency Context Resolution with Internet Technologies (ECRIT) Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: TBD Working Group Chairs: TBD In a number of areas the public switched telephone network (PSTN) has been configured to recognize a short, easily memorized number as a call for emergency services. These numbers 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. 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 specify how those technologies may be used within this context. 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 describe a layered approach to the problem, showing 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 service enter. 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 non-voice communications (e.g. text messaging) where appropriate. Deliverables: Informational RFC describing the problem (needs to be simple and early, early, early) BCP describing strategies for call originators identifying emergency calls. (Including provisioning local targets and use of URIs) BCP describing strategies for associating call originators with physical locations. (Both originator-based and network-based strategies) 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). _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 08:28:03 2004 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 IAA25146 for ; Mon, 27 Sep 2004 08:28:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBujV-0004s4-Pa for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 08:35:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBuYx-0008NV-DI; Mon, 27 Sep 2004 08:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBuQg-0007lq-Sv for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 08:16:31 -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 IAA24054 for ; Mon, 27 Sep 2004 08:16:29 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBuYI-0004aU-Vv for sipping-emergency@ietf.org; Mon, 27 Sep 2004 08:24:23 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8RCFtR18597; Mon, 27 Sep 2004 08:15:55 -0400 (EDT) Received: from [47.130.17.12] (acart092.ca.nortel.com [47.130.17.12]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNPJJ63; Mon, 27 Sep 2004 08:15:56 -0400 Message-ID: <4158047A.3090603@nortelnetworks.com> Date: Mon, 27 Sep 2004 08:15:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" 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-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org, "'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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit The endeavour is reasonable, but I suspect the agenda is a bit broad. Some items seem a bit out of scope for the IETF. Specific comments marked by [PTT]. Peterson, Jon wrote: > Greetings SIPPING-emergency folk, > > Allison and I are considering the following proposal from Ted Hardie for a > new working group in the Transport Area focusing on emergency call routing. > > We'd like some feedback from SIPPING-emergency subscribers about the overall > propriety of this endeavor and, in particular, the charter text and > deliverables attached below. > [snip] [snipped OK goals] > 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). [PTT] This seems to be taken out of someone's conversation. What is an Emergency Service Context? > > 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?) > [PTT] This is surely out of scope. It's a practical network engineering issue rather than a question of technology. > 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). > > > _______________________________________________ > 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 From sipping-emergency-bounces@ietf.org Mon Sep 27 09:13:45 2004 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 ; 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 ; 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 User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" 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'" X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-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 From sipping-emergency-bounces@ietf.org Mon Sep 27 10:03:53 2004 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 KAA00508 for ; Mon, 27 Sep 2004 10:03:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwEG-0006Yz-IP for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 10:11:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBw5Y-0004HM-3B; Mon, 27 Sep 2004 10:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBw1y-00031V-8b for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 09:59:06 -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 JAA00210 for ; Mon, 27 Sep 2004 09:59:03 -0400 (EDT) Message-Id: <200409271359.JAA00210@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBw9R-0006Uq-1M for sipping-emergency@ietf.org; Mon, 27 Sep 2004 10:06:59 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CBw1g-000717-Po; Mon, 27 Sep 2004 08:58:49 -0500 From: "Brian Rosen" To: "'Peterson, Jon'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 09:58:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSkdQhDTOEyFFyqSJumB0bezm2/5wAHCCmA In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF41CD@stntexch04.cis.neustar.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.8 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Cc: 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: 7bit I am very happy to see some motion on this very pressing problem. In the absence of IETF work, other national or regional groups are working on solutions that are contrary to the "no national variants" of the Internet. I do think mention should be made of other work, perhaps explicitly soliciting requirements from such entities as NENA and ETSI EMTEL. There are several problems that need to be solved that go beyond this particular problem statement. The most significant is that the location that is supplied needs to be "validated" prior to using it. This is a primary problem, and it's essential that it be included in the charter. I believe that making scope so narrow that only routing is considered would be a serious mistake. Another issue is that while in some jurisdictions, there is a single location to which calls are directed, in some, the nature of the emergency determines the routing. Another issue missing from the charter is an explicit inclusion of both civic and geo locations (street address and lat/lon/altitude). The charter needs to cover location precision to at least a room. It's not clear if this is in scope or not. The mechanism to determine location is not in scope, but representation, and thus validation, should be. Specific suggestions on the wording of the charter follow: > > Emergency Context Resolution with Internet Technologies (ECRIT) if validation of location is considered, this would not be a great name > > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: TBD > > Working Group Chairs: TBD I volunteer > > In a number of areas the public switched telephone network (PSTN) > has been configured to recognize a short, easily memorized number as > a call for emergency services. These numbers 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. 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. This is incorrect. You don't always have a short number, choice of number is currently explicitly national (with the single exception of the EU 112 number primarily limited to mobile). There is more to location within emergency calling besides "context" and there are more than location that may determine the appropriate call center. Perhaps: Calling for help using the publics switched telephone network (PSTN) is a primary function which must be provided for in any Internet based communication system. Emergency calls for assistance are answered at special call centers. An emergency call must be directed to the correct call center, which depends on the location of the caller and in some jurisdictions, the nature of the emergency. The call itself must include the location either directly or indirectly. Prior to use for determining a call center location must be determined to be valid (known to the call center as a location to which help may be dispatched). > > 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. Okay > There are, however, Internet technologies available to describe location > and > to manage call routing. This working group will specify how those > technologies > may be used within this context. This presupposes that the available technologies are appropriate. This might be true, but it might not. Perhaps: Describing location and carriage of location within various protocols is defined in other IETF working groups. This working group will specify how location, in both civic and geospatial forms can be validated and used to route calls. >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. Is this an attempt to avoid the scope of IEPREP? If so, it's incorrect. IEPREP is concerned with an entirely different kind of call - one made by a responder using the existing facilities using a priority. Agree that this is out of scope. There is no call for assistance (9-1-1/1-1-2) that has preemption that I am aware of. Priority for emergency calls is often imposed by carriers, but rarely required. If you intended to avoid IEPREP, perhaps: This group is concerned with calls made by ordinary users to request emergency assistance. Emergency calls by responders using Internet facilities are the province of the IEPREP working group and out of scope for this working group. > > The group will describe a layered approach to the problem, showing 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 > service enter. It's not clear that there is any layering. I think this wording doesn't advance anyone's understanding of what the work is. Perhaps: This group will describe how location may be validated prior to use, and how validated location may be used to route calls to the correct emergency call 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 non-voice communications (e.g. text messaging) where appropriate. I'm not sure what is implied here. There are two kinds of text messaging protocols that might be used: Instant messaging and interactive text streams. Both have the notion of "session". Perhaps: While current emergency calls are voice only, the Internet provides a variety of media streams that may be used to summon help. This work will include voice, video and Instant Messaging as well as interactive text. > > Deliverables: > > Informational RFC describing the problem > (needs to be simple and early, early, early) > > BCP describing strategies for call originators identifying emergency > calls. > (Including provisioning local targets and use of URIs) This is somewhat problematic as it overlaps protocol groups. Maybe need to qualify this as with the concurrence of such groups (I'm thinking SIPPING and XMPP). Wording may need a hint of the "nature of the emergency" problem. > > BCP describing strategies for associating call originators with > physical locations. > (Both originator-based and network-based strategies) I'm not sure what is meant here. Right now, I think most endpoints learn location from DHCP and supply it using SIP/XMPP with PIDF-LO. It's worth saying that somewhere. Is that what was intended by this? I hope you did not intend to imply network based insertion of location in call flows; I think we are constrained by geopriv to have endpoints learn location and supply it on emergency calls. Need a new requirement Standards Track RFC describing how location is validated prior to use. > > 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. I don't see how you can ignore how the data is maintained. I suppose it depends on the query mechanism; if you choose the right query mechanism, there may already be mechanisms for maintaining data. > (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). This should be deleted. You don't know what query mechanism to use. If, for example, you use the DNS, than this is incorrect. > > BCP describing the call routing strategies for ip911. very poor choice of acronym; has U.S. implication. Use ipSOS > (e.g.: does an ERC have a sip: URI to talk to, or do we need to last > mile via PSTN?) I suspect we DON'T want to work on migration strategies. Just assume the ERC can terminate a SIP call. It's too late for IETF to wade into that one. > > BCP describing how to discover ERC capabilities. > (can a deaf person IM this center or can we route through a relay?) I'm skeptical of this, again crosses protocol groups boundaries. Problem does need to be solved. Perhaps: BCP describing how routing may be affected by capabilities in the ERC or constraints on the caller (e.g. caller with disabilities engaging a relay service). > > Threats and security documentation > (mainly pointers, but the pointers need to be gathered). > Brian _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 11:38:41 2004 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 LAA08330 for ; Mon, 27 Sep 2004 11:38:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBxi2-0008MJ-JF for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 11:46:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxZp-0008Bl-4h for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 11:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxYx-000839-UK for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 11:37:16 -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 LAA08270 for ; Mon, 27 Sep 2004 11:37:12 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBxgb-0008KW-CP for sipping-emergency@ietf.org; Mon, 27 Sep 2004 11:45:10 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 27 Sep 2004 08:37:40 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8RFaelr002838; Mon, 27 Sep 2004 08:36:41 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA02299; Mon, 27 Sep 2004 08:36:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20040927101840.028c0200@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Sep 2004 10:36:15 -0500 To: "Brian Rosen" , "'Peterson, Jon'" , From: "James M. Polk" Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing In-Reply-To: <200409271359.JAA00210@ietf.org> References: <7927C67249E4AD43BC05B539AF0D129801AF41CD@stntexch04.cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.1 (+++) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 3.1 (+++) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 I'd like to make several points: Brian mentions geo-location needing to be validated prior to being used in this application - yet we know this is not possible. I find that interesting. Regarding civil location being validated prior to use: Brain's alternate wording makes it appear this application is the primary purpose for providing location into endpoints, that location needs to be run by the local emergency services company/org/gov entity to be considered 'good enough' for use with all forms of location conveyance, and I think that's getting ahead of ourselves. Location conveyances will be a multi-billion $$ industry that should not have to be vetted through this process just to be used. His wording seems to (flat out does) make it necessary for any element location to be validated before anything else can happen - even the call. Is this really true? What happens if a location is not validated? I agree location precision needs to be addressed. I agree that some jurisdictions route a call based on the nature of the emergency (to police, to medical, to marine, to mountain rescue, etc), and should be mentioned in the routing of the call portion of the charter. Video should be mentioned (just as IM was). Rerouting of the media stream from the ERC to the responders (either to their base facilities or to those in the field), or between ERCs should be mentioned. At 09:58 AM 9/27/2004 -0400, Brian Rosen wrote: >I am very happy to see some motion on this very pressing problem. In the >absence of IETF work, other national or regional groups are working on >solutions that are contrary to the "no national variants" of the Internet. >I do think mention should be made of other work, perhaps explicitly >soliciting requirements from such entities as NENA and ETSI EMTEL. > >There are several problems that need to be solved that go beyond this >particular problem statement. The most significant is that the location >that is supplied needs to be "validated" prior to using it. This is a >primary problem, and it's essential that it be included in the charter. >I believe that making scope so narrow that only routing is considered would >be a serious mistake. > >Another issue is that while in some jurisdictions, there is a single >location to which calls are directed, in some, the nature of the emergency >determines the routing. > >Another issue missing from the charter is an explicit inclusion of both >civic and geo locations (street address and lat/lon/altitude). > >The charter needs to cover location precision to at least a room. It's not >clear if this is in scope or not. The mechanism to determine location is >not in scope, but representation, and thus validation, should be. > >Specific suggestions on the wording of the charter follow: > > > > > > Emergency Context Resolution with Internet Technologies (ECRIT) >if validation of location is considered, this would not be a great name > > > > > > Transport Area Director(s): > > Allison Mankin > > Jon Peterson > > > > Transport Area Advisor: TBD > > > > Working Group Chairs: TBD >I volunteer > > > > > In a number of areas the public switched telephone network (PSTN) > > has been configured to recognize a short, easily memorized number as > > a call for emergency services. These numbers 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. 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. >This is incorrect. You don't always have a short number, choice of number >is currently explicitly national (with the single exception of the EU 112 >number primarily limited to mobile). There is more to location within >emergency calling besides "context" and there are more than location that >may determine the appropriate call center. > >Perhaps: >Calling for help using the publics switched telephone network (PSTN) is a >primary function which must be provided for in any Internet based >communication system. Emergency calls for assistance are answered at >special call centers. An emergency call must be directed to the correct >call center, which depends on the location of the caller and in some >jurisdictions, the nature of the emergency. The call itself must include >the location either directly or indirectly. Prior to use for determining a >call center location must be determined to be valid (known to the call >center as a location to which help may be dispatched). > > > > 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. >Okay > > > There are, however, Internet technologies available to describe location > > and > > to manage call routing. This working group will specify how those > > technologies > > may be used within this context. >This presupposes that the available technologies are appropriate. This >might be true, but it might not. Perhaps: >Describing location and carriage of location within various protocols is >defined in other IETF working groups. This working group will specify how >location, in both civic and geospatial forms can be validated and used to >route calls. > > >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. >Is this an attempt to avoid the scope of IEPREP? If so, it's incorrect. >IEPREP is concerned with an entirely different kind of call - one made by a >responder using the existing facilities using a priority. Agree that this >is out of scope. There is no call for assistance (9-1-1/1-1-2) that has >preemption that I am aware of. Priority for emergency calls is often >imposed by carriers, but rarely required. If you intended to avoid IEPREP, >perhaps: >This group is concerned with calls made by ordinary users to request >emergency assistance. Emergency calls by responders using Internet >facilities are the province of the IEPREP working group and out of scope for >this working group. > > > > > The group will describe a layered approach to the problem, showing 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 > > service enter. >It's not clear that there is any layering. I think this wording doesn't >advance anyone's understanding of what the work is. Perhaps: >This group will describe how location may be validated prior to use, and how >validated location may be used to route calls to the correct emergency call >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 non-voice communications (e.g. text messaging) where appropriate. >I'm not sure what is implied here. There are two kinds of text messaging >protocols that might be used: Instant messaging and interactive text >streams. Both have the notion of "session". Perhaps: >While current emergency calls are voice only, the Internet provides a >variety of media streams that may be used to summon help. This work will >include voice, video and Instant Messaging as well as interactive text. > > > > > > Deliverables: > > > > Informational RFC describing the problem > > (needs to be simple and early, early, early) > > > > BCP describing strategies for call originators identifying emergency > > calls. > > (Including provisioning local targets and use of URIs) >This is somewhat problematic as it overlaps protocol groups. >Maybe need to qualify this as with the concurrence of such groups (I'm >thinking SIPPING and XMPP). Wording may need a hint of the "nature of the >emergency" problem. > > > > > BCP describing strategies for associating call originators with > > physical locations. > > (Both originator-based and network-based strategies) >I'm not sure what is meant here. Right now, I think most endpoints learn >location from DHCP and supply it using SIP/XMPP with PIDF-LO. It's worth >saying that somewhere. Is that what was intended by this? I hope you did >not intend to imply network based insertion of location in call flows; I >think we are constrained by geopriv to have endpoints learn location and >supply it on emergency calls. > >Need a new requirement >Standards Track RFC describing how location is validated prior to use. > > > > > 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. >I don't see how you can ignore how the data is maintained. I suppose it >depends on the query mechanism; if you choose the right query mechanism, >there may already be mechanisms for maintaining data. > > > (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). >This should be deleted. You don't know what query mechanism to use. If, >for example, you use the DNS, than this is incorrect. > > > > > BCP describing the call routing strategies for ip911. >very poor choice of acronym; has U.S. implication. Use ipSOS > > > (e.g.: does an ERC have a sip: URI to talk to, or do we need to last > > mile via PSTN?) >I suspect we DON'T want to work on migration strategies. Just assume the >ERC can terminate a SIP call. It's too late for IETF to wade into that one. > > > > > BCP describing how to discover ERC capabilities. > > (can a deaf person IM this center or can we route through a relay?) >I'm skeptical of this, again crosses protocol groups boundaries. Problem >does need to be solved. Perhaps: >BCP describing how routing may be affected by capabilities in the ERC or >constraints on the caller (e.g. caller with disabilities engaging a relay >service). > > > > Threats and security documentation > > (mainly pointers, but the pointers need to be gathered). > > > > >Brian > > > > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 12:25:37 2004 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 MAA10823 for ; Mon, 27 Sep 2004 12:25:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CByRJ-0000fn-4B for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 12:33:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CByEc-0002tc-Uk; Mon, 27 Sep 2004 12:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxyo-00072v-Bz for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 12:03:58 -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 MAA09890 for ; Mon, 27 Sep 2004 12:03:55 -0400 (EDT) Message-Id: <200409271603.MAA09890@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBy6S-0000ML-AH for sipping-emergency@ietf.org; Mon, 27 Sep 2004 12:11:53 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CBxyi-0004ZC-B2; Mon, 27 Sep 2004 11:03:52 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Peterson, Jon'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 12:03:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSkp8qsl4eL4szkRb2UrOQJVzqwAAAAM2xg In-Reply-To: <4.3.2.7.2.20040927101840.028c0200@localhost> Importance: Low X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.8 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Content-Transfer-Encoding: 7bit Cc: 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Content-Transfer-Encoding: 7bit When you place an emergency call, the location is used to determine where to send the call, and it is used to dispatch responders. If the location you supply does not match anything the call center recognizes, the wrong thing may happen. What you want to do is to compare the address you have against a list maintained by the emergency response system to make sure they know where that is. An example is illustrative. If you ask me my home address, I'd tell you that it is 470 Conrad Drive, Mars, PA. However, that is NOT the address that should be used to determine where to send an emergency call from my home. That is because the post office boundary is not the same as the emergency call system boundary. If you were to determine the serving ERC without validation, you would send my emergency call to the Butler County ERC, which serves Mars, rather than to the NEWCOM center that serves Pine Township, where I live. There are many, many such problems. The solution is that you validate the address before use. There is no street named "Conrad" in Mars. Oh, there might be, which is another one of those "many, many such problems". Similarly, if the ERC doesn't know how to dispatch the call, even if it comes to the correct ERC, people can die. You don't mess around with the quality of the data here. You validate it before you use it. Very few people know about this problem. It wouldn't be obvious to me if I hadn't been involved with this area for the last couple years. It isn't actually all that interesting to most users of location. I don't care if commercial users validate or not. I care that we specify the way to validate so that users have confidence they will get help when they need it. You need to do the validation BEFORE you place an emergency call. The system is usually willing to accept an unvalidated location, which can happen because real systems fail, but it treats them specially. You can't get into any discussion with emergency services folks about location without the validation problem coming up early. There is a lot of accumulated experience on that issue which we ignore at our peril. The problem is very real, and there is no way I can see to avoid it. An address has to be compared against the Master address guide, before you use it to make a routing decision, and before you send it to the ERC. Now, to be fair, you don't "validate" a geospatial location. However, you do worry, a whole lot, about the quality if you try to convert from civic to geo before you use the geo. It has all of the same problems; you have to validate the address first. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, September 27, 2004 11:36 AM > To: Brian Rosen; 'Peterson, Jon'; sipping-emergency@ietf.org > Cc: mankin@psg.com > Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency > calling and routing > > I'd like to make several points: > > Brian mentions geo-location needing to be validated prior to being used in > this application - yet we know this is not possible. I find that > interesting. > > Regarding civil location being validated prior to use: Brain's alternate > wording makes it appear this application is the primary purpose for > providing location into endpoints, that location needs to be run by the > local emergency services company/org/gov entity to be considered 'good > enough' for use with all forms of location conveyance, and I think that's > getting ahead of ourselves. Location conveyances will be a multi-billion > $$ > industry that should not have to be vetted through this process just to be > used. > > His wording seems to (flat out does) make it necessary for any element > location to be validated before anything else can happen - even the call. > Is this really true? What happens if a location is not validated? > > I agree location precision needs to be addressed. > > I agree that some jurisdictions route a call based on the nature of the > emergency (to police, to medical, to marine, to mountain rescue, etc), and > should be mentioned in the routing of the call portion of the charter. > > Video should be mentioned (just as IM was). > > Rerouting of the media stream from the ERC to the responders (either to > their base facilities or to those in the field), or between ERCs should be > mentioned. > > At 09:58 AM 9/27/2004 -0400, Brian Rosen wrote: > >I am very happy to see some motion on this very pressing problem. In the > >absence of IETF work, other national or regional groups are working on > >solutions that are contrary to the "no national variants" of the > Internet. > >I do think mention should be made of other work, perhaps explicitly > >soliciting requirements from such entities as NENA and ETSI EMTEL. > > > >There are several problems that need to be solved that go beyond this > >particular problem statement. The most significant is that the location > >that is supplied needs to be "validated" prior to using it. This is a > >primary problem, and it's essential that it be included in the charter. > >I believe that making scope so narrow that only routing is considered > would > >be a serious mistake. > > > >Another issue is that while in some jurisdictions, there is a single > >location to which calls are directed, in some, the nature of the > emergency > >determines the routing. > > > >Another issue missing from the charter is an explicit inclusion of both > >civic and geo locations (street address and lat/lon/altitude). > > > >The charter needs to cover location precision to at least a room. It's > not > >clear if this is in scope or not. The mechanism to determine location is > >not in scope, but representation, and thus validation, should be. > > > >Specific suggestions on the wording of the charter follow: > > > > > > > > > > Emergency Context Resolution with Internet Technologies (ECRIT) > >if validation of location is considered, this would not be a great name > > > > > > > > > Transport Area Director(s): > > > Allison Mankin > > > Jon Peterson > > > > > > Transport Area Advisor: TBD > > > > > > Working Group Chairs: TBD > >I volunteer > > > > > > > > In a number of areas the public switched telephone network (PSTN) > > > has been configured to recognize a short, easily memorized number as > > > a call for emergency services. These numbers 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. 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. > >This is incorrect. You don't always have a short number, choice of > number > >is currently explicitly national (with the single exception of the EU 112 > >number primarily limited to mobile). There is more to location within > >emergency calling besides "context" and there are more than location that > >may determine the appropriate call center. > > > >Perhaps: > >Calling for help using the publics switched telephone network (PSTN) is a > >primary function which must be provided for in any Internet based > >communication system. Emergency calls for assistance are answered at > >special call centers. An emergency call must be directed to the correct > >call center, which depends on the location of the caller and in some > >jurisdictions, the nature of the emergency. The call itself must include > >the location either directly or indirectly. Prior to use for determining > a > >call center location must be determined to be valid (known to the call > >center as a location to which help may be dispatched). > > > > > > 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. > >Okay > > > > > There are, however, Internet technologies available to describe > location > > > and > > > to manage call routing. This working group will specify how those > > > technologies > > > may be used within this context. > >This presupposes that the available technologies are appropriate. This > >might be true, but it might not. Perhaps: > >Describing location and carriage of location within various protocols is > >defined in other IETF working groups. This working group will specify > how > >location, in both civic and geospatial forms can be validated and used to > >route calls. > > > > >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. > >Is this an attempt to avoid the scope of IEPREP? If so, it's incorrect. > >IEPREP is concerned with an entirely different kind of call - one made by > a > >responder using the existing facilities using a priority. Agree that > this > >is out of scope. There is no call for assistance (9-1-1/1-1-2) that has > >preemption that I am aware of. Priority for emergency calls is often > >imposed by carriers, but rarely required. If you intended to avoid > IEPREP, > >perhaps: > >This group is concerned with calls made by ordinary users to request > >emergency assistance. Emergency calls by responders using Internet > >facilities are the province of the IEPREP working group and out of scope > for > >this working group. > > > > > > > > The group will describe a layered approach to the problem, showing 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 > > > service enter. > >It's not clear that there is any layering. I think this wording doesn't > >advance anyone's understanding of what the work is. Perhaps: > >This group will describe how location may be validated prior to use, and > how > >validated location may be used to route calls to the correct emergency > call > >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 non-voice communications (e.g. text messaging) where > appropriate. > >I'm not sure what is implied here. There are two kinds of text messaging > >protocols that might be used: Instant messaging and interactive text > >streams. Both have the notion of "session". Perhaps: > >While current emergency calls are voice only, the Internet provides a > >variety of media streams that may be used to summon help. This work will > >include voice, video and Instant Messaging as well as interactive text. > > > > > > > > > > Deliverables: > > > > > > Informational RFC describing the problem > > > (needs to be simple and early, early, early) > > > > > > BCP describing strategies for call originators identifying emergency > > > calls. > > > (Including provisioning local targets and use of URIs) > >This is somewhat problematic as it overlaps protocol groups. > >Maybe need to qualify this as with the concurrence of such groups (I'm > >thinking SIPPING and XMPP). Wording may need a hint of the "nature of > the > >emergency" problem. > > > > > > > > BCP describing strategies for associating call originators with > > > physical locations. > > > (Both originator-based and network-based strategies) > >I'm not sure what is meant here. Right now, I think most endpoints learn > >location from DHCP and supply it using SIP/XMPP with PIDF-LO. It's worth > >saying that somewhere. Is that what was intended by this? I hope you > did > >not intend to imply network based insertion of location in call flows; I > >think we are constrained by geopriv to have endpoints learn location and > >supply it on emergency calls. > > > >Need a new requirement > >Standards Track RFC describing how location is validated prior to use. > > > > > > > > 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. > >I don't see how you can ignore how the data is maintained. I suppose it > >depends on the query mechanism; if you choose the right query mechanism, > >there may already be mechanisms for maintaining data. > > > > > (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). > >This should be deleted. You don't know what query mechanism to use. If, > >for example, you use the DNS, than this is incorrect. > > > > > > > > BCP describing the call routing strategies for ip911. > >very poor choice of acronym; has U.S. implication. Use ipSOS > > > > > (e.g.: does an ERC have a sip: URI to talk to, or do we need to > last > > > mile via PSTN?) > >I suspect we DON'T want to work on migration strategies. Just assume the > >ERC can terminate a SIP call. It's too late for IETF to wade into that > one. > > > > > > > > BCP describing how to discover ERC capabilities. > > > (can a deaf person IM this center or can we route through a > relay?) > >I'm skeptical of this, again crosses protocol groups boundaries. > Problem > >does need to be solved. Perhaps: > >BCP describing how routing may be affected by capabilities in the ERC or > >constraints on the caller (e.g. caller with disabilities engaging a relay > >service). > > > > > > Threats and security documentation > > > (mainly pointers, but the pointers need to be gathered). > > > > > > > > >Brian > > > > > > > > > >_______________________________________________ > >Sipping-emergency mailing list > >Sipping-emergency@ietf.org > >https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 13:27:34 2004 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 NAA14723 for ; Mon, 27 Sep 2004 13:27:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzPQ-0001oT-E8 for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 13:35:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzCE-0001pZ-Oj; Mon, 27 Sep 2004 13:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBz7b-0001Aa-FJ for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 13:17:08 -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 NAA13789 for ; Mon, 27 Sep 2004 13:17:03 -0400 (EDT) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzFG-0001Zn-32 for sipping-emergency@ietf.org; Mon, 27 Sep 2004 13:25:02 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id i8RHGQA11081 for ; Mon, 27 Sep 2004 13:16:26 -0400 (EDT) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg02.cc.telcordia.com (SAVSMTP 3.1.6.45) with SMTP id M2004092713162526987 for ; Mon, 27 Sep 2004 13:16:25 -0400 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 13:16:25 -0400 Message-ID: From: "Abbott, Nadine B." To: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency ca lling and routing Date: Mon, 27 Sep 2004 13:16:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Completely support the advice Brian is sharing about location validation requirements (at least in North America). Nadine Abbott -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, September 27, 2004 12:04 PM To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org Cc: mankin@psg.com Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Importance: Low When you place an emergency call, the location is used to determine where to send the call, and it is used to dispatch responders. If the location you supply does not match anything the call center recognizes, the wrong thing may happen. What you want to do is to compare the address you have against a list maintained by the emergency response system to make sure they know where that is. An example is illustrative. If you ask me my home address, I'd tell you that it is 470 Conrad Drive, Mars, PA. However, that is NOT the address that should be used to determine where to send an emergency call from my home. That is because the post office boundary is not the same as the emergency call system boundary. If you were to determine the serving ERC without validation, you would send my emergency call to the Butler County ERC, which serves Mars, rather than to the NEWCOM center that serves Pine Township, where I live. There are many, many such problems. The solution is that you validate the address before use. There is no street named "Conrad" in Mars. Oh, there might be, which is another one of those "many, many such problems". Similarly, if the ERC doesn't know how to dispatch the call, even if it comes to the correct ERC, people can die. You don't mess around with the quality of the data here. You validate it before you use it. Very few people know about this problem. It wouldn't be obvious to me if I hadn't been involved with this area for the last couple years. It isn't actually all that interesting to most users of location. I don't care if commercial users validate or not. I care that we specify the way to validate so that users have confidence they will get help when they need it. You need to do the validation BEFORE you place an emergency call. The system is usually willing to accept an unvalidated location, which can happen because real systems fail, but it treats them specially. You can't get into any discussion with emergency services folks about location without the validation problem coming up early. There is a lot of accumulated experience on that issue which we ignore at our peril. The problem is very real, and there is no way I can see to avoid it. An address has to be compared against the Master address guide, before you use it to make a routing decision, and before you send it to the ERC. Now, to be fair, you don't "validate" a geospatial location. However, you do worry, a whole lot, about the quality if you try to convert from civic to geo before you use the geo. It has all of the same problems; you have to validate the address first. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, September 27, 2004 11:36 AM > To: Brian Rosen; 'Peterson, Jon'; sipping-emergency@ietf.org > Cc: mankin@psg.com > Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency > calling and routing > > I'd like to make several points: > > Brian mentions geo-location needing to be validated prior to being > used in this application - yet we know this is not possible. I find > that interesting. > > Regarding civil location being validated prior to use: Brain's > alternate wording makes it appear this application is the primary > purpose for providing location into endpoints, that location needs to > be run by the local emergency services company/org/gov entity to be > considered 'good enough' for use with all forms of location > conveyance, and I think that's getting ahead of ourselves. Location > conveyances will be a multi-billion $$ industry that should not have > to be vetted through this process just to be used. > > His wording seems to (flat out does) make it necessary for any element > location to be validated before anything else can happen - even the > call. Is this really true? What happens if a location is not > validated? > > I agree location precision needs to be addressed. > > I agree that some jurisdictions route a call based on the nature of > the emergency (to police, to medical, to marine, to mountain rescue, > etc), and should be mentioned in the routing of the call portion of > the charter. > > Video should be mentioned (just as IM was). > > Rerouting of the media stream from the ERC to the responders (either > to their base facilities or to those in the field), or between ERCs > should be mentioned. > > At 09:58 AM 9/27/2004 -0400, Brian Rosen wrote: > >I am very happy to see some motion on this very pressing problem. In > >the absence of IETF work, other national or regional groups are > >working on solutions that are contrary to the "no national variants" > >of the > Internet. > >I do think mention should be made of other work, perhaps explicitly > >soliciting requirements from such entities as NENA and ETSI EMTEL. > > > >There are several problems that need to be solved that go beyond this > >particular problem statement. The most significant is that the > >location that is supplied needs to be "validated" prior to using it. > >This is a primary problem, and it's essential that it be included in > >the charter. I believe that making scope so narrow that only routing > >is considered > would > >be a serious mistake. > > > >Another issue is that while in some jurisdictions, there is a single > >location to which calls are directed, in some, the nature of the > emergency > >determines the routing. > > > >Another issue missing from the charter is an explicit inclusion of > >both civic and geo locations (street address and lat/lon/altitude). > > > >The charter needs to cover location precision to at least a room. > >It's > not > >clear if this is in scope or not. The mechanism to determine > >location is not in scope, but representation, and thus validation, > >should be. > > > >Specific suggestions on the wording of the charter follow: > > > > > > > > > > Emergency Context Resolution with Internet Technologies (ECRIT) > >if validation of location is considered, this would not be a great > >name > > > > > > > > > Transport Area Director(s): > > > Allison Mankin > > > Jon Peterson > > > > > > Transport Area Advisor: TBD > > > > > > Working Group Chairs: TBD > >I volunteer > > > > > > > > In a number of areas the public switched telephone network (PSTN) > > > has been configured to recognize a short, easily memorized number as > > > a call for emergency services. These numbers 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. 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. > >This is incorrect. You don't always have a short number, choice of > number > >is currently explicitly national (with the single exception of the EU > >112 number primarily limited to mobile). There is more to location > >within emergency calling besides "context" and there are more than > >location that may determine the appropriate call center. > > > >Perhaps: > >Calling for help using the publics switched telephone network (PSTN) > >is a primary function which must be provided for in any Internet > >based communication system. Emergency calls for assistance are > >answered at special call centers. An emergency call must be directed > >to the correct call center, which depends on the location of the > >caller and in some jurisdictions, the nature of the emergency. The > >call itself must include the location either directly or indirectly. > >Prior to use for determining > a > >call center location must be determined to be valid (known to the > >call center as a location to which help may be dispatched). > > > > > > 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. > >Okay > > > > > There are, however, Internet technologies available to describe > location > > > and > > > to manage call routing. This working group will specify how those > > > technologies may be used within this context. > >This presupposes that the available technologies are appropriate. > >This might be true, but it might not. Perhaps: Describing location > >and carriage of location within various protocols is defined in other > >IETF working groups. This working group will specify > how > >location, in both civic and geospatial forms can be validated and > >used to route calls. > > > > >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. > >Is this an attempt to avoid the scope of IEPREP? If so, it's > >incorrect. IEPREP is concerned with an entirely different kind of > >call - one made by > a > >responder using the existing facilities using a priority. Agree that > this > >is out of scope. There is no call for assistance (9-1-1/1-1-2) that > >has preemption that I am aware of. Priority for emergency calls is > >often imposed by carriers, but rarely required. If you intended to > >avoid > IEPREP, > >perhaps: > >This group is concerned with calls made by ordinary users to request > >emergency assistance. Emergency calls by responders using Internet > >facilities are the province of the IEPREP working group and out of > >scope > for > >this working group. > > > > > > > > The group will describe a layered approach to the problem, showing > > > 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 > > > service enter. > >It's not clear that there is any layering. I think this wording > >doesn't advance anyone's understanding of what the work is. Perhaps: > >This group will describe how location may be validated prior to use, > >and > how > >validated location may be used to route calls to the correct > >emergency > call > >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 non-voice communications (e.g. text messaging) where > appropriate. > >I'm not sure what is implied here. There are two kinds of text > >messaging protocols that might be used: Instant messaging and > >interactive text streams. Both have the notion of "session". > >Perhaps: While current emergency calls are voice only, the Internet > >provides a variety of media streams that may be used to summon help. > >This work will include voice, video and Instant Messaging as well as > >interactive text. > > > > > > > > > > Deliverables: > > > > > > Informational RFC describing the problem > > > (needs to be simple and early, early, early) > > > > > > BCP describing strategies for call originators identifying > > > emergency calls. > > > (Including provisioning local targets and use of URIs) > >This is somewhat problematic as it overlaps protocol groups. Maybe > >need to qualify this as with the concurrence of such groups (I'm > >thinking SIPPING and XMPP). Wording may need a hint of the "nature > >of > the > >emergency" problem. > > > > > > > > BCP describing strategies for associating call originators with > > > physical locations. > > > (Both originator-based and network-based strategies) > >I'm not sure what is meant here. Right now, I think most endpoints > >learn location from DHCP and supply it using SIP/XMPP with PIDF-LO. > >It's worth saying that somewhere. Is that what was intended by this? > >I hope you > did > >not intend to imply network based insertion of location in call > >flows; I think we are constrained by geopriv to have endpoints learn > >location and supply it on emergency calls. > > > >Need a new requirement > >Standards Track RFC describing how location is validated prior to > >use. > > > > > > > > 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. > >I don't see how you can ignore how the data is maintained. I suppose > >it depends on the query mechanism; if you choose the right query > >mechanism, there may already be mechanisms for maintaining data. > > > > > (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). > >This should be deleted. You don't know what query mechanism to use. > >If, for example, you use the DNS, than this is incorrect. > > > > > > > > BCP describing the call routing strategies for ip911. > >very poor choice of acronym; has U.S. implication. Use ipSOS > > > > > (e.g.: does an ERC have a sip: URI to talk to, or do we need > > > to > last > > > mile via PSTN?) > >I suspect we DON'T want to work on migration strategies. Just assume > >the ERC can terminate a SIP call. It's too late for IETF to wade > >into that > one. > > > > > > > > BCP describing how to discover ERC capabilities. > > > (can a deaf person IM this center or can we route through a > relay?) > >I'm skeptical of this, again crosses protocol groups boundaries. > Problem > >does need to be solved. Perhaps: > >BCP describing how routing may be affected by capabilities in the ERC > >or constraints on the caller (e.g. caller with disabilities engaging > >a relay service). > > > > > > Threats and security documentation > > > (mainly pointers, but the pointers need to be gathered). > > > > > > > > >Brian > > > > > > > > > >_______________________________________________ > >Sipping-emergency mailing list > >Sipping-emergency@ietf.org > >https://www1.ietf.org/mailman/listinfo/sipping-emergency > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > _______________________________________________ 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 From sipping-emergency-bounces@ietf.org Mon Sep 27 15:16:44 2004 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 PAA23644 for ; Mon, 27 Sep 2004 15:16:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC174-0003vm-3x for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 15:24:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0wY-0001Yq-Rb for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 15:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0s9-0007Ph-PK for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 15:09: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 PAA22431 for ; Mon, 27 Sep 2004 15:09:15 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC0zp-0003lR-5T for sipping-emergency@ietf.org; Mon, 27 Sep 2004 15:17:13 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2004 12:14:52 -0700 X-BrightmailFiltered: true Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8RJ8e3c005310; Mon, 27 Sep 2004 12:08:42 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA06784; Mon, 27 Sep 2004 12:08:39 -0700 (PDT) From: "Marc Linsner" To: "'Brian Rosen'" , "'Peterson, Jon'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 15:08:37 -0400 Message-ID: <010101c4a4c5$65e31530$2c0d0d0a@mlinsnerzk7abh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200409271359.JAA00210@ietf.org> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Content-Transfer-Encoding: 7bit Cc: 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 3.1 (+++) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Content-Transfer-Encoding: 7bit I too agree this work is much needed. Other comments in-line..... > -----Original Message----- > From: sipping-emergency-bounces@ietf.org > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, September 27, 2004 9:59 AM > To: 'Peterson, Jon'; sipping-emergency@ietf.org > Cc: mankin@psg.com > Subject: RE: [Sipping-emergency] proposed charter,new wg on > emergency calling and routing > > > I am very happy to see some motion on this very pressing > problem. In the absence of IETF work, other national or > regional groups are working on solutions that are contrary to > the "no national variants" of the Internet. I do think > mention should be made of other work, perhaps explicitly > soliciting requirements from such entities as NENA and ETSI EMTEL. > > There are several problems that need to be solved that go > beyond this particular problem statement. The most > significant is that the location that is supplied needs to be > "validated" prior to using it. This is a primary problem, > and it's essential that it be included in the charter. I > believe that making scope so narrow that only routing is > considered would be a serious mistake. > > Another issue is that while in some jurisdictions, there is a > single location to which calls are directed, in some, the > nature of the emergency determines the routing. > > Another issue missing from the charter is an explicit > inclusion of both civic and geo locations (street address and > lat/lon/altitude). > > The charter needs to cover location precision to at least a > room. It's not clear if this is in scope or not. The > mechanism to determine location is not in scope, but > representation, and thus validation, should be. > > Specific suggestions on the wording of the charter follow: > > > > > > Emergency Context Resolution with Internet Technologies (ECRIT) > if validation of location is considered, this would not be a > great name > > > > > > Transport Area Director(s): > > Allison Mankin > > Jon Peterson > > > > Transport Area Advisor: TBD > > > > Working Group Chairs: TBD > I volunteer I volunteer also. > > > > > In a number of areas the public switched telephone network > (PSTN) has > > been configured to recognize a short, easily memorized number as > > a call for emergency services. These numbers 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. 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. > This is incorrect. You don't always have a short number, > choice of number is currently explicitly national (with the > single exception of the EU 112 number primarily limited to > mobile). There is more to location within emergency calling > besides "context" and there are more than location that may > determine the appropriate call center. > > Perhaps: > Calling for help using the publics switched telephone network > (PSTN) is a primary function which must be provided for in > any Internet based communication system. Emergency calls for > assistance are answered at special call centers. An > emergency call must be directed to the correct call center, > which depends on the location of the caller and in some > jurisdictions, the nature of the emergency. The call itself > must include the location either directly or indirectly. > Prior to use for determining a call center location must be > determined to be valid (known to the call center as a > location to which help may be dispatched). I don't believe the IETF should require validation, this is a local decision. The IETF can describe/develop the mechanism for validation, but it is the user(s) to determine the requirement. > > > > 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. > Okay > > > There are, however, Internet technologies available to describe > > location and to manage call routing. This working group > will specify > > how those technologies > > may be used within this context. > This presupposes that the available technologies are > appropriate. This might be true, but it might not. Perhaps: > Describing location and carriage of location within various > protocols is defined in other IETF working groups. This > working group will specify how location, in both civic and > geospatial forms can be validated and used to route calls. Agree with Brian, if existing technologies can't fulfill the requirements, something new will be needed. > > >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. > Is this an attempt to avoid the scope of IEPREP? If so, it's > incorrect. IEPREP is concerned with an entirely different > kind of call - one made by a responder using the existing > facilities using a priority. Agree that this is out of > scope. There is no call for assistance (9-1-1/1-1-2) that > has preemption that I am aware of. Priority for emergency > calls is often imposed by carriers, but rarely required. If > you intended to avoid IEPREP, > perhaps: > This group is concerned with calls made by ordinary users to > request emergency assistance. Emergency calls by responders > using Internet facilities are the province of the IEPREP > working group and out of scope for this working group. > > > > > The group will describe a layered approach to the problem, > showing 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 service enter. > It's not clear that there is any layering. I think this > wording doesn't advance anyone's understanding of what the > work is. Perhaps: This group will describe how location may > be validated prior to use, and how validated location may be > used to route calls to the correct emergency call center. Validation is one process that would apply to civil locations only. > > >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 non-voice communications (e.g. text messaging) where > appropriate. > I'm not sure what is implied here. There are two kinds of > text messaging protocols that might be used: Instant > messaging and interactive text streams. Both have the notion > of "session". Perhaps: While current emergency calls are > voice only, the Internet provides a variety of media streams > that may be used to summon help. This work will include > voice, video and Instant Messaging as well as interactive text. > > > > > > Deliverables: > > > > Informational RFC describing the problem > > (needs to be simple and early, early, early) > > > > BCP describing strategies for call originators identifying > emergency > > calls. > > (Including provisioning local targets and use of URIs) > This is somewhat problematic as it overlaps protocol groups. > Maybe need to qualify this as with the concurrence of such > groups (I'm thinking SIPPING and XMPP). Wording may need a > hint of the "nature of the emergency" problem. > > > > > BCP describing strategies for associating call originators with > > physical locations. > > (Both originator-based and network-based strategies) > I'm not sure what is meant here. Right now, I think most > endpoints learn location from DHCP and supply it using > SIP/XMPP with PIDF-LO. It's worth saying that somewhere. Is > that what was intended by this? I hope you did not intend to > imply network based insertion of location in call flows; I > think we are constrained by geopriv to have endpoints learn > location and supply it on emergency calls. > > Need a new requirement > Standards Track RFC describing how location is validated prior to use. Again, civil location validation as required by the user(s). > > > > > 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. > I don't see how you can ignore how the data is maintained. I > suppose it depends on the query mechanism; if you choose the > right query mechanism, there may already be mechanisms for > maintaining data. > > > (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). > This should be deleted. You don't know what query mechanism > to use. If, for example, you use the DNS, than this is incorrect. Agree with Brian, delete this statement as mechanism is yet-to-be-determined. > > > > > BCP describing the call routing strategies for ip911. > very poor choice of acronym; has U.S. implication. Use ipSOS > > > (e.g.: does an ERC have a sip: URI to talk to, or do > we need to > > last mile via PSTN?) > I suspect we DON'T want to work on migration strategies. > Just assume the ERC can terminate a SIP call. It's too late > for IETF to wade into that one. > > > > > BCP describing how to discover ERC capabilities. > > (can a deaf person IM this center or can we route through a > > relay?) > I'm skeptical of this, again crosses protocol groups > boundaries. Problem > does need to be solved. Perhaps: > BCP describing how routing may be affected by capabilities in > the ERC or constraints on the caller (e.g. caller with > disabilities engaging a relay service). > > > > Threats and security documentation > > (mainly pointers, but the pointers need to be gathered). > > > > > Brian > -Marc Linsner- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 15:17:37 2004 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 PAA23796 for ; Mon, 27 Sep 2004 15:17:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC17v-0003wn-69 for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 15:25:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0wZ-0001Z7-1x for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 15:13:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0sA-0007QM-6v for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 15:09: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 PAA22436 for ; Mon, 27 Sep 2004 15:09:16 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC0zq-0003lR-2n for sipping-emergency@ietf.org; Mon, 27 Sep 2004 15:17:14 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2004 12:15:07 -0700 X-BrightmailFiltered: true Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8RJ8v3c005595; Mon, 27 Sep 2004 12:08:58 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA07104; Mon, 27 Sep 2004 12:08:55 -0700 (PDT) From: "Marc Linsner" To: "'Brian Rosen'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 15:08:54 -0400 Message-ID: <010401c4a4c5$6f91b870$2c0d0d0a@mlinsnerzk7abh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200409271603.MAA09890@ietf.org> X-Spam-Score: 2.3 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable In-line..... > -----Original Message----- > From: sipping-emergency-bounces@ietf.org=20 > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, September 27, 2004 12:04 PM > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org > Cc: mankin@psg.com > Subject: RE: [Sipping-emergency] proposed charter,new wg on=20 > emergency calling and routing > Importance: Low >=20 >=20 > When you place an emergency call, the location is used to=20 > determine where to send the call, and it is used to dispatch=20 > responders. If the location you supply does not match=20 > anything the call center recognizes, the wrong thing may=20 > happen. What you want to do is to compare the address you=20 > have against a list maintained by the emergency response=20 > system to make sure they know where that is. >=20 > An example is illustrative. If you ask me my home address,=20 > I'd tell you that it is 470 Conrad Drive, Mars, PA. However,=20 > that is NOT the address that should be used to determine=20 > where to send an emergency call from my home. That is=20 > because the post office boundary is not the same as the=20 > emergency call system boundary. =20 So? As long as '470 Conrad Drive, Mars, PA.' is unique, modern data processing can handle it. If you were to determine the=20 > serving ERC without validation, you would send my emergency=20 > call to the Butler County ERC, which serves Mars, rather than=20 > to the NEWCOM center that serves Pine Township, where I live. Validation and routing are 2 separate issues. If in fact, 470 = Conrad....., is a good address, the routing function (which will be based on data = from the ERC entities) better get it right and send the call the NEWCOM = center as you describe. All that validation *may* offer is to verify that you = (the end-user) didn't spell Conrad as Conard (or put Street instead of Drive, etc.)! I realize there are locales that utilize a different 'location' address for emergency purposes than the postal address, but the IETF = can't fix this. I'm not against validation, but your example isn't the real reason for validation.=20 >=20 [snip] -Marc Linsner- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 15:26:13 2004 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 PAA24517 for ; Mon, 27 Sep 2004 15:26:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1GF-000450-UZ for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 15:34:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC15R-0006El-Kl; Mon, 27 Sep 2004 15:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC12n-0003xn-Ko for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 15:20:17 -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 PAA24103 for ; Mon, 27 Sep 2004 15:20:15 -0400 (EDT) Message-Id: <200409271920.PAA24103@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1AT-0003z6-EN for sipping-emergency@ietf.org; Mon, 27 Sep 2004 15:28:13 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CC12i-00009B-IU; Mon, 27 Sep 2004 14:20:12 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 15:20:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUA In-Reply-To: <010401c4a4c5$6f91b870$2c0d0d0a@mlinsnerzk7abh> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Agreed that you COULD change the way the system works now to have a translation from postal address to dispatch address. They don't do that now, but they could. In that regard, maybe a bad example. If you were to propose that the system have a translation, then some kind of spec would have to be written that said that, which might be a new deliverable. Misspellings, missing or extra directionals (North, Southwest, ..), confusion between Main Street and Main Drive, etc. are better examples. The point is to make sure that the call will be routed correctly, and responders will be dispatched correctly BEFORE the location is needed to do so, and the only way we know how to do that is to compare the address against some kind of master list. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, September 27, 2004 3:09 PM > To: 'Brian Rosen'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > calling and routing > > In-line..... > > > -----Original Message----- > > From: sipping-emergency-bounces@ietf.org > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen > > Sent: Monday, September 27, 2004 12:04 PM > > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org > > Cc: mankin@psg.com > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > emergency calling and routing > > Importance: Low > > > > > > When you place an emergency call, the location is used to > > determine where to send the call, and it is used to dispatch > > responders. If the location you supply does not match > > anything the call center recognizes, the wrong thing may > > happen. What you want to do is to compare the address you > > have against a list maintained by the emergency response > > system to make sure they know where that is. > > > > An example is illustrative. If you ask me my home address, > > I'd tell you that it is 470 Conrad Drive, Mars, PA. However, > > that is NOT the address that should be used to determine > > where to send an emergency call from my home. That is > > because the post office boundary is not the same as the > > emergency call system boundary. > > So? As long as '470 Conrad Drive, Mars, PA.' is unique, modern data > processing can handle it. > > If you were to determine the > > serving ERC without validation, you would send my emergency > > call to the Butler County ERC, which serves Mars, rather than > > to the NEWCOM center that serves Pine Township, where I live. > > Validation and routing are 2 separate issues. If in fact, 470 > Conrad....., > is a good address, the routing function (which will be based on data from > the ERC entities) better get it right and send the call the NEWCOM center > as > you describe. All that validation *may* offer is to verify that you (the > end-user) didn't spell Conrad as Conard (or put Street instead of Drive, > etc.)! I realize there are locales that utilize a different 'location' > address for emergency purposes than the postal address, but the IETF can't > fix this. > > I'm not against validation, but your example isn't the real reason for > validation. > > > > [snip] > > -Marc Linsner- > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 15:52:48 2004 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 PAA26469 for ; Mon, 27 Sep 2004 15:52:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1fz-0004bc-BW for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 16:00:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1X2-0000HV-FI for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 15:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1PD-0005gJ-DN for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 15:43:27 -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 PAA25773 for ; Mon, 27 Sep 2004 15:43:25 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from dpvc-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1Wt-0004Ow-K9 for sipping-emergency@ietf.org; Mon, 27 Sep 2004 15:51:24 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 27 Sep 2004 15:45:18 -0400 Message-ID: Thread-Topic: [Sipping-emergency] proposed charter, new wg on emergency calling and routing thread-index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUAAAC2ZOA= To: "Brian Rosen" , "Marc Linsner" , X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable While validation is important as described by both of you, this should = in no way intefere with the processing of a call to an ERC. Feedback = should be provided to the end user or IAP if the location information = is out of acceptable parameters (e.g. out of street range, wrong = spelling etc.) and also provided to an ERC or ERC service provider as a = method to ensure that the erroneous information is corrected BEFORE an = emergency call is ever placed. However, the ability for that particular = device to place an emergency call should not be restricted by this = process (didn't see it anywhere in the proposal but I wanted to make = sure that it is stated) - this mirrors the current process of validation = here in North America for PSTN originated calls. Nate Wilcox -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, September 27, 2004 3:20 PM To: 'Marc Linsner'; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency calling and routing Agreed that you COULD change the way the system works now to have a translation from postal address to dispatch address. They don't do that now, but they could. In that regard, maybe a bad example. If you were = to propose that the system have a translation, then some kind of spec would have to be written that said that, which might be a new deliverable. Misspellings, missing or extra directionals (North, Southwest, ..), confusion between Main Street and Main Drive, etc. are better examples. The point is to make sure that the call will be routed correctly, and responders will be dispatched correctly BEFORE the location is = needed to do so, and the only way we know how to do that is to compare the address against some kind of master list. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, September 27, 2004 3:09 PM > To: 'Brian Rosen'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > calling and routing >=20 > In-line..... >=20 > > -----Original Message----- > > From: sipping-emergency-bounces@ietf.org > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen > > Sent: Monday, September 27, 2004 12:04 PM > > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org > > Cc: mankin@psg.com > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > emergency calling and routing > > Importance: Low > > > > > > When you place an emergency call, the location is used to > > determine where to send the call, and it is used to dispatch > > responders. If the location you supply does not match > > anything the call center recognizes, the wrong thing may > > happen. What you want to do is to compare the address you > > have against a list maintained by the emergency response > > system to make sure they know where that is. > > > > An example is illustrative. If you ask me my home address, > > I'd tell you that it is 470 Conrad Drive, Mars, PA. However, > > that is NOT the address that should be used to determine > > where to send an emergency call from my home. That is > > because the post office boundary is not the same as the > > emergency call system boundary. >=20 > So? As long as '470 Conrad Drive, Mars, PA.' is unique, modern data > processing can handle it. >=20 > If you were to determine the > > serving ERC without validation, you would send my emergency > > call to the Butler County ERC, which serves Mars, rather than > > to the NEWCOM center that serves Pine Township, where I live. >=20 > Validation and routing are 2 separate issues. If in fact, 470 > Conrad....., > is a good address, the routing function (which will be based on data = from > the ERC entities) better get it right and send the call the NEWCOM = center > as > you describe. All that validation *may* offer is to verify that you = (the > end-user) didn't spell Conrad as Conard (or put Street instead of = Drive, > etc.)! I realize there are locales that utilize a different = 'location' > address for emergency purposes than the postal address, but the IETF = can't > fix this. >=20 > I'm not against validation, but your example isn't the real reason for > validation. >=20 > > > [snip] >=20 > -Marc Linsner- >=20 >=20 _______________________________________________ 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 From sipping-emergency-bounces@ietf.org Mon Sep 27 15:55:00 2004 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 PAA26623 for ; Mon, 27 Sep 2004 15:55:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1i4-0004mC-Py for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 16:02:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1Y1-0000ji-DW; Mon, 27 Sep 2004 15:52:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1Sa-0006zQ-DU for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 15:46:56 -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 PAA26070 for ; Mon, 27 Sep 2004 15:46:54 -0400 (EDT) Message-Id: <200409271946.PAA26070@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1aG-0004TT-Je for sipping-emergency@ietf.org; Mon, 27 Sep 2004 15:54:53 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CC1SU-0001yZ-8i; Mon, 27 Sep 2004 14:46:51 -0500 From: "Brian Rosen" To: , "'Marc Linsner'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 15:46:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUAAAC2ZOAAAF7kwA== In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit What's an IAP? Agree, you send the call, validated or not. Of course if the validation fails, where do you send the call? Brian > -----Original Message----- > From: wilcox@e911.psd.state.vt.us [mailto:wilcox@e911.psd.state.vt.us] > Sent: Monday, September 27, 2004 3:45 PM > To: Brian Rosen; Marc Linsner; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > calling and routing > > While validation is important as described by both of you, this should in > no way intefere with the processing of a call to an ERC. Feedback should > be provided to the end user or IAP if the location information is out of > acceptable parameters (e.g. out of street range, wrong spelling etc.) and > also provided to an ERC or ERC service provider as a method to ensure that > the erroneous information is corrected BEFORE an emergency call is ever > placed. However, the ability for that particular device to place an > emergency call should not be restricted by this process (didn't see it > anywhere in the proposal but I wanted to make sure that it is stated) - > this mirrors the current process of validation here in North America for > PSTN originated calls. > > Nate Wilcox > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, September 27, 2004 3:20 PM > To: 'Marc Linsner'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > calling and routing > > > Agreed that you COULD change the way the system works now to have a > translation from postal address to dispatch address. They don't do that > now, but they could. In that regard, maybe a bad example. If you were to > propose that the system have a translation, then some kind of spec would > have to be written that said that, which might be a new deliverable. > > Misspellings, missing or extra directionals (North, Southwest, ..), > confusion between Main Street and Main Drive, etc. are better examples. > The point is to make sure that the call will be routed correctly, > and responders will be dispatched correctly BEFORE the location is needed > to > do so, and the only way we know how to do that is to compare the address > against some kind of master list. > > Brian > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Monday, September 27, 2004 3:09 PM > > To: 'Brian Rosen'; sipping-emergency@ietf.org > > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > > calling and routing > > > > In-line..... > > > > > -----Original Message----- > > > From: sipping-emergency-bounces@ietf.org > > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen > > > Sent: Monday, September 27, 2004 12:04 PM > > > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org > > > Cc: mankin@psg.com > > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > > emergency calling and routing > > > Importance: Low > > > > > > > > > When you place an emergency call, the location is used to > > > determine where to send the call, and it is used to dispatch > > > responders. If the location you supply does not match > > > anything the call center recognizes, the wrong thing may > > > happen. What you want to do is to compare the address you > > > have against a list maintained by the emergency response > > > system to make sure they know where that is. > > > > > > An example is illustrative. If you ask me my home address, > > > I'd tell you that it is 470 Conrad Drive, Mars, PA. However, > > > that is NOT the address that should be used to determine > > > where to send an emergency call from my home. That is > > > because the post office boundary is not the same as the > > > emergency call system boundary. > > > > So? As long as '470 Conrad Drive, Mars, PA.' is unique, modern data > > processing can handle it. > > > > If you were to determine the > > > serving ERC without validation, you would send my emergency > > > call to the Butler County ERC, which serves Mars, rather than > > > to the NEWCOM center that serves Pine Township, where I live. > > > > Validation and routing are 2 separate issues. If in fact, 470 > > Conrad....., > > is a good address, the routing function (which will be based on data > from > > the ERC entities) better get it right and send the call the NEWCOM > center > > as > > you describe. All that validation *may* offer is to verify that you > (the > > end-user) didn't spell Conrad as Conard (or put Street instead of Drive, > > etc.)! I realize there are locales that utilize a different 'location' > > address for emergency purposes than the postal address, but the IETF > can't > > fix this. > > > > I'm not against validation, but your example isn't the real reason for > > validation. > > > > > > > [snip] > > > > -Marc Linsner- > > > > > > > > > _______________________________________________ > 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 From sipping-emergency-bounces@ietf.org Mon Sep 27 16:27:14 2004 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 QAA29347 for ; Mon, 27 Sep 2004 16:27:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2DI-0005ek-9v for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 16:35:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1lf-0007A3-GJ for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 16:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1hl-00050D-QD for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:02:37 -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 QAA26947 for ; Mon, 27 Sep 2004 16:02:35 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1pQ-0004sE-T7 for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:10:34 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 27 Sep 2004 13:05:21 -0700 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8RK0dxQ023287; Mon, 27 Sep 2004 13:02:03 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA03008; Mon, 27 Sep 2004 12:52:10 -0700 (PDT) From: "Marc Linsner" To: "'Brian Rosen'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 15:52:08 -0400 Message-ID: <010601c4a4cb$79ec1d50$2c0d0d0a@mlinsnerzk7abh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200409271923.i8RJMNJ8028657@sj-inbound-4.cisco.com> X-Spam-Score: 2.3 (++) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit A point I tried to make wrt your example was to say that even current MSAG architectures allow jurisdictional lines to split streets in many different configurations without requiring exotic things to happen (like ERC overlay naming, etc.). In VoIP, pre-validation of civil location prevents call routing failures. Yes, for this reason, validation is a good thing. I also would submit that if the VoIP call got routed to an ERC, then it's most likely dispatchable (so we may be able to quit using that argument). I would purpose to the user(s), that in areas where ERC jurisdictional lines are grossly different from civil address lines, then loose routing based solely on city/town would/should not be implemented. VoIP makes it almost impossible to 'default route' due to VPN tunnels, etc. as compared to legacy mechanisms. -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, September 27, 2004 3:20 PM > To: 'Marc Linsner'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on > emergency calling and routing > > > Agreed that you COULD change the way the system works now to > have a translation from postal address to dispatch address. > They don't do that now, but they could. In that regard, > maybe a bad example. If you were to propose that the system > have a translation, then some kind of spec would have to be > written that said that, which might be a new deliverable. > > Misspellings, missing or extra directionals (North, > Southwest, ..), confusion between Main Street and Main Drive, > etc. are better examples. The point is to make sure that the > call will be routed correctly, and responders will be > dispatched correctly BEFORE the location is needed to do so, > and the only way we know how to do that is to compare the > address against some kind of master list. > > Brian > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Monday, September 27, 2004 3:09 PM > > To: 'Brian Rosen'; sipping-emergency@ietf.org > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > emergency > > calling and routing > > > > In-line..... > > > > > -----Original Message----- > > > From: sipping-emergency-bounces@ietf.org > > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of > Brian Rosen > > > Sent: Monday, September 27, 2004 12:04 PM > > > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org > > > Cc: mankin@psg.com > > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > > emergency calling and routing > > > Importance: Low > > > > > > > > > When you place an emergency call, the location is used to > determine > > > where to send the call, and it is used to dispatch > responders. If > > > the location you supply does not match anything the call center > > > recognizes, the wrong thing may happen. What you want to > do is to > > > compare the address you have against a list maintained by the > > > emergency response system to make sure they know where that is. > > > > > > An example is illustrative. If you ask me my home > address, I'd tell > > > you that it is 470 Conrad Drive, Mars, PA. However, that > is NOT the > > > address that should be used to determine where to send an > emergency > > > call from my home. That is because the post office > boundary is not > > > the same as the emergency call system boundary. > > > > So? As long as '470 Conrad Drive, Mars, PA.' is unique, > modern data > > processing can handle it. > > > > If you were to determine the > > > serving ERC without validation, you would send my > emergency call to > > > the Butler County ERC, which serves Mars, rather than to > the NEWCOM > > > center that serves Pine Township, where I live. > > > > Validation and routing are 2 separate issues. If in fact, 470 > > Conrad....., is a good address, the routing function (which will be > > based on data from the ERC entities) better get it right > and send the > > call the NEWCOM center as > > you describe. All that validation *may* offer is to verify > that you (the > > end-user) didn't spell Conrad as Conard (or put Street > instead of Drive, > > etc.)! I realize there are locales that utilize a > different 'location' > > address for emergency purposes than the postal address, but > the IETF can't > > fix this. > > > > I'm not against validation, but your example isn't the real > reason for > > validation. > > > > > > > [snip] > > > > -Marc Linsner- > > > > > > > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 16:57:39 2004 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 QAA06293 for ; Mon, 27 Sep 2004 16:57:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2gk-0007qP-RS for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 17:05:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1m7-0007QJ-Dd; Mon, 27 Sep 2004 16:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1id-0005Nq-5h for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:03:31 -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 QAA27096 for ; Mon, 27 Sep 2004 16:03:28 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1q9-0004tK-Nh for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:11:27 -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 i8RK2DPm005242; Mon, 27 Sep 2004 20:02:14 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 16:02:13 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41DA@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency cal ling and routing Date: Mon, 27 Sep 2004 16:02:11 -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.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sipping-emergency@ietf.org, "'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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Henning, Certainly, this charter was not intended to guarantee to any particular outcome of the standards process, but rather to select a narrow scope of work that is likely to be achievable. No doubt a choice of scope can make all the difference in the selection of a solution. If you're especially concerned about, say, the mention of IRIS in the text below, that can be elided from the final version. The deliverables text there is still rough. Specific suggestions would be helpful, obviously. I appreciate that you feel a requirement has been missed in the charter; I have a hard time looking at the deliverables you cite below, though, and understanding in what respect they suggest a nationally-specific or centralized design for this work (neither of which would be default assumptions for IETF work). Can you suggest any specific language here that will improve the starter text? Do you just want to see something in the descriptive text of the charter to the effect that the design here needs to be delegative and allow distribution of call routing data? If so, I'd have no problem including something to that effect. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, September 27, 2004 5:49 AM > To: Peterson, Jon > Cc: sipping-emergency@ietf.org; 'mankin@psg.com' > Subject: Re: [Sipping-emergency] proposed charter, new wg on emergency > calling and routing > > > 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 From sipping-emergency-bounces@ietf.org Mon Sep 27 17:33:15 2004 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 RAA11168 for ; Mon, 27 Sep 2004 17:33:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3FD-0000yJ-E2 for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 17:41:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2sK-0002ly-0c; Mon, 27 Sep 2004 17:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1rd-0002Pe-LG for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:12:49 -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 QAA27550 for ; Mon, 27 Sep 2004 16:12:47 -0400 (EDT) Message-Id: <200409272012.QAA27550@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1zG-000539-SU for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:20:46 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CC1rV-0003yh-4Y; Mon, 27 Sep 2004 15:12:41 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , Subject: How to handle Validation failures was RE: [Sipping-emergency] proposed charter, new wg on emergency Date: Mon, 27 Sep 2004 16:12:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSkzNu7IznNxiFjTXWLNKQuZQoAiwAAGbZQ In-Reply-To: <010601c4a4cb$79ec1d50$2c0d0d0a@mlinsnerzk7abh> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit I changed the subject, as we are off the subject of a new charter, as we agree validation should be in that charter. Agree that boundaries are irregular in many strange and wonderous ways and we probably have to live with that rather than demand that they change their service boundaries to make routing easier. I do think that if we can answer the call as VoIP in the ERC, then we can transfer the call, with location, to the correct ERC in the case of a routing failure, which is a Very Good Thing (tm). I further propose that civic address is hierarchical, and "default" routing can be hierarchical. If you have a valid municipality name, but an invalid street, you can route to a default for that municipality. If you have a valid state, but an invalid county or municipality name, you can route to a default for that state, etc. Of course, in many countries, there is only one ERC for the country, so default routing is easier for them. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, September 27, 2004 3:52 PM > To: 'Brian Rosen'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > calling and routing > > A point I tried to make wrt your example was to say that even current MSAG > architectures allow jurisdictional lines to split streets in many > different > configurations without requiring exotic things to happen (like ERC overlay > naming, etc.). > > In VoIP, pre-validation of civil location prevents call routing failures. > Yes, for this reason, validation is a good thing. I also would submit > that > if the VoIP call got routed to an ERC, then it's most likely dispatchable > (so we may be able to quit using that argument). I would purpose to the > user(s), that in areas where ERC jurisdictional lines are grossly > different > from civil address lines, then loose routing based solely on city/town > would/should not be implemented. VoIP makes it almost impossible to > 'default route' due to VPN tunnels, etc. as compared to legacy mechanisms. > > -Marc- > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, September 27, 2004 3:20 PM > > To: 'Marc Linsner'; sipping-emergency@ietf.org > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > emergency calling and routing > > > > > > Agreed that you COULD change the way the system works now to > > have a translation from postal address to dispatch address. > > They don't do that now, but they could. In that regard, > > maybe a bad example. If you were to propose that the system > > have a translation, then some kind of spec would have to be > > written that said that, which might be a new deliverable. > > > > Misspellings, missing or extra directionals (North, > > Southwest, ..), confusion between Main Street and Main Drive, > > etc. are better examples. The point is to make sure that the > > call will be routed correctly, and responders will be > > dispatched correctly BEFORE the location is needed to do so, > > and the only way we know how to do that is to compare the > > address against some kind of master list. > > > > Brian > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Monday, September 27, 2004 3:09 PM > > > To: 'Brian Rosen'; sipping-emergency@ietf.org > > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > emergency > > > calling and routing > > > > > > In-line..... > > > > > > > -----Original Message----- > > > > From: sipping-emergency-bounces@ietf.org > > > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of > > Brian Rosen > > > > Sent: Monday, September 27, 2004 12:04 PM > > > > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org > > > > Cc: mankin@psg.com > > > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > > > emergency calling and routing > > > > Importance: Low > > > > > > > > > > > > When you place an emergency call, the location is used to > > determine > > > > where to send the call, and it is used to dispatch > > responders. If > > > > the location you supply does not match anything the call center > > > > recognizes, the wrong thing may happen. What you want to > > do is to > > > > compare the address you have against a list maintained by the > > > > emergency response system to make sure they know where that is. > > > > > > > > An example is illustrative. If you ask me my home > > address, I'd tell > > > > you that it is 470 Conrad Drive, Mars, PA. However, that > > is NOT the > > > > address that should be used to determine where to send an > > emergency > > > > call from my home. That is because the post office > > boundary is not > > > > the same as the emergency call system boundary. > > > > > > So? As long as '470 Conrad Drive, Mars, PA.' is unique, > > modern data > > > processing can handle it. > > > > > > If you were to determine the > > > > serving ERC without validation, you would send my > > emergency call to > > > > the Butler County ERC, which serves Mars, rather than to > > the NEWCOM > > > > center that serves Pine Township, where I live. > > > > > > Validation and routing are 2 separate issues. If in fact, 470 > > > Conrad....., is a good address, the routing function (which will be > > > based on data from the ERC entities) better get it right > > and send the > > > call the NEWCOM center as > > > you describe. All that validation *may* offer is to verify > > that you (the > > > end-user) didn't spell Conrad as Conard (or put Street > > instead of Drive, > > > etc.)! I realize there are locales that utilize a > > different 'location' > > > address for emergency purposes than the postal address, but > > the IETF can't > > > fix this. > > > > > > I'm not against validation, but your example isn't the real > > reason for > > > validation. > > > > > > > > > > [snip] > > > > > > -Marc Linsner- > > > > > > > > > > > > > > > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 17:33:21 2004 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 RAA11197 for ; Mon, 27 Sep 2004 17:33:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3FI-0000yY-D0 for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 17:41:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2sS-0002z3-TX; Mon, 27 Sep 2004 17:17:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1vt-0004qz-BX for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:17:14 -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 QAA28054 for ; Mon, 27 Sep 2004 16:17:10 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from dpvc-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC23Z-0005CS-R9 for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:25:10 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 27 Sep 2004 16:19:05 -0400 Message-ID: Thread-Topic: [Sipping-emergency] proposed charter, new wg on emergency calling and routing thread-index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUAAAC2ZOAAAF7kwAABIjcO To: "Brian Rosen" , "Marc Linsner" , X-Spam-Score: 0.3 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0226401041==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============0226401041== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SUFQIC0gSW5mcmFzdHJ1Y3R1cmUgQWNjZXNzIFByb3ZpZGVyIC0gd2hvbWV2ZXIgaXMgYXdhcmUg b2YgYSkgdGhlIHBoeXNpY2FsIGxvY2F0aW9uIG9mIHRoZSBlbmQgdXNlciBhbmQgYikgcHJvdmlk ZXMgSW50ZXJuZXQgYWNjZXNzIHRvIHRoZSBlbmQgdXNlci4NCiANCllvdXIgc2Vjb25kIHF1ZXN0 aW9uIGludHJvZHVjZXMgdGhlIG5vdGlvbiBvZiBkZWZhdWx0IGNhbGwgcm91dGluZyAtIHRoaXMg aXMgaW1wb3J0YW50IHRvIGNvbnNpZGVyIGFzIHdlbGwsIG5vdCBvbmx5Zm9yICB0aGlzIHJlYXNv biBidXQgYWxzbyAgZm9yIG90aGVyIHByb2Nlc3MgZmFpbHVyZXMgdGhhdCBtYXkgb2NjdXIuIEhv dyB0aGlzIGluZm9ybWF0aW9uIGdldHMgdG8gdGhlIGVuZCBkZXZpY2UgLSB3aGV0aGVyIGl0IGlz IHByZS1kZXRlcm1pbmVkIGFuZCBzdGF0aWNhbGx5IGVudGVyZWQgb3IsIGFzc2lnbmVkIGF0IGEg bG93ZXIgbGV2ZWwgdGhhbiB0aGUgSUFQICAtIEkgZG9uJ3Qga25vdyAtIG1heWJlIGJvdGg/IA0K IA0KTmF0ZSBXaWxjb3gNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEJy aWFuIFJvc2VuIFttYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXRdIA0KCVNlbnQ6IE1vbiA5LzI3LzIw MDQgMzo0NiBQTSANCglUbzogd2lsY294QGU5MTEucHNkLnN0YXRlLnZ0LnVzOyAnTWFyYyBMaW5z bmVyJzsgc2lwcGluZy1lbWVyZ2VuY3lAaWV0Zi5vcmcgDQoJQ2M6IA0KCVN1YmplY3Q6IFJFOiBb U2lwcGluZy1lbWVyZ2VuY3ldIHByb3Bvc2VkIGNoYXJ0ZXIsbmV3IHdnIG9uIGVtZXJnZW5jeSBj YWxsaW5nIGFuZCByb3V0aW5nDQoJDQoJDQoNCglXaGF0J3MgYW4gSUFQPw0KCQ0KCUFncmVlLCB5 b3Ugc2VuZCB0aGUgY2FsbCwgdmFsaWRhdGVkIG9yIG5vdC4NCgkNCglPZiBjb3Vyc2UgaWYgdGhl IHZhbGlkYXRpb24gZmFpbHMsIHdoZXJlIGRvIHlvdSBzZW5kIHRoZSBjYWxsPw0KCQ0KCUJyaWFu DQoJDQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogd2lsY294QGU5MTEu cHNkLnN0YXRlLnZ0LnVzIFttYWlsdG86d2lsY294QGU5MTEucHNkLnN0YXRlLnZ0LnVzXQ0KCT4g U2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMDQgMzo0NSBQTQ0KCT4gVG86IEJyaWFuIFJv c2VuOyBNYXJjIExpbnNuZXI7IHNpcHBpbmctZW1lcmdlbmN5QGlldGYub3JnDQoJPiBTdWJqZWN0 OiBSRTogW1NpcHBpbmctZW1lcmdlbmN5XSBwcm9wb3NlZCBjaGFydGVyLG5ldyB3ZyBvbiBlbWVy Z2VuY3kNCgk+IGNhbGxpbmcgYW5kIHJvdXRpbmcNCgk+DQoJPiBXaGlsZSB2YWxpZGF0aW9uIGlz IGltcG9ydGFudCBhcyBkZXNjcmliZWQgYnkgYm90aCBvZiB5b3UsIHRoaXMgc2hvdWxkIGluDQoJ PiBubyB3YXkgaW50ZWZlcmUgd2l0aCB0aGUgcHJvY2Vzc2luZyBvZiBhIGNhbGwgdG8gYW4gRVJD LiBGZWVkYmFjayBzaG91bGQNCgk+IGJlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlciBvciBJQVAg aWYgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uICBpcyBvdXQgb2YNCgk+IGFjY2VwdGFibGUgcGFy YW1ldGVycyAoZS5nLiBvdXQgb2Ygc3RyZWV0IHJhbmdlLCB3cm9uZyBzcGVsbGluZyBldGMuKSBh bmQNCgk+IGFsc28gcHJvdmlkZWQgdG8gYW4gRVJDIG9yIEVSQyBzZXJ2aWNlIHByb3ZpZGVyIGFz IGEgbWV0aG9kIHRvIGVuc3VyZSB0aGF0DQoJPiB0aGUgZXJyb25lb3VzIGluZm9ybWF0aW9uIGlz IGNvcnJlY3RlZCBCRUZPUkUgYW4gZW1lcmdlbmN5IGNhbGwgaXMgZXZlcg0KCT4gcGxhY2VkLiBI b3dldmVyLCB0aGUgYWJpbGl0eSBmb3IgdGhhdCBwYXJ0aWN1bGFyIGRldmljZSB0byBwbGFjZSBh bg0KCT4gZW1lcmdlbmN5IGNhbGwgc2hvdWxkIG5vdCBiZSByZXN0cmljdGVkIGJ5IHRoaXMgcHJv Y2VzcyAoZGlkbid0IHNlZSBpdA0KCT4gYW55d2hlcmUgaW4gdGhlIHByb3Bvc2FsIGJ1dCBJIHdh bnRlZCB0byBtYWtlIHN1cmUgdGhhdCBpdCBpcyBzdGF0ZWQpIC0NCgk+IHRoaXMgbWlycm9ycyB0 aGUgY3VycmVudCBwcm9jZXNzIG9mIHZhbGlkYXRpb24gaGVyZSBpbiBOb3J0aCBBbWVyaWNhIGZv cg0KCT4gUFNUTiBvcmlnaW5hdGVkIGNhbGxzLg0KCT4NCgk+IE5hdGUgV2lsY294DQoJPg0KCT4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+IEZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86 YnJAYnJpYW5yb3Nlbi5uZXRdDQoJPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNywgMjAwNCAz OjIwIFBNDQoJPiBUbzogJ01hcmMgTGluc25lcic7IHNpcHBpbmctZW1lcmdlbmN5QGlldGYub3Jn DQoJPiBTdWJqZWN0OiBSRTogW1NpcHBpbmctZW1lcmdlbmN5XSBwcm9wb3NlZCBjaGFydGVyLG5l dyB3ZyBvbiBlbWVyZ2VuY3kNCgk+IGNhbGxpbmcgYW5kIHJvdXRpbmcNCgk+DQoJPg0KCT4gQWdy ZWVkIHRoYXQgeW91IENPVUxEIGNoYW5nZSB0aGUgd2F5IHRoZSBzeXN0ZW0gd29ya3Mgbm93IHRv IGhhdmUgYQ0KCT4gdHJhbnNsYXRpb24gZnJvbSBwb3N0YWwgYWRkcmVzcyB0byBkaXNwYXRjaCBh ZGRyZXNzLiAgVGhleSBkb24ndCBkbyB0aGF0DQoJPiBub3csIGJ1dCB0aGV5IGNvdWxkLiAgSW4g dGhhdCByZWdhcmQsIG1heWJlIGEgYmFkIGV4YW1wbGUuICBJZiB5b3Ugd2VyZSB0bw0KCT4gcHJv cG9zZSB0aGF0IHRoZSBzeXN0ZW0gaGF2ZSBhIHRyYW5zbGF0aW9uLCB0aGVuIHNvbWUga2luZCBv ZiBzcGVjIHdvdWxkDQoJPiBoYXZlIHRvIGJlIHdyaXR0ZW4gdGhhdCBzYWlkIHRoYXQsIHdoaWNo IG1pZ2h0IGJlIGEgbmV3IGRlbGl2ZXJhYmxlLg0KCT4NCgk+IE1pc3NwZWxsaW5ncywgbWlzc2lu ZyBvciBleHRyYSBkaXJlY3Rpb25hbHMgKE5vcnRoLCBTb3V0aHdlc3QsIC4uKSwNCgk+IGNvbmZ1 c2lvbiBiZXR3ZWVuIE1haW4gU3RyZWV0IGFuZCBNYWluIERyaXZlLCBldGMuIGFyZSBiZXR0ZXIg ZXhhbXBsZXMuDQoJPiBUaGUgcG9pbnQgaXMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNhbGwgd2ls bCBiZSByb3V0ZWQgY29ycmVjdGx5LA0KCT4gYW5kIHJlc3BvbmRlcnMgd2lsbCBiZSBkaXNwYXRj aGVkIGNvcnJlY3RseSBCRUZPUkUgdGhlIGxvY2F0aW9uIGlzIG5lZWRlZA0KCT4gdG8NCgk+IGRv IHNvLCBhbmQgdGhlIG9ubHkgd2F5IHdlIGtub3cgaG93IHRvIGRvIHRoYXQgaXMgdG8gY29tcGFy ZSB0aGUgYWRkcmVzcw0KCT4gYWdhaW5zdCBzb21lIGtpbmQgb2YgbWFzdGVyIGxpc3QuDQoJPg0K CT4gQnJpYW4NCgk+DQoJPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiA+IEZyb206 IE1hcmMgTGluc25lciBbbWFpbHRvOm1saW5zbmVyQGNpc2NvLmNvbV0NCgk+ID4gU2VudDogTW9u ZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMDQgMzowOSBQTQ0KCT4gPiBUbzogJ0JyaWFuIFJvc2VuJzsg c2lwcGluZy1lbWVyZ2VuY3lAaWV0Zi5vcmcNCgk+ID4gU3ViamVjdDogUkU6IFtTaXBwaW5nLWVt ZXJnZW5jeV0gcHJvcG9zZWQgY2hhcnRlcixuZXcgd2cgb24gZW1lcmdlbmN5DQoJPiA+IGNhbGxp bmcgYW5kIHJvdXRpbmcNCgk+ID4NCgk+ID4gSW4tbGluZS4uLi4uDQoJPiA+DQoJPiA+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+ID4gPiBGcm9tOiBzaXBwaW5nLWVtZXJnZW5jeS1i b3VuY2VzQGlldGYub3JnDQoJPiA+ID4gW21haWx0bzpzaXBwaW5nLWVtZXJnZW5jeS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NCgk+ID4gPiBTZW50OiBNb25kYXks IFNlcHRlbWJlciAyNywgMjAwNCAxMjowNCBQTQ0KCT4gPiA+IFRvOiAnSmFtZXMgTS4gUG9sayc7 ICdQZXRlcnNvbiwgSm9uJzsgc2lwcGluZy1lbWVyZ2VuY3lAaWV0Zi5vcmcNCgk+ID4gPiBDYzog bWFua2luQHBzZy5jb20NCgk+ID4gPiBTdWJqZWN0OiBSRTogW1NpcHBpbmctZW1lcmdlbmN5XSBw cm9wb3NlZCBjaGFydGVyLG5ldyB3ZyBvbg0KCT4gPiA+IGVtZXJnZW5jeSBjYWxsaW5nIGFuZCBy b3V0aW5nDQoJPiA+ID4gSW1wb3J0YW5jZTogTG93DQoJPiA+ID4NCgk+ID4gPg0KCT4gPiA+IFdo ZW4geW91IHBsYWNlIGFuIGVtZXJnZW5jeSBjYWxsLCB0aGUgbG9jYXRpb24gaXMgdXNlZCB0bw0K CT4gPiA+IGRldGVybWluZSB3aGVyZSB0byBzZW5kIHRoZSBjYWxsLCBhbmQgaXQgaXMgdXNlZCB0 byBkaXNwYXRjaA0KCT4gPiA+IHJlc3BvbmRlcnMuICBJZiB0aGUgbG9jYXRpb24geW91IHN1cHBs eSBkb2VzIG5vdCBtYXRjaA0KCT4gPiA+IGFueXRoaW5nIHRoZSBjYWxsIGNlbnRlciByZWNvZ25p emVzLCB0aGUgd3JvbmcgdGhpbmcgbWF5DQoJPiA+ID4gaGFwcGVuLiAgV2hhdCB5b3Ugd2FudCB0 byBkbyBpcyB0byBjb21wYXJlIHRoZSBhZGRyZXNzIHlvdQ0KCT4gPiA+IGhhdmUgYWdhaW5zdCBh IGxpc3QgbWFpbnRhaW5lZCBieSB0aGUgZW1lcmdlbmN5IHJlc3BvbnNlDQoJPiA+ID4gc3lzdGVt IHRvIG1ha2Ugc3VyZSB0aGV5IGtub3cgd2hlcmUgdGhhdCBpcy4NCgk+ID4gPg0KCT4gPiA+IEFu IGV4YW1wbGUgaXMgaWxsdXN0cmF0aXZlLiAgSWYgeW91IGFzayBtZSBteSBob21lIGFkZHJlc3Ms DQoJPiA+ID4gSSdkIHRlbGwgeW91IHRoYXQgaXQgaXMgNDcwIENvbnJhZCBEcml2ZSwgTWFycywg UEEuICBIb3dldmVyLA0KCT4gPiA+IHRoYXQgaXMgTk9UIHRoZSBhZGRyZXNzIHRoYXQgc2hvdWxk IGJlIHVzZWQgdG8gZGV0ZXJtaW5lDQoJPiA+ID4gd2hlcmUgdG8gc2VuZCBhbiBlbWVyZ2VuY3kg Y2FsbCBmcm9tIG15IGhvbWUuICBUaGF0IGlzDQoJPiA+ID4gYmVjYXVzZSB0aGUgcG9zdCBvZmZp Y2UgYm91bmRhcnkgaXMgbm90IHRoZSBzYW1lIGFzIHRoZQ0KCT4gPiA+IGVtZXJnZW5jeSBjYWxs IHN5c3RlbSBib3VuZGFyeS4NCgk+ID4NCgk+ID4gU28/ICBBcyBsb25nIGFzICc0NzAgQ29ucmFk IERyaXZlLCBNYXJzLCBQQS4nIGlzIHVuaXF1ZSwgbW9kZXJuIGRhdGENCgk+ID4gcHJvY2Vzc2lu ZyBjYW4gaGFuZGxlIGl0Lg0KCT4gPg0KCT4gPiBJZiB5b3Ugd2VyZSB0byBkZXRlcm1pbmUgdGhl DQoJPiA+ID4gc2VydmluZyBFUkMgd2l0aG91dCB2YWxpZGF0aW9uLCB5b3Ugd291bGQgc2VuZCBt eSBlbWVyZ2VuY3kNCgk+ID4gPiBjYWxsIHRvIHRoZSBCdXRsZXIgQ291bnR5IEVSQywgd2hpY2gg c2VydmVzIE1hcnMsIHJhdGhlciB0aGFuDQoJPiA+ID4gdG8gdGhlIE5FV0NPTSBjZW50ZXIgdGhh dCBzZXJ2ZXMgUGluZSBUb3duc2hpcCwgd2hlcmUgSSBsaXZlLg0KCT4gPg0KCT4gPiBWYWxpZGF0 aW9uIGFuZCByb3V0aW5nIGFyZSAyIHNlcGFyYXRlIGlzc3Vlcy4gIElmIGluIGZhY3QsIDQ3MA0K CT4gPiBDb25yYWQuLi4uLiwNCgk+ID4gaXMgYSBnb29kIGFkZHJlc3MsIHRoZSByb3V0aW5nIGZ1 bmN0aW9uICh3aGljaCB3aWxsIGJlIGJhc2VkIG9uIGRhdGENCgk+IGZyb20NCgk+ID4gdGhlIEVS QyBlbnRpdGllcykgYmV0dGVyIGdldCBpdCByaWdodCBhbmQgc2VuZCB0aGUgY2FsbCB0aGUgTkVX Q09NDQoJPiBjZW50ZXINCgk+ID4gYXMNCgk+ID4geW91IGRlc2NyaWJlLiAgQWxsIHRoYXQgdmFs aWRhdGlvbiAqbWF5KiBvZmZlciBpcyB0byB2ZXJpZnkgdGhhdCB5b3UNCgk+ICh0aGUNCgk+ID4g ZW5kLXVzZXIpIGRpZG4ndCBzcGVsbCBDb25yYWQgYXMgQ29uYXJkIChvciBwdXQgU3RyZWV0IGlu c3RlYWQgb2YgRHJpdmUsDQoJPiA+IGV0Yy4pISAgSSByZWFsaXplIHRoZXJlIGFyZSBsb2NhbGVz IHRoYXQgdXRpbGl6ZSBhIGRpZmZlcmVudCAnbG9jYXRpb24nDQoJPiA+IGFkZHJlc3MgZm9yIGVt ZXJnZW5jeSBwdXJwb3NlcyB0aGFuIHRoZSBwb3N0YWwgYWRkcmVzcywgYnV0IHRoZSBJRVRGDQoJ PiBjYW4ndA0KCT4gPiBmaXggdGhpcy4NCgk+ID4NCgk+ID4gSSdtIG5vdCBhZ2FpbnN0IHZhbGlk YXRpb24sIGJ1dCB5b3VyIGV4YW1wbGUgaXNuJ3QgdGhlIHJlYWwgcmVhc29uIGZvcg0KCT4gPiB2 YWxpZGF0aW9uLg0KCT4gPg0KCT4gPiA+DQoJPiA+IFtzbmlwXQ0KCT4gPg0KCT4gPiAtTWFyYyBM aW5zbmVyLQ0KCT4gPg0KCT4gPg0KCT4NCgk+DQoJPg0KCT4NCgk+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJPiBTaXBwaW5nLWVtZXJnZW5jeSBtYWls aW5nIGxpc3QNCgk+IFNpcHBpbmctZW1lcmdlbmN5QGlldGYub3JnDQoJPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBwaW5nLWVtZXJnZW5jeQ0KCT4NCgk+DQoJPg0K CQ0KCQ0KCQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoJU2lwcGluZy1lbWVyZ2VuY3kgbWFpbGluZyBsaXN0DQoJU2lwcGluZy1lbWVyZ2VuY3lA aWV0Zi5vcmcNCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBwaW5n LWVtZXJnZW5jeQ0KCQ0KCQ0KCQ0KDQo= --===============0226401041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============0226401041==-- From sipping-emergency-bounces@ietf.org Mon Sep 27 17:33:53 2004 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 RAA11295 for ; Mon, 27 Sep 2004 17:33:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3Fp-000107-NP for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 17:41:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2tI-0003t9-7L; Mon, 27 Sep 2004 17:18:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2Bt-0003Lk-V9 for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:33:46 -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 QAA00586 for ; Mon, 27 Sep 2004 16:33:43 -0400 (EDT) Message-Id: <200409272033.QAA00586@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2Ja-00060t-8l for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:41:42 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CC2Bo-0005fs-C1; Mon, 27 Sep 2004 15:33:40 -0500 From: "Brian Rosen" To: , "'Marc Linsner'" , Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing Date: Mon, 27 Sep 2004 16:33:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUAAAC2ZOAAAF7kwAABIjcOAAB6ODA= In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Aha! I've been calling it an AIP=Access Infrastructure Provider, i.e. the service provider that has the "last mile" infrastructure and thus normally knows where you are. Brian > -----Original Message----- > From: wilcox@e911.psd.state.vt.us [mailto:wilcox@e911.psd.state.vt.us] > Sent: Monday, September 27, 2004 4:19 PM > To: Brian Rosen; Marc Linsner; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > calling and routing > > IAP - Infrastructure Access Provider - whomever is aware of a) the > physical location of the end user and b) provides Internet access to the > end user. > > Your second question introduces the notion of default call routing - this > is important to consider as well, not onlyfor this reason but also for > other process failures that may occur. How this information gets to the > end device - whether it is pre-determined and statically entered or, > assigned at a lower level than the IAP - I don't know - maybe both? > > Nate Wilcox > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Mon 9/27/2004 3:46 PM > To: wilcox@e911.psd.state.vt.us; 'Marc Linsner'; sipping- > emergency@ietf.org > Cc: > Subject: RE: [Sipping-emergency] proposed charter,new wg on > emergency calling and routing > > > > What's an IAP? > > Agree, you send the call, validated or not. > > Of course if the validation fails, where do you send the call? > > Brian > > > -----Original Message----- > > From: wilcox@e911.psd.state.vt.us > [mailto:wilcox@e911.psd.state.vt.us] > > Sent: Monday, September 27, 2004 3:45 PM > > To: Brian Rosen; Marc Linsner; sipping-emergency@ietf.org > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > emergency > > calling and routing > > > > While validation is important as described by both of you, this > should in > > no way intefere with the processing of a call to an ERC. Feedback > should > > be provided to the end user or IAP if the location information is > out of > > acceptable parameters (e.g. out of street range, wrong spelling > etc.) and > > also provided to an ERC or ERC service provider as a method to > ensure that > > the erroneous information is corrected BEFORE an emergency call is > ever > > placed. However, the ability for that particular device to place > an > > emergency call should not be restricted by this process (didn't > see it > > anywhere in the proposal but I wanted to make sure that it is > stated) - > > this mirrors the current process of validation here in North > America for > > PSTN originated calls. > > > > Nate Wilcox > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, September 27, 2004 3:20 PM > > To: 'Marc Linsner'; sipping-emergency@ietf.org > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > emergency > > calling and routing > > > > > > Agreed that you COULD change the way the system works now to have > a > > translation from postal address to dispatch address. They don't > do that > > now, but they could. In that regard, maybe a bad example. If you > were to > > propose that the system have a translation, then some kind of spec > would > > have to be written that said that, which might be a new > deliverable. > > > > Misspellings, missing or extra directionals (North, Southwest, > ..), > > confusion between Main Street and Main Drive, etc. are better > examples. > > The point is to make sure that the call will be routed correctly, > > and responders will be dispatched correctly BEFORE the location is > needed > > to > > do so, and the only way we know how to do that is to compare the > address > > against some kind of master list. > > > > Brian > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Monday, September 27, 2004 3:09 PM > > > To: 'Brian Rosen'; sipping-emergency@ietf.org > > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > emergency > > > calling and routing > > > > > > In-line..... > > > > > > > -----Original Message----- > > > > From: sipping-emergency-bounces@ietf.org > > > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian > Rosen > > > > Sent: Monday, September 27, 2004 12:04 PM > > > > To: 'James M. Polk'; 'Peterson, Jon'; sipping- > emergency@ietf.org > > > > Cc: mankin@psg.com > > > > Subject: RE: [Sipping-emergency] proposed charter,new wg on > > > > emergency calling and routing > > > > Importance: Low > > > > > > > > > > > > When you place an emergency call, the location is used to > > > > determine where to send the call, and it is used to dispatch > > > > responders. If the location you supply does not match > > > > anything the call center recognizes, the wrong thing may > > > > happen. What you want to do is to compare the address you > > > > have against a list maintained by the emergency response > > > > system to make sure they know where that is. > > > > > > > > An example is illustrative. If you ask me my home address, > > > > I'd tell you that it is 470 Conrad Drive, Mars, PA. However, > > > > that is NOT the address that should be used to determine > > > > where to send an emergency call from my home. That is > > > > because the post office boundary is not the same as the > > > > emergency call system boundary. > > > > > > So? As long as '470 Conrad Drive, Mars, PA.' is unique, modern > data > > > processing can handle it. > > > > > > If you were to determine the > > > > serving ERC without validation, you would send my emergency > > > > call to the Butler County ERC, which serves Mars, rather than > > > > to the NEWCOM center that serves Pine Township, where I live. > > > > > > Validation and routing are 2 separate issues. If in fact, 470 > > > Conrad....., > > > is a good address, the routing function (which will be based on > data > > from > > > the ERC entities) better get it right and send the call the > NEWCOM > > center > > > as > > > you describe. All that validation *may* offer is to verify that > you > > (the > > > end-user) didn't spell Conrad as Conard (or put Street instead > of Drive, > > > etc.)! I realize there are locales that utilize a different > 'location' > > > address for emergency purposes than the postal address, but the > IETF > > can't > > > fix this. > > > > > > I'm not against validation, but your example isn't the real > reason for > > > validation. > > > > > > > > > > [snip] > > > > > > -Marc Linsner- > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 19:48:50 2004 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 TAA22471 for ; Mon, 27 Sep 2004 19:48:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC5MS-0003ym-Ma for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 19:56:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC5DZ-0007Wx-Fa; Mon, 27 Sep 2004 19:47:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC5AV-00078Z-Uv for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 19:44:32 -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 TAA21997 for ; Mon, 27 Sep 2004 19:44:28 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC5ID-0003sN-Hs for sipping-emergency@ietf.org; Mon, 27 Sep 2004 19:52:30 -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 i8RNgDPm013473; Mon, 27 Sep 2004 23:42:14 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 19:42:13 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41DD@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Brian Rosen'" , "'Marc Linsner'" , sipping-emergency@ietf.org Subject: RE: How to handle Validation failures was RE: [Sipping-emergency] proposed charter, new wg on emergency Date: Mon, 27 Sep 2004 19:42:12 -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.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > I changed the subject, as we are off the subject of a new charter, > as we agree validation should be in that charter. > Brian, I'm not sure that everyone on this distribution agrees that validation should be in the scope of this proposed working group. In fact, until I read your mail, I had gotten the sense that several voices (including James, Marc and Nate) were questioning this idea. I think validation as such is probably outside of the core expertise of the IETF, whereas routing is more likely to be a place where we can do some solid work. The expertise of the IETF does not lie in subjects like whether Conrad St is in Butler County or Pine Township, nor in recommending how you might figure something like that out. Moreover, this seems to be a back-end application issue, not a protocol issue, as I think a number of people have already pointed out. I think that validation is a separable operation from routing, even if it is a prerequisite in some operational models. An umbrella specification that described everything you needed to do in order to provide emergency services might include validation, but that doesn't mean that the routing protocol should change in any way because validation was or was not performed. But I don't think the IETF has the breadth to tackle that whole umbrella. Jon Peterson NeuStar, Inc. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 22:27:34 2004 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 WAA03026 for ; Mon, 27 Sep 2004 22:27:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC7q4-0006yQ-J3 for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 22:35:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC7br-0004Sz-K7; Mon, 27 Sep 2004 22:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC7T1-0003jh-LA for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 22:11:53 -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 WAA02361 for ; Mon, 27 Sep 2004 22:11:44 -0400 (EDT) Message-Id: <200409280211.WAA02361@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC7al-0006kO-5u for sipping-emergency@ietf.org; Mon, 27 Sep 2004 22:19:47 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CC7Sq-0005U0-3w; Mon, 27 Sep 2004 21:11:36 -0500 From: "Brian Rosen" To: "'Peterson, Jon'" , "'Marc Linsner'" , Subject: RE: How to handle Validation failures was RE: [Sipping-emergency] proposed charter, new wg on emergency Date: Mon, 27 Sep 2004 22:11:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF41DD@stntexch04.cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSk65xQEbQeA9aHSvqqjk8Iyc+j7QAA+ttA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit I did not mean to imply that the group, or IETF agreed on validation. I was really only addressing Nate. Sorry for the confusion. I can get any number of professionals in the emergency call space to talk to you about validation. Nate is a good resource. It's a fundamental requirement when you have location. It's separable in the sense that you could have two entirely separate mechanisms to determine routing and to validate a location. However, I observe that both involve the same sequence of actions: you take a location, and look it up in a database to determine where to route the call. If you don't find the location in the database, then it's not a valid location. You can do the lookup any time, and use any mechanism to query, but you need to use a lookup to determine boundaries, and that lookup can, by implication, validate the address. That makes the job easy, which is good, but the real issue is that it's a requirement, a pressing requirement, that won't wait. It's not backend if you want the USER to be able to determine if the location is valid. I care, and I think it needs to be a first class requirement. Whether it's backend or not, it needs to be standardized because the parts that deliver the address and the parts that have the database are independent of each other and need to be able to work together. The expertise is not an issue. The validation problem is simple. Any complications are really in the nature of the representation of the information and are in any event shared with the routing. Brian > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Monday, September 27, 2004 7:42 PM > To: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org > Subject: RE: How to handle Validation failures was RE: [Sipping-emergency] > proposed charter, new wg on emergency > > > > I changed the subject, as we are off the subject of a new charter, > > as we agree validation should be in that charter. > > > > Brian, > > I'm not sure that everyone on this distribution agrees that validation > should be in the scope of this proposed working group. In fact, until I > read > your mail, I had gotten the sense that several voices (including James, > Marc > and Nate) were questioning this idea. > > I think validation as such is probably outside of the core expertise of > the > IETF, whereas routing is more likely to be a place where we can do some > solid work. The expertise of the IETF does not lie in subjects like > whether > Conrad St is in Butler County or Pine Township, nor in recommending how > you > might figure something like that out. Moreover, this seems to be a back- > end > application issue, not a protocol issue, as I think a number of people > have > already pointed out. > > I think that validation is a separable operation from routing, even if it > is > a prerequisite in some operational models. An umbrella specification that > described everything you needed to do in order to provide emergency > services > might include validation, but that doesn't mean that the routing protocol > should change in any way because validation was or was not performed. But > I > don't think the IETF has the breadth to tackle that whole umbrella. > > Jon Peterson > NeuStar, Inc. > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Mon Sep 27 22:28:53 2004 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 WAA03102 for ; Mon, 27 Sep 2004 22:28:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC7rL-0006zo-Uo for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 22:36:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC7dA-0004Ws-Av; Mon, 27 Sep 2004 22:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC7WQ-000469-LX for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 22:15: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 WAA02511 for ; Mon, 27 Sep 2004 22:15:16 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC7e7-0006nL-G5 for sipping-emergency@ietf.org; Mon, 27 Sep 2004 22:23:18 -0400 Received: from razor.cs.columbia.edu (IDENT:Noc9qszlGURI2A++dWcPbMSFsrpBSLX8@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8S2F6wG002609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 27 Sep 2004 22:15:07 -0400 (EDT) Received: from [127.0.0.1] (IDENT:P3Ju1hXiEGyrcWNHleRZshh/rcuPJ3Qb@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8S2F0YZ014894; Mon, 27 Sep 2004 22:15:00 -0400 Message-ID: <4158C91F.7040303@cs.columbia.edu> Date: Mon, 27 Sep 2004 22:14:55 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sipping-emergency] proposed charter, new wg on emergency cal ling and routing References: <7927C67249E4AD43BC05B539AF0D129801AF41DA@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF41DA@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.27.6 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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org, "'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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > Henning, > > Certainly, this charter was not intended to guarantee to any particular > outcome of the standards process, but rather to select a narrow scope of > work that is likely to be achievable. No doubt a choice of scope can make > all the difference in the selection of a solution. If you're especially > concerned about, say, the mention of IRIS in the text below, that can be > elided from the final version. The deliverables text there is still rough. > Specific suggestions would be helpful, obviously. One relatively simple division has three deliverables: - A terminology and requirements informational document - A 'how to identify an emergency call' BCP - A 'how to route an emergency call based on location information' BCP/STD (depending on whether new protocol work is needed or one simply describes how to use something existing for this) I find it somewhat strange, also, that the call routing protocol isn't mentioned. Should the WG concern itself with H.323, Skype, Asterisk and other protocols? (While I suspect some similarities across these, scoping might be helpful here. I'm again speaking from NENA experience here, particularly in the I2 discussions.) > > I appreciate that you feel a requirement has been missed in the charter; I > have a hard time looking at the deliverables you cite below, though, and > understanding in what respect they suggest a nationally-specific or > centralized design for this work (neither of which would be default > assumptions for IETF work). Can you suggest any specific language here that > will improve the starter text? Do you just want to see something in the My concern is primarily due to the directory notion. Once this is removed, the worry is diminished. I think writing this requirement as part of the charter would be quite helpful. > descriptive text of the charter to the effect that the design here needs to > be delegative and allow distribution of call routing data? If so, I'd have > no problem including something to that effect. Indeed. Let's just say that there are people in certain companies (not generally active in the IETF) that have an interest in a centrally-controlled, pay-for-use one-big-national directory model since that corresponds nicely to their existing ALI business model. Those involved in the NENA discussion can fill in the details, but they are probably not relevant here. > > Jon Peterson > NeuStar, Inc. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 07:01:54 2004 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 HAA12685 for ; Tue, 28 Sep 2004 07:01:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCFru-0006lo-Fx for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 07:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCFif-0001Bw-AV; Tue, 28 Sep 2004 07: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 1CCFeq-0000uB-RH for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 06:56: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 GAA12534 for ; Tue, 28 Sep 2004 06:56:29 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from dpvc-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCFmf-0006hd-A5 for sipping-emergency@ietf.org; Tue, 28 Sep 2004 07:04:37 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 28 Sep 2004 06:58:19 -0400 Message-ID: Thread-Topic: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency thread-index: AcSk7OQ67kVhP0iWSjW9e47ruj2B2gAWwR9A To: "Peterson, Jon" , "Brian Rosen" , "Marc Linsner" , X-Spam-Score: 1.1 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Validating location information is implicit for routing. Otherwise, all = calls would be treated as "default" routed or worse, would rely on other = mechanisms to provide routing instructions outside the control of the = ECC (the ECC currently provides instructions and input on the construct = of the MSAG to the extent possible, which is used for the validation = process). Unvalidated location information could reduce or even prevent = a timely emergency response to a particular location. As I implied = before, the lack of validation should not prevent delivery of a call to = a geographically appropriate ECC however, all efforts need to be made to = ensure that end devices utilize validated location information. So, if = the charter of this effort is to decide on how routing is accomplished = than validation of the information used to make that routing decision = should be considered in the process as well. Nate=20 -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, September 27, 2004 7:42 PM To: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency > I changed the subject, as we are off the subject of a new charter, > as we agree validation should be in that charter. >=20 Brian, I'm not sure that everyone on this distribution agrees that validation should be in the scope of this proposed working group. In fact, until I = read your mail, I had gotten the sense that several voices (including James, = Marc and Nate) were questioning this idea. I think validation as such is probably outside of the core expertise of = the IETF, whereas routing is more likely to be a place where we can do some solid work. The expertise of the IETF does not lie in subjects like = whether Conrad St is in Butler County or Pine Township, nor in recommending how = you might figure something like that out. Moreover, this seems to be a = back-end application issue, not a protocol issue, as I think a number of people = have already pointed out. I think that validation is a separable operation from routing, even if = it is a prerequisite in some operational models. An umbrella specification = that described everything you needed to do in order to provide emergency = services might include validation, but that doesn't mean that the routing = protocol should change in any way because validation was or was not performed. = But I don't think the IETF has the breadth to tackle that whole umbrella. Jon Peterson NeuStar, Inc.=20 _______________________________________________ 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 From sipping-emergency-bounces@ietf.org Tue Sep 28 08:44:05 2004 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 IAA18510 for ; Tue, 28 Sep 2004 08:44:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHSm-0000N3-Cj for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 08:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCH9c-00072z-AQ; Tue, 28 Sep 2004 08:32:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCH6q-0006aM-55 for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 08:29:32 -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 IAA17730 for ; Tue, 28 Sep 2004 08:29:30 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHEf-00007p-GW for sipping-emergency@ietf.org; Tue, 28 Sep 2004 08:37:37 -0400 Received: from razor.cs.columbia.edu (IDENT:9lDdZmKfGvtcnUPOKyanvkg1qnZPFrxQ@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8SCTRwG006383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 28 Sep 2004 08:29:28 -0400 (EDT) Received: from [127.0.0.1] (IDENT:5AcrekDmlUvj5O148wdACAfk5ZinTMIo@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8SCTQYZ018643; Tue, 28 Sep 2004 08:29:27 -0400 Message-ID: <41595926.4040002@cs.columbia.edu> Date: Tue, 28 Sep 2004 08:29:26 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wilcox@e911.psd.state.vt.us Subject: Re: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency References: In-Reply-To: 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.28.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: 2409bba43e9c8d580670fda8b695204a 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit This can be seen as a special case of testing. Thus, if you assume that there is a test mode that attempts to reach the PSAP, but does not actually ring, you'd have tested the full routing chain, including whether the civic address is indeed mappable. A separate question is whether a separate address-only validation mode is appropriate. This probably depends on the overall architecture. As we've discussed before, I think there is general agreement that you'd want the ability for end-to-end non-interfering testing in any event. wilcox@e911.psd.state.vt.us wrote: > Validating location information is implicit for routing. Otherwise, > all calls would be treated as "default" routed or worse, would rely > on other mechanisms to provide routing instructions outside the > control of the ECC (the ECC currently provides instructions and input > on the construct of the MSAG to the extent possible, which is used > for the validation process). Unvalidated location information could > reduce or even prevent a timely emergency response to a particular > location. As I implied before, the lack of validation should not > prevent delivery of a call to a geographically appropriate ECC > however, all efforts need to be made to ensure that end devices > utilize validated location information. So, if the charter of this > effort is to decide on how routing is accomplished than validation of > the information used to make that routing decision should be > considered in the process as well. > > Nate _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 09:09:37 2004 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 JAA20191 for ; Tue, 28 Sep 2004 09:09:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHrS-0000uc-K2 for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 09:17:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHet-0004E8-RQ; Tue, 28 Sep 2004 09:04:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHVU-00026t-UB for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 08:55:00 -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 IAA19238 for ; Tue, 28 Sep 2004 08:54:59 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHdK-0000bv-GJ for sipping-emergency@ietf.org; Tue, 28 Sep 2004 09:03:06 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Sep 2004 05:57:54 -0700 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8SCsLwp005856; Tue, 28 Sep 2004 05:54:22 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA29076; Tue, 28 Sep 2004 05:54:23 -0700 (PDT) From: "Marc Linsner" To: "'Peterson, Jon'" , "'Brian Rosen'" , Date: Tue, 28 Sep 2004 08:54:23 -0400 Message-ID: <014801c4a55a$48bde260$2c0d0d0a@mlinsnerzk7abh> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF41DD@stntexch04.cis.neustar.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Subject: [Sipping-emergency] Civil location syntax validation - was RE: How to handle Validation failures X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Changed the subject line to more correctly describe the function. Civil location syntax validation could be considered as a requirement = when determining the routing design. If routing is designed properly, = validation will simply be a routing query that utilizes the response differently. Validation, in this context, does not include the verification that the device is actually located where it claims to be, it is simply a process that verifies that the syntax/value of the location provided describes a valid location known by all. A simple routing query that produces a = routing result is validation in this context. -Marc Linsner- > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: Monday, September 27, 2004 7:42 PM > To: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org > Subject: RE: How to handle Validation failures was RE:=20 > [Sipping-emergency] proposed charter, new wg on emergency >=20 >=20 >=20 > > I changed the subject, as we are off the subject of a new=20 > charter, as=20 > > we agree validation should be in that charter. > >=20 >=20 > Brian, >=20 > I'm not sure that everyone on this distribution agrees that=20 > validation should be in the scope of this proposed working=20 > group. In fact, until I read your mail, I had gotten the=20 > sense that several voices (including James, Marc and Nate)=20 > were questioning this idea. >=20 > I think validation as such is probably outside of the core=20 > expertise of the IETF, whereas routing is more likely to be a=20 > place where we can do some solid work. The expertise of the=20 > IETF does not lie in subjects like whether Conrad St is in=20 > Butler County or Pine Township, nor in recommending how you=20 > might figure something like that out. Moreover, this seems to=20 > be a back-end application issue, not a protocol issue, as I=20 > think a number of people have already pointed out. >=20 > I think that validation is a separable operation from=20 > routing, even if it is a prerequisite in some operational=20 > models. An umbrella specification that described everything=20 > you needed to do in order to provide emergency services might=20 > include validation, but that doesn't mean that the routing=20 > protocol should change in any way because validation was or=20 > was not performed. But I don't think the IETF has the breadth=20 > to tackle that whole umbrella. >=20 > Jon Peterson > NeuStar, Inc.=20 >=20 _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 09:14:06 2004 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 JAA20617 for ; Tue, 28 Sep 2004 09:14:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHvq-00013h-DE for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 09:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHi8-0007P8-Ce; Tue, 28 Sep 2004 09:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHe6-0003tE-Dm for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 09:03:54 -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 JAA19689 for ; Tue, 28 Sep 2004 09:03:52 -0400 (EDT) Message-Id: <200409281303.JAA19689@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHlw-0000mB-28 for sipping-emergency@ietf.org; Tue, 28 Sep 2004 09:12:00 -0400 Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CCHck-00084w-Ap; Tue, 28 Sep 2004 08:02:30 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Peterson, Jon'" , Date: Tue, 28 Sep 2004 09:02:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <014801c4a55a$48bde260$2c0d0d0a@mlinsnerzk7abh> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSlWksr7xmKHk9hTuibqFKVjg+vrQAAEt3A X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.8 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Subject: [Sipping-emergency] RE: Civil location syntax validation - was RE: How to handle Validation failures X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Yeah, that's the way I see it. Validation is a requirement. Validation is the first part of determining a route: A query using the location information as the key. Any answer is validation. The answer is the route. You can do the validation query without needing the route. You do that as an independent verification that the location information is valid. Validation is automatically performed when you determine the route, either during a test operation as Henning describes, or for the actual call (not implying whether route determination is done prior to or at the time of an emergency call). Jon, is that sufficient information to consider validation within the charter? Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, September 28, 2004 8:54 AM > To: 'Peterson, Jon'; 'Brian Rosen'; sipping-emergency@ietf.org > Subject: Civil location syntax validation - was RE: How to handle > Validation failures > > Changed the subject line to more correctly describe the function. > > Civil location syntax validation could be considered as a requirement when > determining the routing design. If routing is designed properly, > validation > will simply be a routing query that utilizes the response differently. > Validation, in this context, does not include the verification that the > device is actually located where it claims to be, it is simply a process > that verifies that the syntax/value of the location provided describes a > valid location known by all. A simple routing query that produces a > routing > result is validation in this context. > > > -Marc Linsner- > > > > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Monday, September 27, 2004 7:42 PM > > To: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org > > Subject: RE: How to handle Validation failures was RE: > > [Sipping-emergency] proposed charter, new wg on emergency > > > > > > > > > I changed the subject, as we are off the subject of a new > > charter, as > > > we agree validation should be in that charter. > > > > > > > Brian, > > > > I'm not sure that everyone on this distribution agrees that > > validation should be in the scope of this proposed working > > group. In fact, until I read your mail, I had gotten the > > sense that several voices (including James, Marc and Nate) > > were questioning this idea. > > > > I think validation as such is probably outside of the core > > expertise of the IETF, whereas routing is more likely to be a > > place where we can do some solid work. The expertise of the > > IETF does not lie in subjects like whether Conrad St is in > > Butler County or Pine Township, nor in recommending how you > > might figure something like that out. Moreover, this seems to > > be a back-end application issue, not a protocol issue, as I > > think a number of people have already pointed out. > > > > I think that validation is a separable operation from > > routing, even if it is a prerequisite in some operational > > models. An umbrella specification that described everything > > you needed to do in order to provide emergency services might > > include validation, but that doesn't mean that the routing > > protocol should change in any way because validation was or > > was not performed. But I don't think the IETF has the breadth > > to tackle that whole umbrella. > > > > Jon Peterson > > NeuStar, Inc. > > > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 09:14:28 2004 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 JAA20667 for ; Tue, 28 Sep 2004 09:14:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHwB-000148-Rt for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 09:22:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHi8-0007PK-J5; Tue, 28 Sep 2004 09:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHeP-0003yr-1j for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 09:04:13 -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 JAA19706 for ; Tue, 28 Sep 2004 09:04:11 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from dpvc-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHmD-0000lw-OQ for sipping-emergency@ietf.org; Tue, 28 Sep 2004 09:12:19 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 28 Sep 2004 09:06:03 -0400 Message-ID: Thread-Topic: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency thread-index: AcSlV0rpDu1XqMjjTSeVb3PvgHagtAAA2VvU To: "Henning Schulzrinne" X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0148856734==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 --===============0148856734== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIG5vbi1pbnRlcmZlcmluZyB0ZXN0aW5nIGVuZCB0byBlbmQuDQoNCiANCg0K VWx0aW1hdGVseSwgcm91dGluZyBvZiBhIGNhbGwgZG9lcyBub3Qgc3RvcCBhdCBhbiBFQ0MuIEZv ciBhbGwgcHJhY3RpY2FsIHB1cnBvc2VzIGl0IGFsc28gZGVyaXZlcyBhIG1lYW5zIGZvciBkZXRl cm1pbmluZyB0aGUgY29ycmVjdCByZXNwb25zZSwgd2hpY2ggaXMgcGFydCBvZiB0aGUgbWVzc2Fn ZSByZWxheSAoaW5jb3Jwb3JhdGluZyBlbWVyZ2VuY3kgcmVzcG9uZGVycyBpbiB0aGUgY2hhaW4p LiBWYWxpZGF0aW9uIG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uIGFsc28gZW5zdXJlcyB0aGF0IHRo ZSBjb3JyZWN0IHJlc3BvbnNlIHJlY29tbWVuZGF0aW9uIGlzIGFzc2lnbmVkLiBUYWtlIGZvciBl eGFtcGxlIHR3byBsb2NhdGlvbnMgdGhhdCByZXNpZGUgc2lkZS1ieS1zaWRlLCBvbmUgaXMgYSBy ZXNpZGVuY2UgYW5kIHRoZSBvdGhlciBpcyBhIG51Y2xlYXIgcG93ZXIgcGxhbnQuIEZvciB0aGUg cmVzaWRlbmNlLCBhIHN0YW5kYXJkIHJlc3BvbnNlIGZvciBmaXJlIGFwcGFyYXR1cyBpcyBmaW5l IGhvd2V2ZXIsIGZvciB0aGUgbnVjbGVhciBwb3dlciBwbGFudCBhbiBlbnRpcmVseSBkaWZmZXJl bnQgcmVzcG9uc2Ugc2NlbmFyaW8gbWF5IGJlIG5lY2Vzc2FyeSAocGVyaGFwcyB0aGUgZmlyZSBk ZXBhcnRtZW50IGxvY2F0ZWQgYXQgdGhlIGZhY2lsaXR5IGl0c2VsZikuIElmIHRoZSBjYWxsIGlz IHJvdXRlZCB0byB0aGUgRUNDIHJlc3BvbnNpYmxlIGZvciB0aGF0IGxvY2F0aW9uIHdpdGhvdXQg dmFsaWRhdGlvbiBvZiB0aGF0IGxvY2F0aW9uIGluZm9ybWF0aW9uIChhbmQgdWx0aW1hdGVseSB2 YWxpZGF0aW9uIG9mIHJlc3BvbmRlciBpbmZvcm1hdGlvbiksIHRoZXJlIHdpbGwgYmUgbm8gaW5k aWNhdGlvbiB0aGF0IGEgZGlmZmVyZW50IHJlc3BvbnNlIGlzIG5lY2Vzc2FyeSBhbmQgY29ycmVj dCByb3V0aW5nIG9mIHRoZSBjYWxsIGhhcyBub3QgYmVlbiBhY2NvbXBsaXNoZWQuIEN1cnJlbnRs eSwgdGhpcyBpcyBhY2NvbXBsaXNoZWQgaW4gdGhlIFVTIDktMS0xIHN5c3RlbSBieSBhc3NpZ25p bmcgYSBzcGVjaWFsIHpvbmUgKEVTWikgdG8gdGhhdCBsb2NhdGlvbiBhbmQgYXNzaWduaW5nIGFu IGluZGljYXRvciAoRVNOKSB0byB0aGF0IGxvY2F0aW9uIHRoYXQgZGVyaXZlcyB0aGUgY29ycmVj dCBwb2xpY2UsIGZpcmUgYW5kIEVNUyByZXNwb25zZS4gDQoNCiANCg0KVG8gZ2l2ZSB5b3UgYSBy ZWFsIHdvcmxkIGV4YW1wbGU6IEZvcmQgTW90b3IgQ29tcGFueSBqdXN0IHNlbGVjdGVkIHRvIHJl cGxhY2UgYWxsIG9mIHRoZWlyIHRyYWRpdGlvbmFsIHBob25lIHN5c3RlbXMgd2l0aCBWb0lQIHNl cnZpY2UgKDUwLDAwMCsgZW5kIGRldmljZXMpLiBZb3UgY2FuIGJldCB0aGF0IGluIHNvbWUgb2Yg dGhlIGxhcmdlciBwbGFudHMsIHRoZXkgaGF2ZSB0aGVpciBvd24gcmVzcG9uZGVycyBmb3IgUG9s aWNlLCBGaXJlIGFuZCBFTVMgc2VydmljZXMuDQoNCiANCg0KTmF0ZSANCiANCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tIA0KRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOmhnc0Bj cy5jb2x1bWJpYS5lZHVdIA0KU2VudDogVHVlIDkvMjgvMjAwNCA4OjI5IEFNIA0KVG86IHdpbGNv eEBlOTExLnBzZC5zdGF0ZS52dC51cyANCkNjOiBQZXRlcnNvbiwgSm9uOyBzaXBwaW5nLWVtZXJn ZW5jeUBpZXRmLm9yZyANClN1YmplY3Q6IFJlOiBIb3cgdG8gaGFuZGxlIFZhbGlkYXRpb24gZmFp bHVyZXMgd2FzIFJFOiBbU2lwcGluZy1lbWVyZ2VuY3ldcHJvcG9zZWQgY2hhcnRlciwgbmV3IHdn IG9uIGVtZXJnZW5jeQ0KDQoNCg0KCVRoaXMgY2FuIGJlIHNlZW4gYXMgYSBzcGVjaWFsIGNhc2Ug b2YgdGVzdGluZy4gVGh1cywgaWYgeW91IGFzc3VtZSB0aGF0DQoJdGhlcmUgaXMgYSB0ZXN0IG1v ZGUgdGhhdCBhdHRlbXB0cyB0byByZWFjaCB0aGUgUFNBUCwgYnV0IGRvZXMgbm90DQoJYWN0dWFs bHkgcmluZywgeW91J2QgaGF2ZSB0ZXN0ZWQgdGhlIGZ1bGwgcm91dGluZyBjaGFpbiwgaW5jbHVk aW5nDQoJd2hldGhlciB0aGUgY2l2aWMgYWRkcmVzcyBpcyBpbmRlZWQgbWFwcGFibGUuDQoJDQoJ QSBzZXBhcmF0ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIGEgc2VwYXJhdGUgYWRkcmVzcy1vbmx5IHZh bGlkYXRpb24gbW9kZQ0KCWlzIGFwcHJvcHJpYXRlLiBUaGlzIHByb2JhYmx5IGRlcGVuZHMgb24g dGhlIG92ZXJhbGwgYXJjaGl0ZWN0dXJlLiBBcw0KCXdlJ3ZlIGRpc2N1c3NlZCBiZWZvcmUsIEkg dGhpbmsgdGhlcmUgaXMgZ2VuZXJhbCBhZ3JlZW1lbnQgdGhhdCB5b3UnZA0KCXdhbnQgdGhlIGFi aWxpdHkgZm9yIGVuZC10by1lbmQgbm9uLWludGVyZmVyaW5nIHRlc3RpbmcgaW4gYW55IGV2ZW50 Lg0KCQ0KCXdpbGNveEBlOTExLnBzZC5zdGF0ZS52dC51cyB3cm90ZToNCgk+IFZhbGlkYXRpbmcg bG9jYXRpb24gaW5mb3JtYXRpb24gaXMgaW1wbGljaXQgZm9yIHJvdXRpbmcuIE90aGVyd2lzZSwN Cgk+IGFsbCBjYWxscyB3b3VsZCBiZSB0cmVhdGVkIGFzICJkZWZhdWx0IiByb3V0ZWQgb3Igd29y c2UsIHdvdWxkIHJlbHkNCgk+IG9uIG90aGVyIG1lY2hhbmlzbXMgdG8gcHJvdmlkZSByb3V0aW5n IGluc3RydWN0aW9ucyBvdXRzaWRlIHRoZQ0KCT4gY29udHJvbCBvZiB0aGUgRUNDICh0aGUgRUND IGN1cnJlbnRseSBwcm92aWRlcyBpbnN0cnVjdGlvbnMgYW5kIGlucHV0DQoJPiBvbiB0aGUgY29u c3RydWN0IG9mIHRoZSBNU0FHIHRvIHRoZSBleHRlbnQgcG9zc2libGUsIHdoaWNoIGlzIHVzZWQN Cgk+IGZvciB0aGUgdmFsaWRhdGlvbiBwcm9jZXNzKS4gVW52YWxpZGF0ZWQgbG9jYXRpb24gaW5m b3JtYXRpb24gY291bGQNCgk+IHJlZHVjZSBvciBldmVuIHByZXZlbnQgYSB0aW1lbHkgZW1lcmdl bmN5IHJlc3BvbnNlIHRvIGEgcGFydGljdWxhcg0KCT4gbG9jYXRpb24uIEFzIEkgaW1wbGllZCBi ZWZvcmUsIHRoZSBsYWNrIG9mIHZhbGlkYXRpb24gc2hvdWxkIG5vdA0KCT4gcHJldmVudCBkZWxp dmVyeSBvZiBhIGNhbGwgdG8gYSBnZW9ncmFwaGljYWxseSBhcHByb3ByaWF0ZSBFQ0MNCgk+IGhv d2V2ZXIsIGFsbCBlZmZvcnRzIG5lZWQgdG8gYmUgbWFkZSB0byBlbnN1cmUgdGhhdCBlbmQgZGV2 aWNlcw0KCT4gdXRpbGl6ZSB2YWxpZGF0ZWQgbG9jYXRpb24gaW5mb3JtYXRpb24uIFNvLCBpZiB0 aGUgY2hhcnRlciBvZiB0aGlzDQoJPiBlZmZvcnQgaXMgdG8gZGVjaWRlIG9uIGhvdyByb3V0aW5n IGlzIGFjY29tcGxpc2hlZCB0aGFuIHZhbGlkYXRpb24gb2YNCgk+IHRoZSBpbmZvcm1hdGlvbiB1 c2VkIHRvIG1ha2UgdGhhdCByb3V0aW5nIGRlY2lzaW9uIHNob3VsZCBiZQ0KCT4gY29uc2lkZXJl ZCBpbiB0aGUgcHJvY2VzcyBhcyB3ZWxsLg0KCT4NCgk+IE5hdGUNCgkNCgkNCgkNCg0K --===============0148856734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============0148856734==-- From sipping-emergency-bounces@ietf.org Tue Sep 28 20:30:52 2004 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 UAA08877 for ; Tue, 28 Sep 2004 20:30:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSUs-0007k2-3d for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 20:39:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS3V-0001Tw-Lu; Tue, 28 Sep 2004 20:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRl9-0003Mc-Pp for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 19:51:52 -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 TAA05824 for ; Tue, 28 Sep 2004 19:51:48 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRsv-0006eC-9u for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:00:03 -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 i8SNoCPm001792; Tue, 28 Sep 2004 23:50:12 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Sep 2004 19:50:12 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41E8@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Brian Rosen'" , "'Marc Linsner'" , sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - wa s RE: How to handle Validation failures Date: Tue, 28 Sep 2004 19:50:06 -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: 8f374d0786b25a451ef87d82c076f593 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc So, just to make sure I understand, validation uses the same network operation, basically, that would be used for a route query? Agreed that it should be possible for a route query to return 'I didn't understand your address format', 'I understand your address and it isn't actually valid', and so on beyond just the sunny-day case of returning the route. Also, plus or minus some authorization and operational issues, I agree that an ordinary user should be able to launch this sort of query outside the context of an emergency call. To be clear, what I want to avoid is specifying exactly what happens in the backend of the server that causes responses like 'your address isn't actually valid'. I don't think we have the expertise to address that. Provided that the essence of the proposed requirement is that it be possible to use the route query mechanism as a validation mechanism, I have no problem with this. The question is, are there any differences in architecture/network messaging/security model/etc that I'm missing, here, which result from this requirement? If not, is this requirement inert (i.e., does it fail to have any impact on our protocol design)? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, September 28, 2004 6:02 AM > To: 'Marc Linsner'; 'Peterson, Jon'; sipping-emergency@ietf.org > Subject: [Sipping-emergency] RE: Civil location syntax > validation - was > RE: How to handle Validation failures > > > Yeah, that's the way I see it. > > Validation is a requirement. > Validation is the first part of determining a route: > A query using the location information as the key. > > Any answer is validation. The answer is the route. > > You can do the validation query without needing the route. > You do that as an independent verification that the > location information is valid. Validation is > automatically performed when you determine the route, > either during a test operation as Henning describes, > or for the actual call (not implying whether route > determination is done prior to or at the time of > an emergency call). > > Jon, is that sufficient information to consider validation > within the charter? > > Brian > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Tuesday, September 28, 2004 8:54 AM > > To: 'Peterson, Jon'; 'Brian Rosen'; sipping-emergency@ietf.org > > Subject: Civil location syntax validation - was RE: How to handle > > Validation failures > > > > Changed the subject line to more correctly describe the function. > > > > Civil location syntax validation could be considered as a > requirement when > > determining the routing design. If routing is designed properly, > > validation > > will simply be a routing query that utilizes the response > differently. > > Validation, in this context, does not include the > verification that the > > device is actually located where it claims to be, it is > simply a process > > that verifies that the syntax/value of the location > provided describes a > > valid location known by all. A simple routing query that produces a > > routing > > result is validation in this context. > > > > > > -Marc Linsner- > > > > > > > > > > > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Monday, September 27, 2004 7:42 PM > > > To: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org > > > Subject: RE: How to handle Validation failures was RE: > > > [Sipping-emergency] proposed charter, new wg on emergency > > > > > > > > > > > > > I changed the subject, as we are off the subject of a new > > > charter, as > > > > we agree validation should be in that charter. > > > > > > > > > > Brian, > > > > > > I'm not sure that everyone on this distribution agrees that > > > validation should be in the scope of this proposed working > > > group. In fact, until I read your mail, I had gotten the > > > sense that several voices (including James, Marc and Nate) > > > were questioning this idea. > > > > > > I think validation as such is probably outside of the core > > > expertise of the IETF, whereas routing is more likely to be a > > > place where we can do some solid work. The expertise of the > > > IETF does not lie in subjects like whether Conrad St is in > > > Butler County or Pine Township, nor in recommending how you > > > might figure something like that out. Moreover, this seems to > > > be a back-end application issue, not a protocol issue, as I > > > think a number of people have already pointed out. > > > > > > I think that validation is a separable operation from > > > routing, even if it is a prerequisite in some operational > > > models. An umbrella specification that described everything > > > you needed to do in order to provide emergency services might > > > include validation, but that doesn't mean that the routing > > > protocol should change in any way because validation was or > > > was not performed. But I don't think the IETF has the breadth > > > to tackle that whole umbrella. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > > > > > > _______________________________________________ > 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 From sipping-emergency-bounces@ietf.org Tue Sep 28 20:30:57 2004 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 UAA08909 for ; Tue, 28 Sep 2004 20:30:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSUx-0007kf-3r for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 20:39:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS3W-0001UI-2b; Tue, 28 Sep 2004 20:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRlb-0003OK-UO for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 19:52:20 -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 TAA05832 for ; Tue, 28 Sep 2004 19:52:16 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRtX-0006f8-EB for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:00:31 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2004 16:51:55 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8SNpiwK014597; Tue, 28 Sep 2004 16:51:45 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA27926; Tue, 28 Sep 2004 16:51:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20040928183937.034dbf00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Sep 2004 18:51:45 -0500 To: Henning Schulzrinne , "Peterson, Jon" From: "James M. Polk" Subject: Re: [Sipping-emergency] proposed charter, new wg on emergency cal ling and routing In-Reply-To: <4158C91F.7040303@cs.columbia.edu> References: <7927C67249E4AD43BC05B539AF0D129801AF41DA@stntexch04.cis.neustar.com> <7927C67249E4AD43BC05B539AF0D129801AF41DA@stntexch04.cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sipping-emergency@ietf.org, "'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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 At 10:14 PM 9/27/2004 -0400, Henning Schulzrinne wrote: >Peterson, Jon wrote: >>Henning, >>The deliverables text there is still rough. >>Specific suggestions would be helpful, obviously. > >One relatively simple division has three deliverables: > >- A terminology and requirements informational document I agree this deliverable is necessary to ensure everyone with the different backgrounds involved do not continue to talk past each other - sometimes without knowing they are. >- A 'how to identify an emergency call' BCP "How to identify a session set-up request is to an emergency response center" (we need to think longer term than just voice) is a good task, although I don't know if it should be its own deliverable, or part of a larger effort. >- A 'how to route an emergency call based on location information' BCP/STD >(depending on whether new protocol work is needed or one simply describes >how to use something existing for this) This should be a deliverable, but could be combined with the item above to create an "identity and route and emergency session request" document. As a general thought here - there are a lot of BCPs being proposed. BCPs are generally *not* obsoleted or modified with future experience; therefore I believe these efforts should lean down the STDs Track process if possible so that a behavior or a mechanism can be modified to account for future learned capabilities. I know this is an unusual request if there is not protocol modification done, but this is an unusual area of work. >I find it somewhat strange, also, that the call routing protocol isn't >mentioned. Should the WG concern itself with H.323, Skype, Asterisk and >other protocols? \ SIP should be the base set-up protocol in the charter >(While I suspect some similarities across these, scoping might be helpful >here. I'm again speaking from NENA experience here, particularly in the I2 >discussions.) >>Jon Peterson >>NeuStar, Inc. > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 20:32:16 2004 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 UAA09037 for ; Tue, 28 Sep 2004 20:32:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSWD-0007mb-Mo for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 20:40:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS3u-0001oj-GK; Tue, 28 Sep 2004 20:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRtb-0005hW-Kc for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 20:00:35 -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 UAA06658 for ; Tue, 28 Sep 2004 20:00:32 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCS1X-0006wf-6h for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:08:47 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 28 Sep 2004 17:00:36 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8T001wK020696; Tue, 28 Sep 2004 17:00:01 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA08802; Tue, 28 Sep 2004 17:00:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20040928185242.01d2e6f8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Sep 2004 19:00:01 -0500 To: wilcox@e911.psd.state.vt.us, "Peterson, Jon" , "Brian Rosen" , "Marc Linsner" , From: "James M. Polk" Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 At 06:58 AM 9/28/2004 -0400, wilcox@e911.psd.state.vt.us wrote: >Validating location information is implicit for routing. this might not be the case. If I live in Dallas, Texas, and Dallas has one centralized ERC (which it does), wouldn't my call get routed correctly if I had any of the 3 following conditions also present? - the inclusion of my correct street address in Dallas - the inclusion of a different street address in Dallas than the one I am calling from - no street address provided Under each of these 3 conditions, the call set-up would still be sent to the correct ERC, because for this large metro area, the pertinent information (that I was calling from Dallas) was included. >Otherwise, all calls would be treated as "default" routed or worse, would >rely on other mechanisms to provide routing instructions outside the >control of the ECC (the ECC currently provides instructions and input on >the construct of the MSAG to the extent possible, which is used for the >validation process). Unvalidated location information could reduce or even >prevent a timely emergency response to a particular location. As I implied >before, the lack of validation should not prevent delivery of a call to a >geographically appropriate ECC however, all efforts need to be made to >ensure that end devices utilize validated location information. So, if the >charter of this effort is to decide on how routing is accomplished than >validation of the information used to make that routing decision should be >considered in the process as well. > >Nate cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 20:38:07 2004 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 UAA09462 for ; Tue, 28 Sep 2004 20:38:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSbr-0007tH-Lj for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 20:46:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSLk-0006e8-FE; Tue, 28 Sep 2004 20:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRzp-00083l-8k for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 20:07:01 -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 UAA07294 for ; Tue, 28 Sep 2004 20:06:59 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCS7j-0007C7-Sq for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:15:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 28 Sep 2004 17:12:49 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8T06Nlr015229; Tue, 28 Sep 2004 17:06:24 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA18760; Tue, 28 Sep 2004 17:06:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20040928190125.027914a8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Sep 2004 19:06:26 -0500 To: Henning Schulzrinne , wilcox@e911.psd.state.vt.us From: "James M. Polk" Subject: Re: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency In-Reply-To: <41595926.4040002@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab At 08:29 AM 9/28/2004 -0400, Henning Schulzrinne wrote: >This can be seen as a special case of testing. Thus, if you assume that >there is a test mode that attempts to reach the PSAP, but does not >actually ring, you'd have tested the full routing chain, including whether >the civic address is indeed mappable. how would a new user to a new area (say I just got off the plane in Chicago and didn't know I was actually 25 miles away from that city, and jurisdictionally in another ERC's area) know they had the wrong ERC say their phone will indeed contact the right ERC when they do call 911? Will a red flashing light go off on the phone with a warning screaming "danger danger will robinson"? That the phone can do this test is huge for this effort, it is just a matter of telling which ERC responded positively, and either knowing that the phone can call 911 when the emergency arrives or the wrong ERC (when contacted) can transfer the call when it is placed. >A separate question is whether a separate address-only validation mode is >appropriate. This probably depends on the overall architecture. As we've >discussed before, I think there is general agreement that you'd want the >ability for end-to-end non-interfering testing in any event. > >wilcox@e911.psd.state.vt.us wrote: >>Validating location information is implicit for routing. Otherwise, >>all calls would be treated as "default" routed or worse, would rely >>on other mechanisms to provide routing instructions outside the >>control of the ECC (the ECC currently provides instructions and input >>on the construct of the MSAG to the extent possible, which is used >>for the validation process). Unvalidated location information could >>reduce or even prevent a timely emergency response to a particular >>location. As I implied before, the lack of validation should not >>prevent delivery of a call to a geographically appropriate ECC >>however, all efforts need to be made to ensure that end devices >>utilize validated location information. So, if the charter of this >>effort is to decide on how routing is accomplished than validation of >>the information used to make that routing decision should be >>considered in the process as well. >>Nate > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 20:42:46 2004 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 UAA09770 for ; Tue, 28 Sep 2004 20:42:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSgO-0007yv-2l for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 20:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSPB-000808-PQ; Tue, 28 Sep 2004 20:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS5L-0002nE-Si for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 20:12:43 -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 UAA07797 for ; Tue, 28 Sep 2004 20:12:42 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSDG-0007Nv-GV for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:20:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 28 Sep 2004 17:18:31 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8T0C6lr021240; Tue, 28 Sep 2004 17:12:07 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA27261; Tue, 28 Sep 2004 17:12:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20040928191103.0380c008@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Sep 2004 19:12:08 -0500 To: wilcox@e911.psd.state.vt.us, "Henning Schulzrinne" From: "James M. Polk" Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 At 09:06 AM 9/28/2004 -0400, wilcox@e911.psd.state.vt.us wrote: >I agree with non-interfering testing end to end. > >Ultimately, routing of a call does not stop at an ECC. For all practical >purposes it also derives a means for determining the correct response, >which is part of the message relay (incorporating emergency responders in >the chain). Validation of location information also ensures that the >correct response recommendation is assigned. Take for example two >locations that reside side-by-side, one is a residence and the other is a >nuclear power plant. What if the residential caller is calling about the power plant that is on fire? ;-) >For the residence, a standard response for fire apparatus is fine however, >for the nuclear power plant an entirely different response scenario may be >necessary (perhaps the fire department located at the facility itself). If >the call is routed to the ECC responsible for that location without >validation of that location information (and ultimately validation of >responder information), there will be no indication that a different >response is necessary and correct routing of the call has not been >accomplished. Currently, this is accomplished in the US 9-1-1 system by >assigning a special zone (ESZ) to that location and assigning an indicator >(ESN) to that location that derives the correct police, fire and EMS response. > > > >To give you a real world example: Ford Motor Company just selected to >replace all of their traditional phone systems with VoIP service (50,000+ >end devices). You can bet that in some of the larger plants, they have >their own responders for Police, Fire and EMS services. > > > >Nate > >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Tue 9/28/2004 8:29 AM >To: wilcox@e911.psd.state.vt.us >Cc: Peterson, Jon; sipping-emergency@ietf.org >Subject: Re: How to handle Validation failures was RE: >[Sipping-emergency]proposed charter, new wg on emergency > > > > This can be seen as a special case of testing. Thus, if you > assume that > there is a test mode that attempts to reach the PSAP, but does not > actually ring, you'd have tested the full routing chain, including > whether the civic address is indeed mappable. > > A separate question is whether a separate address-only validation > mode > is appropriate. This probably depends on the overall architecture. As > we've discussed before, I think there is general agreement that you'd > want the ability for end-to-end non-interfering testing in any event. > > wilcox@e911.psd.state.vt.us wrote: > > Validating location information is implicit for routing. Otherwise, > > all calls would be treated as "default" routed or worse, would rely > > on other mechanisms to provide routing instructions outside the > > control of the ECC (the ECC currently provides instructions and > input > > on the construct of the MSAG to the extent possible, which is used > > for the validation process). Unvalidated location information could > > reduce or even prevent a timely emergency response to a particular > > location. As I implied before, the lack of validation should not > > prevent delivery of a call to a geographically appropriate ECC > > however, all efforts need to be made to ensure that end devices > > utilize validated location information. So, if the charter of this > > effort is to decide on how routing is accomplished than > validation of > > the information used to make that routing decision should be > > considered in the process as well. > > > > Nate > > > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 20:51:23 2004 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 UAA10303 for ; Tue, 28 Sep 2004 20:51:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSoi-0008AL-5o for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 20:59:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSY9-0001tj-2q; Tue, 28 Sep 2004 20:42:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSNG-00073n-Dl for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 20:31:14 -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 UAA08945 for ; Tue, 28 Sep 2004 20:31:12 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSVB-0007jk-AL for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:39:26 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 28 Sep 2004 17:31:14 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8T0Ue3c010906 for ; Tue, 28 Sep 2004 17:30:40 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA20877 for ; Tue, 28 Sep 2004 17:30:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20040928191224.033abed0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Sep 2004 19:30:40 -0500 To: From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sipping-emergency] Does validation make coordinates obsolete? X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Since some on this list have been claiming validation is a mandatory function of calling for (911-type) assistance, why would coordinates ever be used again? This is troubling for many reasons, not the least of which is the fact that the PIDF-LO ID (in the RFC-Editor now) states coordinates are the default location conveyance (not civil addressing). Validation of coordinates makes no sense to most, and I feel validation of civil addressing is a false sense of verification. cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 20:53:21 2004 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 UAA10435 for ; Tue, 28 Sep 2004 20:53:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSqb-0008Dh-Tu for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 21:01:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSYO-00028D-PW; Tue, 28 Sep 2004 20:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSOv-0007nK-1Z for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 20:32:57 -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 UAA09082 for ; Tue, 28 Sep 2004 20:32:55 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSWp-0007mn-Us for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:41:09 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2004 17:32:33 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8T0WLwp029642 for ; Tue, 28 Sep 2004 17:32:22 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA23312 for ; Tue, 28 Sep 2004 17:32:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20040928191908.034536c8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Sep 2004 19:32:22 -0500 To: From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sipping-emergency] Does validation mean anything location based is ruled by the 911 folks? X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Does the need/rule (law?) for validation of a civil address for 911-type services mean coordinates will never be transmitted in the coming location industry? The whole idea of providing location to someone or some service is to convey where you are or get where they are or where the relation is between the two. If 911 services are going to require civil location validation in order to place a 911-type call, then doesn't that mean that any multimedia device I happen to have will have to support a civil location only, and be validated by the 911-type service prior to me being able to send you my location in any protocol? Just wondering where we're being steered... cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Tue Sep 28 22:07:54 2004 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 WAA13926 for ; Tue, 28 Sep 2004 22:07:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCU0n-00010x-Tw for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 22:16:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCTqO-0004LO-Ox; Tue, 28 Sep 2004 22:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCTjD-00030J-Q3 for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 21:57:59 -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 VAA13303 for ; Tue, 28 Sep 2004 21:57:57 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from dpvc-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCTrA-0000pv-Ek for sipping-emergency@ietf.org; Tue, 28 Sep 2004 22:06:12 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping-emergency] Does validation mean anything location based is ruled by the 911 folks? X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 28 Sep 2004 21:59:47 -0400 Message-ID: Thread-Topic: [Sipping-emergency] Does validation mean anything location based is ruled by the 911 folks? thread-index: AcSlvy/XXMKVcc+6Qvez3/rrTpweIgAA6Znm To: "James M. Polk" , X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0887813098==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 --===============0887813098== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFtZXMsDQoNCiANCg0KIkRvZXMgdGhlIG5lZWQvcnVsZSAobGF3PykiDQoNCiANCg0KTlcgLSBM YXdzIHJlbGF0aW5nIHRvIGVtZXJnZW5jeSBjYWxsIGRlbGl2ZXJ5IGFwcGx5IHRvIFBTVE4gYmFz ZWQgY2FsbHMgYW5kIGFyZSBqdXJpc2RpY3Rpb25hbGx5IHJlbGF0ZWQgKGkuZS4sIG9uIGEgc3Rh dGUgYnkgc3RhdGUgYmFzaXMpLiBBcyBmYXIgYXMgSSBrbm93IHRoZXJlIGFyZSBubyBsYXdzIGdv dmVybmluZyB0aGUgZGVsaXZlcnkgb2YgY2FsbHMgdGhhdCBvcmlnaW5hdGUgb24gdGhlIEludGVy bmV0LiANCg0KIA0KDQogImZvciB2YWxpZGF0aW9uIG9mIGEgY2l2aWwgYWRkcmVzcyBmb3IgOTEx LXR5cGUNCnNlcnZpY2VzIG1lYW4gY29vcmRpbmF0ZXMgd2lsbCBuZXZlciBiZSB0cmFuc21pdHRl ZCBpbiB0aGUgY29taW5nIGxvY2F0aW9uDQppbmR1c3RyeT8iDQoNCiANCg0KTlcgLSBXaGVuIHRo ZSB0ZWNobm9sb2d5IGlzIGF2YWlsYWJsZSBmb3IgY29vcmRpbmF0ZXMgdG8gYmUgcHJvdmlkZWQg YnkgYSByZWxpYWJsZSAodGhpbmsgY29uZmlkZW5jZSBhbmQgdW5jZXJ0YWludHkpIGRldmljZSB0 aGVuLCBjb29yZGluYXRlcyBzaG91bGQgYmUgY29uc2lkZXJlZC4gVHJ1dGhmdWxseSwgd2l0aCB0 aGUgYWR2ZW50IG9mIDgwMi4xNmUgSSBiZWxpZXZlIHRoYXQgaXQgd2lsbCBiZSBhbiBhYnNvbHV0 ZSBuZWNlc3NpdHkgdG8gdmlzaXQgdGhlIGNvb3JkaW5hdGUgcmVxdWlyZW1lbnQgaG93ZXZlciwg bW9zdCBlbmQgdXNlcnMgY2FuL3dpbGwgcmVsYXRlIHRvIHRoZWlyIGxvY2F0aW9uIHZpYSBhIGNp dmljIGFkZHJlc3MuIEFJUCdzIHdpbGwgcHJvdmlkZSBhIGNpdmljIGFkZHJlc3MgTE8uIFRoZWly IGlzIHNpbXBseSBubyBjdXJyZW50IG1ldGhvZCB0aGF0IGlzIHJlbGlhYmxlIHRvIGdlbmVyYXRl IGEgdmFsaWQgZ2VvIGxvYyByaWdodCBub3cgdGhhdCBpcyBjb21tb25seSBkZXBsb3llZC4gSXMg aXQgZmFpciB0byB3YWl0IGZvciB0aGlzIHRlY2hub2xvZ3kgdG8gYmVjb21lIGF2YWlsYWJsZSBi ZWZvcmUgbG9jYXRpb24gaW5mb3JtYXRpb24gY2FuIGJlIGRlbGl2ZXJlZD8gDQoNCiANCg0KQlRX IC0gR2VvIGJhc2VkIGxvY2F0aW9uIHByb3Zpc2lvbmluZyBpbiB0aGUgY3VycmVudCB3aXJlbGVz cyBpbmR1c3RyeSBmb3IgZW1lcmdlbmN5IGNhbGxzIGlzIGhpZ2hseSB1bnJlbGlhYmxlIGFuZCBt aXNsZWFkaW5nLiBJIGhvcGUgdGhlICJjb21pbmcgbG9jYXRpb24gaW5kdXN0cnkiIGRvZXMgbm90 IGRlcGxveSBhbnkgb2YgdGhlIHNhbWUgdGVjaG5pcXVlcyB1c2VkIGN1cnJlbnRseSBmb3IgY2Vs bHVsYXIgY2FsbHMuIEl0IElTIG1pc2VyYWJsZSBmcm9tIGEgcmVsaWFiaWxpdHkgYW5kIGFjY3Vy YWN5IHN0YW5kIHBvaW50Lg0KDQogIA0KDQoiVGhlIHdob2xlIGlkZWEgb2YgcHJvdmlkaW5nIGxv Y2F0aW9uIHRvIHNvbWVvbmUgb3Igc29tZSBzZXJ2aWNlIGlzIHRvDQpjb252ZXkgd2hlcmUgeW91 IGFyZSBvciBnZXQgd2hlcmUgdGhleSBhcmUgb3Igd2hlcmUgdGhlIHJlbGF0aW9uIGlzIGJldHdl ZW4NCnRoZSB0d28uIElmIDkxMSBzZXJ2aWNlcyBhcmUgZ29pbmcgdG8gcmVxdWlyZSBjaXZpbCBs b2NhdGlvbiB2YWxpZGF0aW9uIGluDQpvcmRlciB0byBwbGFjZSBhIDkxMS10eXBlIGNhbGwsIg0K DQogDQoNCk5XIC0gQSBsb2NhdGlvbiB0aGF0IGlzIG5vdCB2YWxpZGF0ZWQgc2hvdWxkIG5vdCBi ZSBkZW5pZWQgYW4gb3Bwb3J0dW5pdHkgdG8gcGxhY2UgYW4gZW1lcmdlbmN5IGNhbGwuIE90aGVy IHByb2Nlc3NlcyBjYW4gYWNjb21wbGlzaCB2YWxpZGF0aW9uIGFmdGVyIHRoZSBpbnZhbGlkIGxv Y2F0aW9uIGluZm9ybWF0aW9uIGlzIGRlbGl2ZXJlZCBhbmQgLCB0aGUgdmFsaWRhdGlvbiBwcm9j ZXNzIGl0c2VsZiBjYW4gdHJpZ2dlciBhIHNlcmllcyBvZiBldmVudHMgdGhhdCB3aWxsIHByb2Fj dGl2ZWx5IHJlc29sdmUgdGhlIGlzc3VlIHdlbGwgaW4gYWR2YW5jZSBvZiBhIGNhbGwgYmVpbmcg cGxhY2VkLg0KDQogDQoNCiJ0aGVuIGRvZXNuJ3QgdGhhdCBtZWFuIHRoYXQgYW55IG11bHRpbWVk aWEgZGV2aWNlIEkgaGFwcGVuIHRvIGhhdmUgd2lsbCBoYXZlIHRvIHN1cHBvcnQgYSBjaXZpbCBs b2NhdGlvbiBvbmx5LCINCg0KIA0KDQpOVyAtIFNlZSBteSBlYXJsaWVyIGNvbW1lbnRzLiBJcyB0 aGVyZSBhIHJlYXNvbiB3aHkgYm90aCBjaXZpYyBhbmQgZ2VvIGNhbm5vdCBiZSBzdXBwb3J0ZWQ/ DQoNCiANCg0KImFuZCBiZSB2YWxpZGF0ZWQgYnkgdGhlIDkxMS10eXBlIHNlcnZpY2UgcHJpb3Ig dG8gbWUgYmVpbmcgYWJsZSB0byBzZW5kIHlvdSBteQ0KbG9jYXRpb24gaW4gYW55IHByb3RvY29s PyINCg0KIA0KDQpOVyAtIFRoaXMgaXMgaW5jb3JyZWN0IGFuZCBpbiBmYWN0IEkgc2FpZCB0aGUg Y29udHJhcnkgdG8gdGhpcyB5ZXN0ZXJkYXkuIENhbGxzIHNob3VsZCBzdGlsbCBiZSBkZWxpdmVy ZWQgZXZlbiBpZiB0aGUgbG9jYXRpb24gdGhlIGRldmljZSBhdHRlbXB0ZWQgdG8gdXNlIGlzIG5v dCB2YWxpZCAoYW5kIGZhaWxlZCB2YWxpZGF0aW9uKS4gTXkgaG9wZSBpcyB0aGF0IHRoZSBsb2Nh dGlvbiBjYW4gYmUgY29ycmVjdGVkIGJlZm9yZSB0aGUgZGV2aWNlIGV2ZXIgcGxhY2VzIGEgY2Fs bCBidXQsIHVuZGVyIG5vIGNpcmN1bXN0YW5jZSwgc2hvdWxkIGEgY2FsbCBiZSBkZW5pZWQganVz dCBiZWNhdXNlIHRoZSBsb2NhdGlvbiBmYWlsZWQgdmFsaWRhdGlvbi4gDQoNCg0KDQoNCk15IGVh cmxpZXIgInNjZW5hcmlvIGJhc2VkIiBjb21tZW50cyB3ZXJlIG9ubHkgcHJvdmlkZWQgdG8gZXN0 YWJsaXNoIGEgYmFzZWxpbmUgb2YgcmVxdWlyZW1lbnRzIHRoYXQgd29yayB3ZWxsIGluIHRoZSBl eGlzdGluZyBlbWVyZ2VuY3kgY2FsbCBzeXN0ZW0uIEkgd291bGQgYXNzdW1lIHRoYXQgeW91IHdv dWxkIGFncmVlIHRoYXQgcHJvdmlkaW5nIGFjY3VyYXRlIGxvY2F0aW9uIGRhdGEgdG8gZ2VuZXJh dGUgYSBwcmVjaXNlIGVtZXJnZW5jeSByZXNwb25zZSBzaG91bGQgYmUgb25lIG9mIHRoZSBnb2Fs cyBvZiB0aGlzIGVmZm9ydC4gSSBkb24ndCB0aGluayB5b3UgYWdyZWUgdGhhdCBwcm92aWRpbmcg YW1iaWd1b3VzIChvciBubykgbG9jYXRpb24gZGF0YSBpcyBoZWxwZnVsLiAgDQoNCiANCg0KIkp1 c3Qgd29uZGVyaW5nIHdoZXJlIHdlJ3JlIGJlaW5nIHN0ZWVyZWQuLi4iDQoNCiANCg0KTlcgLSBJ ZiB5b3UgZmVlbCB0aGF0IHlvdSBhcmUgYmVpbmcgInN0ZWVyZWQiIGluIGEgc3BlY2lmaWMgZGly ZWN0aW9uLCB0aGF0IGlzIG5vdCBteSBpbnRlbnQuDQoNCiANCg0KTmF0ZSANCg0KIA0KDQo= --===============0887813098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============0887813098==-- From sipping-emergency-bounces@ietf.org Tue Sep 28 23:14:54 2004 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 XAA20148 for ; Tue, 28 Sep 2004 23:14:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCV3d-0002Y0-4H for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 23:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCUtl-0003Ob-0b; Tue, 28 Sep 2004 23:12:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCUmB-0000q7-3x for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 23:05:09 -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 XAA18386 for ; Tue, 28 Sep 2004 23:05:04 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCUtv-0002Cu-MF for sipping-emergency@ietf.org; Tue, 28 Sep 2004 23:13:20 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8T34Zpl013906; Tue, 28 Sep 2004 23:04:35 -0400 (EDT) Message-ID: <415A262C.60904@dynamicsoft.com> Date: Tue, 28 Sep 2004 23:04:12 -0400 From: Jonathan Rosenberg 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" Subject: Re: [Sipping-emergency] RE: Civil location syntax validation - wa s RE: How to handle Validation failures References: <7927C67249E4AD43BC05B539AF0D129801AF41E8@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF41E8@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: "'Marc Linsner'" , 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit inline. Peterson, Jon wrote: > So, just to make sure I understand, validation uses the same network > operation, basically, that would be used for a route query? > > Agreed that it should be possible for a route query to return 'I didn't > understand your address format', 'I understand your address and it isn't > actually valid', and so on beyond just the sunny-day case of returning the > route. Also, plus or minus some authorization and operational issues, I > agree that an ordinary user should be able to launch this sort of query > outside the context of an emergency call. I'm not so sure of that. It seems that there is a lot of very useful information in this database - which addresses exist, which do not, and information on the relative proximity of civil addresses to each other (two addresses that map to the same ERC would be "close" in some way). As a result, I feel that there are probably privacy implications of allowing worldwide open access to this database. Seems like it would be mined by spammers to validate mailing addresses, and used for all sorts of other nefarious purposes. Along those lines, I think it might be a good idea to sprinkle some nice words into the charter about taking into consideration privacy concerns, and properly balancing them with the needs of emergency call routing. -Jonathan R. -- 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 From sipping-emergency-bounces@ietf.org Tue Sep 28 23:56:53 2004 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 XAA22670 for ; Tue, 28 Sep 2004 23:56:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCViI-0003Ol-3L for sipping-emergency-web-archive@ietf.org; Wed, 29 Sep 2004 00:05:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCVYF-0003MI-PD; Tue, 28 Sep 2004 23:54:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCVWK-0002QJ-WF for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 23:52:51 -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 XAA22526 for ; Tue, 28 Sep 2004 23:52:46 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCVeF-0003Ap-Kh for sipping-emergency@ietf.org; Wed, 29 Sep 2004 00:01:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2004 21:05:41 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8T3q9wp023360; Tue, 28 Sep 2004 20:52:09 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA28705; Tue, 28 Sep 2004 20:52:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20040928223925.03466028@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Sep 2004 22:52:10 -0500 To: Jonathan Rosenberg , "Peterson, Jon" From: "James M. Polk" Subject: Privacy Concerns (was Re: [Sipping-emergency] RE: Civil location syntax validation - wa s RE: How to handle Validation failures) In-Reply-To: <415A262C.60904@dynamicsoft.com> References: <7927C67249E4AD43BC05B539AF0D129801AF41E8@stntexch04.cis.neustar.com> <7927C67249E4AD43BC05B539AF0D129801AF41E8@stntexch04.cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "'Marc Linsner'" , John Morris , 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 At 11:04 PM 9/28/2004 -0400, Jonathan Rosenberg wrote: >Along those lines, I think it might be a good idea to sprinkle some nice >words into the charter about taking into consideration privacy concerns, >and properly balancing them with the needs of emergency call routing. this is what I was referring to when I made the quip about being steered. I see this being a tracking capability. The phone (or multimedia device in general) has to obtain an address given by the network and test its deliverability to a government service before that device will potentially ever be used for any service (not just 911). This means to me that "the system" always knows where the device is (because it always delivers an accurate and valid address to it, and that device test pings for reachability and accuracy of the location it is given, on an ongoing basis). The periodic test ping/no-op packets ensuring a PSAP can be reached if a 911-type session is attempted has to reveal the return addressing, including each user's URI. This has huge hijacking and misuse potential written all over it, as Jonathan pointed out; not only in the database, but in the gleaning of packets to and from targets. >-Jonathan R. > >-- >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 cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Wed Sep 29 03:47:41 2004 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 DAA02445 for ; Wed, 29 Sep 2004 03:47:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCZJf-0007IJ-8g for sipping-emergency-web-archive@ietf.org; Wed, 29 Sep 2004 03:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCZ2A-0003kr-Tl; Wed, 29 Sep 2004 03:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCZ00-0003C4-4a for sipping-emergency@megatron.ietf.org; Wed, 29 Sep 2004 03:35:40 -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 DAA02094 for ; Wed, 29 Sep 2004 03:35:38 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCZ7z-00077m-LD for sipping-emergency@ietf.org; Wed, 29 Sep 2004 03:43:55 -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 i8T7YFPm014655; Wed, 29 Sep 2004 07:34:15 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Sep 2004 03:34:14 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41F2@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - wa s RE: How to handle Validation failures Date: Wed, 29 Sep 2004 03:34:10 -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.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "'Marc Linsner'" , 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Privacy concerns are one aspect of the authorization problem, sure. A lot of it depends on what sort of information is exchanged in the routing query. Realistically, I think that the revelation of the existence or non-existence of an address does not intrinsically have privacy implications. Proximity of addresses to one another is also, I believe, public information I could get from Yahoo! Maps or Mapquest or something, and is not intrinsically a source of privacy leakage. On the other hand, if you can use it to determine the name of the family that lives at a particular address, or something, then that's problematic. Either way, I suspect that there will probably be a business model associated with validation, and that people won't want to validate your address gratis at will. As such, I imagine that there may be some authorization policies surrounding all of this irrespective of privacy anyway. Of course, it makes sense to have some privacy text in the charter. It's easier for me to see how a route query outside the context of validation (for a real emergency call) has privacy implications. If validation is essentially indistinguishable from validation, then the protocol will have to provide the some privacy tools for both. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, September 28, 2004 8:04 PM > To: Peterson, Jon > Cc: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org > Subject: Re: [Sipping-emergency] RE: Civil location syntax > validation - > wa s RE: How to handle Validation failures > > > inline. > > Peterson, Jon wrote: > > > So, just to make sure I understand, validation uses the same network > > operation, basically, that would be used for a route query? > > > > Agreed that it should be possible for a route query to > return 'I didn't > > understand your address format', 'I understand your address > and it isn't > > actually valid', and so on beyond just the sunny-day case > of returning the > > route. Also, plus or minus some authorization and > operational issues, I > > agree that an ordinary user should be able to launch this > sort of query > > outside the context of an emergency call. > > I'm not so sure of that. > > It seems that there is a lot of very useful information in > this database > - which addresses exist, which do not, and information on the > relative > proximity of civil addresses to each other (two addresses that map to > the same ERC would be "close" in some way). As a result, I feel that > there are probably privacy implications of allowing worldwide open > access to this database. Seems like it would be mined by spammers to > validate mailing addresses, and used for all sorts of other nefarious > purposes. > > Along those lines, I think it might be a good idea to > sprinkle some nice > words into the charter about taking into consideration > privacy concerns, > and properly balancing them with the needs of emergency call routing. > > -Jonathan R. > > -- > 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 From sipping-emergency-bounces@ietf.org Wed Sep 29 07:47:33 2004 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 HAA23781 for ; Wed, 29 Sep 2004 07:47:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCd3o-00048Q-EK for sipping-emergency-web-archive@ietf.org; Wed, 29 Sep 2004 07:55:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCciZ-0002Y0-M7; Wed, 29 Sep 2004 07:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCcac-0000Ik-N4 for sipping-emergency@megatron.ietf.org; Wed, 29 Sep 2004 07:25:42 -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 HAA22127 for ; Wed, 29 Sep 2004 07:25:41 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from dpvc-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCcid-0003lV-Ml for sipping-emergency@ietf.org; Wed, 29 Sep 2004 07:34:00 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - was RE: How to handle Validation failures X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 29 Sep 2004 07:27:33 -0400 Message-ID: Thread-Topic: [Sipping-emergency] RE: Civil location syntax validation - was RE: How to handle Validation failures thread-index: AcSl+RLX+vORzh2URN6D/UKfVHVFSwAHJCZP To: "Peterson, Jon" , "Jonathan Rosenberg" X-Spam-Score: 1.1 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Marc Linsner , 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: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1961013583==" Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --===============1961013583== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmFsaWRhdGlvbiBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBzaG91bGQgb25seSBvY2N1ciBvbmNl LiBUaGlzIGhhcHBlbnMsIGluIHRoZSBjYXNlIG9mIGEgREhDUCBhc3NpZ25lZCBsb2NhdGlvbiBb ZHJhZnQtaWV0Zi1nZW9wcml2LWRoY3AtY2l2aWwtMDNdLCBiZWZvcmUgdGhlIGRldmljZSBldmVy IHJldHJpZXZlcyB0aGUgaW5mb3JtYXRpb24uIEkgYW0gbm90IHByb3Bvc2luZyBhIGNvbnRpdW91 cyBwaW5nIG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uIGFnYWluc3QgYSB2YWxpZGF0aW9uIGRhdGFi YXNlIGZyb20gdGhlIGRldmljZSBpdHNlbGYuIFJvdXRpbmcgaW5mb3JtYXRpb24gY291bGQgcm91 dGluZWx5IGJlIHRlc3RlZCBpbiB0aGUgYWJzZW5jZSBvZiBhbnkgZGV2aWNlIGFjdHVhbGx5IGhh dmluZyBsb2NhdGlvbiBhc3NvY2lhdGVkIHdpdGggaXQuIFRoaXMgY291bGQgYmUgYSByYW5kb20g c2VsZWN0aW9uIG9mIHByZS12YWxpZGF0ZWQgbG9jYXRpb25zIHVzaW5nIGtub3duIHJvdXRlcyB0 byB0aGUgRVJDIGZyb20gZGlmZmVyZW50IG9yaWdpbmF0aW9uIHBvaW50cyAodG8gdGhlIGV4dGVu dCBwb3NzaWJsZSAtIHBlcmhhcHMgYSB0ZXN0IHRvIGVuZCBwb2ludCB3aGVyZSBhIGRldmljZSBN QVkgcmVzaWRlIGFuZCB0aGVuIGEgdGVzdCB0byBFQ0MgZnJvbSB0aGUgc2FtZSB0ZXN0aW5nIG9y aWdpbmF0aW9uIHBvaW50IHVzaW5nIExPIGJhc2VkIHJvdXRpbmcgaW5mb3JtYXRpb24pLiBUaGUg b25seSB0aW1lIHRoYXQgdGhlIGxvY2F0aW9uIGdldHMgZGVsaXZlcmVkIGlzIGluIHRoZSBldmVu dCBvZiBhbiBlbWVyZ2VuY3kgY2FsbCBhbmQgdGhlbiBvbmx5IG9uY2UgYW5kIG9ubHkgdG8gdGhl IEVDQy4gT2YgY291cnNlLCBmb3IgbW9iaWxpdHkgdGhpcyB3b3VsZCBiZSBkaWZmZXJlbnQgYXMg Y29udGludW91cyB1cGRhdGVzIHNob3VsZCBvY2N1ciBkdXJpbmcgYW4gZW1lcmdlbmN5IGNhbGwg YmFzZWQgb24gZ2VvIGxvYyBvbmx5LiANCiANClJlY29udGFjdCBpbmZvcm1hdGlvbiBzaG91bGQg b25seSBiZSBzZW50IGR1cmluZyBlbWVyZ2VuY3kgY2FsbHMgYXMgd2VsbC4gUGVyc29uYWwgaW5m b3JtYXRpb24gdG8gdGhlIGV4dGVudCBwb3NzaWJsZSBtYXkgbmV2ZXIgYmUgc2VudC4NCiANCk5h dGUNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IFBldGVyc29uLCBKb24g W21haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXpdIA0KCVNlbnQ6IFdlZCA5LzI5LzIwMDQg MzozNCBBTSANCglUbzogJ0pvbmF0aGFuIFJvc2VuYmVyZycgDQoJQ2M6ICdNYXJjIExpbnNuZXIn OyBzaXBwaW5nLWVtZXJnZW5jeUBpZXRmLm9yZyANCglTdWJqZWN0OiBSRTogW1NpcHBpbmctZW1l cmdlbmN5XSBSRTogQ2l2aWwgbG9jYXRpb24gc3ludGF4IHZhbGlkYXRpb24gLSB3YXMgUkU6IEhv dyB0byBoYW5kbGUgVmFsaWRhdGlvbiBmYWlsdXJlcw0KCQ0KCQ0KDQoJUHJpdmFjeSBjb25jZXJu cyBhcmUgb25lIGFzcGVjdCBvZiB0aGUgYXV0aG9yaXphdGlvbiBwcm9ibGVtLCBzdXJlLiBBIGxv dCBvZg0KCWl0IGRlcGVuZHMgb24gd2hhdCBzb3J0IG9mIGluZm9ybWF0aW9uIGlzIGV4Y2hhbmdl ZCBpbiB0aGUgcm91dGluZyBxdWVyeS4NCglSZWFsaXN0aWNhbGx5LCBJIHRoaW5rIHRoYXQgdGhl IHJldmVsYXRpb24gb2YgdGhlIGV4aXN0ZW5jZSBvciBub24tZXhpc3RlbmNlDQoJb2YgYW4gYWRk cmVzcyBkb2VzIG5vdCBpbnRyaW5zaWNhbGx5IGhhdmUgcHJpdmFjeSBpbXBsaWNhdGlvbnMuIFBy b3hpbWl0eSBvZg0KCWFkZHJlc3NlcyB0byBvbmUgYW5vdGhlciBpcyBhbHNvLCBJIGJlbGlldmUs IHB1YmxpYyBpbmZvcm1hdGlvbiBJIGNvdWxkIGdldA0KCWZyb20gWWFob28hIE1hcHMgb3IgTWFw cXVlc3Qgb3Igc29tZXRoaW5nLCBhbmQgaXMgbm90IGludHJpbnNpY2FsbHkgYSBzb3VyY2UNCglv ZiBwcml2YWN5IGxlYWthZ2UuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB5b3UgY2FuIHVzZSBpdCB0 byBkZXRlcm1pbmUgdGhlDQoJbmFtZSBvZiB0aGUgZmFtaWx5IHRoYXQgbGl2ZXMgYXQgYSBwYXJ0 aWN1bGFyIGFkZHJlc3MsIG9yIHNvbWV0aGluZywgdGhlbg0KCXRoYXQncyBwcm9ibGVtYXRpYy4N CgkNCglFaXRoZXIgd2F5LCBJIHN1c3BlY3QgdGhhdCB0aGVyZSB3aWxsIHByb2JhYmx5IGJlIGEg YnVzaW5lc3MgbW9kZWwNCglhc3NvY2lhdGVkIHdpdGggdmFsaWRhdGlvbiwgYW5kIHRoYXQgcGVv cGxlIHdvbid0IHdhbnQgdG8gdmFsaWRhdGUgeW91cg0KCWFkZHJlc3MgZ3JhdGlzIGF0IHdpbGwu IEFzIHN1Y2gsIEkgaW1hZ2luZSB0aGF0IHRoZXJlIG1heSBiZSBzb21lDQoJYXV0aG9yaXphdGlv biBwb2xpY2llcyBzdXJyb3VuZGluZyBhbGwgb2YgdGhpcyBpcnJlc3BlY3RpdmUgb2YgcHJpdmFj eQ0KCWFueXdheS4NCgkNCglPZiBjb3Vyc2UsIGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgc29tZSBw cml2YWN5IHRleHQgaW4gdGhlIGNoYXJ0ZXIuIEl0J3MNCgllYXNpZXIgZm9yIG1lIHRvIHNlZSBo b3cgYSByb3V0ZSBxdWVyeSBvdXRzaWRlIHRoZSBjb250ZXh0IG9mIHZhbGlkYXRpb24NCgkoZm9y IGEgcmVhbCBlbWVyZ2VuY3kgY2FsbCkgaGFzIHByaXZhY3kgaW1wbGljYXRpb25zLiBJZiB2YWxp ZGF0aW9uIGlzDQoJZXNzZW50aWFsbHkgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSB2YWxpZGF0aW9u LCB0aGVuIHRoZSBwcm90b2NvbCB3aWxsIGhhdmUNCgl0byBwcm92aWRlIHRoZSBzb21lIHByaXZh Y3kgdG9vbHMgZm9yIGJvdGguDQoJDQoJSm9uIFBldGVyc29uDQoJTmV1U3RhciwgSW5jLg0KCQ0K CT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+IEZyb206IEpvbmF0aGFuIFJvc2VuYmVy ZyBbbWFpbHRvOmpkcm9zZW5AZHluYW1pY3NvZnQuY29tXQ0KCT4gU2VudDogVHVlc2RheSwgU2Vw dGVtYmVyIDI4LCAyMDA0IDg6MDQgUE0NCgk+IFRvOiBQZXRlcnNvbiwgSm9uDQoJPiBDYzogJ0Jy aWFuIFJvc2VuJzsgJ01hcmMgTGluc25lcic7IHNpcHBpbmctZW1lcmdlbmN5QGlldGYub3JnDQoJ PiBTdWJqZWN0OiBSZTogW1NpcHBpbmctZW1lcmdlbmN5XSBSRTogQ2l2aWwgbG9jYXRpb24gc3lu dGF4DQoJPiB2YWxpZGF0aW9uIC0NCgk+IHdhIHMgUkU6IEhvdyB0byBoYW5kbGUgVmFsaWRhdGlv biBmYWlsdXJlcw0KCT4NCgk+DQoJPiBpbmxpbmUuDQoJPg0KCT4gUGV0ZXJzb24sIEpvbiB3cm90 ZToNCgk+DQoJPiA+IFNvLCBqdXN0IHRvIG1ha2Ugc3VyZSBJIHVuZGVyc3RhbmQsIHZhbGlkYXRp b24gdXNlcyB0aGUgc2FtZSBuZXR3b3JrDQoJPiA+IG9wZXJhdGlvbiwgYmFzaWNhbGx5LCB0aGF0 IHdvdWxkIGJlIHVzZWQgZm9yIGEgcm91dGUgcXVlcnk/DQoJPiA+DQoJPiA+IEFncmVlZCB0aGF0 IGl0IHNob3VsZCBiZSBwb3NzaWJsZSBmb3IgYSByb3V0ZSBxdWVyeSB0bw0KCT4gcmV0dXJuICdJ IGRpZG4ndA0KCT4gPiB1bmRlcnN0YW5kIHlvdXIgYWRkcmVzcyBmb3JtYXQnLCAnSSB1bmRlcnN0 YW5kIHlvdXIgYWRkcmVzcw0KCT4gYW5kIGl0IGlzbid0DQoJPiA+IGFjdHVhbGx5IHZhbGlkJywg YW5kIHNvIG9uIGJleW9uZCBqdXN0IHRoZSBzdW5ueS1kYXkgY2FzZQ0KCT4gb2YgcmV0dXJuaW5n IHRoZQ0KCT4gPiByb3V0ZS4gQWxzbywgcGx1cyBvciBtaW51cyBzb21lIGF1dGhvcml6YXRpb24g YW5kDQoJPiBvcGVyYXRpb25hbCBpc3N1ZXMsIEkNCgk+ID4gYWdyZWUgdGhhdCBhbiBvcmRpbmFy eSB1c2VyIHNob3VsZCBiZSBhYmxlIHRvIGxhdW5jaCB0aGlzDQoJPiBzb3J0IG9mIHF1ZXJ5DQoJ PiA+IG91dHNpZGUgdGhlIGNvbnRleHQgb2YgYW4gZW1lcmdlbmN5IGNhbGwuDQoJPg0KCT4gSSdt IG5vdCBzbyBzdXJlIG9mIHRoYXQuDQoJPg0KCT4gSXQgc2VlbXMgdGhhdCB0aGVyZSBpcyBhIGxv dCBvZiB2ZXJ5IHVzZWZ1bCBpbmZvcm1hdGlvbiBpbg0KCT4gdGhpcyBkYXRhYmFzZQ0KCT4gLSB3 aGljaCBhZGRyZXNzZXMgZXhpc3QsIHdoaWNoIGRvIG5vdCwgYW5kIGluZm9ybWF0aW9uIG9uIHRo ZQ0KCT4gcmVsYXRpdmUNCgk+IHByb3hpbWl0eSBvZiBjaXZpbCBhZGRyZXNzZXMgdG8gZWFjaCBv dGhlciAodHdvIGFkZHJlc3NlcyB0aGF0IG1hcCB0bw0KCT4gdGhlIHNhbWUgRVJDIHdvdWxkIGJl ICJjbG9zZSIgaW4gc29tZSB3YXkpLiBBcyBhIHJlc3VsdCwgSSBmZWVsIHRoYXQNCgk+IHRoZXJl IGFyZSBwcm9iYWJseSBwcml2YWN5IGltcGxpY2F0aW9ucyBvZiBhbGxvd2luZyB3b3JsZHdpZGUg b3Blbg0KCT4gYWNjZXNzIHRvIHRoaXMgZGF0YWJhc2UuIFNlZW1zIGxpa2UgaXQgd291bGQgYmUg bWluZWQgYnkgc3BhbW1lcnMgdG8NCgk+IHZhbGlkYXRlIG1haWxpbmcgYWRkcmVzc2VzLCBhbmQg dXNlZCBmb3IgYWxsIHNvcnRzIG9mIG90aGVyIG5lZmFyaW91cw0KCT4gcHVycG9zZXMuDQoJPg0K CT4gQWxvbmcgdGhvc2UgbGluZXMsIEkgdGhpbmsgaXQgbWlnaHQgYmUgYSBnb29kIGlkZWEgdG8N Cgk+IHNwcmlua2xlIHNvbWUgbmljZQ0KCT4gd29yZHMgaW50byB0aGUgY2hhcnRlciBhYm91dCB0 YWtpbmcgaW50byBjb25zaWRlcmF0aW9uDQoJPiBwcml2YWN5IGNvbmNlcm5zLA0KCT4gYW5kIHBy b3Blcmx5IGJhbGFuY2luZyB0aGVtIHdpdGggdGhlIG5lZWRzIG9mIGVtZXJnZW5jeSBjYWxsIHJv dXRpbmcuDQoJPg0KCT4gLUpvbmF0aGFuIFIuDQoJPg0KCT4gLS0NCgk+IEpvbmF0aGFuIEQuIFJv c2VuYmVyZywgUGguRC4gICAgICAgICAgICAgICAgNjAwIExhbmlkZXggUGxhemENCgk+IENoaWVm IFRlY2hub2xvZ3kgT2ZmaWNlciAgICAgICAgICAgICAgICAgICAgUGFyc2lwcGFueSwgTkogMDcw NTQtMjcxMQ0KCT4gZHluYW1pY3NvZnQNCgk+IGpkcm9zZW5AZHluYW1pY3NvZnQuY29tICAgICAg ICAgICAgICAgICAgICAgRkFYOiAgICg5NzMpIDk1Mi01MDUwDQoJPiBodHRwOi8vd3d3Lmpkcm9z ZW4ubmV0ICAgICAgICAgICAgICAgICAgICAgIFBIT05FOiAoOTczKSA5NTItNTAwMA0KCT4gaHR0 cDovL3d3dy5keW5hbWljc29mdC5jb20NCgk+DQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCglTaXBwaW5nLWVtZXJnZW5jeSBtYWlsaW5nIGxpc3QN CglTaXBwaW5nLWVtZXJnZW5jeUBpZXRmLm9yZw0KCWh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcHBpbmctZW1lcmdlbmN5DQoJDQoJDQoJDQoNCg== --===============1961013583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency --===============1961013583==-- From sipping-emergency-bounces@ietf.org Wed Sep 29 09:15:31 2004 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 JAA01073 for ; Wed, 29 Sep 2004 09:15:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCeQx-0006Db-Lr for sipping-emergency-web-archive@ietf.org; Wed, 29 Sep 2004 09:23:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCeAj-0004OU-KZ; Wed, 29 Sep 2004 09:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdsj-0000nf-U6 for sipping-emergency@megatron.ietf.org; Wed, 29 Sep 2004 08:48:30 -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 IAA28838 for ; Wed, 29 Sep 2004 08:48:28 -0400 (EDT) Received: from [12.35.60.98] (helo=IPOfCard1.guest-tek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCe0c-0005dF-5h for sipping-emergency@ietf.org; Wed, 29 Sep 2004 08:56:48 -0400 Received: from BROSENLT ([172.18.1.253]) by IPOfCard1.guest-tek.com (8.11.6/8.11.6) with ESMTP id i8TCQ3Z04171; Wed, 29 Sep 2004 08:26:04 -0400 Message-Id: <200409291226.i8TCQ3Z04171@IPOfCard1.guest-tek.com> From: "Brian Rosen" To: , "'Peterson, Jon'" , "'Jonathan Rosenberg'" Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - wasRE: How to handle Validation failures Date: Wed, 29 Sep 2004 08:45:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSl+RLX+vORzh2URN6D/UKfVHVFSwAHJCZPAAKuMmA= X-Spam-Score: 0.8 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: "'Marc Linsner'" , 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: 7bit I think it should be POSSIBLE for a user at a UA to determine if the address he has is valid. Normally, the address will come from a source that is pretty reliable, assuming you trust the last mile provider, and should be validated prior to use. Since there are many such last mile providers, and quite a few "Master Street Address Guides" a standardized mechanism is required. Jon is correct; all we need is an error return from the mechanism that determines route from location. Again, since there are multiple entities that need to get this information, and multiple entities that supply the information, a protocol is needed. I agree that privacy concerns are real, and should be mentioned in the charter. James' concern about location reported in geo is easily dealt with. The point of validation is to make sure that the reported location is dispatchable - a responder can be directed to that location and will be able to find the person in need of help. Geospatial coordinates are precise, with no ambiguity of the sort that gives rise to the validation concern for civic addresses. To be sure, you have to convert geo to civil to do the dispatch, which is yet another problem I think we must solve, and that conversion must be accurate enough to yield a valid civic address, but for the purposes of this discussion, a location reported in geo form does not need to be validated. Brian > -----Original Message----- > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > bounces@ietf.org] On Behalf Of wilcox@e911.psd.state.vt.us > Sent: Wednesday, September 29, 2004 7:28 AM > To: Peterson, Jon; Jonathan Rosenberg > Cc: Marc Linsner; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - > wasRE: How to handle Validation failures > > Validation of location information should only occur once. This happens, > in the case of a DHCP assigned location [draft-ietf-geopriv-dhcp-civil- > 03], before the device ever retrieves the information. I am not proposing > a contiuous ping of location information against a validation database > from the device itself. Routing information could routinely be tested in > the absence of any device actually having location associated with it. > This could be a random selection of pre-validated locations using known > routes to the ERC from different origination points (to the extent > possible - perhaps a test to end point where a device MAY reside and then > a test to ECC from the same testing origination point using LO based > routing information). The only time that the location gets delivered is in > the event of an emergency call and then only once and only to the ECC. Of > course, for mobility this would be different as continuous updates should > occur during an emergency call based on geo loc only. > > Recontact information should only be sent during emergency calls as well. > Personal information to the extent possible may never be sent. > > Nate > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Wed 9/29/2004 3:34 AM > To: 'Jonathan Rosenberg' > Cc: 'Marc Linsner'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] RE: Civil location syntax > validation - was RE: How to handle Validation failures > > > > Privacy concerns are one aspect of the authorization problem, sure. > A lot of > it depends on what sort of information is exchanged in the routing > query. > Realistically, I think that the revelation of the existence or non- > existence > of an address does not intrinsically have privacy implications. > Proximity of > addresses to one another is also, I believe, public information I > could get > from Yahoo! Maps or Mapquest or something, and is not intrinsically > a source > of privacy leakage. On the other hand, if you can use it to > determine the > name of the family that lives at a particular address, or something, > then > that's problematic. > > Either way, I suspect that there will probably be a business model > associated with validation, and that people won't want to validate > your > address gratis at will. As such, I imagine that there may be some > authorization policies surrounding all of this irrespective of > privacy > anyway. > > Of course, it makes sense to have some privacy text in the charter. > It's > easier for me to see how a route query outside the context of > validation > (for a real emergency call) has privacy implications. If validation > is > essentially indistinguishable from validation, then the protocol > will have > to provide the some privacy tools for both. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, September 28, 2004 8:04 PM > > To: Peterson, Jon > > Cc: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org > > Subject: Re: [Sipping-emergency] RE: Civil location syntax > > validation - > > wa s RE: How to handle Validation failures > > > > > > inline. > > > > Peterson, Jon wrote: > > > > > So, just to make sure I understand, validation uses the same > network > > > operation, basically, that would be used for a route query? > > > > > > Agreed that it should be possible for a route query to > > return 'I didn't > > > understand your address format', 'I understand your address > > and it isn't > > > actually valid', and so on beyond just the sunny-day case > > of returning the > > > route. Also, plus or minus some authorization and > > operational issues, I > > > agree that an ordinary user should be able to launch this > > sort of query > > > outside the context of an emergency call. > > > > I'm not so sure of that. > > > > It seems that there is a lot of very useful information in > > this database > > - which addresses exist, which do not, and information on the > > relative > > proximity of civil addresses to each other (two addresses that map > to > > the same ERC would be "close" in some way). As a result, I feel > that > > there are probably privacy implications of allowing worldwide open > > access to this database. Seems like it would be mined by spammers > to > > validate mailing addresses, and used for all sorts of other > nefarious > > purposes. > > > > Along those lines, I think it might be a good idea to > > sprinkle some nice > > words into the charter about taking into consideration > > privacy concerns, > > and properly balancing them with the needs of emergency call > routing. > > > > -Jonathan R. > > > > -- > > 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 > > > _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Wed Sep 29 09:57:33 2004 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 JAA04955 for ; Wed, 29 Sep 2004 09:57:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCf5d-0007Dp-Ne for sipping-emergency-web-archive@ietf.org; Wed, 29 Sep 2004 10:05:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCekV-0003lW-D9; Wed, 29 Sep 2004 09:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCeY7-00012R-JI for sipping-emergency@megatron.ietf.org; Wed, 29 Sep 2004 09:31:15 -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 JAA02351 for ; Wed, 29 Sep 2004 09:31:13 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCeg9-0006WK-7Q for sipping-emergency@ietf.org; Wed, 29 Sep 2004 09:39:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Sep 2004 06:44:13 +0000 X-BrightmailFiltered: true Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8TDUdwp016614; Wed, 29 Sep 2004 06:30:39 -0700 (PDT) Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA11480; Wed, 29 Sep 2004 06:30:38 -0700 (PDT) From: "Marc Linsner" To: "'Jonathan Rosenberg'" , "'Peterson, Jon'" Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - wa s RE: How to handle Validation failures Date: Wed, 29 Sep 2004 09:30:40 -0400 Message-ID: <000201c4a628$83fb6590$8501a8c0@mlinsnerzk7abh> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <415A262C.60904@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Jonathan, In-line..... > > Peterson, Jon wrote: > > > So, just to make sure I understand, validation uses the > same network > > operation, basically, that would be used for a route query? > > > > Agreed that it should be possible for a route query to return 'I > > didn't understand your address format', 'I understand your > address and > > it isn't actually valid', and so on beyond just the > sunny-day case of > > returning the route. Also, plus or minus some authorization and > > operational issues, I agree that an ordinary user should be able to > > launch this sort of query outside the context of an emergency call. > > I'm not so sure of that. > > It seems that there is a lot of very useful information in > this database > - which addresses exist, which do not, and information on the > relative > proximity of civil addresses to each other (two addresses that map to > the same ERC would be "close" in some way). As a result, I feel that > there are probably privacy implications of allowing worldwide open > access to this database. Seems like it would be mined by spammers to > validate mailing addresses, and used for all sorts of other nefarious > purposes. > > Along those lines, I think it might be a good idea to > sprinkle some nice > words into the charter about taking into consideration > privacy concerns, > and properly balancing them with the needs of emergency call routing. > > -Jonathan R. > If you don't open up the ability to view the civil address routing information, including the ability to 'mine' the address information, the alternative would be to create a for-fee service to gain access to this public information. I suggest you look at and play with: http://zip4.usps.com/zip4/welcome.jsp In your example, spammers would love this site. Street addresses are already public information that is freely available. -Marc Linsner- _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency From sipping-emergency-bounces@ietf.org Wed Sep 29 10:11:54 2004 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 KAA06544 for ; Wed, 29 Sep 2004 10:11:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCfJW-0007Tz-F1 for sipping-emergency-web-archive@ietf.org; Wed, 29 Sep 2004 10:20:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCf8D-0002p0-67; Wed, 29 Sep 2004 10:08:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCepI-0004qn-JT for sipping-emergency@megatron.ietf.org; Wed, 29 Sep 2004 09:49:00 -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 JAA04016 for ; Wed, 29 Sep 2004 09:48:58 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCexH-0006zH-La for sipping-emergency@ietf.org; Wed, 29 Sep 2004 09:57:19 -0400 Received: from razor.cs.columbia.edu (IDENT:b4ygcz3IZnqchUjzSP8ndYjgPTwFsMIG@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TDm9x6021357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 29 Sep 2004 09:48:10 -0400 (EDT) Received: from [127.0.0.1] (IDENT:af7CganCtc4LNkFeZnbmDPgHxeYo38wN@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TDm4YZ031119; Wed, 29 Sep 2004 09:48:05 -0400 Message-ID: <415ABD15.8060404@cs.columbia.edu> Date: Wed, 29 Sep 2004 09:48:05 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sipping-emergency] RE: Civil location syntax validation - wasRE: How to handle Validation failures References: <200409291226.i8TCQ3Z04171@IPOfCard1.guest-tek.com> In-Reply-To: <200409291226.i8TCQ3Z04171@IPOfCard1.guest-tek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.28.8 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: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: sipping-emergency@ietf.org, "'Jonathan Rosenberg'" , wilcox@e911.psd.state.vt.us, "'Marc Linsner'" X-BeenThere: sipping-emergency@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: sipping-emergency.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-emergency-bounces@ietf.org Errors-To: sipping-emergency-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit > conversion must be accurate enough to yield a valid civic address, but for > the purposes of this discussion, a location reported in geo form does not > need to be validated. In some cases, it is helpful if the user can easily do a sanity check on the geo location. It is useful to know if my current geo location puts me, due to some technical error like a big-endian/little-endian snafu or a confusion of longitude and latitude, in Africa instead of New York. _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency