[dispatch] draft-winterbottom-dispatch-locparam

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 22 July 2015 09:16 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 19B971AD0A7 for <dispatch@ietfa.amsl.com>; Wed, 22 Jul 2015 02:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YJ_KS7gXWDIx for <dispatch@ietfa.amsl.com>; Wed, 22 Jul 2015 02:16:55 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A391AD0A5 for <dispatch@ietf.org>; Wed, 22 Jul 2015 02:16:55 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown []) by Websense Email Security Gateway with ESMTPS id 70A7BA54C050D for <dispatch@ietf.org>; Wed, 22 Jul 2015 09:16:51 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com []) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6M9GqE0024158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dispatch@ietf.org>; Wed, 22 Jul 2015 11:16:52 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 11:16:52 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: draft-winterbottom-dispatch-locparam
Thread-Index: AdDEXyQD/iDurzCzTN+VcVMxRrjtLw==
Date: Wed, 22 Jul 2015 09:16:51 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B697490B9@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/fu2PARdhuDugTfr-vinvW0AUUxI>
Subject: [dispatch] draft-winterbottom-dispatch-locparam
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 09:16:57 -0000

Issues from the dispatch meeting discussion:

1)	In regard to trust, what is needed is a mechanism to meet the following from the EC mandate:

". The enhancement, i.e. location data provision, is expected to be determined by the originating telephony or electronic communications service provider, capable of originating voice calls through a number or numbers in national telephone numbering plans, and be provided at call setup to the PSAP as soon as the call reaches the authority handling the emergency calls."

The proposal in the document is that the recipient of a SIP request will either know that the entity that sent or proxied the SIP request is either an "originating telephony or electronic communications service provider" or trusts that entity to make a proper discrimination of that.

Relying on certificates or known domain names would require PSAPs and networks routeing emergency calls to have a maintained database of all known "originating telephony or electronic communications service provider" worldwide.

2)	The question was raised as to whether it should be specific for emergency call. I see no reason why it should be. It does not interfere with the location itself, or the privacy of the location itself. Further, I have a concern of any protocol mechanism that is emergency call specific, as it never gets tested until one wants to make an emergency call.

3)	I believe Cullen mentioned privacy, but I am not sure in what context. The mechanism does not interfere with any of the privacy requirements defined for the Geolocation header field. Further if the trust in 1) above is not met, it is only the parameter that is removed, not the Geolocation header field itself.