RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency

"James M. Polk" <jmpolk@cisco.com> Wed, 29 September 2004 00:32 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09037 for <sipping-emergency-web-archive@ietf.org>; 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 <sipping-emergency@ietf.org>; 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" <jon.peterson@neustar.biz>, Brian Rosen <br@brianrosen.net>, Marc Linsner <mlinsner@cisco.com>, sipping-emergency@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency
In-Reply-To: <B4D8D0C58294F54DA9DB6C6A9AEF38502A971F@artemis.vt911.local >
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: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 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