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

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 28 September 2004 12:44 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 IAA18510 for <sipping-emergency-web-archive@ietf.org>; 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 <sipping-emergency@ietf.org>; 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 <hgs@cs.columbia.edu>
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: <B4D8D0C58294F54DA9DB6C6A9AEF38502A971F@artemis.vt911.local>
In-Reply-To: <B4D8D0C58294F54DA9DB6C6A9AEF38502A971F@artemis.vt911.local>
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: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 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