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:38 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 UAA09462 for <sipping-emergency-web-archive@ietf.org>; 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 <sipping-emergency@ietf.org>; 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 <hgs@cs.columbia.edu>, wilcox@e911.psd.state.vt.us
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: <41595926.4040002@cs.columbia.edu>
References: <B4D8D0C58294F54DA9DB6C6A9AEF38502A971F@artemis.vt911.local> <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: 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: <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: 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