[Sipping] comments on draft-schulzrinne-sipping-emergency-arch

"Drage, Keith (Keith)" <drage@lucent.com> Mon, 01 March 2004 02:28 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24879 for <sipping-archive@odin.ietf.org>; Sun, 29 Feb 2004 21:28:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd9a-0005Zh-67 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:27:34 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212RYkI021430 for sipping-archive@odin.ietf.org; Sun, 29 Feb 2004 21:27:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd9Z-0005ZZ-NH for sipping-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:27:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24873 for <sipping-web-archive@ietf.org>; Sun, 29 Feb 2004 21:27:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd9X-0007bk-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:27:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd8g-0007V5-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:26:39 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axd86-0007Nk-00 for sipping-web-archive@ietf.org; Sun, 29 Feb 2004 21:26:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd87-00054E-KP; Sun, 29 Feb 2004 21:26:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd7Y-00052h-I1 for sipping@optimus.ietf.org; Sun, 29 Feb 2004 21:25:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24737 for <sipping@ietf.org>; Sun, 29 Feb 2004 21:25:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axd7V-0007Ks-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:25:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axd6e-0007Ei-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:24:33 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Axd65-00078k-00 for sipping@ietf.org; Sun, 29 Feb 2004 21:23:57 -0500
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i212NPr29249 for <sipping@ietf.org>; Sun, 29 Feb 2004 20:23:25 -0600 (CST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CK1JBG>; Mon, 1 Mar 2004 02:23:24 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00B3EF82C@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: sipping@ietf.org
Date: Mon, 01 Mar 2004 02:23:23 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [Sipping] comments on draft-schulzrinne-sipping-emergency-arch
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60

In general, I am happy with this draft, but in reading it, I did have a few specific comments.

1)	Section 3 (Terminology). I am confused here, and in the rest of the document, about the distinction between ECC and PSAP. I think the issue here is that as defined by the associated text, these are actually different concepts in some countries, yet the text goes on to say that in USA, PSAP is the ECC. Maybe we need to clarify.

2)	Section 5.2. Mobile systems, possible in conjunction with the cell site location, may also transmit mobile country code and mobile network code of the host network. This MCC and MNC in itself does constitute location information, in that it tells that the user (with border constraints) is in a particular country) - which may be sufficient itself for determining the ECC to be used.

3)	Section 5.3. Somewhere around here, for any particular emergency call, we need to identify that it is possible to have multiple elements of location information generated by different entities involved in the call (e.g. terminal generated, outbound proxy generated, etc.). We need a statement that each location can be added to the call information, and that one does not overwrite another. It is up to the ECC to decide which (if any) location it wishes to believe, possibly in association with any location from the end user received via the media path.

4)	Section 5.4. Where information is delivered later, do we need an indicator within the INVITE that such information may be available later in the call? What is the mechanism for providing information later in the call (push or pull), i.e. is additional information just sent later in the dialog in another request, or does the location gathering entity indicate the availability of new information which can then be fetched.

5)	Section 7. This section seems to assume sips. As this is apparently a hop-by-hop mechanism, what is wrong with depending on any hop by hop security mechanism, e.g. IPsec - why does it have to be SIPs.

6)	Section 9. In addition to the generic mechanism mentioned here, there may be access transport specific mechanisms for downloading this information to the UE. For example, a 3GPP phone from release 5 onwards can have this information downloaded from visited network entities at network registration time. The existence of these mechanisms should be acknowledged in the document at this point.

regards

Keith

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP